After updating to 2.3.1 (I might have skipped one or two minor updates), I noticed Picard no longer generates acoustid’s for files it doesn’t identify.
Not with scanning and not with new menu option tools / generate acoustid fingerprints.
Is this expected behaviour?
That’s not new behavior at all. AcoustIDs are not “generated” by Picard but get assigned to fingerprints by the AcoustID server. If you use the “Scan” function to identify the files and the AcoustID server cannot identify the files (because it cannot match the fingerprint to any existing AcoustID) then you get no match and also not AcoustID.
There can be cases where you get an AcoustID from scanning but Picard will still not match it to any file. That happens if there is a matching AcoustID, but it has either no links to any MusicBrainz recordings or the linked MusicBrainz recordings do match the existing metadata so badly that Picard will not match it. For the latter case you can adjust the thresholds in Options > Advanced to still get it matched even for bad matches.
Last the “generate AcoustId fingerprints” will never give you an AcoustID since it does not do any requests to the AcoustID server, it just generates the fingerprints for the selected files.
2 Likes
Thanks for the quick reply.
This was (nearly) always the case in the previous version I used. With SAVE the AcoustID would be written as a tag. And in a lot of cases the following LOOKUP would yield a valid result.
Something has changed and not for the better, for my workflow at least.
1 Like
Nothing changed here, Picard will still save the AcoustId if it is available. Lookup is unrelated to AcoustId, only Scan will make use of the AcoustId service.
If you don’t get results from Scan either the AcoustId service does not know about the music you are scanning or there might be an error on querying the AcoustId service. Please check Help > View Error/Debug log if there are any request errors for AcoustId.org logged.
Otherwise if you think there should be AcoustIds for the music you are scanning enable debug more in the log view and scan the files, then post any output in the debug log here.
1 Like
Ok thanks for the suggestions, I will follow them up and report back.
As I said, the following scenario was a common occurrence:
- scan a cluster, no results
- save AcoustID’s
- run lookup → succesful identification
Or am I still mixing things up?
I can’t say for sure why it so often did not find results for Scan but still assigning a AcoustID. But the thing missing here is that there is no relation between Scan and Lookup.
First, scanning a cluster currently is not different from scanning single file. This might change in the future if we improve the scanning to better consider clusters, but for now scan does not make use of clustering at all.
If the lookup gave you results it would have done so without scanning before. That’s because Lookup does not consider the AcoustID at all, it just searches for matches based on the existing metadata.
Scan on the other hand primarily uses the AcoustID and only uses existing metadata to decide for the best match if the AcoustID matches multiple recordings or to select the release.
2 Likes