Merging Works - Oldest or most complete target?

Does everything get transferred to the target work if the source has better/more info than the target?

I’m looking at this edit. The target has much less information than the other, but the editor has indicated that he chose the target because it’s the oldest.

I know the merge How-To for Releases says you should choose the more complete release, because certain things aren’t transferred. Is that true for Works as well?


In this merge, the only thing that will not be transferred is the full caps title.
If the duplicate had a disambiguation comment, it would not be transferred either.

Here, according to all recordings, full caps title is wrong, and there is no comment.

So no problem.

If problem, anyway, we could still edit the target to correct it.


The Style Leader and/or Community Manager have said you should prefer to merge into the more correct entry / more used entry, even if it’s not the oldest.

In this case, since it’s a lazy J-WID import, the full caps title is wrong, and the oldest target should be far more used than the brand new lazy import.

1 Like

I believe the spirit of merging to oldest is to limit the possibility of breaking links. if one is more used, that should be the target.

1 Like

MusicBrainz merge edits don’t break MBID links, so that’s definitely not the spirit.

Merge edits could change the “primary” MBID delivered by the webservice to clients, but I was told that MusicBrainz doesn’t care if this happens.

That doesn’t always add up. Often you will find the better quality item is due to it being more popular \ better linked so has had the data better checked.

One of the main things I look at when merging is how many entities are linked with the aim to cause least disruption.

1 Like

Thanks for the education.

Indeed, to prevent breaking outwards links. *
There are more outwards links in older entities (you identify them thanks to their lower row ID).

* Links that use the current page MBID to find stuff in other sites (although kind of almost never used, IMO) or in your local files (maybe for some foobar2000 foo_run MBID based scripts, I don’t know) or memory.

This is not always the case and needs to be checked. It is very common for a newer release to have many more links attached to it. Old just means Old. It does not imply most used\most linked.

An example: And old recording is added in 2015, but has no length attached. Maybe it was on an LP or no DiscID available. A newer recording is added with a length in 2017. Now for the next five years it is this newer recording that is being attached to compilations and other releases and has dozens of outward links. Finally someone adds a length to the oldest recording and needs to now merge it as they can see it is really the same recording.

This is an example of when you’d merge to the “newer” recording due to more links.


You can’t really check the kind of links I mentioned, so I always assume the older the better:

It’s true that my kind of links are ultra rare.

But as all the links you mention are MB managed links (URL relationships, etc.) so there is no problem merging in either ways.

Then it’s more logical to me to keep merging towards the original or older entities rather than towards the duplicates.

It’s a no-brainer and I can use the small time I save doing this, in more important things or things that really require useful research.

When you see fifty releases attached to a recording, and one link attached to a different recording, it is pretty easy to take an educated guess as to which has more external links.

I assume you click on and at least look at all recordings you are merging? Blind merging without checking is dangerous. I’ve been untangling a whole raft of blind merges lately caused by cover bands who perform covers of artists like “Vangelis”, but incorrectly have Recording Credits set to Vangelis instead of the person performing the recording. These can’t be spotted when a merge is just done on time or AcoustID. You always have to double check what you are merging by at least opening the recording and checking the Release it is on.

And in the process of opening the Recording page you can see the number of Releases linked to it, making picking the target of a merge easier.

The 50 release attached recording’s MBID may have been created 7 days ago only for one release, and then a very old 49 release attached recording was merged into it (bad).
Then any other recording’s MBID (even 1 release) will be easily older than 7 days.

I’m not talking exactly of external links, there is absolutely zero problems with external links that we do see in MB, whatever the direction of the merge is.

I am talking of these rarer outside uses of MBID, that are broken when you don’t merge towards the oldest MBID (that can be the recording with 1 track vs the recording with 500 tracks).

And yes I do check my merges, but errors always happen (usually when a recording has been reused by totally unrelated track in a previous Add release or Merge recordings edit).

And that is not what I am saying, if you read my example. I even put years into my example. And it is based on experience. But I will leave the discussion as I can see you do not want to understand my point.

1 Like

Sorry for not understanding and not being able to explain my example.



Ah! This one, sorry I didn’t read it entirely, at first.
OK, I see.

I am scared to death of being the cause of some of the horrible mergers I have seen. I am not merging just to pass the time. I want all versions of Gene Autry’s 1947 recording of “Here Comes Santa Claus (Right Down Santa Claus Lane)” on one page, with all the correct spellings, information and dates. I want another page with the 1957 re-recording he did, another for the 1962 version, and so on. None of these versions should be on the wrong page, because if I had any doubt, and the accousticIDs or timings failed to match, I should never have merged it.

You only merge items that pass your proprietary method of proving they are the same recording, and your method better be good! Open each recording? What? If you are in too much of a rush, or too lazy to do this, please don’t merge anything anymore, because you are doing it wrong. Not everybody is cut out to do this, just like not everybody is cut out to be a brain surgeon. It is also not right to decide you are not cut out to be a brain surgeon halfway into your second lobotomy; you should have quit when you chopped up your first patient! Same for merging, if you merged Kate Smith’s 1939 version of “God Bless America” with a live tape recorded at a baseball game that was also 2:46, that is your signal to never merge again.

Friends, my final message for today’s sermon is after you master the skills required to merge on this website, then we can quibble over what makes the best target. Oldest is not a rule, it is a place to start. You have to check each candidate, and you can decide which makes the best target after you eliminate all those with mispellings and scant information.

The rest I still need to learn more about:
I am curious if a recording with multiple discs, a scanned booklet and other complex details affects the process at all. I like to merge into the one loaded with pictures, information and links. If it happens to be the oldest, that’s fine, but if not I would still do it.


Much of the time when you see wrongly linked tracks and recordings it’s not usually because of a prior merge, even though of course it can be. I believe mostly it was just picked wrong when adding the release to start with. Unfortunately, many editors just pick what is first suggested to them in the recordings page of an add due to it being the same time. And it’s correct most of the time, when dealing with modern recordings, but can cause issues on older ones that have been re-recorded multiple times.


If I was Attorney General of Musicbrainz, I would file a criminal complaint against discogs for negligent music homicide for the bad information that goes from their website to ours. As for their mb accomplices that use import script without checking, I will be in my office for 2 weeks researching that.

1 Like