Weird behavior from mass merge script (false length matches)

userscripts
classical
Tags: #<Tag:0x00007f2a09329878> #<Tag:0x00007f2a09329440>
#1

@steinbdj put in a bunch of recording merges using the mass merge script, along with a note that the lengths match well. The auto-comment that the script puts in claims they do too… but they don’t.

https://musicbrainz.org/edit/48088350 for example claims same track time. But it’s actually 2:44 vs. 3:06, a rather significant difference. Checking the recordings, ¾ of the album track times agree with the 2:44, but it also has a 3:06 on it. Seems like the mass-merge script used that time, ignoring the majority of them (I’d guess that’s the release that was targeted)… Also really weird that the same catalog number but released in different countries has different times.

Of course, it looks like a couple are missing disc IDs and one of the ones that has them doesn’t match the track times. So maybe it’s just data entry error, copied from release to release… One is also an impressively ahead of its time digital media release from 1986!

I guess I’m leaning towards the merge is correct, and the track times in the database are probably bogus. But it seems like the mass merge script ought to notice weird discrepancies like this.

[edit: I have this release. I have one with the bar code ending with a 9, catalog 415 132-2—so one of the two claiming 2:44. Both the printed booklet and the disc itself give the time as 3:06. So the times are probably just wrong. Interestingly, my disc ID matches the disc ID on the …8 barcode release. I suspect the two 9 releases should be merged and the only difference between the 8 and 9 ones is UPC vs. EAN.]

Merge duplicate recordings between two editions of the same album with “mb. MASS MERGE RECORDINGS”
#2

Track durations are same even though recording durations aren’t. Track durations used by this script are taken from tracklists of releases mentioned on edit note and these are having exactly same duration for this recording.

#3

This type of situation typically happens when editors add releases and select “release duplicates” from the same release group as a basis of new release. If you don’t check the durations you are easily adding incorrect durations to your release. For example one of these can be explained with https://musicbrainz.org/edit/30613598 which seems to use durations of digital download. Soon after it https://musicbrainz.org/edit/30613655 was done but “Set track durations” was never selected.

#4

It’s odd because the outlier track times are supported by DiscIDs. But for each track, there is one outlier track time. In any event, seems clear that these edits aren’t going to make the situation worse, so I’d propose letting them go forward. But I’ll keep an eye on this conversation and cancel if the consensus appears to be that we should do something else.

Thanks!

#5

I went ahead and selected it now. I thought that was supposed to happen automatically when you added the first disc ID.

Now I just get to figure out if I actually have two copies of that, since the one I was looking at last night had a different bar code… (Or maybe the bar code is different from the number printed under it.)

#6

Thanks @derobert this is good concern, it happens to me too and is sign of badly assigned track/recording that should lead to medium edit rather than recording merge.
The script should help this in the… future.
Thanks very much @ListMyCDs.com for your quick and accurate support! :bowing_man: