I have a weird situation where one particular file (it’s this recording, and there’s nothing wrong with it) simply will not produce an acoustID, no matter what I’ve tried. All other files from the same release (100 of them) generate/match just fine.
I am using 2.7.3 “portable” in Windows 10, and (in case it matters) it is running off a secondary HDD.
When I scan it, it flashes grey for a second then matches nothing. Dragging it on to the correct track produces the expected “red fingerprint”, and I can click submit, but there is no acoustID tag there, whether I save or not. Have tried this multiple times. Nothing in the log.
I tried starting in debug with the -d flag but I can’t drag/drop any file in that way?
I would open a bug report but I have no idea how to describe it better, was hoping some more experienced user/dev might have some better troubleshooting steps for me. Thanks!
As I understand it, Picard is only submitting the information to the acoustid server, and when the fingerprint grays out that just means that the server accepted what Picard sent. If there’s an internal error in the acoustid server - or even just a delay in applying the fingerprint - there’s nothing useful that Picard logs could tell you.
Picard can only set the AcoustID tag if the AcoustID server returns a response that contains the ID, if the fingerprint is freshly submitted or not processed yet there also is no ID yet.
Best would be to enable debug mode (via command line parameter or on the Help > View Error/Debug Log dialog), then scan this file. The log should show the response by the AcoustID server.
This indicates you are running the command prompt as administrator, and in extension Picard itself runs as administrator. Don’t do that, run it with normal user rights. Windows prevents drag and drop between privileged and unprivileged apps.
OK thanks @elomatreb@outsidecontext that helped. The acoustID is not a match (which has happened to me on scans many times), and when I move it manually BEFORE hitting a submit button this is what the log says:
D: 08:40:46,590 file.move:615: Moving <FLACFile ‘1.11 - The Chords - Sh-Boom.flac’> from <Cluster ‘Unclustered Files’> to <Track 542b6a49-8326-46eb-897c-7a542aeba048 ‘Sh-Boom’>
D: 08:40:47,701 acousticbrainz_init_.get:72: ABExtractor: AcousticBrainz disabled
Why wouldn’t it let me make a “new” submission?
PS I did not know this!
Windows prevents drag and drop between privileged and unprivileged apps.
Would be great, if you could show the log output of an actual “Scan”. It might actually still be that the AcoustID server did find results, but the AcoustID provided metadata was so different from the existing data on your file that Picard considered it not a valid match. In that case it might help if you lower the threshold in Options > Advanced > Matching for “Minimal similarity for matching files to tracks”.
Did you do a scan before? Only if you do a scan or alternatively “Generate AcoustID fingerprints” on the file Picard will run the fpcalc utility to generate the AcoustID fingerprint, and only then there is something to submit.
Sorry, followed along/read through and didn’t think there was anything interesting in it. Can’t put the whole log here because no text-file attaching and it’s too long for inline, but I have it saved.
For posterity, the steps I took:
started Picard (portable 2.7.3), cleared log (in debug mode)
dragged/dropped file in question, it matched by tags (tagged in foobar2000 w/ MB plugin)
dragged it back to unclustered to scan it (side note: I don’t know how to keep it from tag matching first, i want an acoustID on every track)
scanned it, flash grey then white for no match
right-clicked and generated fingerprint
dragged it back to its match, noted a) that there was no acoustID tag and b) that the file appeared as saved (perhaps because I’ve done this umpteen times)
clicked submit, saw success message in debug window, saved log
Needless to say, no acoustID on the file at this point. (I have since the OP scanned and generated for other unmatched files, without incident)
As I wrote above the debug output of this scan step could be useful, as it shows the request made to AcoustID and the response. Otherwise it is all really guesswork. As you had submitted the fingerprint before it would be expected that AcoustID by now has a match for this fingerprint. But it could also be that for some reason the AcoustID server has issues with importing this fingerprint or something.
Sorry, this sat for a long time… a couple more pieces of information, and then I will try to post bits of the log in pieces.
I tried re-ripping this disc, and got the exact same results from the new rip (which I will use for logging, since it’s theoretically “cleaner”)
I found another track on another disc from this release that has a variation of the same problem: this time, the acoustID is “matched” it points to a different release, and when moved produces the usual red fingerprint. The submission again logs as successful, but the acoustID doesn’t appear there; the fingerprint is present on the recording picard found, and it is of course the same track/recording–a different ID appears on both.
OK here are the steps with as much of the log as I can post.
First, try to tag .wav files using the MB plugin in foobar2000 v1.6.9, the full disc ToC does not match so perhaps my drive is doing something wrong (though Exact Audio Copy states in its log “Accurately ripped (confidence 55) [00750984] (AR v2)”) – could use release ID, but never mind, Picard can do it!
Next, drag the .wav files into picard, scan them. They all match first to different releases except the track in question, but no big deal, happens a lot with anthologies. Drag them all into their correct places on my release, interestingly mostly showing as known IDs except for three tracks, all of which are “false” new submissions, i.e. the fingerprints are already associated with the respective MB recordings: here, here, and here. Not posting the log for this, doesn’t seem relevant, though it is odd.
Drag the unmatched file onto the target recording. Note the lack of acoustID in the “new” tags, but also the red fingerprint in picard? Log:
D: 12:29:48,640 config.event:254: Config file update requested on thread 13576
D: 12:29:51,472 ui\itemviews.dropMimeData:778: Drop target = <Track 542b6a49-8326-46eb-897c-7a542aeba048 ‘Sh-Boom’>
D: 12:29:51,472 ui\itemviews.drop_urls:744: Dropped the URL: ‘file:///E:/m/rippin/doo wop rerip.flacf/11 - Sh‐Boom.wav’
D: 12:29:51,473 file.move:615: Moving <WAVFile ‘11 - Sh‐Boom.wav’> from <Cluster ‘Unclustered Files’> to <Track 542b6a49-8326-46eb-897c-7a542aeba048 ‘Sh-Boom’>
With track in question highlighted, click “Submit AcoustIDs” in picard menu. (Turns out this tries to submit the 3 false positives as well, generating an enormous log full of fingerprints in who knows what order, so I redo all this but remove all the other matches this time, and repeat the steps above, with the same log results.) Log:
Doing a lookup on the fingerprint submitted in the logs gives no results, and checking the submission status currently shows the submission is still pending. That might indicate some issue on the AcoustID side with importing this fingerprint. @lukz might be able to help
I see, I assumed it was “generated” locally, but that makes sense. I fingerprinted a batch of rips today, ~13 releases, and it happened twice more, again with random individual tracks where the release otherwise matched fully (and this from releases in lots of collections). Would be nice to know what’s going on.
The fingerprint, or rather its text representation, is the longish gibberish in your log snippet. You can save it to the tags if you want (there is an option for that in Options > Fingerprinting), but for most that is not very useful. The fingerprint is directly calculated from the audio.
Sorry, I was unclear–“generated” was the wrong word. I have read the link and understand the process, basically just another version of a checksum.
There is some kind of bug here; either picard is reporting the wrong status or “success” doesn’t mean what it used to. What is odd is that a) after you “generate” the ID quite literally nothing happens–I can’t see that fingerprint, even in the log, unless I submit and b) the log indicates a full submission success (I guess because async/no await?) despite failure.
That indicates some issue on the AcoustID server side.
When fingerprints get submitted to the AcoustID server they end up in a submission queue, and the server will process them eventually. Usually this happens very fast, so import should happen in a few seconds or maybe a few minutes. There might be time of high load where it takes longer. But in this case it is quite clearly stuck and not just delayed.
Thanks, that was what I was looking for… you might have mentioned that this whole thread is a duplicate! Also answers my question about generation (fingerprint vs. acoustID)
