No acoustIDs on MB release

Hello, I’m seeing another bit of odd acoustID behavior (perhaps related to my prior open issue, still unresolved/recurring).

I added discIDs to this release, ripped it, tagged it using the foobar2000 MB plugin, and then scanned the tracks using the latest picard. Most of the tracks matched IDs, and those that didn’t matched other recordings on other discs, so there were a few submissions to make, nothing out of the ordinary. The submissions went fine according to the logs.

But on the release itself, no IDs are showing. Is there a way to trace what happened to the IDs?

Baiscall the same as we did on No acoustID generated for a single file? - #20 by crappy : Check the Picard logs for the results of the submission, query the acoust ID API for the status of those submissions.

Apart from that processing the submitted fingerprints is really on the AcoustID side, not much Picard can do about that.

1 Like

Thanks for the reply, I figured that was a next step, but some of these already existed in acoustID and weren’t submitted. Is there a reason MB and acoustID would not be “linked” for a given release?

1 Like

AcoustID allows fingerprint submission without a recording MBID, so not all submitted fingerprints are linked to a recording. Picard does not do this, it only submits fingerprints linked with a recording ID. But other tools might submit fingerprints without recording MBID.

So just to make sure I understand, you’re saying some non-MB user likely submitted these fingerprints, and from MB’s point of view everything is likely stuck in the same queue/pending state on acoustID as everything else we looked at?

Not sure I understand you correctly now, but probably the answer is yes :slight_smile:

Just want to say that both are completely separate things:

  • If you see an AcoustID on acoustid.org that is not linked to a MB recording that means the fingerprints for this AcoustID has been submitted without a recording MBID (but instead usually with basic metadata, that will be displayed on the AcoustID page)
  • If you submitted a fingerprint from within Picard, and the Picard logs indicate the submission was successful, but the link between the AcoustID and recording does not show up (neither on AcoustID.org nor on MusicBrainz.org) this indicates that the AcoustID server has not yet processed the submission or failed to process it (for whatever reason).

Btw, how did you find out that there is an existing AcoustID that is no linked to the recording? Can you provide a link

1 Like

Ah I meant to say… unlike in the other case, the fingerprints are saved on the files!

I don’t know the acoustID API well, just took a look at the documentation, is there a simple front-end way to check the status of an ID from a file tag?

Ok, I see now. First we need to differentiate, there are two possible tags Picard can write to the files:

  • acoustid_id: This is not the fingerprint, this is the AcoustID a fingerprint matches to. AcoustIDs are provided by the AcoustID server
  • acoustid_fingerprint: This would be the actual acoustic fingerprint calculated for the file. By default Picard does not write this tag, but you can enable writing this tag in the options. In most cases this would not be really useful, as the fingerprint can be calculated any time from the audio.

Now if you use “Scan”, Picard will:

  1. Calculate the fingerprint for the file
  2. Make a query against the AcoustID API with this fingerprint, which will return AcoustIDs that match this fingerprint

Depending on the result of the query, one of the following things can happen:

  1. The query returns at least one matching AcoustID which is linked to a MB recording: Picard will try to load this recording (choosing the release it considers best matching) and set the acoustid_id tag.
  2. The query returns an AcoustID, but it is not linked to any MB recording: Since Picard 2.7 the acoustid_id is being set, but there is no recording to load so the file remains on the unmatched files pane. Prior to Picard 2.7 the acoustid_id tag also does not get set.
  3. The query returns no AcoustIDs: No recordings are loaded, the acoustid_id is not being set
  4. The query was not successful, e.g. due to a network error. The end result is the same as for 3. The logs will tell more. Depending on the nature of the issue retrying the scan might give results.

Not directly. For the state of the actual submission you need the submission ID, and Picard does not track past submissions. I have some ideas about making Picard keep track of all submissions and provide an UI to see the state. But nothing concrete yet, and it’s unlikely I will work on this any time soon.

To look at an AcoustID you can use “Lookup in browser” if you right click on that AcoustID in the metadata view at the bottom of Picard’s screen.

4 Likes

This is the most helpful info yet, thanks. Really clarifies things (better than the MB wiki imo), and the right-click lookup rules (didn’t know about that).

Randomly checking a handful of my local IDs shows that they are linked to MB recordings, but not this release’s, BUT only a few (and surely not every one I checked) were submissions on my part. So I still don’t really understand that limbo…

Picking this back up to say that the acoustIDs in question never emerged from their submitted state properly (as far as I can gather), which I guess means the bug is still bugging.

I started in today merging the recordings, and along the way found that this was a duplicate release, added in 2020 in a separate release group, and so I’m now merging them toward the original, much more heavily edited release (first added in 2005!)

I’m bumping the thread to ask whether the duplicate issue could somehow be involved? Realizing it doesn’t sound that logical but I haven’t seen this kind of duplication or mass acoustID failure before or since, across many edits…

1 Like