merged duplicate releases to a clean copy. https://musicbrainz.org/edit/85008009 #3 “The Fresh Prince of Bel Air” recording has many merged tracks and had many AcoustIDs, now there are none!
If I remember correctly merged recordings would also merge the unique AcoustIDs. Not the case lately. I’ve noticed this in other recording merges also.
I hope they are not being completely lost or not just displaying. Either case this seems to be a serious problem.
Hope @lukz can shed some light on issue and it could be addressed soon.
Someone who owns the audio file will need to re-submit the AcoustID in Picard. What was lost is the relationship between the Recording MBID and the AcoustID_ID - the AcoustID data itself is not lost.
Usually, merging into the oldest MBID prevents this situation from occurring. I’ll just take this moment to claim that the official MusicBrainz docs [1][2] give bad advice on how to merge.
Not surprising it is from that kind of big VA merge. I’ve been caught out with them before as you need to carefully check directions to find each recording that is the oldest.
I assume there is a ticket on this somewhere. Hopefully it is something that can be recovered as I assume the old MB Recording ID → AcoustID is still around.
What seems to be happening are the sources associated AcoustIDs are being disregarded in favour of the targets AcoustIDs, if it has any or not. I believe they’re in the acoustid db somewhere, but the association has been broken or is not being shown on MB.
Prior to this weird behaviour every recordings associated AcoustIDs was merged, oldest to newest, vice versa direction did not matter.
Lately my workaround has been to merge to towards the recordings with the most AcoustIDs, not necessarily the oldest. That’s possible with individual recordings, but with whole mediums, things become problematic as in the above examples.
This is a fundamental concern that needs to be addressed.
I hope @lukz or whoever maintains it can look in to this issue.
Your description points to the issue being at the MB end. After a merge the old recording IDs still work, so AcoustID would still be able to link from their side. It is a hiccup at the MB side that has currently forgotten to merge this data.
The data is not actually stored on the MB side. When you look at the AcoustID fingerprints page for a recording, MB does perform a query against AcoustID.org, asking it for all AcoustIDs linked to that recording ID.
So to me this looks like AcoustID needs to better handle the case of merged recordings.
In another recent discussion here there was also a case where fingerprint lookups with Picard got confused because recordings got merged. The AcoustID still exists, but it is linked to the old recording ID. And that means on AcoustID it shows up being linked to a no longer existing MBID without further metadata.
If AcoustID would handle this and consider the merge and update the links to the new MBID it would fix both issues.
Thanks for that. Now understand. So the old AcoustID is pointing at the old pre-merge Recording MBID, so when MB asks for the AcoustIDs, the AcoustID end now doesn’t realise that it has two sets of data that should have been merged.
The good part of this should be nothing is lost, just needs an update of some form run.
I wonder how he knows about merges. I guess he has to run a search of some form for all Merge requests so that data can be mirrored on that site.
Yes, nothing should be really lost. AcoustID still has the links to recording MBIDs, and the MB database has the knowledge of the merges. So while the current state makes it difficult for us to find and use the data, all information required should exist and allow to update existing data once this is better supported.
I don’t know exactly how AcoustID uses the MB data, and which data it queries in real time and for what it relies on its own database sync. But since the information about merges is in the MB database it should be possible to handle this somehow.