How did you find out they do not end at 2:00? Picard explicitly calls the AcoustID fingerprinting tool with fpcalc -length 120 to limit the audio to 2 minutes. That’s also the default value for fpcalc.
The reason behind that decision was that in order to identify a file, you don’t need more than that, so running the algorithm on the whole file is a waste of time. The fingerprinting algorithms MusicBrainz used before only used 60 seconds (MusicIP) and 30 seconds (TRM, if I remember correctly).
The first one is an old AcoustID, they were shorter indeed. If you rescan now the 2 minute recording, it will get a long AcoustID as well.
But I also think it would be nice that all the recording is scanned, if it is only a matter of CPU, instead of only first two minutes.
TRM < PUID < AcoustID < larger and larger but still why not complete as we are almost there ?
It’s mostly just CPU. Back when I was designing AcoustID, I really wanted it to be super fast. For Picard-style lookups, even the 2 minutes was too much, but I though it’s a nice compromise.
I didn’t realize AcoustIDs would get used for other purposes, like checking which recordings are the same, it was only meant as a search tool. I’d like to upgrade the database to full fingerprints, but the server code currently doesn’t handle that, so I need to first make it possible to replace those short fingerprints with full ones. It will eventually happen, but it will take time.
So both fingerprints only cover 2:00. But the second appears to be longer as it comes from a newer pingerprinting version which produces more data. It this what you are saying?
Also, I noticed that for the first fingerprint, a length of exactly 2:00 minutes is reported while the associated recording is of length 2:02. This might mean that it is cut at 2:00 (or it might come from the fact that a single MB recording may be linked to a variety of tracks with differing lengths). However, for the second fingerprint, a length of 5:05 is reported for the fingerprint as well as for the recording. So I thought that this fingerprint covers the full length and is not cut.
Could you clarify, please? I really would like to understand this.
Thank you for this information!
Yes, it would be great to remove the 2:00 limitation, to start collecting full length fingerprints, better sooner than later. The CPU problem should self-heal as processors get faster and faster over the years.
I’m not sure whether this is to do with the 2 mins mark but sometimes I find false matches with insufficient information to resolve. Take https://acoustid.org/track/dcd88e4a-3de8-4332-9151-2f5898adda64 for example. This is associated with 2 recordings of the same work, by different performers. Both releases seem to have been correctly tagged with their performers according to the cover art. How might these be teased apart?
When I scan the tracks in Picard, with all the meta data cleaned out and even the files names change to something ambiguous, it always prefers the vocal version.
Although the vocals clearly begin around 1"06’ mark. I thought may be because they were previously merged, it had some kind of “memory”. So didn’t dwell on it too much.
But now with the ones I’ve added above, I’m beginning to think there’s something else going on.
I’ve tried submitting with the fingerprint app (windows) and Picard, same results.