Discussion about labels
LabelSortName
At that time, there are no known cases of two or more "collaborating" labels jointly issuing a release (please don't confuse this with distributors/holding mentioned on sleeves), so there should theoretically be no need for rules regarding collaborations.
I know of a few examples of this - eg,
![[WWW]](/-/musicbrainz/img/moin-www.png)
http://www.discogs.com/release/529682 (happens a LOT with split releases). -- Gecks Ok... I'm too conservative for such stuff :p - please go ahead and add thoughts about it: do we want "collabs"? ampersand versus "and"? new AR needed? etc, -- dmppanda 2007-04-05 11:53:12
ok i would suggest only using "collabs" (ie separate label called "Label X and Y" or something) for long term label collaborations, where a specific cat# scheme is used. Eg http://www.discogs.com/label/Quattro%2FUK+Discs (not a great example but notice the unique cat#). regarding how to name them - IMO just do it as on the sleeve. if they list them separately, use '&', as seems to be the custom. one thing though - it's important not to get confused with sublabels and collaborations. a sublabel could be a collaboration - eg, Quattro may own UK Discs, but they have created this unique imprint to issue records, so it's a new label, but it is a sublable like any other, and not really a 'collaboration' beyond the label name, so in this case i don't think a new AR would work. -- Gecks yes, I definitely want to avoid LazyUser to create a bunch of bogus "collabs" entries, and to see zealous editors massively use collabs AR without checking if the collab label entry is legit or not (which is mainly why I "ignored" collabs at that time). Suggestion for the time being: let the dust settle down a bit, and build up a list/report on this page (or on the LabelFuture page) of all real label collaborations. -- dmppanda 2007-04-05 13:48:26
The last point (4) of LabelSortName style may be discussed, and one may argue that some label can use the name of their founder, and that such names may follow the usual artist SortNameStyle. I don't think so, and I would like to see concrete examples before taking decision and add additional sorting rules. -- dmppanda 2007-01-29 18:54:31
Eg, "David Geffen Company", though to be honest as this is a trademarked company name, I don't think re-arranging it would be right. I imagine this is true with all other examples. -- Gecks
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 disputable, we may want to use SpecialPurposeLabels (possibly [autorelease]).
This should probably be "self-releases", as that's the term I've only ever seen used, at least in contemporary music. We perhaps want to make the distinction between self-releases and white label releases, though, despite them being nearly the same thing. --Gecks
NGS/Major rehaul
Known limitations requiring lots of work and major modifications:
Ideally, we could be able to attach multiple release events (release date and country) to a unique catalog number / EAN. -- dmppanda 2006-11-03 21:22:07
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 2007-01-07 13:37:16
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 2007-01-07 13:37:16 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 2007-01-07 16:15:53 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 2007-01-09 15:22:31
Labels activities may be very complex (dismantling, dormant labels, reviving), and the concept of a single life between two points in time (begin date and end date) may prove rather inadequate (or at least a raw approximation). At that time there's no way to provide with a better model, though there is hope this issue may be solved later (note that the problem is similar with groups). We need a richer way to describe label activities and period of activities. -- dmppanda 2007-03-22 14:21:05
CategoryLabel CategoryDiscussion