I think there is some confusion here. First of, it’s not really that “Scan” is the old function and it gets replaced with new “Generate AcoustID fingerprints” button. Both serve different purposes.
“Generate AcoustID fingerprints” does calculate the fingerprint (using the fpcalc utility) for the files. It does not do any requests to the AcoustID server. It was added to address the use case that people wanted to submit data (fingerprints) to AcoustID but did not want to use AcoustID to identify their files.
The fingerprint is different from the AcoustID. The fingerprint is directly generated from the audio data using a mathematical algorithm. It currently is not stored in the files, as it is easy and reasonable fast to regenerate. So if you load back a file into Picard and want to submit its fingerprint to AcoustID you need to generate that fingerprint again. But you really don’t need this fingerprint permanently, it is only of use for querying the AcoustID server for matches or submitting it to AcoustID.
The fingerprint itself was basically invisible in Picard before. Once generated Picard kept it around as long as the file was loaded, but there was no indication whether a file had a fingerprint generated or if it was already submitted to AcoustID or not. Hence the new “Fingerprint status” column.
Now there is that magical AcoustID. The AcoustID is kind of a grouping of similar fingerprints. One important feature of the AcoustID fingerprints is that they can be compared for similarity. So while the fingerprint for e.g. a lossy file might be slightly different (due to differences in audio) it will be very similar to other fingerprints of the same recording. To get the AcoustID one needs to query the AcoustID server using the fingerprint. AcoustID will search its database for AcoustID with matching fingerprints attached and will return a search result. This result can also include details about matching MB releases as the AcoustID serves as the link between fingerprints and MusicBrainz data. It’s important to note that there is no guarantee the AcoustID will return any results, it is possible there is no match for this fingerprint. It’s also possible there is an AcoustID, but no linked MusicBrainz data.
The “Generate AcoustID fingerprints” action currently does not query the AcoustID server for matches, hence there is no AcoustID in return. I intentionally left this out. You don’t need this to submit the fingerprint to AcoustID but it slows down the entire process by a factor of 2.5 - 4 (or even more, depending on your internet speed and the actual response time of the server).
We could of course do this lookup to get the AcoustID just for the sake of it. But not sure how to call this then without raising wrong expectations. I intentionally called the action “Generate AcoustID fingerprints”, because this is what it does and what you can actually “generate” (aka calculate). You cannot “generate” AcoustIDs, you can search for matching AcoustIDs. But you probably won’t get one.
There is no need for neither dragging nor clustering, you can generate the fingerprints directly on the right. Actually this is kind of the idea here.
When you hit scan for files on the left which don’t have any AcoustID tag yet you will basically never see any AcoustIDs on the left. That’s because as soon as the response from the AcoustID server comes the file will be moved to the right. The only exception to this should be the rare case where there is an AcoustID for the file but no MB recording linked to it, then the file would stay on the left.
It is frustrating for me to have wasted so many hours over a complete misunderstanding of a feature. Next time I’ll leave it until things are better documented so I can test in a way that helps people.
Actually I value your feedback very much. I wouldn’t have written a lengthy reply trying to explain the fingerprinting otherwise.
. I was looking forward to quickly updating the AcoustIDs on my tracks, but the fingerprinting feature does nothing for that. It is useful when creating new AcoustID records in the MB database, but not helpful for backfilling existing AcoustIDs.