Label: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
(answer to shep (Imported from MoinMoin))
(answer to the furry animal. replaced (,) pairs by <,> pairs (Imported from MoinMoin))
Line 92: Line 92:
The system currently has known limitations, that may be solved later:
The system currently has known limitations, that may be solved later:
* Ideally, we could be able to attach multiple release events (release date and country) to a unique catalog number / EAN. -- [[User:dmppanda|dmppanda]] 21:22, 03 November 2006 (UTC)
* Ideally, we could be able to attach multiple release events (release date and country) to a unique catalog number / EAN. -- [[User:dmppanda|dmppanda]] 21:22, 03 November 2006 (UTC)
* Also one release event could use multiple labels. For example Inside Out Music records are always distributed by SPV and they have an SPV catalogue number as well as an IO catalogue number. Therefore I think one "release set" should contain: several (release date, release region) pairs, several (label, catalogue number) pairs and single fields such as the [[EAN]] (of which the barcode is just the representation, but could leave the name like that as it's easier to identify for users which don't know that). -- [[User:Shepard|Shepard]] 13:37, 07 January 2007 (UTC)
* Also one release event could use multiple labels. For example Inside Out Music records are always distributed by SPV and they have an SPV catalogue number as well as an IO catalogue number. Therefore I think one "release set" should contain: several <release date, release region> pairs, several <label, catalogue number> pairs and single fields such as the [[EAN]] (of which the barcode is just the representation, but could leave the name like that as it's easier to identify for users which don't know that). -- [[User:Shepard|Shepard]] 13:37, 07 January 2007 (UTC)
* ARs such as the [[Discogs Relationship Type|DiscogsRelationshipType]] and the [[Amazon Relationship Type|AmazonRelationshipType]] would ideally be attached to a release set - but I guess that has to wait until we can separate between releases and albums. :) -- [[User:Shepard|Shepard]] 13:37, 07 January 2007 (UTC)
* ARs such as the [[Discogs Relationship Type|DiscogsRelationshipType]] and the [[Amazon Relationship Type|AmazonRelationshipType]] would ideally be attached to a release set - but I guess that has to wait until we can separate between releases and albums. :) -- [[User:Shepard|Shepard]] 13:37, 07 January 2007 (UTC)
** I'm not sure I understand correctly these last points. How would we allow: on one hand, a single release event (country, date) to be linked to several different label/cat/bar (as in your example), and to single AMZ/Discogs links, and on the other hand, a single release set (single label/cat/bar) to be linked to several different release events and several different AMZ/Discogs links? Though this question is theoretical ;) - Also do you imply that Discogs/AMZ links should be unique to a release set? -- [[User:dmppanda|dmppanda]] 16:15, 07 January 2007 (UTC)
** I'm not sure I understand correctly these last points. How would we allow: on one hand, a single release event (country, date) to be linked to several different label/cat/bar (as in your example), and to single AMZ/Discogs links, and on the other hand, a single release set (single label/cat/bar) to be linked to several different release events and several different AMZ/Discogs links? Though this question is theoretical ;) - Also do you imply that Discogs/AMZ links should be unique to a release set? -- [[User:dmppanda|dmppanda]] 16:15, 07 January 2007 (UTC)
*** Well, one release date could refer to several label releases (ie, different pages on amazon and discogs), and indeed, different release dates could refer to different label releases. Finally, one label release (ie, page on amazon and discogs) could be a release on 2 or more labels (eg [http://www.discogs.com/release/374880 http://www.discogs.com/release/374880]). I think the best way to to this would be to allow for ARs (specially discogs and amazon ones, perhaps others) specific to release events, but this is probably difficult/impossible. Ultimately I think this will all be easier to deal with when NGS gets here. -- [[User:Gecks|Gecks]]
*** Well, one release date could refer to several label releases (ie, different pages on amazon and discogs), and indeed, different release dates could refer to different label releases. Finally, one label release (ie, page on amazon and discogs) could be a release on 2 or more labels (eg [http://www.discogs.com/release/374880 http://www.discogs.com/release/374880]). I think the best way to to this would be to allow for ARs (specially discogs and amazon ones, perhaps others) specific to release events, but this is probably difficult/impossible. Ultimately I think this will all be easier to deal with when NGS gets here. -- [[User:Gecks|Gecks]]
*** My initial idea in [[Release Data Set|ReleaseDataSet]] was to have one set for each unique release (identified by the EAN for example, although sometimes not even they identify a unique release). In this set you would then have a list of <release date, release country> pairs - still for this unique release, because different countries have different days in the week when music is mostly released, so the item with the EAN 1234567890123 could be released on Monday in .de and on Wednesday in the UK for example. Then you would also store a list of <label, cat> pairs, because different labels work on one unique release - as I described in my example above, [[Inside Out|InsideOut]] releases are always distributed by SPV and both have their own catalogue system. And then you store other identifiers in this set, like the EAN, Discogs/ASIN stuff (yes, unique to a release set).<br/> Note though that this page here is about a first step into the right direction. The ideas in [[Release Data Set|ReleaseDataSet]] are relativised by [[NGS]] where the whole tracklisting with titles, tracktimes, [[Disc ID|DiscID]]s and so on would be included in a "release set". So, not everything needs to be coded yet, limitations are implied. One label per release date is a good start. If this was to be extended before labels go live, I would prefer multiple labels per date over multiple dates per label, but that's just a personal preference. -- [[User:Shepard|Shepard]] 15:22, 09 January 2007 (UTC)


==Discussion==
==Discussion==

Revision as of 15:22, 9 January 2007

~+Labels +~
Content:

Template:LabelsStatus

What is a Record Label?

Record labels may refer to:

  • Music groups:
    • A music group is a financial holding, whose purpose is solely to control and manage other companies directly involved in the production of sound recordings
  • Record companies:
    • A record company manages imprints, and coordinates the production / manufacturing / promotion / enforcement of copyright protection / relations with artist / PR / distribution of sound recordings. Record labels may directly handle one or more of these aspects, or may sign contractual agreements with other companies to do the job.
  • Imprints:
    • An imprint is (strictly, and nothing more than) a brand (and trademark) associated with the marketing of sound recordings (an imprint is not a company). An imprint may be marketed as a project, unit or division of the company that manages it.

MusicBrainz should keep track of imprints, companies involved into either production or distribution, and to some extent music groups. Typically, all these informations are available on the media sleeves.

At that time, we don't think we should keep track of companies involved in the other aspects of the music industry (PR...), or get into too much financial details. There are two reasons for that:

  • such informations are usually not available from sleeves
  • they are probably irrelevant to MusicBrainz goal (being a music database)

Informations about labels stored in the database

These fields are stored directly in each label's record:

  • LabelID: the UUID of the label (not editable)
  • LabelName: the name of the label
  • LabelSortname: the sortname of the label
  • LabelAlias: aliases
  • LabelCode: the unique code of the label
  • LabelBeginDate: this is the creation date (or "first used name" date) of the label entity
  • LabelEndDate: this is the date at which the company went bankrupt, was dismantled, or the name was used for the last time
  • LabelComment: field to distinguish between identically named labels
  • LabelAnnotation: general information about the label that may be of interest to other users
  • LabelCountry: the country in which the company was founded
  • LabelType: the "type" of the label

Many other kinds of information can be represented using AdvancedRelationships. You can read AdvancedRelationshipTypes for informations on all kind of relationships, or more specifically check LabelRelationshipClass for label centric informations.

Editing labels

Any MusicBrainz user can edit labels in several ways:

Informative external resources about labels

300px-WMM-nielsensvg

The following sites are useful to find labels homepages:

Wikipedia has an extensive labels list, and a lot of articles:

Genre oriented resources:

Global market share overview:

  • There are mainly "4 big ones": Universal Music Group, EMI Group, Warner Music Group, and Sony BMG who own a vast majority of all other labels.

F.A.Q./Miscellaneous

How to handle autoreleases?

In some cases, artists "autoproduce" and "autorelease" their own records. As long as an imprint is possible to positively identify, it should be used as a label entry. If there's no such thing, or if the creation of such a label entry is discutable, we may want to use SpecialPurposeLabels (possibly [autorelease]).

Can an imprint and the company that controls it have the same name?

Yes, definitely. Actually, a company "A" may sell its own imprint "A" to another company "B" and continue to exist as company "A", while the imprint is being operated by company "B"... This can result in really confusing situations... Usually though, editors in MusicBrainz will deal with imprints exclusively (which *is* the information available on sleeves).

Known problems and limitations

The system currently has known limitations, that may be solved later:

  • Ideally, we could be able to attach multiple release events (release date and country) to a unique catalog number / EAN. -- dmppanda 21:22, 03 November 2006 (UTC)
  • Also one release event could use multiple labels. For example Inside Out Music records are always distributed by SPV and they have an SPV catalogue number as well as an IO catalogue number. Therefore I think one "release set" should contain: several <release date, release region> pairs, several <label, catalogue number> pairs and single fields such as the EAN (of which the barcode is just the representation, but could leave the name like that as it's easier to identify for users which don't know that). -- Shepard 13:37, 07 January 2007 (UTC)
  • ARs such as the DiscogsRelationshipType and the AmazonRelationshipType would ideally be attached to a release set - but I guess that has to wait until we can separate between releases and albums. :) -- Shepard 13:37, 07 January 2007 (UTC)
    • I'm not sure I understand correctly these last points. How would we allow: on one hand, a single release event (country, date) to be linked to several different label/cat/bar (as in your example), and to single AMZ/Discogs links, and on the other hand, a single release set (single label/cat/bar) to be linked to several different release events and several different AMZ/Discogs links? Though this question is theoretical ;) - Also do you imply that Discogs/AMZ links should be unique to a release set? -- dmppanda 16:15, 07 January 2007 (UTC)
      • Well, one release date could refer to several label releases (ie, different pages on amazon and discogs), and indeed, different release dates could refer to different label releases. Finally, one label release (ie, page on amazon and discogs) could be a release on 2 or more labels (eg http://www.discogs.com/release/374880). I think the best way to to this would be to allow for ARs (specially discogs and amazon ones, perhaps others) specific to release events, but this is probably difficult/impossible. Ultimately I think this will all be easier to deal with when NGS gets here. -- Gecks
      • My initial idea in ReleaseDataSet was to have one set for each unique release (identified by the EAN for example, although sometimes not even they identify a unique release). In this set you would then have a list of <release date, release country> pairs - still for this unique release, because different countries have different days in the week when music is mostly released, so the item with the EAN 1234567890123 could be released on Monday in .de and on Wednesday in the UK for example. Then you would also store a list of <label, cat> pairs, because different labels work on one unique release - as I described in my example above, InsideOut releases are always distributed by SPV and both have their own catalogue system. And then you store other identifiers in this set, like the EAN, Discogs/ASIN stuff (yes, unique to a release set).
        Note though that this page here is about a first step into the right direction. The ideas in ReleaseDataSet are relativised by NGS where the whole tracklisting with titles, tracktimes, DiscIDs and so on would be included in a "release set". So, not everything needs to be coded yet, limitations are implied. One label per release date is a good start. If this was to be extended before labels go live, I would prefer multiple labels per date over multiple dates per label, but that's just a personal preference. -- Shepard 15:22, 09 January 2007 (UTC)

Discussion

  • The use of a label entity for collections names must be made with extra-care. Definitely, one must not use collection names printed on the front cover as a label name, but only if the collection name is printed in place of the label name, and is really used by the producing label as is. For example, any of the "Verve Jazz Masters" releases are from label Verve, dot, and "Jazz Masters" should be part of the release name. Compare this with the Original Jazz Classics releases, by label Fantasy. -- dmppanda 21:22, 03 November 2006 (UTC)
  • Although... it's somewhat an interesting side-effect to be able to use phony labels as collection names...
  • How should artists that release their own stuff be handled? Create a label page for the artist? (I know of several autoreleasers within the Danish folk music milieu alone.) --FrederikSOlesen Template:DateTime
    • I guess it boils down to: does a legal entity (association, company, whatever) exists, and does the media bears a barcode? If so, then *this* (whatever *this* is) is the "label" (even if owned by the artist, even if nothing more than a trademark name to which the barcode has been attributed. If not, then I guess we are dealing with people distributing CDr around, out of any kind of structure (be it commercial or legal), right? In this case, IMO there is no label at all (and possibly no release event either). Probably the same goes for "internet" releases out of any "official" structures. Wether we want a "phony" label (or more than one?) to distinguish between such "autorelease" and "no-info-yet-release" is an open question. -- dmppanda 08:47, 07 November 2006 (UTC)
  • It would be useful to have an 'add label' link on the page generated when you 'use this release in a relationship' -- Gecks
    • uh, i was kinda confused :) i thought labels > release relationships were done through AR, but it's actually a link to a release event. Just thought I'd put this down for the record as I guess some others might make the same mistake? Not sure how to stop that happening, though... -- Gecks
  • I would like to subscribe to Labels, simular as for artists. -- Schika
    • If I recall well that conversation on the mailing-list (check the link at the top of the page), I think luks said it was planned -- dmppanda 16:15, 07 January 2007 (UTC)