History:Album Rework Proposal

From MusicBrainz Wiki
Status: This page describes a failed proposal. It is not official, and should only be used, if at all, as the basis for a new proposal.



Proposal number: RFC-Unassigned
Champion: None
Status: Failed, due to Officially closed as Abandoned, March 24, 2010
This proposal was not tracked in Trac.



Introduction

This is my second try for an alternative/extending proposal to ReleaseGroups. I've given up some of the ideas in ReleaseHandlingPhilosophy (my first try) and steadily developed my ideas in ReleaseDataSet. But now I think I got the final idea. So here's what I think in one page (as requested ;) )...

The motivation of this proposal is to be able to render every existing case of albums with it intuitively and non-redundant but still keeping it easy to use. The first is achieved by splitting albums into several entity types which can be re-used and combined/linked. The latter is the challenge of the GUI.

Entity Types

There are several entity types for describing an album. I use the term "entity" here as in AdvancedEntities. They all can be part of an AdvancedRelationship (well, I don't know how much sense this makes for physical media yet...).

Release

A release is what you buy. It is released at a certain date in certain regions (sometimes also on different days in the regions) and unique identified by code number systems like the EAN, catalogue numbers, etc. A release can contain several albums. It is mostly equal to what I have described in ReleaseDataSet (except the different attributes described in ReleaseTypeRestructuringProposal are now spread over the entity types and this entity is more independent from albums).

The following is a technical description, so ignore it if you want. ;)

  • Parameters: title, (labelid, (cat#))*, (date, (region))+, (codesystem, code)*, status, packing, annotation (with backlog)

Where

  • title only contains text like "Limited Edition", "Re-Issue", "Gold Edition", ... (not the title of the released album(s)! they are stored in the linked albums)
  • status is one of: Official | Commercial | Bootleg | Promotional (so the release status values in ReleaseTypeRestructuringProposal)
  • packing is one of: jewel case | digipak | ...
  • annotation can contain detailed info about packing & shape, bonus stuff (stickers, autographs), mediums that could not be entered into the db and what not.

Album

The AlbumEntity holds one unique set of titles of one physical media, that is: the album title and links to TrackEntities (in a certain order) which then store their title and duration and so on. That means:

And again the parameter listing:

  • title, type, tracklisting, language, encoding, annotation (with backlog)

With type being mostly the main types in ReleaseTypeRestructuringProposal. Multiple can be selected.

Physical Media

This is the container for what was the DiscID and CD TOC before. It holds:

  • TOC, disc id, type

Where

  • TOC & disc id is normally for CD media only, perhaps we can create identifiers for other media types in the future.
  • type is one of the physical media types described in ReleaseTypeRestructuringProposal except digital media! Web albums simply don't get a physical media entity attached to them.

Box

The BoxEntity is used for linking albums contained in multi-disc-release together in a certain order. This applies only for releases which don't go under "one main album + bonus disc" but which are several discs which require an ordering.

Also: you can nest boxes into one another. So for these box sets which were (box 2, disc 3) before you would have one main Box, then sub boxes and then the albums.

Note: boxes cannot only contain albums released together in one release. We also could store those singles that have disc numbers although they weren't released together (which often is done in the UK) in one box - the difference is that they all link to their own release.

  • Parameters: title, annotation (with backlog)

The title holds the title of the whole box. If the albums in it have no own title (what we had in "(disc 1: Blah Blah)" before) then they simply have an empty title field.

Album Group

This is a set of albums that describe the same abstract album idea, like: different versions with bonus tracks, re-releases that differ somehow, transliterations/transcriptions/translations, remasters, but not re-recordings!

The purpose of this is to make linking with AdvancedRelationships easier. It is one of the meta groups described in AdvancedEntity. You could for example make an AdvancedRelationship to an AlbumGroup like "has ... performed by" which then is a statement about all contained albums.

  • Parameters: title, annotation (with backlog)

Linking

These are the entities so far. But the most complex part is the linking which unfolds the full potential of the entities. I divide that into linking by database IDs and linking with AdvancedRelationships.

Internal linking

First there are some problems that arise through the many different cases there are with releases. I identified the following:

  • One release can contain several albums
  • One album can contain several releases, or: a release can contain an album that was released before, which leads to:
    • One physical media (even with the same CD TOC) can be contained in several releases
    • But they cannot simply be referenced to from the release because the release is about several albums, so there needs to be a way to link them to album and release together
  • One album can contain several physical media identifiers (because it is an abstract title listing independent from different pressings of the physical media)
  • Info is not always complete - we can have an album without physical media and release attached or we can have just the physical media attached or just the release or both
  • Web albums don't even have a physical media to be attached
  • If an album was released alone and in a box together with others you need to attach the release to the box too or it is not clear if the release is about the box or the single album
  • ...

I'm no expert in databases but I found the following linking schema doing the job. If you think it can be simplified at some positions tell me and I (hopefully) can show you a case where this doesn't work. :)

Linking Album, Physical Media and Release: Table album_pm_release with columns album, pm, release as references with all rows being pairwise diverse and (album, pm, release) = (x,y,z)|(x,y,_)|(x,_,z) but not (x,_,_).

Linking Box and Release: One box can have several releases. One release can be about several boxes (only if there are transliterated/transcripted/translated versions of the box). Also you need to link the release to the box and not only to the albums to have it clearly identified. So we have table box_release with columns box, release as references.

Linking Box and Album: The linking needs to be ordered by numbers. So: Table box_album with columns box, number, album.

Same for linking Box to contained sub boxes: Table box_box with columns box, number, subbox.

And finally linking AlbumGroup, Album: Table albumgroup_album with columns group, album.

Open questions:

  • How to handle two-sided vinyl?
  • What about those DualDiscs (a disc with one side being a CD, one side being a DVD)? Handling them as one media leads to problems with tracklistings.

AR linking

All the new entities allow a wide new field for AdvancedRelationshipTypes. But also for the old ones I can think of some new types that might come in handy:

  • album is transliteration of album
  • album is transcription of album
  • album is translation of album
  • album is taken from album (which links singles to their albums)
  • I don't think transcription really fits here. Translation covers one language to another language and transliteration covers one script to another script. --Nikki

And an important change: Discogs URLs being about releases and not albums should only be allowed linking to Release entities. Though moving them there is tricky...

Examples

I will now apply this model to several example cases so that you see what I mean.

Example 1: bonus disc

Apocalyptica's Cult is a good example for bonus discs. It was first released as one disc. Then later this disc was released again together with a bonus disc as "Special Edition". Though we only have two albums in the database: "Cult" and "Cult (bonus disc)" and it's not obvious what was released when with what.

So take a look at a picture of how this model would look like with the new schema.

Example 2: Box with named discs

Tori Amos released the double album "To Venus and Back" with the studio album Orbiting being disc one and the live album Live, Still Orbiting being disc two.

The model looks quite obvious, eh? :)

Example 3: Box with unnamed discs

Dream Theater released the live album "Live at Budokan" as a 3 disc box (disc 1, disc 2, disc 3).

In the model the individual albums wouldn't have titles. Thus only showing them inside the box makes sense.

Example 4: Separate albums released again together

Bonus discs are not the only case where there is no clear disc number ordering in multi disc releases and though no box entity needed. Anathema first released The Crestfallen EP, then Serenades and then both together in one release but without disc numbering (as you can see on the covers).

See the model which also shows how the Discogs links are related to it being about releases and not albums.

Example 5: Transliteration

Different title listings, equal release & disc id. So why not share those both values? :) And Picard could - when doing a lookup for the disc id - use user preferences for language/script to select one title listing.

See the two albums in the db: Planet Pop 4, プラネットポップ4 and the model.

Example 6: Multiple releases

The last example is quite complex. The new Depeche Mode album Playing the Angel was released in many different versions. I go by the following:

  • EU: Normal Edition (1 CD), Deluxe Edition (1 SACD)
  • US: Normal Edition (1 CD), Deluxe Edition (1 CD + 1 DVD)

where all the normal CDs would share the same disc id although they were released in different packagings and by different labels!

The model for that.

Consequences

For presenting

Both albums and releases are equally important. Thus they should be presented equally. The discography of an artist becomes a tricky thing with this.. Only list the albums? Let the user choose whether to display albums or releases? For releases this is complicated as they don't store the album title, so what to display? At least there have to be search interfaces for the code systems identifying releases. A discography only showing albums has to take into account to show albums in album groups and boxes. Also an album released outside a box has to be listed again eventually.

Each entity type needs its own view. Those views have to differ so that it is a clear cut for the user what she/he is looking at ("Oh so this is a release! Maybe I should look at the album!"). The view for releases list all detailed data and a list of all connected albums / boxes. The view for albums has a list of all connected releases (together with attached physical media) but only shows basic info about them.

For the tagger

This is the next mess :-/

The protocol will change non-backwards-compatible. The album identification process goes: first identify the album, then select a release (not to speak of boxes). The CD lookup will get just an album as result or an album and a release (or several releases - or even several albums like the transliterated version in the example).

Separating box title from album title is a good thing for correctness in the db but players not making much use of ID3 info and having weakness in separating different albums with identical names won't like that. So there needs to be a way to "flatten" the data again - like building the album title like the user prefers it. I'm thinking about some sort of TaggerScript which (after the identification process is done) does the job of the tagging process and provides easy means for the user to let his preferences influence the tagging data.

For style guidelines

This is what you will like!

We will...

  • Drop DiscNumberStyle, eventually BoxSetNameStyle
  • Create new style guidelines for the type attributes, for how to connect the entities (like don't use boxes for bonus disc releases) and for the allowed contents of the release title field.

Outlook

After this is done for albums we can go one with artists and tracks.. AlbumGroups being meta entities for different versions of albums which make AR linking easier are just one thing. For tracks we can have songs as meta entities grouping all tracks being about the same abstract idea of a song / one (modified) recording of a song. See TrackGrouping for details.

That was it! Still here? hehe..

Comments

Shepard, hasn't this been superceeded by NGS? If so, should it still be, or should it be moved to Historical / removed? -- BrianSchweitzer 20:32, 20 August 2007 (UTC)

  • This is NGS. -- LukasLalinsky 20:55, 20 August 2007 (UTC)
    • That's what I meant by superceeded - was looking at it from the perspective of wiki intertwingling. (There's no mention of NGS here, nor linkage between the pages, so this then appeared to be historical (pre-NGS) discussion, not the actual NGS itself.) Was wondering if it and the related needed to be marked historical, or intertwingled into the NGS page(s). DeleteWhenCooked -- BrianSchweitzer 23:53, 20 August 2007 (UTC)