Difference between revisions of "User:Rochusw/Recordings"

From MusicBrainz Wiki
(Created page with "== Problems with Recordings == * Most casual editors don't know, which recording should be related to which track, because there is no obviously correct entity. So they choose...")
 
 
(15 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
* Most casual editors don't know, which recording should be related to which track, because there is no obviously correct entity. So they choose either a new recording (best choise, when in doubt) or a recording with the same name and a similar length.
 
* Most casual editors don't know, which recording should be related to which track, because there is no obviously correct entity. So they choose either a new recording (best choise, when in doubt) or a recording with the same name and a similar length.
 
* It is hard to split recordings, which were incorrectly merged (or reused, see above), because the information which fingerprint was added originally for which track is lost (can't be stored, because a track has no identifier).
 
* It is hard to split recordings, which were incorrectly merged (or reused, see above), because the information which fingerprint was added originally for which track is lost (can't be stored, because a track has no identifier).
 +
 +
== Fingerprints / Digests ==
 +
* '''Tracks should have an identifier'''
 +
* It should be difficult (require vote or at least confirmation) to relate more than one fingerprint of the same type to a track or master
 +
* A mix can be related to more than one fingerprint. A mix usually gets it's fingerprints from lower related entities (but needs to have fingerprints on his own, if it is a SAR)
 +
* It should be possible to store additional distinguishing attributes (e.g. DR rating) for tracks and masters
 +
 +
== Levels ==
 +
'''Most levels should be optional.'''
 +
Levels, that ''could'' be useful, are:
 +
* Work Group ("I don't know which variant of this work it is..." - some traditional works have this problem. Could be realized as an aggregate work with a proper "work level" marking)
 +
* Work
 +
* Arrangement (If we continue to use works for this, they should be marked at least as lower level. Search should display top level and show it has sublevels)
 +
* Performance Group (Perfomances by this artist. Tree-structure possible, e.g. subgroup by band-members, subsubgroup by tour ...)
 +
* Performance (Could be releated to Place/Time/Events. "Live" attribute should be on this level)
 +
* Mix (Probably the best choice for the current recording level)
 +
* Master (very optional, this level should be created only if you know exactly what you are doing)
 +
* Track
 +
 +
In most cases it should be possible even for casual editors to relate a track at least to the correct performance group. The release editor should make good suggestions, a start would be
 +
* Relate track to same mix, if the release is based on a release from the same release group.
 +
* Create new performance, if it is a live release.
 +
* Relate track to performance group with same "base" name of the same artist else.
 +
 +
== Lightweight Releases and Release Channels ==
 +
* A standalone recording (SAR) has neither release date nor cover art or other attributes that could be useful. Kepstin has some good thoughts about lightweight releases.
 +
* Sometimes recordings should have common attributes, but we have no "open" releases.
 +
* There could be a "Release Channel" entity (e.g. OcRemix or the Artist's homepage) and "SAR released at date on release channel" / "LWR released on release channel" relationships.

Latest revision as of 00:00, 26 December 2012

Problems with Recordings

  • Most casual editors don't know, which recording should be related to which track, because there is no obviously correct entity. So they choose either a new recording (best choise, when in doubt) or a recording with the same name and a similar length.
  • It is hard to split recordings, which were incorrectly merged (or reused, see above), because the information which fingerprint was added originally for which track is lost (can't be stored, because a track has no identifier).

Fingerprints / Digests

  • Tracks should have an identifier
  • It should be difficult (require vote or at least confirmation) to relate more than one fingerprint of the same type to a track or master
  • A mix can be related to more than one fingerprint. A mix usually gets it's fingerprints from lower related entities (but needs to have fingerprints on his own, if it is a SAR)
  • It should be possible to store additional distinguishing attributes (e.g. DR rating) for tracks and masters

Levels

Most levels should be optional. Levels, that could be useful, are:

  • Work Group ("I don't know which variant of this work it is..." - some traditional works have this problem. Could be realized as an aggregate work with a proper "work level" marking)
  • Work
  • Arrangement (If we continue to use works for this, they should be marked at least as lower level. Search should display top level and show it has sublevels)
  • Performance Group (Perfomances by this artist. Tree-structure possible, e.g. subgroup by band-members, subsubgroup by tour ...)
  • Performance (Could be releated to Place/Time/Events. "Live" attribute should be on this level)
  • Mix (Probably the best choice for the current recording level)
  • Master (very optional, this level should be created only if you know exactly what you are doing)
  • Track

In most cases it should be possible even for casual editors to relate a track at least to the correct performance group. The release editor should make good suggestions, a start would be

  • Relate track to same mix, if the release is based on a release from the same release group.
  • Create new performance, if it is a live release.
  • Relate track to performance group with same "base" name of the same artist else.

Lightweight Releases and Release Channels

  • A standalone recording (SAR) has neither release date nor cover art or other attributes that could be useful. Kepstin has some good thoughts about lightweight releases.
  • Sometimes recordings should have common attributes, but we have no "open" releases.
  • There could be a "Release Channel" entity (e.g. OcRemix or the Artist's homepage) and "SAR released at date on release channel" / "LWR released on release channel" relationships.