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.
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.
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?
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.
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.
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.
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 Compare fingerprints #50160552 and #28728172 | AcoustID
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 (Recording “Fire” by Ghazal - MusicBrainz)
