How to revert recording merge?

Tags: #<Tag:0x00007fbc81092b68> #<Tag:0x00007fbc81092a78> #<Tag:0x00007fbc81092960>

Edit #60587125 is incorrect:

Recording from “Избранное” album — WITH orchestra.
Recording from “Интервью” album — WITHOUT orchestra.

Is there any was to revert the edit?

1 Like

I’m afraid there is no way to fully revert it. Old MBIDs will forever redirect to the new MBID.
Only thing that can be done now is to split them and disable wrongly attached AcoustIDs.



I will take few weeks from me, because I’ll have to wait a week to have each edit applied… :frowning:

If you link your edits here then people could probably vote on them to apply them faster.


@nedotepa, see how “same length” is the typical bad reason for merge: How is "compilations" a reason to merge? :slight_smile:

@Van_de_Bugger, there is unfotrunately no undo/revert.
It’s a tedious manual redo with loss of history.
You have to create a new standalone recording for the most recent added track.
After the creation of this track, badly merged recording should relate to the oldest added track.
You have to add data to it (AcoustID, ISRC, relationships) that you can confirm they should be there.
You have to remove everything from badly merged recording (AcoustID, ISRC, relationships) except those that you can confirm they should be there.


I thought about this for a while.

Wouldn’t it be possible to turn tracks into MB entities as well? Maybe not as visible and noticeable as other entities, but “in the background”. So e.g. if recordings are merged the MBIDs are still linked to the individual tracks, the acoustids, ISRCs and all that too. The recording displays all the identifiers, but there could be a “split” button which instead of creating a new recording with a new MBID reuses the ID from linked to the track you are splitting out and the acoustids and ISCRs get moved too.


That (meaning paulakreuzer’s proposal) seems like it would require keeping a lot of redundant data that would in most cases never be used.

What about if the edit logs recorded historical MBIDs? Currently, once multiple recordings are merged into another, it’s impossible to identify what edit events were associated with which source. If the previous MBIDs were preserved in the logs, one could at least reconstruct which recording an ISRC was originally attached to. (Acoustids are trickier, since they’re not in the edit logs at all.)


How about just adding a “split recording” edit type (didn’t we have that at some point in the past?) which would have an option to move ISRCs, AcoustIDs and relationships (if there is more stuff than that too) into the new recording?


But how would you know where these identifiers belong to unless you can somehow see how they came to the recording?


Ah, that did not occur to me when I was typing my response. You obviously do have a point there :slight_smile:

1 Like

But “same length + same release group + similar track sequence” is, however, very good reason.