History:Release Handling Philosophy Proposal
|Status: This Page is Glorious History!
The content of this page either is bit-rotted, or has lost its reason to exist due to some new features having been implemented in MusicBrainz, or maybe just described something that never made it in (or made it in a different way), or possibly is meant to store information and memories about our Glorious Past. We still keep this page to honor the brave editors who, during the prehistoric times (prehistoric for you, newcomer!), struggled hard to build a better present and dreamed of an even better future. We also keep it for archival purposes because possibly it still contains crazy thoughts and ideas that may be reused someday. If you're not into looking at either the past or the future, you should just disregard entirely this page content and look for an up to date documentation page elsewhere.
This is a proposal that is an alternative solution for some problems the proposal ReleaseGroups tries to solve. I'll give some definitions that are oppositional to the definitions in ReleaseGroups and show why I think ReleaseGroups is not the correct way to solve the problems we have with albums. Also this includes a slightly change in the MusicBrainzPhilosophy of WhatDefinesAUniqueRelease.
Please note: I have abandoned most of the ideas here and decided that a far reaching AlbumRework needs to be done to handle all the problems we have with albums.
Here are some terms used in this proposal:
- Album: The abstract idea of an album. One album can be released in multiple forms: on multiple media formats, with different track listings, as re-release, remaster, re-recording, live version, unplugged version, ... but it still falls under the same idea of the abstract album. One could collect all these versions in an AlbumGroup. This is what is proposed in ReleaseGroups. An album is there called release. But I think this is not what the music industry calls it.
- Edition: One edition or version of an album. Like "original edition", "basic edition", "limited edition", "special edition", "gold edition", "live edition" and so on and so forth.
- Release: The actual release of a certain version of an album at a certain release date. All info concerning one release is to be stored in a ReleaseDataSet.
- AlbumEntity: This is the way we store albums in the database. And album entity combines the abstract idea of an album with a certain release in a way that an abstract album idea will be listed multiple times in the discography.
The basic idea...
...of this proposal is: keep AlbumEntities mostly as before. Don't separate the abstract idea of an album from one actual release or data-set but change the guidelines a little bit.
So we go on saying: in the MB understanding of an album different characteristics of an abstract album idea mean different AlbumEntities. But: more tolerant (but precise) guidelines for repeating identical track listings.
Also: allow "Special Edition", "Gold Edition", ... as legal SubTitle
s if they are printed on the cover. This automatically leads to them being allowed as duplicates. Example: Apocalyptica's album Cult was released in two editions: in 2000 as a normal 1-disc album and in 2001 as a 2-disc album with disc 1 being identical to the previously released 1-disc album. The 2001 edition has "Special Edition" printed on the cover. So what is now "Cult" and "Cult (bonus disc)" would then become "Cult", "Cult: Special Edition (disc 1)" and "Cult: Special Edition (disc 2)".
This can only be done if we allow DiscIDs to be added to multiple nearly identical albums.
Smaller differences which don't justify extra AlbumEntities are expressed through different ReleaseDataSet
s of one album. For this reason the current release data is to be extended. So: "Album Title (Re-Release 2004)" will be stored with an extra ReleaseDataSet under the original AlbumEntity if it doesn't have a different track listing and the track times only differ slightly.
Why not release groups?
The ReleaseGroups proposal was written among others to solve the problem of BoxSet
s but it does not solve it. Example: you have a single being released alone in different versions and one of these versions released in a BoxSet. With ReleaseGroups you sort this single under a group which combines the different versions of the single. But also you want the single released in the BoxSet being grouped in this BoxSet. So there is an overlapping of the groups.
I think now that we have AdvancedRelationships we don't need groups. We can:
- link different re-releases of an AlbumEntity to the original release.
- link remasters to the original release.
So why not also use the PowerOfAR for doing the rest? Something like...
- "is in (box) set with" (perhaps better to think of a link form to just link to the first disc)
- "Single is taken from Album"
- "is re-recording of"
- "is special edition of" (for different versions released at the same or nearly the same day)
- "is [official released] translation/transliteration of"
The rest is then only a question of displaying the info. We have redundancy with release dates of multiple discs selled in one set. We have redundancy with links to reviews which only write about an abstract album but not one single release (but some do!). We have redundancy with Wikipedia articles about abstract albums. We have redundancy with links to Discogs entries which span multiple discs. And we have the same for artists (PerformanceName, LegalName). I think all this can be solved with AR and some work on the displaying interface. How to do this I explain in DisplayInheritance.
Hmm, I still feel that an AdvancedEntity (in your case AlbumGroup) would make a lot of sense here. This way you could link the album entities to the group and not to the first released album. --DonRedman
I'm not sure I understood the solution. It seems to me that you are creating even more AlbumEntities with this proposal. How would a BoxSet release be represented? As a bunch of AlbumEntities (one for each "disc") which are duplicates of the identical single releases of the discs?
And you always need the first of any of those entities to do the linking, it doesn't seem to work with an incomplete dataset which is the more common case in MB. --Fuchs
My twocents: What we currently have in the DB as "Albums" are actually "discs". Not albums, not releases, not editions, but discs. An album can be made up of multiple discs. The exact same disc can be released on its own, as a re-release with an extra disc, or as part of a box set. If the track listing is the same across multiple releases and the sound on the disc is identical, then it's the same disc, regardless of which country it comes out in, what's printed on the cover, or what else is in the package. The slightest difference to the bits on a disc (remastering, extra tracks, etc) make it a different "disc".
The proposal above would encourage massive duplication of information, with the same disc listed multiple times in the database -- In your above example, "Cult" and "Cult: Special Edition (disc 1)" should differ only in album title, but a user might correct a typo in a trackname in one version, but not know to correct the other, meaning bad information could persist.
- I totally disagree. What we have in the DB currently is for two reasons NOT a disc. The first reason is that "disc" is a term referring to physical media. But in the DB we have: Compact Discs, Vinyl Discs, Cassettes, Web Albums, ... The second reason is: the current definition of Album in the DB is neither release-orientated nor orientated at abstract albums but between. We list different editions of one album idea as different AlbumEntities but we do not list different releases (with identical tracklistings and nearly identical track times) as different AlbumEntities. That is we store multiple disc pressings under the same AlbumEntity then.
- OK, semantics. What we have in the DB is a "lump of plastic which somehow can be used with a Hi-Fi to recreate sound", which in most common cases is a CD. Since 99% of album releases on cassette or vinyl contain the exact same music as is on the CD, that point is moot. Take a look at my comments at the bottom of ReleaseGroups and see if that makes sense to you. I think we're both wanting the same thing, but have different ideas on how to implement it in the DB. -- RodBegbie