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.
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.
I saw a new reply in PICARD-991 today and I got some more food for thought. To add to my previous reply and PICARD-878, how would the track that has an AcoustID tag filled in be displayed if it didn’t match any of the attached AcoustIDs for the recording it has been matched to? What would be in the “New Value” tag on the right pane? A warning that it doesn’t match any of the attached AcoustIDs? All of the AcoustIDs attached to the recording being listed?
Also, how do we differentiate between the different values of “AcoustID tag vs mb data” and “AcoustID tag vs real fingerprint”? The latter might happen extremely rarely (due to a bug or the user incorrectly using other mass-taggers to copy+paste tags, etc.) but currently both are displayed as “Original Value” vs “New Value”, without the user knowing whether the tag matches mb or not.
There is also another case where there would be no AcoustIDs attached to the mb recording. This particular case got me thinking about PICARD-250, but this only applies to “tags vs no data” and not “tags vs non-matching data” because currently there can only be 2 values (file tags vs mb data) and the AcoustID field would be the only exception if we added it for lookup, because it can theoretically have 3 different values (real fingerprint vs file tags vs mb data).