History:Release Data Set Proposal

From MusicBrainz Wiki
Revision as of 14:05, 14 October 2005 by Shepard (talk | contribs) (rewrote some parts, refined fields of RDS (Imported from MoinMoin))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

As described in AlbumHandlingPhilosophy the release data of albums needs to be expanded. This is a proposal for replacing the current ReleaseDates, consisting of a date and a country, with a more detailed set of data, the ReleaseDataSet.

Attributes

One AlbumEntity can have multiple ReleaseDataSets. They store the following fields:

  • 0 or more DiscIDs
  • One or more release sets including:
    • Date
    • Region (optional)

As you see DiscIDs can be assigned to one actual release.

Release dates do not necessarily need to store a country. Also country is now replaced by region which also contains Europe, worldwide and such (see ReleaseRegionStyle). Allowing more than one of those date/region sets makes it possible to list multiple countries (with possibly different dates) for the same piece of media.

LabelEntities are described in the AdvancedEntity proposal. The ReleaseDataSet only stores the reference to the entry in a special label table. The set can handle multiple label references if there is more than one label (or the distributor) mentioned on the cover. Also it can optionally store a catalogue identifier for each of them as often the label and the distributor have their own catalgoue identifiers for the same release.

The AlbumEntity then stores:

  • ID
  • Name of the album
  • Artist ID
  • Track listing
  • an initial set of track times if imported from freedb
  • a list of ReleaseDataSets including the set "Unidentified" (explanation below..)
  • perhaps two fields for recording date and place (redundancy for later releases of the album solved with DisplayInheritance)
  • Language and encoding

Converting to this model

If this will be implemented we need to make sure all the data can be converted to the new model. So if DiscIDs are to be attatched to ReleaseDataSets how will this be done when converting?

I therefore propose always having a ReleaseDataSet called "Unidentified" where all the DiscIDs will be put first. They can then be moved to another set.

Presenting the album

This is rather much information so I propose showing only the most important bits and link to a a page showing more details of a ReleaseDataSet which also allows to edit it.

The sets are shown below the track listing and the fields which belong to the whole album (like language/encoding). The set "Unidentified" comes first, then the other sets sorted by (lowest) release date.

On the left we have the most important info of the set (the title "Unidentified" or for the others "date - region <line break> LabelName <line break> more..." with "more" being a link to a page for more details) and on the right the list of DiscIDs for this set (including to total running time and links to move/del the id).

Selecting the info important for the whole album

If we have multiple ASINs then which cover should be displayed? If we have multiple DiscIDs then which track times should be displayed?

If there is no DiscID take the track times from freedb (if none are present display ?:??). Otherwise take the arithmetic mean of the times in the DiscIDs (or first prefer the ids stored under the earliest release date).

If there are several ASINs take the one from the earliest release date.

See also

Discussion


| Original author: Shepard