Fingerprints already submitted? Really? (duration values not listed)

Tags: #<Tag:0x00007fa5ca4378b8> #<Tag:0x00007fa5ca4377c8>

When I load The Rain by Ghazal into MB Picard and scan the tracks, I see that the fingerprints have already been submitted.

Could anyone tell me please why the fingerprints are deemed “already submitted” even though the lengths of my tracks are not listed on the AcoustID webpages? See the list below where I list each track with its duration and the AcoustID track assigned via Picard.

Actually, I have two copies of the album - one I originally obtained in 2004 with mp3 files. The other is the iTunes Plus version (m4a files) obtained recently through Apple’s Tunes Match service.

Fire (m4a): 18:19, 01081a22-64df-4bc1-9bcf-7ee36ea9291a
Note that the duration ist not listed.

Fire (mp3): 18:21, 9fed0a0e-58e4-4f57-850f-9f52131c9640
Note that the duration ist not listed.

Dawn (m4a): 14:59, 4ba3d4aa-503e-49f8-b279-ddea017dff10
Dawn (mp3): 15:01, 4ba3d4aa-503e-49f8-b279-ddea017dff10
Note that the duration ist not listed.

Eternity (m4a): 19:51, 100f3aa4-e06a-4719-8616-9d74f4485e29
Eternity (mp3): 19:51, 100f3aa4-e06a-4719-8616-9d74f4485e29
This duration is listed.

If I go to these pages, I do see fingerprints and durations.
Temporary issue?

I see fingerprints too, just not with the stated durations. Was my question not clear?

AcoustId is a two stage process: First an acoustic fingerprint gets generated for your local files. For a lookup this fingerprint gets sent to AcoustId, which then checks if there is amatching AcoustId by comparing the fingerprints for similarity. In your case that should mean that the fingerprints generated for your files are sufficiently similar to the ones you see on the AcoustId pages.

If you want to check this you could match the files to the proper recording on MusicBrainz in Picard, the use the “Generate AcoustId fingerprints” action and submit the results. If I’m correct a fingerprint with exactly your length should then show up on the AcoustId pages.


Just as a side note: I wondered why the m4a and mp3 version of Fire get different AcoustIds. But there is indeed a difference, see this comparison:

If you use the move up button until the offset shows -45 you can see that the m4a Version on the left has some additional audio at the start but otherwise matches well. If this warrants a separate recording on MB or not depends, best you do a listening test. Is there something significant at the start or is it not audible?


Thank you for looking at this and offering your explanation! I am interested to learn more.

On the track webpages, the fingerprints are listed with their length, e.g.:

That’s why I thought that a difference of, let’s say, 1 second, would get noticed, because that is (among other things) what distinguishes fingerprints from each other. What you are saying is that either Picard or the AcoustID service deemed the duration differences too minor in 4 of the 5 cases.

I did as you suggest. I chose to match with the DE release. Before performing this action, I took a screenshot of the four AcoustID track webpages linked to above. After performing this action, I hard-reloaded the webpages and took another set of screenshots.

Take a look at the side-by-side comparison:

Fire (m4a):

Fire (mp3):



The count in the Sources column went up by one, except for Fire (mp3).
New fingerprint IDs with the new lengths have not been generated.

In really wish what @outsidecontext predicted would have happened, because that would have been really instructive…

My conclusion would be that the file durations are not that important in Acoustid’s comparison between fingerprints. But that also means that the “Length” column is a bit misleading. The sources count is not specific to the stated length, rather to a range of lengths!

The length information cannot be used to infer anything at all, for example which fingerprint ID my particular track has.

This screenshot as proof for the different durations, before and after upgrading to 256 kbps m4a.

The first ~6 seconds are not audible.

On the surface, it seems odd that a 18:20 fingerprint is clustered with a 18:13 fingerprint, rather than with a 18:21 fingerprint.

The shorter (18:19) Fire m4a track is assigned to the AcoustID with a 18:21 fingerprint while the longer (18:21) Fire mp3 track is assigned to the AcoustID with 18:13 and 18:20 fingerprints…

If I take the length values as more or less meaningless (maybe they are some kind of weighted average) then I can just overlook them and trust the process. :laughing: :face_with_hand_over_mouth:

Well, it basically did. You could see that the count for the fingerprint went up by one. That means the AcoustId fingerprint for your file was identical to 50160552. There is indeed a threshold for length differences on AcoustID (not sure right now where this is set). If the difference would have been too far away your fingerprint would have been assigned to a different AcoustID.

I’m not really sure here, actually it would make most sense if all three fingerprints would have been assigned the same AcoustID. But for some reason the server did consider them separate. We can’t really tell from the outside why the algorithm came to this conclusion. All three fingerprints are quite similar if you compare them, e.g. the two longer fingerprints compare almost identical, see

They are not totally meaningless, but there is some threshold that allows for some variation in length. Overall you can see the process worked for you. E.g. the two different encoded files of Fire, which are based on the same recording, both resolve to the same recording on MusicBrainz (


AcoustID says that no fingerprints can have a duration of greater than 7 seconds in variation, even though I’ve seen such cases where they do.