My sense is that most people agreed with this answer (emphasis mine )
I have some disputes regarding my edits and this thread seems very related to my issue.
It concerns CD matrices and “represses” of “releases” which are essentially the same.
No barcode and different print factory on this cover art but same cat#.
The only differences I see are the manufacturing locations, i.e. “Printed in the U.S.A" vs "Printed in Holand” on back cover. Or “Made in the U.S.A. by WEA Manufacturing Inc" vs "Manufactured by Victor Company of Japan Ltd Made in Japan” on CD.
Some have the barcode printed on varying places, it is the same though.
To me it looks like some people want to create and relate every version of a release on Discogs to MusicBrainz.
Should we really add a new release even if only the manufacturing details change but everything else stays same?
In other words, does a new manufacturer (printing location) constitute a new release?
Lets take a look at this as a simple user:
- He buys a release (doesn’t know which pressing, they are essentially the same anyway)
- He rips the tracks to his computer and wants to tag them with Picard.
- Picard now returns every release for his rip (n.b. represses usually have the same TOC)
- It’s more than 10 releases (just the represses)
What does the casual user do?
I guess he will be utterly confused and just chooses randomly.
I’ve noticed there’re relationships for these cases. Can we link multiple labels with the same relationship type to one release and upload varying printing/pressing cover art to the corresponding release?
Entering a new release just for differing manufacturing details duplicates much data IMHO.
In this particular case it seems like some (even if it’s just a little bit) of the actual printed text is different (“printed in Holland”), which is already enough to justify a no vote if it doesn’t match the release.
Assuming we’re talking about these:
Otherwise I don’t think too much data/ too many releases are a problem for MB, that’s what disambiguations and annotations are for. To make it really easy for the casual user we could just merge all releases, since they usually don’t care anyway, but personally I appreciate detailed data.
edit: oh and @Zas should probably be linked in to this conversation
One reason Discogs distinguish releases is because they have different prices on the market.
For example, a vinyl having 50 copies pressed in Japan back to 1983 may have a very different price than the exact same one repressed from same master with the exact same cover art in US in 1990… don’t ask me why, but this is the reality.
For major albums, like The Dark Side of the Moon CD it exists thousands of “releases” (different factories, different presses, different cover arts, different labels/catno/barcodes). Distinguishing them is a real pain, often differences are very slight. Whether they are different “releases” from MusicBrainz users point of view if often a very subjective matter. After all, digital music should be all the same … but in practice, we have different discids, different colours, different texts, etc… the limit is very fuzzy sometimes.
The case of vinyls of different colours is a good example, they may be made in the same exact factory, or not, and sometimes the cover art colour also differs, are they different “releases” or not ? But everyone agrees 1973 japanese vinyl release is pretty different from 2010 german vinyl release, even if they have exact same content and cover art, they will not have the same price on the market. Nor 20 red copies have the same price on the market than 200 black copies, pressed in the same factory, released at the same time.
MusicBrainz users aren’t only Picard users, they may be as well collectors, librarians, researchers, hobbyists, musicians, label managers, etc… if you merge all releases in one, because you think they are the same based on your own criterias, you may exclude users that don’t have the same criterias.
@chirlu said something correct, it is hard to manage all those releases, but my opinion is it is even harder to manage if you merge all major albums releases in one, because differentiating them is already hard. Many users are already uploading cover art totally unrelated to the release in MB (vinyl cover art for a CD release for example), and it is a mess to manage.
@aerozol is right, too much data isn’t much an issue in our database, i prefer “under-merged” releases than “over-merged” releases today because we don’t have tools to easily manage, for example, cover art merged by error.
@chaban seems to think Picard users are confused by those, but in fact most just don’t care about releases at all, and just use the first one, and i would think it is up to apps using MusicBrainz to please their users. Do you truncate a Wikipedia article because it doesn’t fit in your screen ?
@HibiscusKazeneko : in doubt, just create a new release, merging it later is always possible, and you can easily duplicate an existing release. Unmerging isn’t that easy.
Something that happened to me already, finding the exact release matching barcode/catno/label/year/country and full cover art, but noticed the tracklist was different, different discids, almost same matrix runouts… prolly an error in early production, quickly fixed, but in this case … same release or not ? We all agree different tracklists = different releases right ?
We have the case of the same “release” of a CD pressed in different countries/factories but released at the same date, with no distinction of CD source (from example CD pressed in Italy sold in France, while in the same time the CD pressed in France was sold in Italy, official CDs, same release date, exact same cover art, different matrix runouts, same discids). In this case i tend to think it should be considered as the same release with different matrix runouts. This is often the case for big sellers albums in Europe, when one factory cannot handle all.
So, in general, i don’t care matrix runouts, but for major albums with tons of releases i’m very picky about them because it is very hard to distinguish releases, since differences are very slight.
And to be sure one upload the right cover art, it is much better to have details in annotation, in clearly separated releases, etc… people are already messing between cassette and vinyl cover art … even though differences are obvious.
If you merge all The Dark Side of the Moon CDs in one release, because, after all, that’s almost the same data, and almost the same cover art (in many cases), it will not be easy to manage where it stops, we’ll then merge vinyls/CDs/digital and then you’ll end with Atom Heat Mother cover art for it … and collectors will hate you
To conclude i tend to think the smallest difference is still a difference, whether this difference is important is very subjective.
For me, my 1983 first edition CD bought from the artist during the last concert of the band is very different from the 2016 nth edition sold on Amazon having the exact same music / cover art / barcode / label / catno. Clearly different “releases” for me
Reading it, a release seems to be defined by its properties. Cover art isn’t mentioned (and details such as manufacturer).
Release Group style says re-issues should grouped together. How does MusicBrainz define re-issues?
The editing FAQ didn’t help much either:
There are releases with no cover art or even wrong covers! Can I change them?
Please make sure that you have selected the correct release, of course. Check the barcode and catalog number; if they don’t match your release, you probably are looking in the wrong place.
There are two or more releases with the same titles, should I merge them?
Releases should only be merged when the following requirements are met:
- The number of tracks are the same
- The track titles are the same
- The track lengths are the same (or extremely close if the release has no discID).
- The country, label, barcode, format, and packaging, are the same
- The cover art is the same.
The release dates, publishers, and distributors should probably also be the same to warrant a merge.
I found the same release twice. Which one should I remove?
Probably neither. If they are really identical (exactly the same tracks in the same order, same label, catalog number, and release country), you should merge the albums. This helps other users > update their tags, and also allows voters to check that it really is a duplicate.
An interesting bit in “How to add cover art”:
There is also a field for adding a short comment if you want to specify something about the image (like “misprinted first pressing”).
Cover Art doc says:
Cover art, also known as “album art” or “album artwork”, is artwork that provides a visual representation of a release. Normally it refers to the front of the release packaging, but the Cover Art Archive can store images of the back of the release packing, of the media itself, and of many other pieces — right down to the sticker on the shrinkwrap.
So, a release merge requires among others same cover art, publisher and distributor but not manufacturer.
But what exactly is part of a release?
I couldn’t find a distinct definition on MusicBrainz.
Has MusicBrainz adopted certain guidelines from Discogs?
I’ve canceled the controversial open edits.
This is exactly the kind of question I like to see.
If you’re looking for an all-encompassing description document that nails down every fringe case of exactly when something does and does not constitute a new release, not only does that not exist (and shouldn’t imo), because:[quote=“Zas, post:24, topic:79829”]
whether this difference is important is very subjective.[/quote]
Everyone has a different use case, and setting in stone whose needs and wants are more important than other peoples is a bad idea - particularly when we don’t currently have a problem with having ‘too many’ releases or ‘too specific’ releases.
Hopefully we can all live with creating a new release when another editor would prefer it, even if it is a minimal change that we don’t personally need to see differentiated. And hopefully other people will repay us the favour in future.
Even if we did create a doc I would want it written, in bold at the top:
merging is easier than untangling, when in doubt, make a new release and annotate and disambiguate
That said, if anyone can find a better way of doing the style guidelines/docs in a better way without making them over complicated and verbose, yes please!!
Well, i think Discogs definition of a release is very near of MusicBrainz’s one in practice. But MusicBrainz doesn’t define it as clearly for now.
Important points in Discogs definition is:
1.4.4. Manufacturing variations should not be counted as a unique release. For example; different stampers / matrix numbers for the same edition, manufacturing tolerance based variations in the shades of label paper or ink color, or unintended vinyl coloration caused by variation in vinyl stock, etc., would not constitute a unique release.
And the notion of “same edition” is perhaps what is lacking in this discussion.
So basically, i don’t know if MusicBrainz officially adopted certain Discogs guidelines, but for sure, in practice, many editors did. Perhaps just because it makes sense, and because many MB editors are also Discogs editors (which isn’t my case).
The fact is Discogs is one of the best sources when it comes to list different editions of an album, and often MusicBrainz is usually far behind in number of releases (not that quantity = quality, but when you have only 10 releases over 250+ editions i would say quality isn’t there either).
@reosarevok: time to improve official guidelines about what is a release or not for MusicBrainz ?
If someone suggests some good wording, I’m happy to look at it
I think Discogs’ approach is very sensible. And while having more releases doesn’t degrade the data quality, it could add confusion, especially because MB’s interface isn’t very good at displaying lots of information in a way that makes differences clear. So I’m not really in favour of having a different release for every matrix number or run-out code. I am of course, very much in favour of the “if in doubt make a different entity because merging later is easier than untangling” rule of thumb.
Here’s a little draft of what an updated guideline or FAQ could be like:
Thanks for your answers everyone.
I’m sorry for making such a fuss. These edits were a very premature optimization of mine.
I should’ve sticked to a consistent workflow. That is, uploading cover art to a (perfectly) matching release else creating a new one.
I have many more scans in queue, watch my collection.
When full scanned cover art of one of the candidates isn’t avalaible, you can’t compare.
Creating a new release, with full cover art & matrix numbers (in annotation and/or cover art) is the safest way.
Merging will eventually occur when both releases have full infos, scans of the CDs (for example) can then reflect the different possible matrix runouts for the same release.
I wish we had fields to store matrix runouts data instead of using annotation (may be, http://tickets.metabrainz.org/browse/MBS-8393)
Thanks so much for all the work, scans are the best!!
I think that is covered by my third point, though I think it could be more prominent.
Any news on this? Is there a ticket for it, or did it get into the official documentation?
To be honest I barely remember writing that post.
I think I was hoping further discussion would lead to an official proposal, but as you can see that never really happened.
Thanks for the info!
- In my opinion, we should definitely have some sharpening of the official guidelines telling us when two releases should be considered the same and when not. (There will always be corner cases, but it shouldn’t be hard to significantly improve the current situation.)
- I don’t see a reason why not to follow the discogs definition. First, it feels quite reasonable to me, and second, we should not break inter-database compatibility to discogs without a good reason.
- In a nutshell, I fully support the suggestion of mfeulenbelt.
@reosarevok What do you think? Shoudn’t we make something official out of this?
As @zas mentioned these:
- annotation is the most appropriate place for matrix/runout for now until it fits into other fields,
- scans of medium’s inner ring are welcome additions to cover art as proofs for further reviews.
Note that medium will soon have new attributes dedicated to SPARS code, mastering SID code, mould SID code, and matrix/runout numbers. This is a current top priority development, watch MBS-8393 for updates. When these attributes become available, existing identification codes in annotations will just have to be moved to the corresponding medium attributes.
I think differentiating different releases by matrix numbers is inevitable. Matrix numbers tell us about who manufactured a medium and when (by indicating the nth pressing). So even if we don’t use matrix numbers for differentiation, two releases with identical artwork, barcode, etc. will have different manufactured by or possibly manufactured in relationships. The start and end dates will further indicate the pressing of a release, further differentiating releases from the same manufacturing plant.
In most cases we will not know when a certain pressing is manufactured, but not knowing does not mean that information doesn’t exist. So the real question is, should MusicBrainz ignore certain types of information? Should the information we collect and organize be limited by our layout, or should it be the other way around, where the layout is designed to fit the data we want collect?
Sometimes CDs get remastered, but everything else (catalogue number, packaging etc.) remains the same. We can tell them apart using the disc IDs. The matrix number can be another way to identify one particular mastering, so it has its use. I’d only generate a new release when there’s an actual mastering difference in addition to the different matrix number…