AcoustID issue


I am using Picard 2.6.3 on Windows 10. I am currently tagging all my CD collection which I have ripped to flac. I had a strange glitch with one particular album: all tracks are correctly identified except one. Of course, I can match it manually (and it works perfectly), but I’d like to understand what is wrong here.

This happens in the Genesis album Seconds Out, track Dance on a Volcano. the analysis triggers downloading the album data, but Picard never matches this track automatically. After manual matching, Picard does not say the AcoustID should be saved. The track is 8:23 long so this is not a duration issue. I notice this message on several tracks of this album: “No file with matching trackid - IF THERE SHOULD BE ONE, TRY ‘REFRESH’ - (unable to process any saved options, lyrics or ‘keep’ tags)”. Then I notice that there is no AcoustID for this track. This is probably what is wrong about this track. I tried using Scan and Generate AcoustID, but nothing seems to work.

Why can’t Picard set an AcoustID to this track? And what can I do about it?

Right now AcoustID has some problem. Maybe it’s connected


Picard successfully calculated and stored the AcoustIDs for the 11 other tracks and repeatedly refused to set one for this one, but maybe your explanation is the correct one. If nobody has a better explanation, I’ll try again in a few days.

I tried again this evening, same results: Picard refuses to record the AcoustID for this track. All in all, I processed 9200 flac files in Picard. 183 don’t have an AcoustID (from which a dozen [blank] & [silence] should be removed). This issue impacts a few full albums, but also many isolated tracks such as this one from the Genesis album.

Does anyone have an idea what is going on?

“Short” tracks are ignored by the AcoustID server and will not return a fingerprint. I have some 6-second AcoustIDs, but many more 15-second tracks that can’t get an ID.

A miniscule percentage of previously submitted fingerprints of valid track durations cannot be found in Picard Scan, even though MusicBrainz will show a link to an AcoustID. I don’t know that there’s ever been any communication as to why this is happening. It would be difficult to confirm that your audio actually matches that AcoustID_ID since there is at least one layer of abstraction between fpcalc and AcoustID_ID.

Which release version have you exactly? (remastered, original holland,…)

Looked a bit more and not sure same issue but I noticed that

Contributed fingerprints for (before issue happened)

Then some are still not shown on recordings:

  1. Recording “Do I Care? No, No” by Cab Calloway and His Orchestra - Fingerprints - MusicBrainz
  2. Recording “Who’s Yehoodi?” by Cab Calloway and His Orchestra - Fingerprints - MusicBrainz

Opening fingerprints pages on directly from Picard they appear:

  1. Track "dbfa0b9f-30b4-4dcf-82bb-8749c7708786" | AcoustID
  2. Track "c3279a2d-3aab-45da-942f-7292ebd90189" | AcoustID

But the recordings listed have different IDs that the ones ones listed in Picard.

  1. 2c149e2a-85df-43f9-9546-99141925d491 in Picard but df1d49f8-bec7-44dc-8a42-d69fbbfc3b86 in AcoustID
  2. be5f1067-aea6-46e8-986c-3e67891a97ae in Picard but df1d49f8-bec7-44dc-8a42-d69fbbfc3b86 in AcoustID

Also one difference between those 2 examples:

  1. When clicking on recording from Acoust.ID page it displays Recording not found
  2. When clicking on recording from Acoust.ID page it displays the correct Recording

It seems like there is an issue to link to correct recording when merged/unmerged happened on them.

PS: If it can helps: Edits for Do I Care? No, No - MusicBrainz
I unmerged those 2 tracks from their previous recordings via the Edit release/Recordings page as they were linked to the wrong takes
Then for:

  1. No more action (rare take not available on other releases)
  2. Merged this newly created recording to another one (found other releases with same take)

Among the 183 tracks without AcoustID, there are certainly a few short tracks. You are right, I’d have to check this too. But the Genesis track is more than 8 minutes long, so track length is certainly not the explanation here.

I checked, there is no AcoustID in the file after processing with Picard. I can ask Picard to generate one, it displays the little red fingerprint as if the AcoustID was generated, but no AcoustID tag appears in the lower pane and after clicking on “Save” and on “Send AcoustIDs”, the saved flac file still contains no AcoustID tag.

Sorry, the idea of ripping my CDs was to store them in the cellar. I’ll try to fetch them in a few days to get more specific data.

If you use “Generate fingerprints” Picard runs fpcalc on the file to calculate the fingerprint, which you can then submit ( and the red icon indicates that this worked). It does not do an online lookup for an AcoustID.

Use “Scan” to make a lookup rewuest for matching AcoustIDs. What exactly happens if you run Scan on the file?

Is this why some of my tracks won’t return any fingerprints?

Although I can’t detect any AcoustID in the FLAC file, when I drag it in Picard, Picard automatically fetches the album from MusicBraiz and shows the track with the little green rectangle. If I drag the whole album folder, Picard fetches the album too, but all tracks are checked except the “bad” one which has a green rectangle. Then I can drag the lot back to the left pane.

Picard was in French, I switched Picard to English and exited. When I reopened Picard and dragged the album’s flac files into it, Picard fetched the album data from MusicBrainz but this time all tracks had a rectangle except Dance on a Volcano which has a check mark.

Anyhow, pressing on Scan on this file only makes the red fingerprint appear but does not fetch the album data if I previously removed it and I can see briefly a message “No matching tracks for the file (…)”.

Following Comrade_Mike’s comment, I would have checked too, but since Picard does not show me any AcoustID for that track, I can’t.

Picard will by default automatically match files to releases if the files contain release and recording IDs to allow for updating tags in previously tagged files.

So this either means there is no AcoustID matching your files fingerprint or Picard is not confident enough to match the file to any of the suggested recordings because the existing metadata differs significantly. You can try some of the following:

  • To check if badly matching metadata is the fault lower the value for “Minimal similarity for matching files to tracks” in Options > Advanced > Matching. The default is 40%, as a test try 0% and scan again
  • You can match the file manually, generate the fingerprint and submit it, then check a while later if it now gets detected with Scan. I don’t know how well AcoustID submissions currently work and how long to the delay for processing is.
  • Manually run fpcalc on the file from command line with fpcalc /path/to/file. It will output the fingerprint, it you post the output here I can check if AcoustID actually returns a result.
  • or enable debug mode in Help > View Error/Debug Log , run Scan on the file and post the log output here

If you scan or generate a AcoustID from an mp3 and it finds it shouldn’t Picard add it to the file as a tag even if that AcoustID isn’t tied to any release? This isn’t happening to me or it’s very inconsistent/unclear…

I tried scanning some files and then generating and then seemingly there is zero results or response from anything but when I go into the log and scroll around I can see that Picard did get a response from AcoustID and it did get a fingerprint but that doesn’t seem to matter or impact me or my music files even though you might assume it would.

Could you please show us this lines? (PrintScreen? Copy & paste the lines as code?)


D: 13:12:49,007 webservice\ratecontrol.get_delay_to_next_request:113: ('', 443): First request
D: 13:12:49,008 webservice\ratecontrol.increment_requests:138: ('', 443): Incrementing requests to: 1
D: 13:12:49,335 webservice\ratecontrol.decrement_requests:146: ('', 443): Decrementing requests to: 0
D: 13:12:49,335 webservice\__init__._handle_reply:486: Received reply for HTTP 200 (OK)
D: 13:12:49,335 webservice\__init__._handle_reply:495: Response received: {'results': [{'id': '2cd56c4c-70b8-422f-b043-b581f4b3cfec', 'score': 0.999852}], 'status': 'ok'}
D: 13:12:49,338 acoustid\__init__._on_lookup_finished:109: AcoustID: Lookup successful for 'K:\Music\01 Japanese Doujins\# Woodsoft\2000 - Altis - Leaf & PC Game Arrange\05. Theme of Yuri.Hoshihara [L no Kisetsu].mp3'
D: 13:12:49,338 ui\mainwindow.set_statusbar_message:440: No matching tracks for file 'K:\Music\01 Japanese Doujins\# Woodsoft\2000 - Altis - Leaf & PC Game Arrange\05. Theme of Yuri.Hoshihara [L no Kisetsu].mp3'
D: 13:12:49,339 webservice\ratecontrol._out_of_backoff:229: ('', 443): oobackoff; delay: 1000ms -> 500ms; slow start; window size 1.000 -> 2.000

I have this version

I already matched the track manually and saved, so I guess the explanations where Picard finds significantly different metadata is out. Of course, I could “clean” the flac file from any metadata, but my issue is not matching. Picard often does strange things while matching and I am quite used to it. I guess I could fine-tune the percentages, but I have finished ripping my collection, so…

My question here is why can’t I see any AcoustID in the flac file ? Is it actually there but for some reason I can’t see it or is Picard for some reason unable to insert it ?

Here is the fpcalc output:


Here is the debug log after pressing scan:

debug log
D: 07:40:50,032 acoustid\__init__._lookup_fingerprint:152: AcoustID: looking up the fingerprint for file 'D:\Sons\_MusicBrainz Picard\2\Genesis\1985-Seconds Out\2-03. Dance on a Volcano.flac'

D: 07:40:50,033 webservice\ POST-DATA 'meta=recordings%20releasegroups%20releases%20tracks%20compress%20sources&fingerprint=AQADtJGYJImmLBLMxEf4C3fBvvjw40yGWinRHc87XMpBMrSO-vCjF3015AmhcUJ67aioH_3gvsdDOFpuUCquSjHaISTDQg-PHx6jBxqjiNDd4z7CqCF6HmV2wdsXIZcGuTnC48cThRSe6ai4I_2hPciZCfcH_kH5IEwV6GTxIPpRwWKN6N1xDZaJS4Lm5AHNCz3Ww4c-wmGOG_Hgo8eXGLeLr0cjH3143BLqHD1zxJcjtNmhxcElC2E5uA6Xwc5RH0ezxEaoGt-gtCKF8EePX8OzLFJCXPbwcGisHf2P3cYznLhooz_8wA6PmzkunMfnI58G8cePvLvR40qPbod5lBfOI_eQPBFOH82J8gr-HDk0jUuFaPrhXMdk9FKChjly4UfXQOWFpw7MKEcPfVmOMBUvfNnhZzHK4z8u8uiTBZt4VI9QL0Dy5Qjz44mOb_pwNP_RZ86GF_-R_-gzaDl07cb0DA2PJy_-H10Jf4WO_YR_5Mfx4jvip9CRh7CL6_jxJ4fzW7BG4dWCWseJkq3xB66PG8-aoLqK8BXcC9qPE6OKDmmPuz1ew_mDLsxRmWjGEL_xoySPP_jxeCecMjGe4_DhN0eP_NAVBVOiF92LSlfhSvjxdYX2QBsc5niO-ILl6Akc9MejI3t6fByhG_2iosmNa9kkPEkC8Dl6Q0t_HDmxi6nRh0X6Q8PTpQj7B56uIHSEQ1unwmNQrUedH64IHb6Lfsdz6MmRjx7OoNfhyImFbjpeGaV0pNyD9_iDTU-IXhlUSWKDLwmD-DuaH32Ciygj_fCJ5iV4cXhy5NORPHiSnbjW44zQPDz640_BN8P9Ix8PLVX2orIUEtN6hIl6PDSaJsxRi0cfpE8qaLKEcEkER0su1LfwH-EPMUck5Urx_JjIHO7yEU-WvEIuqOkRSj2e4zrRH02dDo9e_OEQKk8hzkc7Dle04LvQvxCPMogTLXhSVB_R5Hg_XEelJ9txH8-PerOOnwiT5EJ1Hc-OxtCoReERHj-cvLieTcQ74WimaME3H2i-ozrxpdxQK0F66AnClZRxZYluXGksXOh3osmjHO9xyTmukLhyNHxQksejGP8RRi80XUduvIvgJQ_eHBepGc2PKpOEN0fFI8yjvFBdIv_whOHxiJyEki9sbcd5D28uVMdx_Qjj5KhJ6FFShLkoVHfxHM1YtNGHK8c__Ah_-HmIOtpRi4Tf4lfxCDoiiZSFa41x36iWozlz4cwxnTlc5diPMFWWIzmNF8-7oIm8DhNz1ErxNMdn4VTxIp2241M-ONllfIS-HPkeVMczVbiy3Kh8NCOPM3TxvHiSoYl49JbwZnFwyUcfbCqDZM4Rihf842Xh7EV95PmIqnEDv7iC9PjhX6i4S_jCIA91nKhESoKidAv06cIVLg7CFS6PX6iJnETy4lGe4DzR3WjiLMePc8fO40qUKmB4PMeYZ0hjFsl83AkVPFKUUPgX_KgcJEviB7l-PPExEQyZSMadHLuOZnKGUEyOxD7-DD3DCE2kJDuuvLiMR4d7vKHwqccRJpJYIrkuvMczpFcK9UU4RUWlHfuFO4ado0K460iWPHhEBudFvELjZkXlHJce9EVz8DmackEfYV6E7hXC_IEmdUfzHLmOo_lQ7_iLZ_nx65h-o7GkCrHWd5AvpNnBf8LJnHjQ5GCs482NtxmNUMezJDpS7jjpI_0hVzKcD19-pE6Ogt8R6kioob-EZ-EW_MGXEw65I8-PD4oPL7uQJ9llvMlxCU6aD2c3PDauo5eQLB9yPMaTnHgUXTgch8Dp4spSoY_QtMODpKYRKt9xTvDxGWdhJj5KWcd1PD-auBxCR8V5Qjv8hajwhEum40mPSxdC9mi-4xEfXBKDMzMa6iil48aP5kcyxckRv8YbNJOONtHx4N3moRea0EecRdyg60T4JEeDi8GjiMa9odSF5hS-B--Lp8JZfJpRH2Eu6EWeCD_RJC9FlLfwhUIzxagX_MELnziji_gkFuEhfgiXZ8fHObhy3MezHF7SWMSTssEbDT-8DJcy4yYu-JmO-8H-IXmYXEOYiugvXMsToUl7tHHwHT984e6DB5Hyw4e2JLiS5PiRN0eY80EXOXiSHof5Q3Fz4agLXzq0yEuFPApV4ccpw0-K400U4_LRhAmf4OFShDl0hJaUBkzSJSIePXiW40GY0M6hPSeyOfjhKEp24mSO5gpKJsKO9keYE8l1XNLhZxyOF82DUj7xJckT_JOOZkeLJ8xy4YnkoKJ0NM8VJGe3Is-iGA9x1MuDZmwT5EueQtXyC3HgxcEpRbiOH-l7qEIYoeaEkcnQG81FcF98XMedCtWSBx4Z-Mf2HKGha0EuG5caNLeD8rgkB2_CokOYKGuR_E6wJ7PwH3AcnDqeHqeQT0oFvYeuQz_68GhUvD1O4zoa6NKRD35qVJYXXJvx9DiPZHmR5QrOvZgyqUcZ6SyuUsGPvkITKjvOfAt-5IT4ZESu42lwlsITXejVwz-qTFmOXz3-EN_RZkHjLMflbHiD5kSVZh2SfgjzCGWizMKVGC-OHk3xLEwmVPqFSOF4QWeOMEfYF20EZWIzlPKhB_2DMLuE_3iGZkuGWscfXEj4D7FTTXh64T_awFMq9MyR47GGbx-aMHOLrhdyojk6l4hJVbgHxRJNhM-wJUc1zihl9The4g6eH_uDUE-QTLkmbONhXsH_oE6yHD_6C80RS6dwCRWVvPDdQTuDUM7RJErx5cG3ENfhf8V1F_cBxYARnCGgiCAGAECEIAoJAgABwAhKhBEACCGEYQgKIghwxipEhHGICgkEQsBowgmj2AhkgBIAKQGMQQozJAgCghAmhCACXESMNABgYgQgSkghhCHASecMIEABJwXwhAABIAOGKYYEAIQAYRgAUCCDjDDEEKQBQMISIQhCFBigHDOAAEHAgAoYYBRClhMCHCEAAAMAdcoBIRA0hEEglECIGUuEgcQB5AijQFhFmRCOCICRURZYYgxABkhCBCFMCaUEEUQAoBhRQCoCjCOGOEEAEIYQYIAFQAGsEBFAIakQQEAAogEDhCFGDBBACEQAIYYAKAgiABAAkEDAGUMEEgA5AQiRBBFFFDKOMGGAQEYZAByAghkklCQECGgQEQAI6oAgiAjABALEIAsAAwgYASQhCiGBFEEAOAaAAQgAARBFhhiEBFCGMIuYEQoJoYBgCAhBACFECESwQhAIiJRjzAChoHBKSYQAE8QABIRgBFkFEKEOOIAINAABQhQHBghAFCAGCOuYQogQZAgjhhCEmCBCAeOMUAILIIURDjDAgQBOICQZocIQywAxjBiDiGGAUGGAIQgg6wgkhBiBFFAEQAYMAQwhQQAQRBEhDGICAIGQMIQwYYACgoFjAAKcMIQIIYwKIxSrCDAAKHBEGE4AIUgQAYQBRCnCgAEEIWodUkRYoyjBAgmDAFAKOEIQAMQgpIADwjBjAQDCeiEAQUgwAQB1xHKAgFKAECMIEIwRRQFgRlgCmQIKAMQYAMIEIYhEhgkiABFIOIKoAEZQQgBwEGjBgAGgCQEQAQIChAwgQFAGiBGCKIKYEgYBIBBizAhqhAMSAUAIMoIIIygBCkEohAKQGEWEREQJAAFhQBCEBSOCIKWAFIAQBQASBhhBhEGGQOAQYfIAIQAChAAklAOGAQGBJAAYQpQAniJgqFGaAqYQM0IBAgwiQgDECeBAECQIQQgSARAADg&duration=505&client=v8pQ6oyB&clientversion=2.6.3.final0&format=json'

D: 07:40:50,048 webservice\ratecontrol.get_delay_to_next_request:118: ('', 443): Last request was 64250 ms ago, starting another one

D: 07:40:50,049 webservice\ratecontrol.increment_requests:138: ('', 443): Incrementing requests to: 1

D: 07:40:50,263 webservice\ratecontrol.decrement_requests:146: ('', 443): Decrementing requests to: 0

D: 07:40:50,264 webservice\__init__._handle_reply:486: Received reply for HTTP 200 (OK)

D: 07:40:50,265 webservice\__init__._handle_reply:495: Response received: {'results': [], 'status': 'ok'}

D: 07:40:50,265 ui\mainwindow.set_statusbar_message:440: No matching tracks for file 'D:\Sons\_MusicBrainz Picard\2\Genesis\1985-Seconds Out\2-03. Dance on a Volcano.flac'

D: 07:40:50,267 webservice\ratecontrol._out_of_backoff:229: ('', 443): oobackoff; delay: 500ms -> 333ms; slow start; window size 2.000 -> 3.000

Now after manually moving the track in the album track list in the right pane:
D: 07:41:22,418 ui\itemviews.dropMimeData:777: Drop target = <Track b3594dcb-cdd9-4015-bea2-f08c46d18a64 'Dance on a Volcano'>

D: 07:41:22,421 ui\itemviews.drop_urls:743: Dropped the URL: 'file:///D:/Sons/_MusicBrainz Picard/2/Genesis/1985-Seconds Out/2-03. Dance on a Volcano.flac'

D: 07:41:22,422 file.move:588: Moving <FLACFile '2-03. Dance on a Volcano.flac'> from <Cluster 'Unclustered Files'> to <Track b3594dcb-cdd9-4015-bea2-f08c46d18a64 'Dance on a Volcano'>

Then after pressing "Save":
D: 07:42:07,668 formats\vorbis._save:227: Saving file 'D:\\Sons\\_MusicBrainz Picard\\2\\Genesis\\1985-Seconds Out\\2-03. Dance on a Volcano.flac'

D: 07:42:07,732 file._rename:512: Moving file 'D:\\Sons\\_MusicBrainz Picard\\2\\Genesis\\1985-Seconds Out\\2-03. Dance on a Volcano.flac' => 'D:\\Sons\\_MusicBrainz Picard\\Genesis\\1985-Seconds Out\\2-03. Dance on a Volcano.flac'

D: 07:42:07,735 file._move_additional_files:572: Moving 'D:\\Sons\\_MusicBrainz Picard\\2\\Genesis\\1985-Seconds Out\\Genesis - Seconds Out.log' to 'D:\\Sons\\_MusicBrainz Picard\\Genesis\\1985-Seconds Out\\Genesis - Seconds Out.log'

D: 07:42:07,750 file._save_and_rename:350: Not removing empty directory: D:\Sons\_MusicBrainz Picard\2\Genesis\1985-Seconds Out is not empty

D: 07:42:07,758 file.update:665: Updating file <FLACFile '2-03. Dance on a Volcano.flac'>

AcoustID does not find any result for this fingerprint. Have you tried submitting this fingerprint after manually matching the file? Note that in mid August there had been an issue with AcoustID submission. So I would suggest that you try submitting the fingerprint again.

1 Like