History talk:Release Annotation Style

From MusicBrainz Wiki
Jump to navigationJump to search

I've been using "Cat#" in all my annotations. I feel changing it to "Catalogue #" is a bit too late. The argument for expanding is moot IMO since the # sign is sort of an abbreviation too. If you insist on changing it on those grounds it should be "Catalogue number" --azertus

  • I have to agree. -Fuchs Also this should not give exact data that is used in the tagger or somewhere but only help storing release data in a standardized way which is acceptable for everyone. I wrote "Cat#" here because it is the shortest way to write it and still everyone can understand what it means - so it's the least effort entering release data with this style. --Shepard
    • In the interim I added a space between "t" and "#" symbol as it is 2 words regardless. Personally I prefer "Catalog #:" as it follows our other general guidelines of the -NO- abbreviation policy, though like stated yes "#" is an abbreviation. I too have added them abbreviated prior to this becoming a -phenomenon- :) the majority are not. At this point if we can get people to -just add it- I'd be happy. -teleGUISE
      • Please stop changing it every day. I won't go over all annotations I created again and again to fix it for no benefit. --Fuchs
        • Plus, "Catalogue vs Catalog" is too hard - another reason to support "Cat#". --MichelleW

In general I use the / (slash) or - (minus) symbol to separate the entries, what to use depends on the entry itself. Some Label names or Catalog numbers contains those symbols, so I choose the symbol which isn't part of the entry to avoid confusion. --Schika

  • Typically the most common use of "-" is in the "Catalog #" itself though label names might also. I think if we make sure fields are separated by " - " that's a _space,hyphen(minus),space_ that helps. A few of us also now use the nhanced annotation style and add the "field titles" in BOLD text. (ie.. Label: Warner Bros. - Catalog #: 1234 - etc.. ) -teleGUISE
    • I think the idea with the enhanced annotation is very good, the "_space,hypen(minus),space_" doesn't help when the entry itself use that. ;) A very rare used char in Label names and catalog # is the · (middle dot) --Schika
      • Why not simply use lists? Apart from looking better, it would also be semantically correct! (Even better if we could use definition lists, but, oh well. :) ) --FrederikSOlesen
        • Look at the first example provided here and tell me again that you want that huge amount of data made even bigger by using lists. ;) -- Shepard 11:41, 25 June 2006 (UTC)
          • I do? Lists are, to my eyes at least, easier to parser than a string of text which doesn't easily (visually) distinguish one part from the next. Using bold text for the identifiers would be a start, but I still prefer lists over separating with " - ". --FrederikSOlesen
    Ugh, that bold format is very ugly IMO, but feel free to use it of course. --azertus

Maybe it's about time to make this official too... The fact that it's only a temporary measure shouldn't pose a problem, IMO. --azertus

  • I think we need to hash out a few things such as the above "Catalog" abbreviation and which separator symbol to use before we can call anything official. I'm happy to see many of us using this now as it's importance is realized which creates more opinions and this discussion. -teleGUISE
    • There is no reason to make annotation style official. As you can see in this discussion, everybody seems to be using a different format anyway. So keep it as an informative record and make this page a hint about which fields are interesting, nothing more nothing less. --Fuchs

I partly reverted an edit deleting the "ASIN: " field. It included the following comment: "Some annotations already in the database have still got an ASIN field. This is deprecated and ideally that info should be converted to an AR link (ASIN is the code used by Amazon; entering one causes the Amazon coverart to be displayed on our album pages)" The field is not deprecated though. It is still needed to differentiate different releases. When adding different groups of release data I even often add a field "DiscID: " if I know which belongs to which release. --Shepard

  • You're absolutely right; I didn't think of that, thanks ;) I might start adding "DiscID: " too... --azertus

What about the position of this in the annotation? E.g. http://musicbrainz.org/showalbum.html?albumid=432251 has other information in the annotation. Where to put the cat# etc.? --Zout

  • I perhaps looks a bit arbitrary.. I always order it like this: first comes info about the album title / album in general ("Special Edition", "Recorded at ...", "Digitally remastered", ...), then the release information, then information about track titles / tracks in general ("Track X has parts: A - B - C", "Last tracktime is off due to removed data track", ...) and (if this does not belong to one of the releases only) information about content of data tracks. --Shepard
    • But it doesn't really matter. I put the release info at the end of the annotation, to make sure all the general info about a release is in the short view. --Fuchs
      • Depends how important which bit of information is for you. I think we should follow DonRedman with this: it still is a wiki freeform field and does not need to be too restrictive. We are all old enough not to end in edit wars because of ordering of information. ;) I hope... --Shepard

I have a number of issues with this: 
  • IMO, the proposed style lacks identification of the format of the release, and I don't think specifying this in the title line is a good solution - I do personnaly add things like '- Format: 5CD' or '- Format: 12"LP'. Sometimes, when there are multiple formats, I condense things on one line using a syntax like 'Cat #: XXX/YYY - Format: 12"LP/CD' etc
  • -- Please don't put several release data sets in one, that defeats the point. -- Shepard 11:19, 05 August 2006 (UTC)
    • -- as far as I remember I did this only for simultaneous lp/cd releases as to save a somewhat unneeded line, but ok, I'll add two lines now ;) --dmppanda
  • I think it also lacks a way to link a line/entry to the corresponding release date - I do personaly append '- Rel: YYYY (State)' when needed
  • -- Well yes, it's a temporary solution until we can really combine it with release dates. Also see how I have done it on Iron Maiden's The Number of the Beast yesterday. ;) -- Shepard 11:19, 05 August 2006 (UTC)
    • -- I like that, although I don't really see the point in splitting things on two lines --dmppanda
  • For some releases, should we use the actual label name, or the name of the label at the time of the release? Or both? AFAIK WEA doesn't exist anymore, but is now Warner Music Group - though, I don't think they changed the cat# of the releases and/or distributors, etc. Same question for the distributors... what if a label change distributor?
  • -- The original name of both label and distributor I'd say since this is the exact data as printed on the release. Otherwise you could also say don't include a label name at all if the label doesn't exist any more. ;) -- Shepard 11:19, 05 August 2006 (UTC)
    • -- So we may end up with a line for label "super label", and another mostly identical line for label "super label renamed", or two lines with a distributor name change? Why not... --dmppanda
  • Frankly, I think adding the lc numbers and/or distributor is not a good idea. IMO it's redundant and prone to errors to add this information to each and every release, and this should better live in a wiki page dedicated to the label (example: Rhino)
  • -- It's not really redundant. Sometimes you cannot identify the correct label for a release if there are several printed on the cover. Adding the LC makes it easier to sort out such mistakes later when we can add labels to the db. And I consider the distributor info as quite important. Label's don't necessarily use the same distributor all the time. And adding the cat#s of distributors without giving their name would be pretty useless too (see this Inside Out release for example). -- Shepard 11:19, 05 August 2006 (UTC)
  • The proposed style doesn't differentiate "producing" labels and "reissue" labels for a release. When this is needed, I prepend something to the entry, like "Original Label", "Reissue Label", although we could agree the first line *is* the producing label...
  • -- One release data set is about one release, so the original label isn't important for this release. Also the "original" label may not be identifiable (when it was released in several countries by different labels, like Iron Maiden's The Number of the Beast. -- Shepard 11:19, 05 August 2006 (UTC)
    • -- Do you suggest we should add a different release per reissue? I know that the "zone" where I'm editing is somewhat specific, but in a lot of cases, it's (quite) important to know the "originating" label... --dmppanda
      • -- If the label changes, it's a whole new release with a different cat# and a different EAN (although considered just one release in MB - but that's what all this is about), so it deserves a new release data set in the annotation. So yes, one line for the original release and one line for the reissue. -- Shepard 16:12, 05 August 2006 (UTC)
  • Releases who suffered multiple titles and a large number of editions are a pain to deal with if we use that <title> thing extra line. I did things like that First Recordings, although I'm not sure it looks good (it's shorter, though)
  • -- IMHO releases with different titles should be added separately, even if the tracklist is the same. -- Shepard 11:19, 05 August 2006 (UTC)
    • -- I think I disagree... My favorite example here demonstrates you would need 6 different releases entries for the exact very same stuff, with nice variations for both the ReleaseArtist and ReleaseTitle --dmppanda
      • -- I would have them all separate. But that's a different discussion unrelated to this page. ;) -- Shepard 16:12, 05 August 2006 (UTC)
  • I think using cdid is somewhat utopic... I like the idea though, but I don't think this is feasible on a large scale...
  • -- Why? It's a way of relating all the info we can add to several places (also: release dates, Discogs links, ASIN links), and once we are able to relate them properly, we can take the info out of the annotations. -- Shepard 11:19, 05 August 2006 (UTC)
    • -- Because our UI to add cdid doesn't encourage/allow the user to annotate in the same move. And while it's possible to track down and link release info to label info without the cd in hand, I think it's pretty hard (impossible?) to do the same for cdid. I still like the idea though ;) --dmppanda
      • -- Yeah, of course this is only possible when you own the CD. But with the NextGenerationSchema we would be able to relate all that data properly (and hopefully easily) so it's just good to already do some of the work now. Btw, note that one disc ID can relate to several release data sets (different catalogue numbers, but same TOC). -- Shepard 16:12, 05 August 2006 (UTC)
  • Sometimes, one of the reissues (say, the original release), has a different track list (say: without the alternate takes). You know that this obscure LP release from 1940 will never come into the db (and you might even miss the exact track orders preventing you to add the release). The db has the late cd re-edition. Still you want the release history to be complete and/or helpful for the buddy who will enter the other obscure edition later. In these cases, I add the extra label line, and append things like "- Omit: #x-#y"
  • This wiki page address only the label "lines" in the release annotation. I think there are other things in release annotations that may be "standardized". I think about "Location:" and "Recording Date:" (as in the example above). Should we use American dates (YYYY/MM/DD)? When tracks have different dates/location, should we use multiple lines and a syntax like "#x-#y, DATE"?

--dmppanda

  • a) those aren't American dates (US uses MM/DD/YYYY), b) I always use the international format: YYYY-MM-DD to make sure it's not ambiguous. --Nikki