What am I misunderstanding? Picard vs Jaikoz vs AcoustID vs AcoustID Fingerprint

Tags: #<Tag:0x00007f23c55f8468> #<Tag:0x00007f23c55f8210> #<Tag:0x00007f23c55f8058> #<Tag:0x00007f23c55ebec0>


I noticed something weird while using Picard and wondering if I’m overthinking this, if I’m missing something, or is this to be expected.

Super simplified version

Blowout all numerical identifies in a track (MB ID, AcoustID, Amazon, ISRC, Barcode, Cat No. etc) using Jaikoz. Save track.
Import Track into Picard, scan, and agree with identifiers, saving various newly introduced ID fields, and Submit AcoustIDs. Remove from Picard.
Import track back into Jaikoz. AcoustID is present, but AcoustID Fingerprint is not. Retrieve AcoustID via Jaikoz. Leaves AcoustID as is, and introduces AcoustID Fingerprint. Save track.
Import back into Picard.

Picard will do one of the following:

Have no idea what the track is anymore. This puzzles me since it has several unchanged MB IDs.
Recognize a portion of the albums tracks, not recognizing the others.
Recognize all of the tracks, but split them across two or more versions.


I’m not exactly sure what the problem you are trying to describe is.

Acoustid is not designed to be a perfect system for matching recordings and two completely different recordings can match the same id.
It is trying to put a lot of data in and reduce this to a hash so this is something that is possible.
I believe when you look up the acousitd it will return all results back to the program and it is then up to the tagger to choose what the best results are.

I’m not sure what you are trying to test If you have found a bug please add a bug report.


If there are the MBIDs in the tags, Picard by default will load the matching releases when you add the files and automatically match the files to them in the right pane. But this can be disabled in options, maybe you did this?

Apart from this Picard will not use the MBIDs when doing a lookup, but it uses the existing tags to find a matching release. This is intentionally, as you should be able to pull a mismatched get from the right and lookup it again. Scan on the other hand is pure AcoustId matching.

It is not quite clear from your description what you actually did in Picard and what you’d expect.