AcoustID resulting from Scan and generated Fingerprints

AcoustID
,
1

In most cases the AcoustID returned from Scan (added to the tag) is the same as the AcoustID to which the sent fingerprint of the file is added. Exceptions were discussed here.

Here’s an interesting example of the possible range of matches:

One Way or Another is a recording with currently 35 enabled acoustIDs (I disabled numerous additional acoustIDs).

A recent Scan of the correctly tagged vinyl version file had this acoustID returned:

Blondie-1978
Blondie-19781006×776 151 KB

A submitted fingerprint (Submit AcoustIDs) is added to another acoustID: Track "34493f33-67d7-4a14-a4ab-c4b383dd0c09" | AcoustID

Blondie-1978-AID
Blondie-1978-AID927×677 65.7 KB

–
A curious fact: the same acoustID was returned for a 2001 remastered CD version (3 years ago):

Blondie-2001
Blondie-20011006×776 160 KB

Again, a fingerprint generated from this file is added to another AcoustID: Track "1151c4fb-d9d7-4874-b331-b1457bc678b6" | AcoustID

Blondie-AID-2001
Blondie-AID-2001916×315 33.2 KB

–
These versions play at a considerably different speed - fingerprints match between offset 1 and 3, shifting: Compare fingerprints #94405395 and #79717386 | AcoustID

Difference in Audacity - mono down-mix, synced at the beginning, difference towards the end is approx. 0.5 secs:

Blondie-dif
Blondie-dif1920×1049 437 KB

Conclusion: These fingerprints are not perfectly similar, but the similarity was enough to recognize the recording by a sufficiently matching fingerprint. Note, that the 2001 remastered CD’s acoustID was probably not available, when it was first scanned. A rescan returns the acoustID to which it submits. Only the vinyl version still gets a different acoustID on scan.

Remark on track length of a submitted fingerprint: my 2001 remastered CD version has a length of ~3:35 – the length of the fingerprint (on acoustid.org) is 3:37. However, my file’s fingerprint was considered to be the same pattern as an existing fingerprint with 2s more.

All these fingerprints are doubtlessly similar. All scans have found the correct recording and the release (of course, they were already correctly tagged)

1 Like
2

Just to add a bit to the detailed information above from the perspective of Picard: I don’t have numbers, but most often looking up a fingerprint on AcoustID will give you a single result (or none at all, if there is no match). That’s because the AcoustID already has some matching threshold and only returns plausible matches.

But in some cases there are multiple AcoustIDs that are similar enough. That usually means the AcoustIDs have fingerprints that the AcoustID server considered distinct enough to assign them to separate AcoustIDs, but the looked up fingerprint has a similarity to both that is close enough to be considered a possible match.

Picard in this case applies the matching score for the AcoustID, the relative submission count for a recording linked to the AcoustID and metadata similarity to select a best fitting result (1). This can mean that in some cases the actually selected AcoustID is not the one with the highest similarity score, see for example the case in PICARD-1565, where the actual wanted result is the second entry.

If however the AcoustID lookup gave results but no matching recordings (either because no recordings are linked to the found AcoustIDs or the found recording’s similarity falls under the track similarity threshold) then Picard will still set the AcoustID tag, but will always use the first result (i.e. the one with the highest score) from AcoustID (2).

(1) Before Picard 2.3 only the first result was considered
(2) Since Picard 2.7 due to popular demand.
2 Likes