Probably a merge in progress that’s not finished yet, because the AcoustID server is lagging behind in submissions. I see the second one as an id only, but the two recordings still exist instead of being merged and one redirecting to the other.
Indeed, there is a recording merge (queued today) in progress, including these 2 recordings, but I don’t think we see that 2nd italic recording because of that: The same merge includes a 3rd recording that is not visible, in AcoustID.org.
Yes, I think it means the AcoustID was linked to a source recording which was merged into this target recording. An AcoustID fingerprint will not move from the source recording to the target recording during a ‘Merge recordings’ edit (in MB). However, the AcoustID track will still have this (now re-directed) recording ID for the original source recording.
I forgot I have a WIP modified version of @loujin’s acoustid-merge-recordings.user.js that resolves italic MBID into their merged title and artist…
I have updated the OP.
Merged recordings really lose their AcoustID, forever?
Unfortunately it seems this is the case, but it isn’t widely known as I’ve informed a number of regulars on some edits. The original question (as far as I know) was posed by @IvanDobsky in Edit #95328271 - MusicBrainz. I’ve mentioned it in a few edits similar to Edit #107685644 - MusicBrainz.
it’s been an issue much further back than that; talk then that those in the source recordings would eventually show up in the target has little evidence (afaict) to show for it. it’s why one should make sure the target in a recording merge has at least one (if not more, or fingerprint-comparable) common acoustid with the others, even if it might not be the one with the oldest mbid. also good practice imo to add the referenced acoustid(s) to your edit note, for future reference in recordings’ edit histories.
I agree that this is a very old issue. I added my edit note as a test so I could literally track it from a live example. Many years before then I had been doing a number of merges using AcoustID as a guide and had a feeling there was an issue, but never traced it.
In the beginning of AcoustID it was working, at least.
Now it feels like the supposedly nightly batch in charge of resolving MB merges (following MBID redirects and update AcoustID database accordingly) is either no longer running at all, or unable to go through all pending MBID.
Wouldn’t it be nice to have a status on this long standing issue?
If AcoustID are just disappearing from MB sight, it makes them quite vain.
