I’d like to get some eyes on edit Edit #102578339 - MusicBrainz and the thinking behind it. It’s a merge of three releases that have the exact same mastering, cover art, etc. but distinguished by different manufacturing of the disc. @dmppanda has extensively documented the justification in their edit note.
Arguments against the merge for me are (a) we have manufactured-at and pressed-at relationships, so we should be able to use them; and (b) it lets us link 1-to-1 to a discogs release. Neither of those are compelling to me personally.
The arguments for are in the note, but to me the most relevant are (a) it’s not a useful or meaningful distinction to 99.9% of users, (b) there’s no audible difference, and (c) data fragmentation makes maintenance harder. (As in a common formulation of Occam’s Razor: “Entities should not be multiplied unnecessarily.”)
Assuming these manufacturing details are visible somewhere (e.g. printed in the booklet), I would be against merging these sorts of releases.
Neither is almost all of the information we store that goes beyond track names, track artists, and cover art.
There’s no audible difference between two releases with totally different cover art either, or even between many digital releases and CD releases of the same album.
Overzealous data normalization/merging is just as big a problem. The edit note specifically mentions duplicate recordings, which can be easily fixed without having to merge the releases.
Been too long a day for me to reply… so I’ll just agree with @elomatreb and have a heap more I would add another time.
MB is about differences. Documenting differences is what we do. If one CD says “Printed in UK” and another says “Printed in Italy” then we make separate releases. If there are different price codes printed then we make new releases. Being pressed in a different factory is a new release because it often leads to its own visual differences too. Not always obvious, but sometimes the way the CD centre is pressed changes. We have Pressed By and Glass Mastered by relationships - why not use them fully?
All us database addicts have our own areas we focus on. It is not always about the sound. It is about the physical object.
Yeah, it can look at mess when you look at Dark Side of the Moon and see over 100 releases listed. But there are more changes between them than is obvious to the average person. And some of us like these stupid and irrelevant details.
As noted above - we separate Digital Audio due to the shop using a different barcode. Something that isn’t even see in the files. Details are interesting to some of us. And this is why this database lives as it does.
(And Discogs is overkill… I could go on a long tangent about how they go too far at splitting SIDs or tiny matrix details… but my head needs to turn off)
I also not read the long post on the edit yet. That is for tomorrow… but I did briefly look at the releases and they are a bit junky. Why they not got relationships setup for the details? It seems just some short disambig comments… if there are factory differences then these should be listed in relationships properly.
Edit: even the artwork is different in that merge. No Printed in Canada logos on the MFG EMI edition. This is kinda the point that some of us see and care about tiny details.
You forgot argument #5 which is quite meaningful IMO: because the releases are separated, their ARs can be different. In these particular releases, the ARs are quite different. Of course, these differences are purely historical, they should not exist. If we keep those releases separated, someone should manually ensure that all ARs from each release match those from the other release… Currently, as described by the comment, Picard shows 2 releases without any way to pick one or the other.
I am not saying these merges should be done, I understand some users could care about this data. But we should try to find a better way to do things;
I don’t edit based on Picard. I think that’s the difference. Some are editing for the data, and some are just trying to tag their files. This is as much of, if not more, IMO, a historical database for music than a tagging site. It’s not hard to go to the release on MB from Picard to make sure you have what you want instead of just relying on what you see on Picard. And what do you mean by “purely historical, they should not exist”? They do exist. That’s the point of a historical database. It’s to see the differences from release to release.
I pointed out in a discussion last year that Discogs’ database guidelines includes the following:
One edition of a release may have many different matrix numbers on individual copies - especially for major label releases. These are considered manufacturing variations for the purposes of cataloguing on Discogs, and not unique releases, so one Discogs ‘release’ may contain multiple variations in matrix numbers etc.
As I see it, it’s a matter of whether MusicBrainz wants to follow the same strategy. Personally, I don’t need to know that much detail, but I have been adding scans of CD matrix runout rings.
It’s not hard to go to the release on MB from Picard to make sure you have what you want instead of just relying on what you see on Picard.
Quite but counterintuitive, since all the releases should have the same ARs and bring the same tags in Picard.
And what do you mean by “purely historical, they should not exist”?
I was writing about the differences. The ARs are correct, but all the releases which those edits would merge should have the same ARs. “Historical” was not the correct word, but my knowledge lf English is not good enough. I meant that some editor happened to add an AR to one of the releases, another added another AR to another release, but actually all the releases should have all the ARs. Synchronizing the ARs across such releases is going to be quite tedious.
I guess we are actually missing a level in the data structure. But I guess this would imply a major change…
for what it’s worth, this probably is why it’s encouraged to add relationships to recordings rather than releases (at least, when you’re sure what recordings a relationship belongs to). the only exceptions I can think of would be relationships Picard doesn’t see, like illustration, mastering, and any places, events, releases, or areas, which most likely vary from release to release
I must admit I find myself agreeing with all sides in this debate. Several years ago I wondered why MB asked for a separate release for different art. Why not just apply all the art and data to the same release? The different art and data tell the history of the release, the music, the label, the artists, and whatever in that list I missed. At this moment in time I do not know what the importance of a piece of data will be in the future. My choice is to keep as much data as MB can.
It was before my time, but as I understand it the “remaster of” recording rel was deprecated in large part because it led to unnecessary duplication and made it harder to accurately manage the more interesting information. That’s always a tradeoff; more data is not always better. (Even detail-mad @IvanDobsky agrees that separate releases by SID code is a bridge too far.)
The question then is whether keeping separate releases for these cases improves the overall data quality and usability. Maybe it does for specific artists/areas that are lucky enough to have obsessive editors; unfortunately there aren’t enough obsessives to go around.
For artists without obsessive editors, honestly, you don’t get releases separated by manufacturer anyway, because they would in most cases not enter relationships at all, and in any case almost never enter manufacturing relationships
What we do get, though, is releases that are implicitly separated by manufacturer because they were imported from discogs entries that have specific manufacturing details. Then I come along with a disc that I just want to get tagged, and I have to decide whether to ignore the discogs details, or to create a new entry for my release. Being a reasonably scrupulous editor, I don’t want to just ignore it, as that might corrupt data (if for instance I add a disc ID). So I’m kind of forced into getting down to the manufacturing level of detail.
I only do what I was taught to do. When we have two different CDs with cover art that changes MB make new releases. If there are different price codes on the rear, MB splits the releases. If one says Printed in UK and the other says Printed in Italy then MB splits the releases. Seems logical that EMI Uden and EMI Swindon are therefore split as we have relationships for these differences.
Yeah, personally I am a details addict. I’ll pour over a CD and fill in all the copyrights. Even the cover designers if they are listed. I realise this is weird, but it is data that is interesting to some. A relational database means we can track where that same recording engineer appeared on multiple tracks.
I understand many are not interested in that stuff. That’s cool. Instead it means if you just want some quick tagging data then you’ll have a few different artwork sets to choose from.
Personal opinion I think Discogs goes too far. I don’t see why “Made in Germany by PDO”, “Made in W.Germany by PDO” and “MADE IN GERMANY BY PDO” should be different. Similar if a CD is printed for five years at the same EMI Swindon factory there seems no logical need to split versions when SIDs started to appear in 1994. If the rest of the other artwork stayed the same, then its logical that is still the same release.
There seems to be no argument about splitting on small artwork changes. In the merge that started this conversation there are some quite clear visual differences between the versions.
I also know I am not the only one who does this, but many others don’t talk or come to the forum who share this level of attention to detail.
BTW - what I really don’t like seeing are people who just blindly copy\paste a large chunk of Matrix data from Discogs as that is a waste of time. If matrix data is added then it should be from a disc in hand. (And there has been plenty of other discussions on that) Similar the people who just copy other data and paste it without using the relationships available (but that is a whole other topic).
We have way way more “catch all releases” than identified editions.
If we have some sorted out manufacturer editions, it’s that the work has been done with efforts.
I fully agree! Furthermore, I do not create new versions if the company name printed in the matrix has changed. As long as content and artwork hasn’t changed, it’s the same release. And I usually note matrix details of represses in an annotation.
Want some mad detail that doesn’t affect the music but requires a new release?
Due to a single line of text on the rear of this box I have had to add a new release. The company who takes credit for the artwork changed, so MB guidelines say “New Release”.
Yet it is clear the CDs have not changed, no content changed. New artwork, new release. Its all about the details
To be honest this discussion leaves me rather confused
That’s where I see myself too.
Fully agreed
Imo different matrix data, especially glass master companies and cat#s, usually imply different release dates and/or areas though artwork and content may be the same. I’m quite sure that many people are interested whether they have a reissue or the first edition of a release, even if comes from the same pressing plant.
And I’m also sure that these differences are much more essential than different barcodes from digital releases (I still don’t know where Qobuz hides it).
In my book it’s exactly the opposite, this one seriously mandates a new release. Different media manufacturer → different relationship → different release.
I think @ernstlx was responding to my comment about changing how a company text is printed - Made in Germany by PDO, MADE IN GERMANY BY PDO, Made in W.Germany by PDO are all really the same thing. i.e. the same company in the relationship.
I’ll pour over a CD and fill in all the copyrights. Even the cover designers if they are listed. I realise this is weird, but it is data that is interesting to some. A relational database means we can track where that same recording engineer appeared on multiple tracks.
