There is something I’m not understanding about Picard. Is it able to use calculated fingerprints and AcoustID to find the song ?
I’ll explain my concern with an example :
I have a song in my library with no metadata inside, file is named “p18-entre-sol-y-palmeras.mp3”
Lookup didn’t do anything
“Scan” has allowed me to get the AcoustID for the file : “16cfa937-8bb6-42f6-8619-58a1dc13324b”
When I search this value in AcoustID here is what I get : Track "16cfa937-8bb6-42f6-8619-58a1dc13324b" | AcoustID => The song is linked to a MusicBrainz recording with the following info : Title “Entre sol y palmeras” Artist “P18”. The AcoustID collected is correct.
Problem is, that’s the only value that Picard saves in my file. After I hit “Save” on my file to write the AcoustID into it, nothing else changes and when I hit “Lookup” I still get no result. I enabled the debug logs and I get this :
D: 14:29:30 Looking up the metadata for file C:\Users\xqyl603\Downloads\zik\p18-entre-sol-y-palmeras.mp3 ...
D: 14:29:30 Updating file <File u'p18-entre-sol-y-palmeras.mp3'>
D: 14:29:30 WSREQ: Last request to (u'musicbrainz.org', 443) was 84732 ms ago, starting another one
D: 14:29:32 Received reply for https://musicbrainz.org:443/ws/2/recording?query=tnum:(18) qdur:(142) track:(p18\-entre\-sol\-y\-palmeras)&limit=25: HTTP 200 (OK)
D: 14:29:32 File 'C:\Users\xqyl603\Downloads\zik\p18-entre-sol-y-palmeras.mp3' identified!
D: 14:29:32 Updating file <File u'p18-entre-sol-y-palmeras.mp3'>
D: 14:29:32 Album de10ccbe-559b-4481-96fc-97063eddcdb2 already loaded.
Looks like the AcoustID it found isn’t used at all by Picard after saving it.
Picard looks for the song in MusicBrainz with only the file name, while i believe it could use the AcoustID and find the song easily.
I went through all options/plugins, and I couldn’t find anything like a checkbox saying “Use AcoustID in search requests”. Is it something that Picard is not meant to do ?
As far as I know, Picard only matches the AcoustID when you hit Scan. That’s at least partially deliberate – while the AcoustID often gets close, it’s usually less accurate than Lookup, which uses a wider selection of metadata and, if the files are clustered, considers multiple files at once (file name shouldn’t play much of a role compared to what’s in the tags; I’m guessing the title in this case either contained the file name rather than something formatted as a title or was empty and the file name was used as a fallback). Maybe the latter should look at the AcoustID as well, but Scan will usually save more than enough information to find the track again without.
At the very least, I’d expect Picard to save “MusicBrainz Release ID” and such. Is there a chance some plugin or script is being overzelous in cleaning the tags?
I’m not sure from your description exactly what your workflow is, are you scanning the track and then is it being matched to its counterpart in the database on the right hand side of Picard? And then you save?
I’ve attached a gif of expected behaviour. In my example the old and new values that are being written are the same but yours should be adding a lot of new ones.
edit: it’s cut off the start a bit, all I do is select the track on the left and hit ‘scan’
The only info I have on the file is the file name. Which is the correct file, but with hyphens : “p18-somos-el-futuro.mp3”. There is no pre-existing tag.
When I hit “lookup” it uses the file name (since there is nothing else), and finds nothing (hyphens don’t help with the search query apparently).
When I hit “scan” it finds the AcoustID perfectly. But that’s it. No additional info : no title, artist, etc. But the AcoustID found is correct.
=> I hit save to write the AcoustID tag into the file, thinking at least now it will have this info for the lookup, maybe it will use it. The AcoustID tag is correctly written into the file.
When i hit “lookup” again, still nothing. Same when i hit “scan”. Even if the fingerprint enabled Picard to identify the correct AcoustID, which is linked to a MusicBrainz Record, it’s like it doesn’t go all the way.
Below is an example workflow in GIF (watch till the end, I lookup the AcoustID in browser) :
All I can say is that it looks like a bug since the discID is linked to a recording… now it’s outside of my sphere of knowledge.
Thanks for the gif btw, very clear!!
You’re welcome
I have an update : I tried disabling every single plugin I had enabled and, oh surprise !, it works now
Guess some plugin prevents the scan from working the way it should !
I you have some time, it would be nice to try it again with a copy of the untagged file, enabling plugins until you find which one is misbehaving (and report a bug for that one).
Yes, the tango info also shows a log in the screen you posted above. That’s either a bug or an issue with the server the tango info plugin is querying.
