Suggestions for changing how AcoustID scanning and lookups work

Tags: #<Tag:0x00007f0509524fa8> #<Tag:0x00007f0509524b70>


I have the feeling that the Scan button is somehow hard to understand, mostly because it is doing multiple things at once.

I propose to:

  • Differentiate Calculating Fingerprints and Look Up (eventually with the help of existing fingerprints)
  • Allow one to calculate fingerprints wherever is the file (unclustered, clustered, already linked to a track but without acoustid)
  • Allow one to submit fingerprints when the file (with its acoustid) is linked to an actual track (whether the file was saved or not)
  • if a file has already a calculated fingerprint, allow one to force re-calculation

Scan action is doing 2 things at the moment: it calculates the fingerprint and look up for matching track
If fingerprinting isn’t configured it does nothing at all (but showing a dialog asking for configuration).

I think Scan should be replaced by Fingerprint action, and having only one Look Up action (which will use fingerprint as well as the rest of available infos to find a matching track)

Forcing recalculation can be a context menu action (on albums or tracks), it can be useful sometimes, but in general there is no need to recalculate.

What do you think ?

Note: matching ticket is at

Submitting AcoustIDs: scan button greyed out

I like your proposed solution to have one button for generating fingerprints and the other button for lookup which would also compare the AcoustID tag. However, I wonder which of the two would have more weight in case one of them wouldn’t match? Many times I found incorrect files only because the AcoustID didn’t match the recording and I was able to figure out that the file was actually a “Radio Edit” of the same song for example (this goes for downloaded stuff). And how would it be displayed if the two didn’t match? Because I’m afraid that people would just submit whatever result they got after the “combined lookup” and this would possibly associate the AcoustIDs with incorrect recordings. Currently you need to move the files into your release manually after a Scan so at least there’s that. And I feel like this ticket of mine could be related to the possible issues we could face: PICARD-878.

Also the following bug could probably cause some problems if we grouped the two features (for people who don’t use the musicbrainz_recordingid tag): PICARD-949. I encountered this issue on one of my VA releases where some of the songs had tags switched around with other songs on the release and I wasn’t able to tell that even after performing Scan unless I checked their duration closely or enabled the musicbrainz_recordingid tag. I am now using the musicbrainz specific tags but some people might not be, so mentioning this here as well just in case.

And here is another related ticket that I found which talks about getting better results for the Scan function: PICARD-827. Might come in handy.


I like the ideas proposed, but I would also like to have something for 1.4.1 so we don’t have to wait for 2.0 for users to have a(n ever-so-slightly) better experience with AcoustIDs in Picard. So I’d stick to just enabling “Submit AcoustIDs” from the right-hand pane for 1.4.1 and then incorporate all the other suggestions in the 2.0 UI/UX overhaul.