Re: [mb-style] Disc catalogue numbers
On 05/04/07, Frederic Da Vitoria [EMAIL PROTECTED] wrote: 2007/4/5, Age Bosma [EMAIL PROTECTED]: Hi, Often multiple disc releases have different catalogue numbers for each disc and a general one for the complete release. An example would be 'Queen - Live at Wembley Stadium' [1][2] with: - Release Cat#: 5 91095 2 - Disc 1 Cat#: 5 91095 2 6 - Disc 2 Cat#: 5 91095 2 5 Obviously there's just one EAN barcode. Which one should we put in the Catalogue# field for a release event? There are different ways to look at it and I haven't made up my mind yet what I prefer: - We are storing the same barcode for both discs so the cat# can differ and we still have a method to combine both discs. - The release cat# should be stored since it's one release and that's who it's in the label's catalogue. - MB doesn't have a way to group discs yet so the disc cat# should be stored because the release cat# only applies to the group IMHO we should work this out as a guideline to add to the wiki before everyone starts doing it in a different way. What's your idea about this? Yours, Age Bosma [1] http://musicbrainz.org/show/release/?releaseid=578208 [2] http://musicbrainz.org/show/release/?releaseid=578216 I'd rely on the Barcode for later grouping of discs but I'd store the disc catalogue #. The album catalogue number could be put in an annotation. I'd do it this way because the day we will create an object to grop discs, we won't have to change anything to the data stored in the discs release events. All we will have to do is group discs by barcode and check in the annotations to get the album catalogue number. 1) not all musical releases have barcodes. i don't think we should rely on it for anything. 2) from a label point of view, the set cat# is most important. eg, most vinyls will have different cat#s in the run out grove (eg 1 1234-A vs 1 1234-B) but that is pretty much extra info. the only time the specific cat#s of a CD disc would be useful is if you owned 1 disc, without the cover. that way you'd be able to track down what set the disc belonged to. if anything goes to the annotation it's the individual disc cat#s, IMO. we must must must store the album cat#, if our label support is gonna be useful. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Disc catalogue numbers
sorry, finger slipped: On 05/04/07, Chris Bransden [EMAIL PROTECTED] wrote: On 05/04/07, Frederic Da Vitoria [EMAIL PROTECTED] wrote: A more extreme problem: I have a box set (cat#=NTCD1952) that contains two cds which are available separately (cat#=NTCD354 NTCD385). Once removed from the box, nothing distinguishes the cds from releases bought separately. How would you enter it? well, currently they are merged together as per BoxSetNameStyle, but were ReleaseGroups here, it would hopefully be a rather trivial matter. under the current system it would be: CD1 = NTCD354 + release date A NTCD1952 + release data B CD2 = NTCD38l + release date C NTCD1952 + release data B ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Media types for releases
On 24/03/07, Alexander Dupuy [EMAIL PROTECTED] wrote: Given the large number of fairly obscure categories (how many artists we're ever released on MD or 4-track?) I don't see why there shouldn't be separate formats for 33/45/78. one potential problem is that one vinyl can potentially have different RPMs on different sides. in fact i have a few myself. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Purevolume URL Relationship
On 21/03/07, Beth [EMAIL PROTECTED] wrote: Another thought is there is a has samples AR already, and I know it didn't feel encompassing enough for the myspace page (perhaps not as well for purevolume?) i think the 'has samples' AR is for connecting a track to the track(s) it samples - http://wiki.musicbrainz.org/SamplesRelationshipType, unless there's another i don't know of of course :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Albums compiled by artists
On 06/03/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, Mar 05, 2007 at 11:28:03PM +0100, Erik Dalén wrote: Jan van Thiel wrote: I agree that these have to be cleaned up. But I don't think a guideline is necessary. Common sense should do the trick ;) And for me that is: if the ReleaseArtist is clearly stated on the release (which is for most/all of these releases), it should be set. Of course, also a DJ-Mixed by/Compiled by AR should be created. I agree :) So in your opinion this release should be Ladytron not Various Artists? http://musicbrainz.org/release/b6cbb7a5-a0c2-47f8-93a2-7157874249eb.html Yes. (imo). -- kuno (warp). thirded :) this release is part of the ladytron canon, regardless of it having VA content. it needs to appear on their artist page (other than just an AR), IMO. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Single numbering
On 01/03/07, Sami Sundell [EMAIL PROTECTED] wrote: I recently came across several edits that change the name of a single from Title into Title (disc 1) or Title (disc 2). I was wondering what that was about (see, for example, http://musicbrainz.org/show/edit/?editid=6101286) and in one case got a note saying it says so in the style guide. Which, sure enough, it does (http://wiki.musicbrainz.org/DiscNumberStyle). However, it makes me wonder why we want to separate different versions of singles, when we don't seem to have the same problem with albums. Yeah, some singles do have a number in their title to note the version of a single. Some may even be sold in combined packages (see http://musicbrainz.org/show/edit/index.html?editid=6080694). On the other hand, we strip out remastered and other similar notes from album releases, so why should we add this information into singles? If the number is seen as a part of the title, I thinkg we should use it as it is stated in the title. Adding (disc n) into the title pretty much signifies it's a part of a multi-disc release, which is, to say the least, confusing, when most singles are still available as separate. i agree. they should be (single X) or something like that. If a single is sold both separately and in a package with another version of the single, then, in my opinion, we should add both into the database; that's what we do with other release types. Queen's Greatest Hits with platinum collection variations etc. are a good example (see http://musicbrainz.org/release/6178318e-5e21-4d73-b8d1-2350eb1eefd0.html). hmm, no we don't :) BoxSetNameStyle! queen's greatest hits is a special case. i believe one or more of the discs in the BoxSet is only available as part of that BoxSet, so the rest of the discs are contextually relevant, even though they exist separately. Actually, we do that with some singles also: for example, The Smashing Pumpkins have the same singles available both as separa te releases and in The Aeroplane Flies High box (see http://musicbrainz.org/artist/ba0d6274-db14-4ef5-b28d-657ebde1a396.html for single listing). again, this is a special case. most (all?) of the aeroplane flies high box are ONLY available as part of the box. they have extra b-sides and the like. but i still agree (disc X) is a bad way to do single numbers :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Clarification about release type: album or compilation
On 12/12/06, Olivier [EMAIL PROTECTED] wrote: Hi, There has been some discussion lately about the proper release type to be added to bundled stuff (twofers and such) (eg: album or compilation). It seems that http://wiki.musicbrainz.org/ReleaseType holds some ambiguity, especially this part: The MusicBrainz project does not generally consider the following to be compilations: a release containing two releases (and/or EPs) released together as a single unit. (the single unit being the ambiguous part) i believe the intent was the 'single unit' is a MBz 'release' Moreover, this seems to be at odds with the general style guide, http://musicbrainz.org/style.html which includes the following line. Compilation. A compilation is a collection of previously released tracks by one or more artists. tracks != EP/Album/Single, etc :) basically IMO the logic is that calling a compilation of 2 EPs a 'compilation' doesn't tell you anything useful. if you call it an 'EP' you can at least normally figure out from the title (eg EP 1 / EP 2) the nature of the whole release, yet you retain the release type of the individual releases. an album with an EP or single bolted on the end, should retain the release type of the 'main' part. As a first attempt at trying to sort this out, we would like your opinions (eg: album or compilation) on the following examples. We'd also like to know how most people have read this so far, and if possible, what was the initial intent of http://wiki.musicbrainz.org/ReleaseType (i) - two discs (vinyl or cds), identical to two previously released albums, with no alterations of the cover art, bundled together in some way both albums. of course they wouldn't be entered separately as per BoxSetNameStyle :) (ii) - two discs, identical to two previously released albums, bundled in a new packaging, under a new release title both albums. (iii) - one disc, containing exactly two previously released albums, under a new name of type Release A / Release B album (iv) - one disc, containing exactly two previously released albums, under a new name *not* of type Release A / Release B album (v) - one disc, containing one previously issued release, with additional (previously unissued) tracks album (or whatever the previously released release type was) (vi) - a set of discs, containing previously issued releases (possibly with additional tracks), stacking tracks on discs with no respect for the separation one disc = one original release (eg: complete edition/anthology boxset). could you give an example? in my experience this would in the real world be made up of different combinations of the previous scenarios (eg, joy divison's box set). i'd say there's normally one main release that you can inherit a releasetype from, for each disc. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Clarification about release type: album or compilation
On 12/12/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: 2006/12/12, Chris Bransden [EMAIL PROTECTED]: On 12/12/06, Olivier [EMAIL PROTECTED] wrote: (i) - two discs (vinyl or cds), identical to two previously released albums, with no alterations of the cover art, bundled together in some way both albums. of course they wouldn't be entered separately as per BoxSetNameStyle :) Chris, I am not sure I understand your answer. If the 2 discs were available separately (identical, same tracks and durations...), BoxSetNameStyle explicitely states that they should be entered separately (although we could put an annotation saying the discs can be found in a box set). yes, they should be entered separately, but not re-entered in their packaged form (which is presumably as some kind of boxset). my apologies for the confusion :) BTW, I suggest that - In the first case, we currently don't cater for retaining box set information and simply treat the albums as seperate albums should be rewritten as - In the first case, we currently don't cater for retaining box set information and simply treat the mediums as separate releases (ii) - two discs, identical to two previously released albums, bundled in a new packaging, under a new release title both albums. Chris, again, I am not sure of your answer. I think (although I can't find the precise reference) that for non classical releases, if the title changes, MB considers it as a different release. right...and those different releases i would consider both albums :) i don't deal with classical stuff. (iii) - one disc, containing exactly two previously released albums, under a new name of type Release A / Release B album I suppose Chris meant New release. Frederic, we're talking about what the *ReleaseType* would be for these releases, not whether they would be added or not. only the first example is something i wouldn't add at all. (iv) - one disc, containing exactly two previously released albums, under a new name *not* of type Release A / Release B album Ditto (v) - one disc, containing one previously issued release, with additional (previously unissued) tracks album (or whatever the previously released release type was) Here, there is no question: different track listing so new release. (vi) - a set of discs, containing previously issued releases (possibly with additional tracks), stacking tracks on discs with no respect for the separation one disc = one original release (eg: complete edition/anthology boxset). could you give an example? in my experience this would in the real world be made up of different combinations of the previous scenarios (eg, joy divison's box set). i'd say there's normally one main release that you can inherit a releasetype from, for each disc. If the track listings were different from any separate release (or the track durations were significantly different), this would be a box set. Now if in one box set some of the cds are different and others are available separately, I don't think we have a rule, although this situation is quite possible. again it's the releasetypes that are the question, not the format of the release itself. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: How to handle band/artist name changes (Was a RFV)
On 05/12/06, Kerensky97 [EMAIL PROTECTED] wrote: Gecks wrote: sorry i don't think this reflects current practice. some artists change names all the time, yet we have chosen one artist name to use as it's the most useful thing to have when tagging. I've seen just the opposite happen on the database, many artists have annotations that specify the artist was once known as something else. The lineup didn't even change, they just started producing albums under a different name (usually due to copyright issues). http://musicbrainz.org/artist/ef58d4c9-0d40-42ba-bfab-9186c1483edd.html DragonForce http://musicbrainz.org/artist/8bf9b24b-e802-4ab6-b342-b348e20b58d4.html Rhapsody yep i said *some* artists. i'd say there's a lot more 'combined' than 'split', but the latter of course is more immediately apparent, whilst you'd have to route around aliases/know the artist to know if the former was taking place. Gecks wrote: it's not just tagging, though. there's also the fact that if you represent all names, you lose a cohesive 1 page discography. also, with ARs being displayed the way they are, the proposed name 2 name relationship would get hidden, when it really would be the MOST important relationship and have to be split from all the others. and finally, we'd get users adding releases to the wrong names/dupes/etc. This was the argument I used when I brought up the issue in irc that artists were changing their names and that I should tag them under their new (or in this particular case their old) popular name. I was told that the database should most closely reflect the release and that the facts shouldn't be changed to fit the database; the database should be fixed to best display the facts. there's no hard rule. it depends who you ask :) I don't think we should change their name from what it is on the release we just need a better way to display information about former names. I'm not sure how NGS will or could address this but I thought it would be neat if the Artist's releases under former names would show on the discography but be greyed out, in a smaller font, or in a compacted form. indeed. and the tagger should have functionality to give you the option of using the current, release-specific, or most popular (how to define??) name. Until something better comes along I still think it's best to list the releases under the name they have on the album; and an AR that links previous names to their current names would help things alot. agree with the latter. for artists that are split we need a relationship that links them together, however this shouldn't be used to change the criteria we use to split artists (currently there is none - it is one of the many things that is solved ad hoc by subscribers of that artist). this discussion always seems to come back to that but it is unnecessary at this point. And until a better solution comes along we'll just have to keep renaming our personal libraries to keep an the releases together for an artist who can't decide on a name (Prince will always be Prince to me, none of that symbol nonsense). like i said, it's not just about tagging... chris/gecks ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Concert Recordings Release Dates
On 04/12/06, Aaron Cooper [EMAIL PROTECTED] wrote: On 12/4/06, Chris Bransden [EMAIL PROTECTED] wrote: IMO only give them a release date if there was a specific release event. the pixies put out live CDs of a similar nature which i *think* were released at the same night of the shows (they used this 'disclive' technology that could press the discs straight away), so there's a release date to go on. if they don't have this, or you're not sure, i say leave it blank. Where do we draw the line then? Is it safe to say that a recording from July was released in a particular year but a recording from December is not? i'd only put the release date in if i was SURE that it released in that year, or that month/day if you're able to be more specific. That will severely mess up the order these recordings are sorted. i'm not too bothered about the sort order - that's more a display issue and anyway is pretty messed up for most artists already, what with bootlegs hardly ever having release dates. The case I'm concerned with is releases like http://musicbrainz.org/release/d4bf22c9-cd7e-44cf-82ee-5c24fb2f3e99.html and a few other concerts from April/May. Can we say that concert recordings are enough like bootlegs that they shouldn't have an official release date? Can we say that they don't explicitly always have a release date so they should not have one set? nah cos sometimes they do. eg, the pixies releases i had earlier. if a release has a vague 'availability date' (eg, like a live bootleg someone uploads to archive.org, then IMO they don't get a release date (even just a 'year') cos they could have been available to people via other means (traders...) before that date, and also it's not really a 'release'. official releases are different because their distribution is controlled, even if it's a download. there will be a set date at which the release was available, it's just a matter of finding when it is :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Audio ripped from DVD video designation
On 03/11/06, Michelle . [EMAIL PROTECTED] wrote: From: Lauri Watts [EMAIL PROTECTED] The attributes apply to the disc itself though, not some potentially illicit audio ripped files from it. The disc itself is official. It's just not an album. Perhaps we need to simply add Video or Mixed content (Video and/or Audio) or both to the release types. Yes, I agree the disc is official. It's just not official as _music_, unless you also count audio ripped from movie DVDs as a music release. Which is the question: does it belong in musicbrainz as an official audio release? (Because it can't be in musicbrainz as an official _video_ release... unless we change some of the aims of MB) the way i see it, it just so happens that people will tend to be tagging mp3 rips of DVDs, but they could feasibly in the future be tagging audio/video rips. infact they could basically do that now, if the tagger supported it. so i say the release type should be official, as it's entry on the DB reflects that of an official release, regardless of our current tagging limitations. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Audio ripped from DVD video designation
On 03/11/06, Michelle . [EMAIL PROTECTED] wrote: From: Chris Bransden [EMAIL PROTECTED] the way i see it, it just so happens that people will tend to be tagging mp3 rips of DVDs, but they could feasibly in the future be tagging audio/video rips. infact they could basically do that now, if the tagger supported it. so i say the release type should be official, as it's entry on the DB reflects that of an official release, regardless of our current tagging limitations. That's an excellent point. The only problem I see is, to what extent should DVD videos be ripped into MB? I have in front of me Starshaped, a Blur DVD with a documentary which is about 50% live footage and 50% candid video, and 2 live concerts with separated tracks. Would I tag just the live tracks, or both the live tracks and the documentary? If just the live tracks, that would be an inaccurate representation of the disc, and shouldn't be placed under official. If both the documentary and live footage, then we ought to enter _all_ music documentaries into the database... which I suppose would make MB a more comprehensive database, but I'm not sure where the line is drawn between musicbrainz and culturebrainz. yeah i think this is the main problem :/ i think our current scope means that only the live/actual song parts of the DVD are worth indexing, but even if we did index everything, it's still not perfect as chapters on DVDs aren't necessarily sequential, or split up in a useful way, so the 'tracklist' becomes less meaningful. for me it's that we cannot currently represent these releases all that well, but none-the-less they are an official release, just a poor representation of one :) perhaps this is a good case for the forthcoming 'pseudo-release' as proposed in the transl(iter)ation discussion? though even then i think this is a slightly different scenario. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Audio ripped from DVD video designation
On 03/11/06, Jason Bouwmeester [EMAIL PROTECTED] wrote: All interesting comments... so I guess I'll enter them as official. But this brings me back to my original question - are these still (bonus disc) designated even though they are *illicit* rips of the audio from a bonus video dvd? And how does that work with the Nirvana 3CD/1DVD-video release - disc 1-4 or disc 1-3 and a bonus disc? as i said before, it depends if the DVD appears on every version, or just some. I believe in this case it is every version, in which case it is not 'bonus', so just use (disc 4) :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Audio ripped from DVD video designation
On 02/11/06, Jason Bouwmeester [EMAIL PROTECTED] wrote: So I've run into a bit of something here. Bonus DVDs (usually of videos) that come with Audio CD releases... some of these exist as ripped audio formats. On the mb-users list, I was directed to the discussion at http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-April/002079.html stating that these are acceptable to enter into MB under Official status, I would also assume these would fall under a Compilation classification as they aren't really albums. Anyways, to the styling. I noticed that Nirvana's With the Lights Out is entered as a (disc 1) to (disc 4) set in MB: http://musicbrainz.org/release/bc38ef5f-de82-4fe7-9646-72feb62e0cca.html http://musicbrainz.org/release/ce579e4f-b0bc-4fe6-b4af-27c37e650e23.html http://musicbrainz.org/release/c0225abe-5af6-465a-9690-c8e709d99ade.html http://musicbrainz.org/release/e831f523-face-41d2-926e-4695d4ec93d8.html HOWEVER, this is incorrect as it was a 3CD/1DVD-video release... hence disc 4 is really an audio rip of the DVD-video. I think that this needs to be indicated in the title somehow, and the best solution I can think of is to use a similar style as indicated by (bonus disc) outlined here: http://wiki.musicbrainz.org/BonusDisc So basically, if the same as BonusDisc, but if it is an audio rip/extraction of a bonus dvd it would be indicated as (bonus dvd), hence With the Lights Out (disc 4) would become With the Lights Out (bonus dvd). Another example CD/DVD-Video release is ATB's Seven Years found here: http://www.amazon.de/Seven-Years-Limited-CD-+-DVD/dp/B0009FU0MY One last thing... (bonus dvd) would work now, but what happens when HDDVD/Blu-ray start to gain momentum? Would (video) work better, with (video disc 1) for multi-disc DVD-video sets? /sigh... Comments? ~jb/haeretik is it a bonus disc, though? ie, is it only with some editions of the set? and anyways, if it is, it still should be (bonus disc) since the (disc) part isn't intended to be specific to any type of media - vinyl, cassettes, CDs, DVDs - they're all discs in MBz speak. hopefully ReleaseGroups will be allow us to embellish a bit more in the future. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Translation Transliteration Relationship Type
On 27/10/06, Kerensky97 [EMAIL PROTECTED] wrote: Alexander Dupuy-2 wrote: The only way to really solve this problem is as part of the release page server - the web code can easily get the lang attribute from the DB when it looks up the title, and display that, using very simple logic to decide whether to call it a translation or transliteration. This is what I have always been arguing for - I don't want to eliminate the distinction between translation and transliteration, I just want the distinction to be automatically computed. That enhancement doesn't require NGS. If you guys can program MB to be smart enough that all the editor does is create the AR itself (with no attributes) and the system looks at the Language, Script to decide whether to call it Translation or Transliteration for the output in the relationship field I'd say that's the way to go, 100%. The only things that might cause the system to trip is: 1. If the language/script isn't set or are identical due to past user error. 2. If the transliteration is a unicode difference (both are English, Latin for instance but one uses unicode the other doesn't). Solve those and it would be a perfect solution. For #1 I'm not sure if it's possible to have the editor be directed to a page where they set the Language, Script then the AR completes or maybe even a new field pops up within the AR edit and gives the editor the option to add the settings needed before continuing. The simplest but least elegant solution would be if the AR just says Error: Go back, set the Language and Script, and do the AR again. For #2 I can only think that a Latin (Unicode) entry needs to be added to the script list so the system can see the difference. as rowaasr13 said on the wiki page, as long as language is same one side of AR is original and another is transliteration, script is irrelevant. - so the system would only need to check on what languages were used for any automated setting of transl(iter)ation. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transl(iteration-ation) AR (Resurrection).
On 13/10/06, Kerensky97 [EMAIL PROTECTED] wrote: I have the basic wiki entry for the AR written, it's just a first draft to get the basic idea and structure of the AR untill specific wording is worked out. http://wiki.musicbrainz.org/TranslationTransliterationRelationshipType#preview Translation/Transliteration Relationship Type i changed: Not all translations and transliterations will be off the official CD or the artist's official site. The ReleaseStatus should be changed to reflect if the transl(iter)ation is ''Official'' if from an official source, or ''Alternate Release'' if fan or editor made. Full definitions of release status are available at the ReleaseAttribute wiki page. to Not all translations and transliterations will be off an official source (eg, in the case of a physical release, the cover tracklisting, or in the case of a download, the tracklist from the official site). The ReleaseStatus should be changed to reflect if the transl(iter)ation is ''Official'' if from an official source, or ''Alternate Release'' if fan or editor made. Full definitions of release status are available at the ReleaseAttribute wiki page. just to make sure people don't add new 'official' releases is an official site has a transl(iter)ation of a tracklisting, but this is not available to buy in any form. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transl(iteration-ation) AR (Resurrection).
On 16/10/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: 2006/10/16, Chris Bransden [EMAIL PROTECTED]: On 13/10/06, Kerensky97 [EMAIL PROTECTED] wrote: I have the basic wiki entry for the AR written, it's just a first draft to get the basic idea and structure of the AR untill specific wording is worked out. http://wiki.musicbrainz.org/TranslationTransliterationRelationshipType#preview Translation/Transliteration Relationship Type i changed: Not all translations and transliterations will be off the official CD or the artist's official site. The ReleaseStatus should be changed to reflect if the transl(iter)ation is ''Official'' if from an official source, or ''Alternate Release'' if fan or editor made. Full definitions of release status are available at the ReleaseAttribute wiki page. to Not all translations and transliterations will be off an official source (eg, in the case of a physical release, the cover tracklisting, or in the case of a download, the tracklist from the official site). The ReleaseStatus should be changed to reflect if the transl(iter)ation is ''Official'' if from an official source, or ''Alternate Release'' if fan or editor made. Full definitions of release status are available at the ReleaseAttribute wiki page. just to make sure people don't add new 'official' releases is an official site has a transl(iter)ation of a tracklisting, but this is not available to buy in any form. I don't understand this... Could we make a list of the ReleaseTypes and the ReleaseStatus values which would be accepted for the new AR? And give for each combination what it would mean? A: Original Release (eg, http://www.discogs.com/release/656463) ReleaseType: Official B: Released in another language (eg, http://www.discogs.com/release/683846) ReleaseType: Official AR between the A and B: A is the original language track listing of release B C: Fan-translated to german ReleaseType: Alternate AR between A and C: A is the original language track listing of release B what i'm saying is that even if Boris put up a tracklisting translation to german on their official website, it would still be an 'alternate' release as it doesn't physically exist. the JP and US versions were pressed and sold. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transl(iteration-ation) AR (Resurrection).
On 12/10/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: 2006/10/12, Kerensky97 [EMAIL PROTECTED]: I could start working on updating the wiki page, most of the info is already in there, but I don't usually mess with the wiki so I may have to bug you on a few details. As for the calling the release status Transl(iter)ation that's about as concise as it gets; i was suggesting Alternate just to leave it a little openeded in case we want to use it to classify anything similar in the future. Right now the type of releases I expect would be going in there are: Translations Transliterations Non-Unicode versions (a form of transliteration I suppose) I was thinking alternate would allow us to throw a few other things in there that we don't want to delete, but we do want to shuffle into the wings untill the database can make better use of it. Those are just some thoughts though, we could settle it by flipping a coin and I'd be fine with it. Do you have any examples? http://musicbrainz.org/release/f205627f-b70a-409d-adbe-66289b614e80.html vs http://musicbrainz.org/release/e5e53519-8951-42dc-87ef-cb9808b04f15.html is probably the most (in)famous. there are some other unicode-fixing alternate versions in the DB as well. i'd also argue that alternate (or something similarly non-specific) is better because you need to be able to distinguish between official transl(iter)ations (ie those that appear on some versions of the CD sleeve) and 'fan-made' ones. ie, you could use 'official' for the former, and 'alternate' for the latter. i think if we have a release type called 'transl(iter)ations', users are going to start applying this to official releases. in fact, they may also do this with 'alternate' so i think the wiki should be clear on what is desirable. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transl(iteration-ation) AR (Resurrection).
On 12/10/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: 2006/10/12, Chris Bransden [EMAIL PROTECTED]: 2006/10/12, Chris Bransden [EMAIL PROTECTED]: i think if we have a release type called 'transl(iter)ations', users are going to start applying this to official releases. in fact, they may also do this with 'alternate' so i think the wiki should be clear on what is desirable. Not if it is an AR: the Ar will be used between an original (or why not a bootleg, live...) and it's transl(iter)ation. If the AR says release A is the transl(iter)ation of release B or release B has transl(iter)ation release A, I would understand that B is the original reference and A is the version that is transliterated. i realise that ARs are going to be used as well, i just think people will apply the 'transl(iter)ation' release type for all transl(iter)ations, regardless of whether or not they are officially released or not. they see a transl(iter)ation, they're going to apply the transl(iter)ation release type, IMO. of course the same could be said for alternate but hopefully that's ambiguous enough that they'd check the guidelines first :) Hopefully, they will (because I think most of the times, they will enter an new release without bothering to check if it already exists in another form), but this is why I insisted on AR: they will have to enter it between two releases, A and B. They will have to choose which is A and which is B, in other words which is the original, and which is the transwhatever. Even if they get mixed up, the voting process should correct most errors. Well, I believe it should. sorry i'm lost now. i'm not sure what working out the original has to do with releasetypes? take this release: Pink (JP): http://musicbrainz.org/release/4a3d60d3-90ea-4a90-938a-06b2aee41bd3.html it was released in the US with translated titles: Pink (US): http://musicbrainz.org/release/e724a07e-4a6b-41e4-95d1-fe9b25d91c3e.html Pink (JP) would be the 'original' in the AR (the band are from Japan), but both are official, pressed versions, so both would be ReleaseType: Official. now, say it was never released in the US, but instead someone translated the titles and put them up on a fansite. the AR would still be the same, but Pink (US) would now be ReleaseType: Alternate/Transl(iter)ation, as no official versions exists with those titles. My concern is that Pink (US) is a Transl(iter)ation in both scenarios, so maybe using Transl(iter)ation as the ReleaseType would mean people would use it even if it was an official release. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transl(iteration-ation) AR (Resurrection).
On 12/10/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: 2006/10/12, Chris Bransden [EMAIL PROTECTED]: sorry i'm lost now. i'm not sure what working out the original has to do with releasetypes? take this release: Pink (JP): http://musicbrainz.org/release/4a3d60d3-90ea-4a90-938a-06b2aee41bd3.html it was released in the US with translated titles: Pink (US): http://musicbrainz.org/release/e724a07e-4a6b-41e4-95d1-fe9b25d91c3e.html Pink (JP) would be the 'original' in the AR (the band are from Japan), but both are official, pressed versions, so both would be ReleaseType: Official. now, say it was never released in the US, but instead someone translated the titles and put them up on a fansite. the AR would still be the same, but Pink (US) would now be ReleaseType: Alternate/Transl(iter)ation, as no official versions exists with those titles. My concern is that Pink (US) is a Transl(iter)ation in both scenarios, so maybe using Transl(iter)ation as the ReleaseType would mean people would use it even if it was an official release. Getting closer! Pink (US) and Pink (JP) are currently different releases. This is currently justified(?) by the fact that for example, I couldn't recognize Pink (JP) as such (since the characters appear as ?? in my browser and I don't read japanese anyhow. Now when the same thing happened to a Yes (UK / US) or Sting (OK / US) album, the us and ok releases are not separated, just added to the release events of the unique release. ah but if they had different tracklistings (say, for words that are spelt differently in the UK/US - eg colour/color, not that i've ever seen that happen!), then they would get seperate entries. it's the same deal - we merge releases when the tracklist is the same, but an official transl(iter)ation means that they aren't by definition. So seperating releases by language is not a MB recommendation, separating Latin / Japanese / Cyrillic / Arabic / whatever releases is just the only way we can currently solve our problems. So I am not sure saying that using an A/T AR for Pink (US) would be a bad thing. i'm not saying that either?? i'm lost again :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Artist type: Project
i would say that bringing an old RFC that IMO never reached consensus, and then 35 mins later going to RFV is moving too quickly. based on http://wiki.musicbrainz.org/ArtistTypeProject, any band that has changed it's lineup could be changed to a project: Or is a mixture of both: it has one or more creative forces behind it, who stay consistent over several releases, but changing performers. - so a band that changes drummers every so often, but always maintains the same guitar+bass player is a project? not veto-ing though, as i think that people seem to have an idea what constitutes a 'real' project, even if i don't :) On 10/10/06, Robert Kaye [EMAIL PROTECTED] wrote: Given that there seem to be no real objections to this, I'd like to put out an official call for veto on this topic. Please speak up in the next 48 hours if you have objections to this issue. Otherwise I will bring the code back for the next server release. Thanks! ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] artist type: project
i never felt it was resolved. i feel that group is a plural, person is a singular, but project is pretty vague. i agree with lauri's comments in the original discussion that if we're to include project, we need collaboration, band, person and group, and all their definitions need to be rock solid (which i feel is impossible) to avoid edit wars. personally i think it's unnecesary. some bands have a key figure who orchestrated the whole thing, but i feel they're still groups, just with only one static member. what about things like NIN where it is him in the studio, a full band (group) live? i don't see what's wrong with just having them as groups, and then showing who the main member is by using 'additional' flags on all the others, if you think there's good reason for this, but even that can be iffy! On 10/10/06, Robert Kaye [EMAIL PROTECTED] wrote: Was there a resolution on this issue? If so, I'd like to include this in the next server release... -- --ruaok Somewhere in Texas a village is *still* missing its idiot. Robert Kaye -- [EMAIL PROTECTED] --http://mayhem-chaos.net ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] How to handle band/artist name changes
On 04/10/06, Aaron Cooper [EMAIL PROTECTED] wrote: On 10/4/06, Chris Bransden [EMAIL PROTECTED] wrote: i think the best argument for unifying artist names *where appropriate* (eg, not for true aliases/regional variations/other??), is that MP3 software and players are largely ordered by artist name. if i used the specific artist name used on all the Silver Mt Zion releases (http://www.discogs.com/artist/A+Silver+Mt.+Zion), their discography would be scattered across my itunes and ipod. to listen to all the ASMZ albums at once, i would have to create a playlist. it would be muchos cool if all the performance names were grouped on the server (solving display issue), and that the grouping name (eg, A Silver Mt. Zion) could be used by the tagger (or at least, the user could chose it, rather than the album specific peformance name). ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style I think you've all heard my arguments before :) So here's my new proposal: 1a. Have an AR that links the two MB Artists - X changed their name to Y for example. A problem might arise when X changed their name to Y, then to Z, and then back to X. We'd need to include dates or something so that we can make the tagger figure out which is the current performing name. or 1b. Have an AR that links the two MB Artists - Y is the most recent performance name of X and link all old names (X) to the newest performance name (Y). 2. Have a variable in Picard that can let you use the %currentArtistiName% instead of %artist%. This would quiet all the whining of the music taggers and me :) it's not neccesarily the most recent that is the one people would want to tag against, though :( also this doesn't solve the problem about having discographies spread over different pages (AR links are all well and good but a chronological list of all albums is really nice). i reckon the artist AR link (which remember aren't particularly readable at the mo) wouldn't be noticed by most users and we'd just be endlessly voting down release additions to the wrong (albeit more popular) performance name. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Featuring artist revisited... (fwd)
just copying my response to style... On 24/09/06, Steve Wyles [EMAIL PROTECTED] wrote: This is regarding the recent blog entry http://blog.musicbrainz.org/archives/2006/09/edit_of_the_wee_2.html and the edit that it mentions, http://musicbrainz.org/show/edit/?editid=5607659 As mentioned on that edit, I feel this subject needs opening up to a wider audience. Here are my reasons why I feel moving to the policy that is being advocated on that edit is a bad idea. 1) Musicbrainz is about recording fact, not necessarily what is on the cover. in this case the fact is what is on the cover, IMO. to 'feature' is to give highlighted billing - to do this is to put on the track title (on the album sleeve/cover) 2) Different (later) versions of the same release can be labelled differently. This can lead to editing wars. IMO this isn't a problem. there's no reason why tracks can't have different (feat.) setups in different contexts. eg, if the featuring artist releases a greatest hits, and a track s/he guested on appears, the previously main artist may well get the feat credit. s/he wouldn't be 'featuring' on her own greatests hits! IMO feat is very context sensitive, and it (amongst other things) should never be unified across all instances of the track. i'm not so sure the guidelines have ever suggested that unification in anyway is the thing to do, anyway. 3) The same work can be shown differently depending on the release it appears on. Particularly when it comes to VA compilation releases. 4) Different entries for the same work can make it difficult to normalize the database at a later date. see above. 5) Editors need to refer to the tracklisting on the cover rather then relying on impirical knowledge. 6) Voters need to refer to the tracklisting on the cover rather than impirical knowledge. see first point. 7) Webservice users will have to check AR entries instead of using either the track or the AR entries. i agree that it should be representable as an AR. IMO the ideal scenario is that performance ARs should be able to have a 'feat' flag, which would cause the tagger to append the (feat. x) to the track title (or perhaps elsewhere/not at all, depending on user prefs), though i've not fully thought this through. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: [mb-users] Featuring artist revisited...
On 25/09/06, P. HarryE. Coenen [EMAIL PROTECTED] wrote: Lukáš et al The example shows the immense waist fo time! And still it the tagger would not tell me the release year! Reading out the TOC would have reloved both! Cheers Harry what do you mean by TOC? the TOC doesn't contain any info, beyond track times. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: [mb-users] Featuring artist revisited...
On 24/09/06, Steve Wyles [EMAIL PROTECTED] wrote: On Sun, 24 Sep 2006, Simon Reinhardt wrote: Steve Wyles wrote: 3) The same work can be shown differently depending on the release it appears on. Particularly when it comes to VA compilation releases. So? Label them differently then. There is no written down guideline to make titles consistent as far as I know. But you are actually attempting to apply consistancy by relying only on what the cover states. Covers can be inconsistant between different countries and also between the original first release and a second print run a couple of months later. Which cover information do you use? the latest. in terms of the same pressing, as far as i can tell the 'latest' (ie, believed to be be 'most accurate') is used in other instances of differences (eg track titles). however this only works for different pressings of the same tracklisting, not entirely different releases (which could be credited differently cos of context) No, what you have is what the person designing the cover decided to include or under instruction by the label, the artist isn't always involved in that process. Also sometimes it depends on the contracts that have been signed as to whether a featuring artist is shown on the tracklisting or not. As far as I'm aware it is MB policy to state facts, not information supplied at the whim of the label. the thing is, 'featuring' often *is* a decision of the label. eg they often use it to bring a new artist to the fore, on the back of an established one, by using the new name to provide guest vocals (say...) on the track. often the entire track itself would be a contractual obligation, so ArtistIntent might be to delete the release :) Track listings on covers can't be relied upon to give accurate information. It should be the judgement of editors to include the important featuring information, not only what the cover states. who are we to make that decision? mostly it would be down to whether or not the editor thinks that the 'guest' is 'famous' enough (define 'famous enough'?) to warrant a billing, right? and what about when artists weren't 'famous' at the time? eg hendrix was a session guitarist and no name band member in the early years - most of which he has long since surpassed in recognition. should he be retroactively 'featured' on these releases? by the same token, a record label might chose to highlight his appearence (feat) on such tracks in a later date, in the context of compilation appearences due to the fact that hendrix plays on them. then the 'feat' begins to make sense. all about context IMO - you can't go wrong. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) x (disc 2), vs x x (bonus disc) / version info for special releases)
On 19/09/06, Don Redman [EMAIL PROTECTED] wrote: On Mon, 18 Sep 2006 10:56:06 +0200, Chris Bransden wrote: so, i tried to create some kind of rule for bonus discs - http://wiki.musicbrainz.org/BonusDisc (the ammendment section) thoughts? i still think this is a worthy ammendment, and noticed another case for it today. any thoughts? Why should the ReleaseAttribute for a Bonus Disc normally not be 'album'? because they are not normally albums :) (exceptions? i can't think of any) And what should it be then? depends what the bonus disc's contents are :) often they are compilations of b-sides (COMPILATION), live cuts (LIVE), combinations of them (OTHER, if neither has the majority), or just random tracks that didn't make it onto the album and weren't otherwise released (OTHER, unless the band decide to call it a bonus 'EP' or whatever) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) x (disc 2), vs x x (bonus disc) / version info for special releases)
On 19/09/06, Lauri Watts [EMAIL PROTECTED] wrote: On 9/19/06, Chris Bransden [EMAIL PROTECTED] wrote: On 19/09/06, Don Redman [EMAIL PROTECTED] wrote: On Mon, 18 Sep 2006 10:56:06 +0200, Chris Bransden wrote: Why should the ReleaseAttribute for a Bonus Disc normally not be 'album'? because they are not normally albums :) (exceptions? i can't think of any) Your argument, then, is they are not albums, because they are not albums. actually i say in the ammendment that they are normally not albums, which i still believe to be true They very often _are_ albums. Just because you choose to call them other doesn't make them not-albums. example of a bonus disc that's an album? i can't think of one, and they certainly aren't a majority, unless our definitions differ. Register this as one very strong objection to the current wording. If it must be mentioned at all, I would like to see it reworded as: Note the release attribute of bonus discs are not necessarily the same as the album they were distributed with. Use 'live', 'remix' or 'compilation' as most appropriate. seems fair enough :) i have changed it to: /!\ Also note that the ReleaseAttribute of bonus discs are not necessarily the same as the release they were distributed with. Use the attribute correct for the Bonus Disc on its own. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) x (disc 2), vs x x (bonus disc) / version info for special releases)
On 19/09/06, Lauri Watts [EMAIL PROTECTED] wrote: On 9/19/06, Chris Bransden [EMAIL PROTECTED] wrote: On 19/09/06, Lauri Watts [EMAIL PROTECTED] wrote: They very often _are_ albums. Just because you choose to call them other doesn't make them not-albums. example of a bonus disc that's an album? i can't think of one, and they certainly aren't a majority, unless our definitions differ. searching for (bonus disc) turns up these on the very first page. I'm sure I could find you hundreds, if I cared to. http://musicbrainz.org/album/aee63bc7-d58a-468c-8ec2-c1877a4710ee.html http://musicbrainz.org/album/b90f102b-c655-4162-86e1-f3748af91bad.html http://musicbrainz.org/album/61ad6a96-8dfd-47ae-8a65-5b893bf49e48.html http://musicbrainz.org/album/6ef9522d-15d5-41e7-9120-d51297b8881c.html http://musicbrainz.org/album/79d6ce90-c213-4fbc-b63f-15b2c5892500.html http://musicbrainz.org/album/c2327a16-de3e-42bd-aacc-8fde5a9ce439.html http://musicbrainz.org/album/b5bac44b-5cf3-4847-823d-a1241f663587.html http://musicbrainz.org/album/a6502413-ee87-47e2-8d71-d37cc5675a01.html http://musicbrainz.org/album/6126cb65-dc8e-4747-845c-898da69eaeb8.html http://musicbrainz.org/album/adca79f8-3876-4cd0-a7b9-1e4a85ff1cb9.html http://musicbrainz.org/album/c4fedac3-636c-45c4-9cdb-d9ee9c44bc0e.html http://musicbrainz.org/album/c626c829-9cc2-4519-aca7-866f6d014165.html http://musicbrainz.org/album/625904b3-316d-4e07-a3a5-4ca16dfe6e10.html http://musicbrainz.org/album/123c984e-6beb-46fe-8710-9b4915f11ed7.html Apparently, very many other people also disagree with you that a bonus disc can be an album. Sure, a handful of those may be miscategorised, but most of them don't look like it to me. i think the reason a lot of them are classed as albums is because users have been applying the attribute of the primary disc to all discs in the release, which is why i added the note in the first place. without any solid guidelines, people are of course free to classify things however they wish (within reason), but i think it's important to discourage the practice of using the attribute of the primary disc. with the next gen schema, we will be able to give the entire package an attribute, rather than the individual discs. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) x (disc 2), vs x x (bonus disc) / version info for special releases)
On 19/09/06, Lauri Watts [EMAIL PROTECTED] wrote: On 9/19/06, Chris Bransden [EMAIL PROTECTED] wrote: i think the reason a lot of them are classed as albums is because users have been applying the attribute of the primary disc to all discs in the release, which is why i added the note in the first I think you underestimate us. As I mentioned, most of those _are_ best classified as albums, and some could go either way (a few live, a few remix, and a couple of new tracks, on one cd) well without researching them i cannot know. i'm not sure how you could either! a list of 20 tracks could be 20 live tracks, 20 b-sides, 20 cuts from other releases, 20 demos, etc. they might even be an entire album that has been previously released, in which case they shouldn't be bonus discs, but merged into the origianl release, depending on where you sit on that arguement. if someone could find me a bonus disc that is proven to be an album i'd be very suprised, though this is all academic with my ammendment worded the way it is. It's very common in some situations, you know. Japanese releases. CD's cost so much more in japan, they get extra goodies to encourage people to buy locally, not import. yep but these are still normally b-sides (perhaps not released before in japan, but elsewhere), demos, etc. as a discogs rock moderator specialising in british and american indie, i see 100s of these at discogs, but i don't think i've ever seen anything *i* would consider to be an album, as a bonus disc. Re-issues of remastered classic albums from cult bands, with a bonus disc of unreleased material, to convince the die hard fans to buy another copy of an album they already have. two examples from my favourite band: http://musicbrainz.org/release/bd62b69e-6ee9-4b0e-b410-2736d4a4bde8.html http://musicbrainz.org/release/685f75a9-6dec-408f-8f3d-0256fc182b95.html though these are both disc 2 'albums' currently (i probably set them up as that, in fact!), really they are bonus discs, and 'other', since they are about 50:50 session/live tracks b-sides. no new material, except the occasional demo track (most of which had been re-recorded for later releases). ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) x (disc 2), vs x x (bonus disc) / version info for special releases)
On 19/09/06, Lauri Watts [EMAIL PROTECTED] wrote: What discogs considers an album has no bearing here. What MusicBrainz considers an album is a something that contains largely previously unreleased material, whether it's demos or not is irrelevant. discogs doesn't consider anything to an album - it doesn't have that definition (LP/CD/etc covers any full-length release - so a 'compilation' and 'album' would both be LP/CD/etc. only singles/EPs are given seperate distinctions - CD5/12/etc). i mentioned it because i have seen a lot of these releases, and know what to expect (i think!) More to the point, it always _has_ been the guideline (whether it was on the wiki or not) to put bonus discs under their appropriate attribute, I was told that the first time I got it wrong, and I've told many other people that since, and moved plenty of discs to the right place. And there are more non-album bonus discs than there are album ones, but that doesn't automatically make every one that is listed as an album wrong. agreed, though i never said that. There's really nothing new being said here, and your guideline has been amended satisfactorily, as far as I'm concerned. closed! i'll give it a week or so for the RFV ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) x (disc 2), vs x x (bonus disc) / version info for special releases)
On 19/05/06, Chris Bransden [EMAIL PROTECTED] wrote: On 08/05/06, Chris Bransden [EMAIL PROTECTED] wrote: i wish there was some kind of consensus on this - my tags are so inconsistant. i have situations like global communication's 76:14 special edition being a seperate release ( http://musicbrainz.org/showalbum.html?albumid=413942 ), yet all of the falls special editions have been merged together ( http://musicbrainz.org/artist/d5da1841-9bc8-4813-9f89-11098090148e.html ). examples like these repeat themselves through my collection and (i assume) the DB. so, i tried to create some kind of rule for bonus discs - http://wiki.musicbrainz.org/BonusDisc (the ammendment section) thoughts? i still think this is a worthy ammendment, and noticed another case for it today. any thoughts? ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) x (disc 2), vs x x (bonus disc) / version info for special releases)
On 18/09/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: I think it makes sense. Are there examples of more than one bolus disc? If so, we would need some way to distinguish them by title (even if they don't have a specific title). (bonus disc 1) / (bonus disc 2) maybe? i guess it follows with DiscNumberStyle ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: english capitalizationofshortenedwordsbeginingwith a single quote
On 03/09/06, Dave Smey [EMAIL PROTECTED] wrote: But more so I am disturbed that many just don't value good arguments and/or research in the discussion. Many weigh in with I like this or I don't like this and I have no idea why or even Obviously there is no rule. Not that that is totally unacceptable (except for the last statement, which IS), but we should try to do a lot better. off topic, but it depends on the discussion. here is IMO a good example of a discussion where it IS just down to personal preference. of course there are plenty of perfectly valid arguments you can use, but in the absense of any authoritative english captilization rules that *specifically* deal with this situation (ergo, that last statment would be acceptable to me - didn't i say it anyway?), non of them are deal breakers. you talk as if personal preference (i (don't) like this) have no merit. i don't think i would go that far. of course research (real-world usage) is valid, but the real question is WHY they used the method they did? IMO it's...personal preference. back on topic, i would go with michelle's reasoning. i think the arguement that a lot of titles don't have these apostrophes is compelling. i never looked at it like that. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.musicbrainz.org)
On 10/08/06, Alexander Dupuy [EMAIL PROTECTED] wrote: This relationship should only be used when the number and order of tracks on the two albums are identical, and each of the titles corresponds in meaning. IMO, like a similar disclaimer in the 'mastered by' relationship, this isn't really neccesary. it's useful to see that album a is a remaster/translation of album b, even if the content is slightly different (as they often are with seperate releases - bonus tracks, etc). unless there's a compelling reason i've missed, of course! i've definitely seen people doing the remastered relationship between 2 slightly different tracklistings and no one seems to care about it. i did an test relationship - http://test.musicbrainz.org/show/release/relationships.html?releaseid=458471 - all seems fine :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On 09/08/06, Rod Begbie [EMAIL PROTECTED] wrote: On 8/9/06, Brian G. [EMAIL PROTECTED] wrote: is virtual really the best name for the release type? rather than using a word and forcing a new meaning why not call it what it really is.. a translation. i don't think mb needs anymore confusing BadTerminology Compare the metadata surrounding http://musicbrainz.org/album/0900aa86-9bbd-4424-b0dd-bfd2942ea02f.html and http://musicbrainz.org/album/f470c26b-0beb-44d0-b49e-4caa02379b76.html. They've got different DiscIDs associated (10 on one, 2 on the other, no cross-over), so which titles you get when you lookup a disk are, essentially, random. One has an album AR. The other has a track AR. And the associated PUIDs on tracks differ. It's a mess, and all because music geeks want their MP3s tagged in different ways. no, it reflects actual differences between the tracklisting on different versions of this album. personally i agree it should be merged, but it is not an analogous situation to these virtual releases. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
On 09/08/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Chris Bransden wrote: IMO this AR is needed regardless. there are plenty of albums that have one tracklisting in one country, and another in another - note I am talking about the *text* on the tracklisitng, nothing else. Thanks for being realistic. :) Although you seem to be for merging them, you understand that, since we have them and they won't just go away, we need to handle them somehow. well, i still don't think i'm being understood so i will re-iterate :) there are in existance releases which have different translations of the tracklistings - nothing virtual about them. eg: http://www.discogs.com/release/656463 (original release) http://www.discogs.com/release/683846 (US version with translated titles) note that the lyrical content on both is exactly the same. regarding 'virtual' translations (ie done by users, not printed on sleeves) - i do agree they should be linked, as they're obviously in the DB, however i don't think they fit here under the current system, as they're not physical releases. if there was a 'virtual' release type, then yes that would make them much more acceptable. however, i don't think this affects the need for this AR, as there are legit printed releases that need the relationship, nevermind 'virtual' ones :) what i was saying is I don't think it's intended for actual translations of the *songs* themselves (eg a band doing a song in their native german, and then releasing an version with re-recorded english lyrics). Which is exactly what Nikki's initial mail said. :) i know, see the post i was replying to original to see why i went down that route :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Torrents as Releases (Was: Billboard's top whatever)
On 31/07/06, Don Redman [EMAIL PROTECTED] wrote: Hmm, there has not been a lot of response to my request. Strange thing, since a lot of people voted. as said, i had already said all i wanted to say i think :) in orter to push the process I'll make a concrete proposal as a Request for Comments MusicBrainz will start to keep track of series of *popular* torrents and have them in the database as compilation, bootleg. We know that they need a release attribute of their own, but there is none for now. define popular :) to quote myself: how do you really measure that on the internet anyway? torrents are the only method of distribution [here], and aren't centralised anyway? i just don't know how i would begin to decide which torrents were worthy and which were not. and also, why torrents? why not archives? playlists? lists found on sites? it goes on :/ ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Is french silly? :p (French capitalization rules)
On 01/08/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: On 8/1/06, Chris Bransden [EMAIL PROTECTED] wrote: On 31/07/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: Third, the rules should be such that those who know the language are able to capitalise correctly does not define correctly. In English there is a _widely_ accepted standard for what correct capitalization means, i'd strongly contest that! there's many - see http://en.wikipedia.org/wiki/Capitalization You didn't read that page carefully enough au contraire! It enumerates capitalization rules in general (like I or February should always be capitalized). Also, it has a special section that enumerates conventions [...] used for capitalizing words in publication titles and headlines, including chapter and section headings. It doesn't say anything about song titles. There is exactly one reference to song titles, an external link at the bottom of the page. (It doesn't seem very authoritative, but as it happens, it has about the same rules as we have.) exactly! publication titles is essentially the same thing (a song title is no different from a chapter title, really), and there is no 'standard' beyond the basic general rules for writing (but that's different from capitalising - ie changing a sentence/phrase into a heading/title). there is no single standard for capitalising in english. if anything, sentence case is more popular these days, for english. not that i'd argue for us to change to that, mind, but it completely comes down to personal preference. I really didn't notice that :) http://news.bbc.co.uk/ is one notable user of sentence case, if anyone cares. right, so i think the fairest way to choose would be a vote. - only native/v good french speakers should vote (it's impossible to say what looks best if you aren't either) No, it's not :) in my experience most people just use what would look good in their own language, which i don't think helps. - their vote should be on the aesthetic quality of the capitilsation, not the ease of application (as before, keeping it simple is easy, but if it looks crap then whats the point?) Nothing prevents us from a trade-off. Remember, we do use the standard way of English capitalization, _with simplifications_, and the simplifications were chosen specifically to make automatic capitalization possible. I don't really contradict my previous argument: there is a standard way of capitalizing English (everything capitalized, except unimportant words), but there is indeed a lot of variation with specific details (what are unimportant words: closed class, prepositions, articles, etc.), and we chose among them one that's easy to automatize. well i guess i completely disagree! like i said, if anything sentence case is the standard (and i believe there's some kind of push for it to be recognised as such, although obviously there's no official language group or anything like that to do such a thing, just busybodies :P). In a way, we could say the same thing about French: the standard way is capitalize only initial words, with a lot of variation about what are initial words. We should chose the one that's easiest to automatize, i.e. just the first one. i find the argument as to which is most aesthitically desirable to be much stronger. but if there were 2 competing standards with equal support, and one was automatable and the other wasn't, then yeah it could be the clincher, but only if the initial support for the standards was based on aesthetic quality alone, IMO. ultimately there are a lot of things in MBz which aren't automated/automatable - that's why we are here, no? ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Is french silly? :p (French capitalization rules)
On 31/07/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: On 7/31/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: 2006/7/31, Chris Bransden [EMAIL PROTECTED]: On 30/07/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: Hmm, I gather you don't have any argument, except that it hurts your eyes. well, isn't that the argument for any capitalisation rule? language is a tricky subject and i doubt any has a nice set of rules agreed upon by all who speak it. [...] the way I see it, the rules should be such that those who know the language are able to capitilise 'correctly', no matter how complex those rules may be. Personally i don't think there's anything wrong with this, and if you think about it, that's pretty much the entire MBz process summed up :) i mean, ultimately it would be easiest if WE JUST TYPED EVERYTHING IN UPPERCASE but that's not ideal, is it? Good point :-) Not really. First, it would be easier to type everything in lowercase (no pesky shift or caps lock). Second, it's easiest to just type everything the way you want. well i think that is still essentially my point (that no/simple rules are the 'easiest' rules), but anyway... Third, the rules should be such that those who know the language are able to capitalise correctly does not define correctly. In English there is a _widely_ accepted standard for what correct capitalization means, i'd strongly contest that! there's many - see http://en.wikipedia.org/wiki/Capitalization if anything, sentence case is more popular these days, for english. not that i'd argue for us to change to that, mind, but it completely comes down to personal preference. while in French there isn't. There are some main currents of thought, and we need to choose one of them. exactly the same as english, then :) None of the points apply to this choice, in my opinion. I mean, I wouldn't have anything against rules that say you should only capitalize attributes of nouns in the genitive case, and only if they are of Latin etymology, except if they are the last word in the title (which is ridiculous, but I have seen orthography and even capitalization rules containing most of those criteria), _if_ that was the _correct_ way of capitalizing song and album titles in the respective language. In French there just is no set of rules about capitalization that can be simply considered correct. right, so i think the fairest way to choose would be a vote, but i would say that: - only native/v good french speakers should vote (it's impossible to say what looks best if you aren't either) - their vote should be on the aesthetic quality of the capitilsation, not the ease of application (as before, keeping it simple is easy, but if it looks crap then whats the point?) such a vote would be difficult to implement, though. i'd hope the discussion reaches a conclusion instead :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Is french silly? :p (French capitalization rules)
On 31/07/06, Nikki [EMAIL PROTECTED] wrote: On Mon, Jul 31, 2006 at 04:08:14PM +0100, Chris Bransden wrote: we had the same problem at discogs.com - currently, Ever First Letter Must Be Capitilised, which is great in that everyone can easily follow it, but crap in that it just looks wrong to me (i'm English) - i mean totally wrong! so i can entirely sympathise with Mangled here. and yet it looks fine to me, for English. :) weirdo :P but yes there are many english people who feel the same. i'm just glad the decision went my way here :) the way I see it, the rules should be such that those who know the language are able to capitilise 'correctly', no matter how complex those rules may be. however it should be anticipated that others will just capitilise as they see fit, but they certainly shouldn't 're-crapify' the text once it's been fixed by someone with The Knowledge. personally i don't think there's anything wrong with this, and if you think about it, that's pretty much the entire MBz process summed up :) Well, of course. The argument here is that there are two ways of doing it. People entering data in MusicBrainz largely use one style (excluding the completely wrong English-style ones) and the wiki has the other style. I don't think either are *wrong*, they're both accepted. However, I still don't see the benefit of choosing the one that the majority of people don't use, other than that it won't hurt panda's eyes. well, the majority of people seem to do the wrong thing in a lot of other areas, else i wouldn't have to look through my subscribed artists every day :) if people do the wrong thing that's fine, but then i think there should be style guide support for native french speakers to put it into the most aesthetically pleasing format. personally i doubt that people really put much thought into the capitlisation of titles when entering them into here of freedb or wherever - mostly it's just about speed, so i wouldn't neccesarily take the format that the majority are in to be an indication of real preference. eg, i never knew english capitilsation fully until i started using MBz, but my own format was near identical anyway, so i liked it :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: FW: [mb-style] What defines a Soundtrack?
On 27/07/06, Beth [EMAIL PROTECTED] wrote: Does anyone else have any more types of soundtracks? I know they can be added later. Just figured I'd get as many outlooks as I could before drawing up the wiki for it. not sure if it really counts, but perhaps deserves a mention: http://musicbrainz.org/release/1aa13905-c3bb-4549-8c78-1c5fd299b2f1.html ^ this isn't an actual soundtrack, but rather a concept album that is a soundtrack to a made up film. I'm never really sure whether to call it an album or a soundtrack, but stuck with album for the time being. i'm sure there are other similar examples in the DB. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: FW: [mb-style] What defines a Soundtrack?
On 27/07/06, Beth [EMAIL PROTECTED] wrote: Can you go into a little more detail? How is it a concept album of the soundtrack? Is it because it was inspired by the movie well, there is no movie :) the basically made a soundtrack album to a movie that doesn't exist (or at least, only in their heads). i kept it as an album because i think it's similar to 'normal' concept albums that are created around a specific theme or 'plot' (eg Pink Floyds' 'the wall'), and the calling it of a soundtrack doesn't really make it into one as we see it (or does it???). ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Setting DJs as owners of Remix CDs
On 26/07/06, David Moran [EMAIL PROTECTED] wrote: I am a firm believer in the ReleaseArtist should be the DJ mixer. Especially when it is as blatant as being the artist on the cover of the CD. I would say only under these circumstances. it isn't rare to have a dance compilation mixed by some no name DJ just to get it running together. often they don't credit them at all, but a liner not mention shouldn't result in it being filed under that artist. but yes to the typical DJ mix CDs having the DJ as the release artist. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Releases with no real title
if you take a look at the very end of http://wiki.musicbrainz.org/UntitledTrackStyle, you'll notice myself suggesting the same thing, but never got round to creating the wiki page :) Yeah, i completely agree with this, and I don't think you'll run into any opposition since UntitledTrackStyle has worked so well. Go for it! :) On 23/07/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: Hi! I noticed this (1) today: it's a release that doesn't really have an official title, only a description. What do you think about extending the rules for untitled tracks (2) to releases? There are quite a few releases that this would apply to (besides bootlegs, of course), including quite a few band demos and promotional tapes. Even (2) has a link to a release that uses this convention (3). (1) http://musicbrainz.org/show/edit/?editid=5190772 (2) http://wiki.musicbrainz.org/UntitledTrackStyle (3) http://musicbrainz.org/show/release/?releaseid=349547 With this convention, releases that don't have a real title (*) would have either [untitled] or a brief description between square brackets. Release (1) would be named anything from [five song sampler from Rude Awakening] to [sampler from Rude Awakening], depending on if there are other samplers for the same album. Untitled demos would be [demo] or [1993 demo], etc, depending on how many demos the band has (brief and distinguishing is the guideline). (* hard to define, I know; we'll have to apeal to user judgment at one point.) For _official_ releases that don't have _official_ names, _if_ there is a common unofficial name, we'd put the unofficial name in brackets. (The difference between an unofficial title and a description is capitalization for titles.) This doesn't apply to bootlegs, of course, since they're not official in the first place. I just want to see some general thoughts, and if it seems appropriate I'll whip up something worthy of a RFC. -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: UntitledReleaseStyle
I would also include a mention of http://wiki.musicbrainz.org/SplitReleaseTitleStyle as an exception. Perhaps also it would be wise to say something about untitled singles? Bit of a grey area as we don't seem to worry much about vinyl (which is the common offender - eg 7inches in plain sleeves) but i'd say something like: Untitled singles should be named after the A side, except in event of a double A side, in which case the title should be that of both track names, split by a space, slash, space. If you are not sure whether the release is a double A side or not, use the latter method. On 25/07/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: This is a request for comments on the new UntitledReleaseStyle* proposed guideline. The rationale from my initial proposal is below. *) http://wiki.musicbrainz.org/UntitledReleaseStyle -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. On 23/07/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: Hi! I noticed this (1) today: it's a release that doesn't really have an official title, only a description. What do you think about extending the rules for untitled tracks (2) to releases? There are quite a few releases that this would apply to (besides bootlegs, of course), including quite a few band demos and promotional tapes. Even (2) has a link to a release that uses this convention (3). (1) http://musicbrainz.org/show/edit/?editid=5190772 (2) http://wiki.musicbrainz.org/UntitledTrackStyle (3) http://musicbrainz.org/show/release/?releaseid=349547 With this convention, releases that don't have a real title (*) would have either [untitled] or a brief description between square brackets. Release (1) would be named anything from [five song sampler from Rude Awakening] to [sampler from Rude Awakening], depending on if there are other samplers for the same album. Untitled demos would be [demo] or [1993 demo], etc, depending on how many demos the band has (brief and distinguishing is the guideline). (* hard to define, I know; we'll have to apeal to user judgment at one point.) For _official_ releases that don't have _official_ names, _if_ there is a common unofficial name, we'd put the unofficial name in brackets. (The difference between an unofficial title and a description is capitalization for titles.) This doesn't apply to bootlegs, of course, since they're not official in the first place. I just want to see some general thoughts, and if it seems appropriate I'll whip up something worthy of a RFC. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Billboard's top whatever
On 26/07/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: I start this thread because of (1) and to a related thread on the user's list. I started it here because I think this is a guideline issue and we need to discuss as such. I encountered similar situations before. (1) http://musicbrainz.org/show/edit/?editid=5258089 The current guidelines say rather flatly that homebrews are discouraged. I think we should at least change that formula to an explicitly more flexible version. Perhaps even add an internet bootleg release rule, separately. I stated this in a (less organized) note on the edit above: homebrews and most torrents are random collections of songs of no musical interest except to a very small number of people, and for a short time. But that doesn't mean all home-burnt CDs and music .torrents are uninteresting for MB. We do keep in the database demo tapes that were released by some obscure band thirty years ago, when they were even more obscure, in 200 copies, on tapes, recorded in their basements. And we (at least I) care for them and consider them important (or at least interesting) pieces of discographic history. How can we then look at a collection of all the songs in one of Billboard's (*) tops and dismiss it as a homebrew just because it was not released on a physical bootleg CD from Russia(**), but through a torrent? I have seen almost-one-year-old torrents of such collections that still had 500+ downloaders. Not to mention that it is, in fact, a collection of the best-sold music of the times, which is not a very arbitrary criterion. but where's the line between arbitrary and non-arbitrary? where's the line between popular and non-popular (and how do you really measure that on the internet anyway? torrents are the only method of distribution, and aren't centralised anyway)? surely any criteria is worthy of indexing if it's popular, and if, say, one were to compile a torrent of the top 100 of 1978 in iceland it would be as non-arbitrary as the case above. IMO you can't make rules about this sort of thing, so it's best to say everything goes (freedb...) or only these concrete cases (current system). Such a collection is, I insist, worthy of MusicBrainz, both as a tagging database and as a discographic database. (In fact, I'd even agree with adding at least some of Billboard's tops even if there was not, in fact, a torrent containing the songs.) you'd index a criteria of music, despite this not neccesarily being released in any form?! ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SeriesNumberStyle - useage for more than one named part/volume in the same track/release
On 12/07/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Chris Bransden wrote: perhaps it could be argued that the proggier end of contemporary music is more likely to affiliate itself with the CSG, though... Please no more genre specific guidelines, that really really sucks. You have no borders between genres and that way you're making it veeery inconsistent. I have tons of text files filled with ideas for grouping titles, sub titles, named parts, multiple title style, medleys, megamixes and so on and wanted to sum this all up in one comprehensive proposal to finally get it written down and made official, but it kept slipping through my fingers, it's a very hairy matter. And since I have enough style issue tickets on my name at the moment I can't handle it yet. So this is an unlucky situation for me because you put me on the spot and I have to react on this now (as it is a very important topic for me) but I haven't finished my thoughts yet. :( haha, well lets forget about it for now then, it's definitely not important at this point :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SeriesNumberStyle - useage for more than one named part/volume in the same track/release
On 12/07/06, Nikki [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 12:18:32PM +0100, Chris Bransden wrote: i propose we enter this as Trilogy, a: The Wonder, b: Hyperstation z: Eliminator Jr., to follow with the general style of PartNumberStyle (ie, seperate PartNumber from TrackTitle with a comma and a space; seperate PartName from PartNumber with a colon and a space; etc) I much prefer the subtitle style than this. would you prefer subtitle style for normal part/series numbers as well? perhaps this is the direction we go in, but as said i'd prefer to wait for shepherds input :) i do think it should be one thing across the board, though. it seems that the classic style guidelines methods of handling such tracks (ie. Trilogy: a. The Wonder - b. Hyperstation - z: Eliminator Jr.) seems to have been adopted in the DB, but i don't think that it looks consistant alongside the widespread PartNumberStyle. If something has been widely adopted, we shouldn't try and oppose it. It won't work [1]. I'm not entirely sure the part number style is what people expect either, I rarely see a release added which uses it. A quick search of the database finds about 12,000 following the current part number style (but I don't know how many of these were added differently and then changed) and 4,000 with part in brackets. well i think that says more about sleeves being inconsistant, more than anything else. PartNumberStyle must be the same as VolumeNumberStyle in presentation, as it's essentially the same thing (SeriesNumberStyle), and hence the style of that was followed. [1] e.g. Most people expect the artist to contain the featuring artists. Trying to keep everything in the right place has been a neverending task. getting off topic now, but i'm not sure i agree with you there! in an album where a guest artist only feat.s on 1 track, then they would be expected to be in the track field, but a VA release, or a release where the feat. is global, then yeah i think people expect to see it in the artist field (or perhaps albumtitle field in the latter scenario). ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: New Artist Type: Project
On 05/07/06, Lauri Watts [EMAIL PROTECTED] wrote: I think I agree more or less with Don (at least, if I understood him right). If the choices were Person or Band then I could see a case for covering things which are more than one person, but are not a band. The choices are Person and Group though, which seems sufficient for me. Pigface, Excessive Force, and Willard Grant Conspiracy are all without any shadow of a doubt groups, but we could spend hours debating if they are collaborations, bands, or projects, and I'm not entirely sure I see what purpose that would serve. this i agree with. i think we're seeing some people intepreting 'group' as some kind of equal effort, where really it just means (to me) group of persons. a lot of groups have 1 singular creative force, and a bunch of glorified session musicians, yet i think this can be solved simply by having the group leader as the 'member', and others as 'additional member' - see http://musicbrainz.org/showrel.html?id=8871type=artist ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] BoxSetNameStyle (again)!
On 21/06/06, Stefan Kestenholz [EMAIL PROTECTED] wrote: define 'people' :P i don't want to see my albums change name depending on what particular package i got them in. i want the album field of my what did we say about just yesterday bout the i don't want this in my tags arguments? you put your opinion above all others, and are continually working against the consensus we worked out really hard. what consensus! there never was one! read the prevous BoxSetNameStyle thread. i put it up for discussion and nothing came of it - i can't be any fairer than that. also i had this reply in my drafts for a few days now, waiting for some other views. it seems no one wants to touch this subject, but i'd rather they did as i'm fed up with having arguments about it :/ it's obnoxious. if we have 2 entries in the database, then everybody can tag against the version they like. you can tag against the clean standalone release, and those who own the boxset do against the boxset. the problem is the discographies become rediculous - any popular band will have tons of boxsets, multiple album sets, bonus disc configurations, etc, etc. MBz has the advantage over discogs in that it doesn't have 'product' oriented discographies, but rather 'music' oriented ones. our logic works better for tagging IMO. i think if we're going to tag by product (and i don't suggest we should), then we should be appending (remaster) to the end of albums, and indexing all those seperately, amongst other things. i just don't see the logic of indexing boxsets seperately if we're not listing everything else. why would you want one and not the other(s)? many releases have different coverart and don't get seperate entry here. no harm in having more than one ASIN for each release. most MBz releases will probably have more than one ASIN for each format, country release, etc. maybe even 10+ if you look hard enough. not anymore, once we do albumgrouping objects (i.e. soon), and add labels/ean/upc support. you ask a diehard discogs'er and whats on the cover should be in the tracklisting supporter should like that. meh, i'm one of those :P releasegroups seems like a good way of organising existing data, as well as possible increasing the scope of what we consider to be a seperate release (eg scrapping point 1 of BoxSetNameStyle), but IMO it's counter productive to work as if it's here already, especially in only one of the areas (what about remasters? maybe we should start adding product info like (Japan version) to?). i think if SG5Disaster taught us anything it's that proceeding as if proposed system modifications are/will be here doesn't help things. i just don't think there's any need to index these things twice when it's the same album - it just doesn't seem to go with MBz logic. we either list ALL releases seperately (ie, seperate pressings, country releases, remasters, etc), or put everything with the same tracklisting together. untill we properly deal with labels, etc, i don't see the former to be workable. again, this will be added, if we don't spend our energy argueing about all that silly stuff. off topic: then we'd turn into discogs, and be useless for tagging, IMO. i don't see the 2 projects having a useful middle ground, though i love both for what they do. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] new artist type colaboration
i agree with adding collaboration as an artist type, but for what is worth i don't agree with at least 1 of yr examples being collaborations :) like i said in the other thread - run-d.m.c vs jason nevins isn't a collaboration, it's just a remix of run dmc by jason nevins. slightly off topic i know but i think if we're going to define 'collaboration' as an artist type i think we need to reinforce what a 'collaboration' is. in my book it is when 2 artists *work together* to create music, rather than just 1 working on the others existing music on their own, and releasing under a combine named. here's an example of a 'true' collab: http://musicbrainz.org/artist/2939b565-afaf-408f-aea1-7636fbf0d6ce.html run dmc vs jason nevins - i don't know what you'd call that, really. perhaps we need an AR for [Artist] is [Artist] remixed by [Artist] (and indeed [Artist] is [Artist] mashed up with [Artist] by [Artist]). infact, i should request that/those AR(s)... On 23/06/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: Hi! I started a week or so ago a thread on the user's list with the same subject as this one. I'm moving it here as I think it's worthy of a style discussion. My problem is with the separation of artists in person and group. I suggested we add another option, collaboration, for, well, collaborations between more clearly-defined artists (bands and soloists). Things like http://musicbrainz.org/showartist.html?artistid=306200 or http://musicbrainz.org/showartist.html?artistid=46486 if you wish. The main problems raised by responders were that (1) a group is just something composed of more than one artist and, separately, (2) it's not clear how to define the difference. Concerning (1), even if that's technically true that that definition exists, for me, and I'm sure for many others, group has a much more cohesive meaning than just some artists singing together. Especially in the context of music, I'm sure most people wouldn't call the two artists I linked above groups. The answer to (2) is, I think, strengthening my first point, too. My first proposition involved several ambiguous and complex criteria, thus being unuseful enough I'm not even going to list them again. Instead I'm going to cheat and propose that we call group only an artist that is (or should, or could be) the target of a X is a member of ... relationship. Things that are targets of X collaborated on ... remain called groups. When we get some developper time, we may even add warnings on conflicts (if I try to say a band is a member of a person, or something is a collaboration and has members, something is very likely wrong, so we should warn the users). Note that I didn't even read the guidelines for is a member of and collaborated on (well, not recently). I just assert that they're (usually, I'm sure someone will find exceptions) mutually exclusive, and the separation matches naturally the change in terminology I propose. -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 19/06/06, Don Redman [EMAIL PROTECTED] wrote: On Mon, 19 Jun 2006 12:19:41 +0200, Chris Bransden wrote: firstly, i don't think any DB/Tagger changes will change the situation (see my previous post). Well, my experience says the opposite. In my very humble experience here at MB, every change at the fringes of the overall structure of the system has led to changes in the semantics of the MB data. The semantical changes are usually - not at the same 'place' as the structural changes, - sometimes huge and drastic - sometimes very minor, but then lead to an outburst of an old problem four months later. I therefore strongly suggest to disucss such a change (which I am for BTW) around the time when we make our first experiences with the tagger script. i don't disagree that this is true generally, but i don't think it will be so in this case. like i said, taggerscript will allow us to say always put/append this type of AR in(to) this ID3 field (if my understanding is correct) - this discussion has shown us that version info is often contextually relevent, and shouldn't be deleted from the tracktitles, but NOT that it should be ADDED to tracktitles. there is version info stored as ARs that is trivia, and never/not always refered to on tracklistings (eg remix relationships, live, earliest version of, etc). TANGENT USED TO ILLUSTRATE MY POINT :P - same with SG5 - (feat. x) should always be included on tracknames (or artist names) if it's on tracklistings - if taggerscript always included performance ARs in track names we'd end up with Foo (guitar by J Bloggs) (drums by A Person) (produced by S Wonder) and so forth. unless of course we add some kind of 'included on trackname' flag to ARs... ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: RenamedRelationshipType
On 20/06/06, Aaron Cooper [EMAIL PROTECTED] wrote: On 6/20/06, Nikki [EMAIL PROTECTED] wrote: On Tue, Jun 20, 2006 at 03:10:45PM +0100, Steve Wyles wrote: I believe the current trend is to separate previous names out into separate artists. Particularly, where it is considered to be a new project or a different style of music. Using aliases for the previous names will result in releases which were issued (and continue to be issued) under the old name to be mis-credited to the current artist name. And adding a new artist for every name change results in many artists to represent one entity. While I support multiple artists for completely separate projects, we don't have anything saying when an alias should be used and when a new artist should be created. t.A.T.u., for example, were originally called Тату but changed their name when they started to release stuff elsewhere. Now they use t.A.T.u. in Russia too. Splitting them would be stupid, they didn't change direction, it's not a different project and some of their Russian songs as Тату appear on non-Russian releases as t.A.T.u.. Yet they clearly started as one name and are now another. That's why I'd like to see something saying just when something deserves a new artist. People seem to hate aliases because they're not used for anything other than searching, but why will anyone ever want to code better stuff for something we never use? Why don't we create a X was released under the alias Y AR? That way we could keep bands that changed their names together in the database. Of course, there'd have to be other satisified conditions, like there was no significant change in membership or whatever we decide, but I don't like the notion that a change in style deserves a new band. A band's style is very subjective and we don't use it now to separate artists who don't change their names but do their style (see Metallica - again, the style is very subjective, but I hope you understand my point). Why not make a X was released under the alias Y AR so that one day these can be tagged under the original band/artist name if desired, but stored under a single MB Artist? that's a really good idea - never thought of it that way! you could have it trigger a prompt when tagging, to. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: RenamedRelationshipType
On 20/06/06, Steve Wyles [EMAIL PROTECTED] wrote: On Tue, 20 Jun 2006, Chris Bransden wrote: On 20/06/06, Aaron Cooper [EMAIL PROTECTED] wrote: Why don't we create a X was released under the alias Y AR? That way we could keep bands that changed their names together in the database. Of course, there'd have to be other satisified conditions, like there was no significant change in membership or whatever we decide, but I don't like the notion that a change in style deserves a new band. A band's style is very subjective and we don't use it now to separate artists who don't change their names but do their style (see Metallica - again, the style is very subjective, but I hope you understand my point). Why not make a X was released under the alias Y AR so that one day these can be tagged under the original band/artist name if desired, but stored under a single MB Artist? that's a really good idea - never thought of it that way! you could have it trigger a prompt when tagging, to. Except that with the current db structure it isn't possible to associate one side of an AR to an artist alias, only to artists. but that's exactly what we'd be doing, no? there's no harm in having an artist entity to also be an alias for the 'master' artist. it just wouldn't have any releases under it, just ARs. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: RenamedRelationshipType
On 20/06/06, Nikki [EMAIL PROTECTED] wrote: On Tue, Jun 20, 2006 at 09:38:51PM +0100, Chris Bransden wrote: but that's exactly what we'd be doing, no? there's no harm in having an artist entity to also be an alias for the 'master' artist. it just wouldn't have any releases under it, just ARs. No no no! If we have separate artists for the artist name used on the cover, various artist albums will get misassigned, people will try to add albums to the empty artists and will try and merge them. We already have a problem with all those. :( perhaps we need a special artist type to make it impossible for releases to be added to them. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Net Releases
On 17/06/06, ZaphodBeeblebrox formerly known as mo [EMAIL PROTECTED] wrote: net release == wordwide this is obvious to me why? I'll tell you, as I live in norway, I cannot get any release that is *only* released in the US, unless I get someone to send that to me. yes you can - amazon.com and so forth do worldwide delivery. IMO there is a distinction that people don't seem to realise - physical releases are intended for certain distributition areas (release country), but this is not the same as saying 'this release is available in [country]', as shops will have their own distribution areas. internet releases have no intent behind their distribution, so IMO they should have a seperate 'country' ([net release] or similar) to reflect this. it's not true that band x released internet album Y in antartica in 2005, or whatever. by saying 'worldwide' you kinda imply this, IMO. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Net Releases
On 18/06/06, joan WHITTAKER [EMAIL PROTECTED] wrote: Do I take it that once Don Redman has spoken that is it - subject closed - decision made? no :) no offence intended toward don, but unless i'm mistaken, we're all equal in style discussions, unless there is no consensus, in which case Rob Kaye steps in. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 18/06/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: This means we may need to add single version to an edited track on a single that isn't marked like that on the cover. Sometimes this track may be the first released. But it can be very confusing to do it otherwise. say you have a single tracklist that reads: 1) Foo 2) B Side how do you tell whether 1) is a 'single version' or not? not everyone will own the album as well. i don't think we should be adding version info on tracks if it's not written on the sleeve, even if we can proove they are different to the standard. by saying that all indentically named tracks are indenticle in contet you require users to have heard all instances of the track in question. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 18/06/06, Don Redman [EMAIL PROTECTED] wrote: To be concrete: If people are able to retrieve this informtation for tagging purposes, and if ARs are displayed in a more practical way, THEN, there will be no need anymore to give the same track title to all versions of the same song, because people can just follow some ARs that point them to the track with the 'original title'. Whatever the 'original title' is and how the ARs work, will have to be worked out. In conclusion I propose to postpone this debate until Picard 0.8 comes out. I then propose not to lead a debate about principles, but a debate about concete solutions to this and the related problems using contextual track titles (that say (album version) if it makes sense _in context_), ARs (taht point to the same track with the most 'context free' title), and Picard 0.8s tagger script that retrieves all this info and uses it for tagging. i'm not sure i'm reading this right, but surely this is the wrong way round? we should be keeping contextual information *now*, and then perhaps thinking about moving it to ARs when this info can be moved to tags? secondly, i'm not sure tagger script is going to help, as surely that will allow you to assign rules like append version info to track names which is not the same as keep version info same as tracklist, as there's version info we store (or will store) that is not on covers. taggerscript will only help on global preferences - i still think we'll always need context-based rules for what is and isn't included on titles. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
On 18/06/06, Don Redman [EMAIL PROTECTED] wrote: On Fri, 16 Jun 2006 10:11:36 +0200, Nikki wrote: * We should have an 'official' and 'unofficial' attribute because some transliterations/translations are officially released, and therefore deserve separate entries. What does official mean in this case? Is this the same as I proposed, namely the distinction whether the trans...tion refers to an actual existing releas or is just a virtual release? yes, see my first reply. i would also like to reflect schika's experience of titles with both the JP (or other) and English translation on the tracklisting. I imagine there's probably cases of the tracklist appearing like: JP Version: 1) [Japanese Text] - [English Translation] 2) ... US Version: 1) [English Translation] 2) ... or various combinations of the above. i think we should probably still say that [JP Version] is an [official] trans...tion of [JP Version], as it's true, but it's just that the JP version also included this trans...tions, if that makes sense :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 19/06/06, derGraph [EMAIL PROTECTED] wrote: Chris Bransden wrote: i'm not sure i'm reading this right, but surely this is the wrong way round? we should be keeping contextual information *now*, and then perhaps thinking about moving it to ARs when this info can be moved to tags? No, in my opinion this is not the wrong way around. The wrong way would be to change the guidelines now just to change them again once we have the Picard and page design requirements Don Redman mentioned. firstly, i don't think any DB/Tagger changes will change the situation (see my previous post). secondly, even if these changes were to work, surely the net result would be that we would store this info, but in a different place - it's simpler to move info than to research and enter it :) Also, I know you fear we might be losing data. However, we're constantly digging up data that using your line of argumentation would already be lost. This information might no longer be on MB, but hey can easily be found. Just think about how many fan pages or cover scans, used to prove an edit, you've seen during the last month. aye, it's not 'lost' in the sense that it can't be found again, but i'd rather we didn't need to in the first place. i for one have gone through my music selection far too many times for discogs and MBz to be doing it again every time we have a rule change :P ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Net Releases
On 19/06/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: On 6/19/06, Chris Bransden [EMAIL PROTECTED] wrote: internet releases have no intent behind their distribution, so IMO they should have a seperate 'country' ([net release] or similar) to reflect this. it's not true that band x released internet album Y in antartica in 2005, or whatever. by saying 'worldwide' you kinda imply this, IMO. But it is actually rather correct. If someone releases an album in, say, Germany, than it's considerably non-trivial for someone in Antarctica (or China, for that matter) to aquire it. i buy cds from hmv.co.jp often, but they weren't RELEASED here (UK), they are just AVAILABLE here, thanks to international shipping. that's why i mean - net releases aren't RELEASED anywhere, they are just AVAILABLE everywhere :) i don't mean that it is not available in antarctica, just that the label had no intent to RELEASE it in that country, as they would in a physical release (where all distribution is planned), it's just AVAILABLE there. by saying RELEASE, i think you imply intent, and there is non with net releases - hence i think net releases should have a seperate 'country' - [net release]/[download]/whatever. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
On 14/06/06, Dustin B [EMAIL PROTECTED] wrote: There's no reason to throw away good info right now just because we're confused with what to do with it, or worse disagree with it because it doesn't make the database pretty. Remember the goal is the ultimate repository of music releases my concern is that these *aren't* music releases. infact i've never really seen the point of transliterations, as i feel the english (or other) version of the trackname is trivia, rather than something you'd want to look at. after all, all other aspects of the release (lyrics etc) will presumably be in the offending language, so i'm not sure it's worth doing. plus i prefer seeing things in the language of origin, even if it is all squiggles to me :) but i appreciate that other people want them, so fair enough in them being added, and i agree that the next steps need to be to make an AR to link them to the original, and then hide, or otherwise seperate unofficial transliterations from official releases. also i think the transliteration AR should have an 'official' or 'unofficial' attribute, to seperate releases that have different titles on the sleeve depending on what market they are in. 'official' transliterations shouldn't be hidden/seperated from the official releases. chris / gecks ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
On 14/06/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Hi again, to sum it up so far: there have been no vetoes but some discussion that put parts of this back to the RFC stage, so I'll split it as follows... I propose adding CoRelationshipAttribute to EngineerRelationshipType (the main type, not all sub types) and within that to the sub type for mixers, and adding ExecutiveRelationshipAttribute to EngineerRelationshipType (again the main type only) as proposed by Schika. For this I let the veto phase open for another 48 hours. If someone thinks we need to clarify those two sub roles first (that is to write the wiki pages for those attributes to exactly describe them), feel free to veto. only one i thing is a bit bizzare is adding ExecutiveRelationshipAttribute to EngineerRelationshipType - i'm not sure what that would mean? also i've never seen it before so i'm inclined to think it's perhaps a very rare occurance. was it 5 appearences we needed for an AR to be valid for inclusion? personally i think if it appears once it's worth including, so i'm not vetoing :) Note that the following discussion arose from this: Schika had examples of liner notes which differentiate between a mixer and a mix engineer. Do we need that separated? well i think you have to be careful as the example (system 7) might mean DJMix when they say Mixed By and Mixed By where they say Mix Engineer. if anyone can find an example where that's definitely not the case then it's probably worth adding seperately. Also he stated a difference between recorded by and recording engineered by again. I think all this needs a new thread so feel free to start one. ;) this is also possible, eg when the recorder (read: producer) has a assisting engineer. of course you could bodge this by crediting them as additional recorded by, but personally i'd prefer to see it as close to the liner notes as possible, so i'd be ok with this being added. i think ultimately we're going to end up with lots of engineering ARs with a lot of overlap, but personally i don't see this as a problem. For the proposed changes of adding GuestRelationshipAttribute to OrchestraRelationshipType and ConductorRelationshipType I feel there definitely is need for more discussion to clarify what this attribute is about in general (wiki page needs to be written) so I abandon the request for those changes. i think it would be ok to include these to be honest as i'm sure there are valid situations for it, even if you applied my logic (which probably stinks :P) however i do think 'guest' needs some explanation/clarification for its general use. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type is the predecessor of
On 14/06/06, derGraph [EMAIL PROTECTED] wrote: For cases where an artist only changed it's name we might use a more general renamed to/was previously known as AR. i'm not so sure such cases would be indexed as seperate artists anyway. see http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-May/002840.html and related discussion ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type is the predecessor of
On 14/06/06, Aaron Cooper [EMAIL PROTECTED] wrote: On 6/14/06, Chris Bransden [EMAIL PROTECTED] wrote: On 14/06/06, derGraph [EMAIL PROTECTED] wrote: For cases where an artist only changed it's name we might use a more general renamed to/was previously known as AR. i'm not so sure such cases would be indexed as seperate artists anyway. see http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-May/002840.html and related discussion There are many examples in the database of groups which have changed their name and are entered as separate artists. For example: Inearthed - Children of Bodom according to the annoation, this seems to be show a stylistic change, not just a name change. these kind of groups would be seperated (ie you'd want them tagged seperate/on seperate artist pages) Burn the Priest - Lamb of God i don't know the artist, so perhaps this is also a stylistic change. if not as far as i'm aware it should be an alias of lamb of god, not a seperate artist. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
On 10/06/06, Simon Reinhardt [EMAIL PROTECTED] wrote:
Hello,
I would like to add some attributes to some AR types and therefore request
ok/veto for each of them:
1. http://wiki.musicbrainz.org/OrchestraRelationshipType could need
http://wiki.musicbrainz.org/GuestRelationshipAttribute
- {orchestra} orchestra {additionally} performed becomes {orchestra} orchestra
{additionally} {guest} performed
2. http://wiki.musicbrainz.org/ConductorRelationshipType could need
http://wiki.musicbrainz.org/GuestRelationshipAttribute
- {additionally} conducted becomes {additionally} {guest} conducted
Rationale for those two: well I have seen lots of guest orchestras being
credited in the liner notes of my albums. :)
more of a general comment, but are you implying that 'guest' means any
performer who isn't a member of the group in question? only i've
always thought of 'guest' only being appropriate when it's written as
such in the liner. eg a studio guitarist isn't a 'guest', but some
famous guitar player probably would be.
and 'guest orchestra' seems unlikely in liners, unless they normally
have a different orchestra as part of the band :)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] How the Style Council Works (Was: RFV: Adding some AR attributes)
On 11/06/06, Don Redman [EMAIL PROTECTED] wrote: If you propose a very minor change, you can skip steps 1 to 3 and request a veto right away. define 'minor' :) personally i think if you are going to skip the RFC stage, the veto period should be longer - just so as many people can see it as possible. 48 hrs is too soon for everyone to see something if it's the first time the issue has been brought up. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] missing accents on Jarre's songs
On 02/06/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: On 6/2/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: Ok, for me this settles it for Equinoxe: No accent. Now we still have a style issue for OXYGENE, though. Because we use capitals for initials only, so the e would be lower case. You wouldn't have OXYGENE, by any chance? Indeed, the original releases (AFAIK) had OXYGENE on the cover, in all caps. It seems to me this confirms the fact that it's the capital that removed the accent, not any weird intent of Jarre, and this would suggest that the same thing happened in the other case, too. Remember, no-one in France spells équinoxe without the accent, it only in cases where it happens to be capitalized that it tends to disappear. I don't get it where this obsession with the cover comes from. It was quite clear to me (until recently) that we intend here to record the names and titles of artists and works, not to record the cover of each release. If we wanted the later, we would be a covers database, and we'd hold bitmaps and SVGs, not text. because it's the cover! eg, take a look at http://musicbrainz.org/search/textsearch.html?query=equinoxetype=release - surely a user typing in the title as seen on the cover of the physical release, should find the right release? JMJ has been reissued/compiled countless times, yet none of these (even those without the original cover - http://www.amazon.co.uk/exec/obidos/ASIN/B0009TA8RC ) have corrected this 'mistake'. i agree, this could well be down to 'inertia', in that people remember the initial cover, and other promotional materials, so best to stick with that unless there's a compelling reason not to. however that's exactly my logic for why we should, as well :) oh and http://wiki.musicbrainz.org/ConsistentOriginalData i guess pretty much agrees with sticking to spelling/grammar mistakes if they are consistant. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] missing accents on Jarre's songs
On 02/06/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: On 6/2/06, Chris Bransden [EMAIL PROTECTED] wrote: Don't forget that while the artist (and probably Jarre) often has a say and an interest in what the cover looks and says on the first release, re-releases are usually handled by the labels, sometimes labels in other countries, and these are notoriously careless with such things (not all, and not always, but often). true, but without proven ArtistIntent to the contrary (ie is there any official source with the accent?), this still falls under ConsistentOriginalData, so should follow what's on the albums. I almost agree with you, except: the style principles page [*] has a section specially for this issue. (1) It says we should usually correct spelling and punctuation, (2) except if it can be shown that the intent [..] was for the spelling [...] to be incorrect. It then (3) goes on to clarify this, saying that 'By intent usually means [...]' and then goes on listing three situations, the last of which is consistency. It also (4) suggests discussion in cases where intent is hard to prove. Now, you may consider this nitpicking, but I think it's important: it never says that consistency proves intent, it just says that usually, unless we have other better reasons, we can use it for that purpose. Note that consistency is usually the last resort in all guidelines. i don't think there was any order of importance implied - they're not numbered. infact i've always thought consistentoriginaldata artistintent, at least in most of the style discussions that seems to be the case. i think artist intent is a bit of a deus ex machina a lot of the time :/ ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] missing accents on Jarre's songs
On 02/06/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: On 6/2/06, Chris Bransden [EMAIL PROTECTED] wrote: On 02/06/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: [...] Note that consistency is usually the last resort in all guidelines. i don't think there was any order of importance implied - they're not numbered. infact i've always thought consistentoriginaldata artistintent, at least in most of the style discussions that seems to be the case. Here you are wrong: the http://wiki.musicbrainz.org/StylePrinciple page begins with: === quote === If you ask yourself in what style something should be entered into MusicBrainz, the following rules apply in this order (strongest on top): 1. Follow ArtistIntent. 2. If 1 is not applicable, follow StrongGuidelines. 3. If neither 1 nor 2 are applicable, use ConsistentOriginalData. 4. If 1 nor 2 nor 3 are not applicable, follow the StyleGuidelines. === quote === That is why I think the ordering of the list two paragraphs below is significant. my mistake, i was reading from the 'addtional notes section': == By intent usually means one of the following: * The artist themselves stated their intent. * There is unambiguous consensus in the community that the artist wanted it this way. * A certain misspelling is consistently found in all (official) releases of the artist. == from that i take it to mean that whatever 'artist intent' means, ConsistentOriginalData is a 'proof' of it (ie bullet point 3), at least for misspellings. i think artist intent is a bit of a deus ex machina a lot of the time :/ I never knew exactly what that phrase means, but if it means what I think... well, as I see things... I already said it once: I think we're supposed to strive for some abstract true info if you will, the closest definition I've seen being artist intent. deus ex machina is a latin phrase that originated from ancient greek plays with nonsensicle plots, where a god or gods would turn up at the end and sort everything out (i think...). what i mean is, it's so hard to prove what an artist really wanted (most likely: they don't care!), yet it's quite easy to apply 'artist intent' to support any style arguament, depending on how you word it :) Since asking the artist is usually not an option, we try to find their intent with information, such as what is written on the cover. That is (to me) clearly not an infalible source. true, but to me it's the best source, other than the from the artists mouth. i think it's bad for us to make assumptions (however likely they may or may not be) that end up with a change to the data. But, mostly (I think) because it's much easier to reach such info, and it usually is quite clear, people tend to think that that is our golden standard (sometimes even when there are clear conflicts), and are (it seems to me) surprised and anoyed when someone introduces other things into consideration. We don't strive to record the covers, we strive for a very abstract correctness. Just because the cover is usually used as an approximation doesn't mean that the other cases are somewhat wrong or arbitrary. It just means we sometimes have to think harder about what's the right thing to do, which is of course hard because the definition of right is quite abstract and sometimes fuzzy. i strive to record covers :P unless there was a known mistake (eg mislabled tracks on a bootleg, or typo on a track name that is not true for all editions). ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] missing accents on Jarre's songs
On 01/06/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: Hi! I might have slipped myself into the mass fixing issue we had a little while ago during Jane's election. Details are here: http://musicbrainz.org/showmod.html?modid=4845882 In short, none of Jean Michel Jarre's albums cover that I ever saw has the correct accents on words like Équinoxe or Oxygène. This is very common slip-up and I don't believe that it reflects any intention of Jarre, except perhaps as a design choice, like all-caps. In other words, I think the fact that this is a common error/carelesness dilutes the importance of consistency in determining artist intent. Now of course that statement is sure not to be agreed upon by everyone here, as for anything involving artist intent. we're not a dictionary - just use what's on the cover IMO. don't even bring artist intent into it because it's not an issue here - if the same title appears on all editions of an album, then it's the way it should be in the DB. it's not just about what the artist wants and doesn't want, it's about what people expect to see if they are familiar with the artist. it's the same logic as saying Guns N' Roses should really be Guns 'n' Roses or maybe even Guns and Roses. lets not even go there :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] ArtistAlias and PerformanceNameStyle conflict / Whatmakes an Alias?
On 29/05/06, joan WHITTAKER [EMAIL PROTECTED] wrote: Would you also do the same to Jefferson Airplane, Jefferson Starship and Starship, all of whom have separate and distinct entries in the mb database. Jefferson Airplane was formed in 1965 and released albums under that name until 1974. Founder member Marty Balin and others left the line up and the band changed it's musical direction re-naming itself Jefferson Starship. Fast forward to 1984 when Paul Kantner, the last remaining founder member left the band. He took legal action regarding the name and won, and the band was thereafter known as Starship. Is it the original objector's contention that all these albums should, for ease of finding them, be grouped under Jefferson Airplane. No I wouldn't suggest that, because in that case the name change reflected a change in musical approach. It's the same with Aphex Twin / AFX - same guy, different styles, so different names (actually that one isn't quite so simple - he's contractually obliged to release all 'Aphex Twin' releases on the Warp label, so uses AFX when releasing stuff on his own label, but this also ties in with a somewhat different musical approach). It's about what you'd want to see as a user - I am of the opinion that the same band should be under the same name, and I believe this was the intension of the ArtistAlias page. There is a difference between a band changing their name, and changing their style and the name to suit, but I believe T/Tyrannosaurus Rex fall into the former category. Chris / Gecks ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV #2: Amazon Relationship Type
On 30/05/06, Stefan Kestenholz [EMAIL PROTECTED] wrote: I'm not so sure we should link to user-created pages if they disappear once the user's item has been bought. do they? even if they don't, they seem to remain even when legit pages for that release exist (presumably added after the user page). I've seen many on amazon.co.uk and they are often dupes and/or full of mistakes. I've no problem with them being added, though, as i'm sure the crap ones could be weeded out with the vote. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] wrong tracklistings
On 30/05/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: What do we do with mods like http://musicbrainz.org/showmod.html?modid=4909762 (other links in notes there). It's a bootleg with an (apparently) notoriously confused tracklisting. My instinct would be to fix the tracklisting and add an annotation; however, this may make the album a bit harder to find and a bit confusing: the annotations are visible only on the extended album view. not sure what you mean about extended album view? however yeah your instinct is correct IMO - with bootlegs (and indeed all tracklistings) we should represent the facts, and note the mistakes in the annotations. we are in the fortunate position of being able to edit our data and CD pressing factories aren't so fortunate :) Also, I'd have to either trust the links or find the album to check the titles. depends on the links :) eg i correct a lot of nirvana bootlegs and http://www.livenirvana.com/digitalnirvana/bootography/ is pretty cast iron for track mistakes et al. that sepultura one looks ok, but i wouldn't really know... ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] wrong tracklistings
On 30/05/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: On 5/30/06, Chris Bransden [EMAIL PROTECTED] wrote: On 30/05/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: [...] the annotations are visible only on the extended album view. not sure what you mean about extended album view? I mean you need to actually click on the album; in the artist page (with the albums toggled open) or the relationships page the annotation is not shown (which is not really wrong, since lots of other things go into annotation that are not supposed to be shown all the time). oh right, i never use this feature :) hmm, not sure how to handle that. We could add a note to the artist annotation, too, but even that's not visible all the time. plus with artists with many albums it would get huuge to the point it wouldn't really be useful. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] ArtistAlias and PerformanceNameStyle conflict / Whatmakes an Alias?
On 30/05/06, Steve Wyles [EMAIL PROTECTED] wrote: On Tue, 30 May 2006, Chris Bransden wrote: It's about what you'd want to see as a user - I am of the opinion that the same band should be under the same name, and I believe this was the intension of the ArtistAlias page. Artist aliases are used to aid searching for mis-spellings or typos of the same artist. It seems you are reading more into http://wiki.musicbrainz.org/ArtistAlias than is actually there. well, it stipulates that legal name changes should be aliased to the 'legal name' (eg Yaz = Yazoo), and if anything i would have thought that that would be a case of indexing both names, as obviously it was originally the artists intent to release it under the first name. T-Rex *changed* their name off their own back. i just don't follow the logic of the examples aliased/not aliased. there doesn't seem to be a logic to them, currently. It is not a simple case of changing name. The style of music released by Tyrannosaurus Rex and T. Rex is completely different. To people that don't understand the history, it is easy to get confused and think they are the same group. Tyrannosaurus Rex effectively disbanded due to disputes between Marc Bolan and Steve Took over musical style and control of the band. Steve Took left (sacked) and Marc Bolan started up T. Rex with Mickey Finn. Although the names are similar, with Marc Bolan being a member of both, the musical style is different and they are not the same group. http://en.wikipedia.org/wiki/T._Rex_(band) - The Bolan/Finn lineup was present on the last Tyrannosaurus Rex album. There definitely was a shift but it seems it preceeded the name change. Even today Tyrannosaurus Rex material is re-released as Tyrannosaurus Rex, not as T. Rex. the same can be said for many artists that currently have their names aliased. I'd just like there to be some kind of logic toward the way we handle artist aliases - there doesn't seem to be one at present. My stance is similar to Don's. I think they should be under the same artist where possible, but when the names (intentionally) represent distinct styles, keep them seperate. Doesn't seem to be much consensus on any view, though :/ ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] ArtistAlias and PerformanceNameStyle conflict / What makes an Alias?
yeah i saw that but it hurt my head thinking about it :) i'm not so sure that splitting up artists in this way (AKA link or not) is the way to go. on the tagging front, considering that most (?) MP3 software (or people's file structures) operate on an X:\Artist\Release\Song.mp3 heriarchy, unifying artists in the way we do currently is beneficial. eg, the back catalogue of 'A Silver Mt. Zion' would be near impossible to select on iTunes if we listed all AKAs as seperate artists, rather than aliases ( http://musicbrainz.org/showaliases.html?artistid=39340 ). also, what would be the difference between AKAs and performance names? 'Aphex Twin', 'AFX', etc, are performance names of 'Richard D. James' - would there also be AKA links between all these as well? secondly, what would be the correct usage of the alias function, if we had an AKA? for typos? slight varyations? and finally, would this mean we duplicate albums that were released under one name, then repressed once the artist changed their name? cheers, chris / gecks On 24/05/06, Cristov Russell [EMAIL PROTECTED] wrote: I think a new a.k.a. AR is needed. I actually raised this a few weeks ago with no comment[1]. Cristov (wolfsong) [1] http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-May/002619.html ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SG5...again (*ducks*)
On 25/05/06, Steve Wyles [EMAIL PROTECTED] wrote: On Thu, 25 May 2006, Chris Bransden wrote: IMO sg5 was a problem because you HAD to make everything an X (feat. Y), regardless of how it was actually billed. This is obviously crap, but it seems now we're going the opposite way and making everything a collaboration! what i want to know is: are you saying that we should: a) reflect reality (ie, we decide what's a colloboration and what isn't, not the sleeves) b) reflect what a song is billed as on its first releasei c) not use feat. x at all i say: d) use what's on the sleeve as it's (normally) contextually appropriate I say a) Go by known fact. but that's just it - what is the known fact? what defines 'feat.' and what defines collaborations? once we appreciate that a single will more likely use X Y, and an album X (feat. Y), then this is a definition we have to make. and what if an artist isn't even billed on a release, yet their contribution is more than or equal to the billed artist? Otherwise in this particular instance and many others, the only release that would be under the collaboration artist would be the single. This makes SG5DR completely pointless and we're back to the mess of .feat, one way on the release by one artist and the opposite way for when the same work is released by the other equally billed artist. well yeah - aretha is a guest on an eurythmics album, but not on a aretha franklin compilation. and on the single they get equal billing - it depends on the context IMO. When in actual fact they are exactly the same work and should be titled and credited identically. Oh! and don't forget the thousands of Performed AR's SG5DR came about from the need to normalise the data a little better, are people now saying that we should go back to the old .feat mechanism? no definitely not - i don't think we should force feat. when it's not written (eg under the old system i had to change collaboration albums to X feat. Y, where who was x and who was y was entirely arbitrary), but i don't think we should get rid of it alltogether. like i said, what makes a feat. and what makes a collab? how can you define this? ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SG5...again (*ducks*)
On 25/05/06, Steve Wyles [EMAIL PROTECTED] wrote: Those are already defined in the styleguides. yep @ http://wiki.musicbrainz.org/FeaturingArtistStyle - A collaboration should only be created for primary artists who contributed equally to the track/release. http://www.inhouse.co.uk/misc/sisters.jpg = aretha franklin on vocals, but the eurythmics wrote the song, made the music, and of course annie lennox also sang (and played keyboards!) :) so according to the rules, this should be a feat. however, i don't go by those rules, because unless each artist has an almost symettrical involvement, you're hardly ever going to get a collaboration. so if aretha wrote, and was also responsible for the creation of 50% of the music (how do you work that out anyway??), then this would be a collab under that definition. nuts! ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SG5...again (*ducks*)
On 25/05/06, david scotson [EMAIL PROTECTED] wrote: One basic fact is key to this and hopefully everyone can agree once it's been pointed out: * there is no basis or rationale for continuing to normalise track titles to include (feat. X) Go dig out your albums and you'll find that very few actually use that format. They might say 'with' or 'duet with' or 'vocals by' or 'ft.' You'll notice as well that as many times the feat or whatever appears attached to the artist as it does to the song (particularly on VA compilations and singles). The only valid reason to do this was to allow a script to extract this information at a later date and store it in the database. This has already happened. I believe that script has actually been written and run. We now have ARs, which not only allow you to store such info, it lets you do so with incredibly fine grained detail. (An unvalid reason might be to make your record collection titles 'neater') ARs stores all information in the same place. ANY performing artist who is not a normal member of the main artist is a 'guest'. There absolutely needs to be a way of defining billed guest artists (ie, those appended to the tracklist/cover of a release, not those in liner notes/small print), outside of the usual producer/engineer/tea boy ARs, and as such the best place for this is the title or artist field, along side the relevent AR for that artist to give specific role info. perhaps a solution would be to add a checkbox for all AR relationships for 'featuring', such that it makes that AR 'special' which entails that it is highlighted on the album page, and appended to the track/artist title (ie as (feat. x) or perhaps even the full AR string) when that file is tagged? hmm i really like that idea actually! We also have the changes brought in as a response to SG5 which allow X feat. Y (or X vs. Y or X meets the Ys uptown or anything else) to be the artist on the single, VA compilations or soundtracks as well as the greatest hits albums of *both* collaborating artists without the side effect of changing the single artist albums to be a VA album. This also means track entries by crazy one-hit wonder dance artists called X feat. Y no longer need to be mutilated to fit in with a now redundant rule, that actually tried to solve a different problem in the first place. agree. All the above means we have enough information stored in the database now to take track title by X vs. Y appearing on X's greatest hits album and transform it, at time of tagging, to track title (feat. Y) by X. Or even track title (feat. A, B and C). Not only that you could use ft. or anything else the user wanted to specify. Anyone who wants their albums tagged like that can have it, it's just a simple matter of programming. So I would suggest alway putting the info in the artist field unless it is incredibly minor (trumpet solo by X, featuring the St. Paul's Choir) in which case just leave it as it is written on the cover and mark it with an appropriate AR. IMO anything deemed worthy by the cover, is worthy to go into the title/artist. i find a lot of people adding (feat. x) and collabs on stuff that was never billed as such, just because they are interested in the x in question. there is a difference between someone appearing on a track, and being *featured* on a track. With reference to Aretha and Eurythmics, if it is really felt that the contribution of Aretha to this song is not enough for her to be awarded the full MusicBrainz ampersand then Eurythmics with Aretha Franklin seems just as good a name for a collaboration to me. my position is still that it can be a different setup depending on the context :) i don't think we should be unifying the track titles/artist names for the same track, because it serves no real purpose. people with the single would want it tagged as X Y, people with X's album would want it X (feat. Y), and Y's album Y (feat. X). generally i think if we stick with the cover the most relevent title will be shown. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SG5...again (*ducks*)
i know, but that wouldn't help this situation because it shows ALL ARs on that track. I agree with showign them all, but we need to highlight featuring ARs somehow. On 25/05/06, Nikki [EMAIL PROTECTED] wrote: On Thu, May 25, 2006 at 07:45:39PM +0100, Chris Bransden wrote: such that it makes that AR 'special' which entails that it is highlighted on the album page The next server release already shows track relationships on the album page. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Proposal for dealing with [unknown] tracks
hmm, i'm in 2 minds. one the one hand, [no artist] is essentially for these situations - for works where it is not neccesary to credit a specific artist (eg sound effect CDs). but on the other hand, i suppose you could argue that in many cases the label (or production house, or whatever), is responsible for the sounds, and so the 'artist'. i don't think that using the label as the artist is the right overall rule, though, because if warner releases a sound effect cd, which is the output of 'super sound effect studios', then they would be better suited as the artist, rather than warner, despite being a company, rather than an artist. On 19/05/06, Beth [EMAIL PROTECTED] wrote: http://wiki.musicbrainz.org/RecordLabelAsArtist ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] song / [untitled] vs. non-album tracks
sounds like we almost need some kind of 'fake album' type release, which could be used to host different track configurations aside from that a CD-ID would produce. i had to kind of do something like that here: http://musicbrainz.org/album/bc71aa3c-da45-455b-bb97-79bf9cc37a1e.html http://musicbrainz.org/album/188d704b-678d-499d-b488-516a7247cc01.html the former has a hidden track that you have to 'rewind' the CD to get to, which doesn't get picked up by normal CD rippers. slightly different case though, as you have to use special programs (EAC) to extract the track, rather than it always being appended to an existing track. On 17/05/06, Don Redman [EMAIL PROTECTED] wrote: On Wed, 17 May 2006 22:24:15 +0200, derGraph wrote: Also, even if such a track as of your example in the NATs, I believe that most users prefer to have the actual album title in their tags and therefore tag it against one of the three tracks on the album. That's a very valid objection. Actually that's what I do (I take the MB tags and edit them myself, and I remove the MBIDs, since the edited tracks are not identical with the MB tracks anymore). So actually this means that in the case I proposed NATs should not be used. DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] song / [untitled] vs. non-album tracks
On 16/05/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Hi, I noticed a little contradiction on the wiki. On http://wiki.musicbrainz.org/NonAlbumTrack it says: quote Tracks hidden in other tracks: * Another kind of HiddenTracks are those where a single (very long) track has music, then a long silence (or noise), followed by one or more (different) pieces of music. Since there is no support for TrackSections, these can be entered as non-album tracks, although there is not complete consensus on this. /quote Though http://wiki.musicbrainz.org/UntitledTrackStyle says: quote [...] When they appear on a track that also has a listed song, this rule has to be used in combination with MultipleTitleStyle, e.g. track 13 (http://musicbrainz.org/showalbum.html?albumid=28611). /quote So do we both title the track on the album song / [untitled] _and_ add the untitled part as a non-album track? IMHO this case needs to be removed from NonAlbumTrack. Perhaps there is no real support for TrackSections but MultipleTitleStyle is a good workaround. agreed. however i must say i hate the mutilation of track titles for hidden tracks - song / [untitled] looks horrific IMO. they should be just left as they are - [untitled] should only be used when the entirity of the track is untitled (ie, use [untitled] rather than no title at all) chris / gecks ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] song / [untitled] vs. non-album tracks
On 16/05/06, derGraph [EMAIL PROTECTED] wrote: Simon Reinhardt wrote: So do I. You can never clearly say if a piece still belongs to the current song or if it's something new. This is not bullet proof enough in my eyes. But we have been voted down on this. :( IMO, you can most times, since usually the sound of the hidden track is completely different. Anyway, I'd support your proposal. I just want to clarify something closely related: If the hidden track is not unnamed, i.e. it appears on another release with a title, then that title is to be used, without any brackets etc. I.e., if Some Long Song is followed by a long silence and then by Funny Little Song, the correct track title would be Some Long Song / Funny Little Song. Correct? yep. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] What makes a release in Classical?
On 09/05/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: I asked the question first on MB Users because I felt it belonged there, but Don Suggested I ask here too, so here we go. I had a feeling (but I may be wrong, since I couldn't find any written confirmation about this) that in classical MB admitted entering different releases (in terms of dates, country or publisher) as long as the recordings were the same (same track listing, same performers, same performance) and no remixing (i.e. no digital cleaning) was done. So that if an editor re-issued a cheap edition of a previous issue from a major editor, it could still be considered as the same album (but the Sony digitally reworked releases of Glenn Gould should be entered separately). i don't think even those should be entered seperately. at least in other genres, a remaster with the same tracklisting would just be merged into the 'normal' release. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] x (disc 1) x (disc 2), vs x x (bonus disc) / version info for special releases
On 05/05/06, derGraph [EMAIL PROTECTED] wrote: Chris Bransden wrote: 1) http://musicbrainz.org/album/d7838033-55fe-4fa4-949a-7bb96cc88839.html was released as a 2 disc version - http://musicbrainz.org/album/45fb70b6-a8af-4f44-9ea8-b03dc528b3b6.html and http://musicbrainz.org/album/d7cebc7d-b5b8-4821-bc6c-148481907b92.html - so it's tri repetae and tri repetae++ - the ++ is on the cover, but i suppose it's version info and should be deleted? but isn't the ++ just a fancy way of saying special edition? On the one hand it is, but on the other hand it is also some kind of artistic expression. Or at least we cannot prove it is only a marketing statement. well it's just a ++ showing that it has more content IMO, but i agree there's no real way of telling, but the same could be said for any special edition... i wish there was some kind of consensus on this - my tags are so inconsistant. i have situations like global communication's 76:14 special edition being a seperate release ( http://musicbrainz.org/showalbum.html?albumid=413942 ), yet all of the falls special editions have been merged together ( http://musicbrainz.org/artist/d5da1841-9bc8-4813-9f89-11098090148e.html ). examples like these repeat themselves through my collection and (i assume) the DB. i just wish there was another way of seperating the actual album from the extra disc. although it's only available as 2 discs in that configuration, the original album is contained in the first disc, if you see what i mean... Sure. But isn't that what AR is for? i'm not sure how ar could help here. the issue is in the tags - there's a difference between an album that's split over 2 discs, and an album that's reissued with bonus tracks, and an extra disc(s). ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: lead/rhythm guitar
On 07/05/06, Matt Perry [EMAIL PROTECTED] wrote: On Fri, 5 May 2006, Bogdan Butnaru wrote: Hi! I started adding ARs for http://musicbrainz.org/album/9687107b-e6e9-4e33-b4ce-a9dbf11de059.html and on http://www.metal-archives.com/release.php?id=6497 the guitars are marked as lead and rythm (though the official site http://www.lakeoftears.net/releases_studio.php doesn't make the distinction). I see the ARs don't have any option for this; should I ignore it, or should we consider adding something? I would ignore it. Lead is just a fancy way of saying I played the solos while these other people kept time. It gets more into what someone did in the song rather than what instrument they played. It would be like having an AR that someone played stride piano[1] in a song. It doesn't make sense for what we want to capture. I would just use guitar or electric guitar in the AR and leave it at that. hmm i would find it useful. how else do you know who played lead and who played rhythm? it's about as useful as who played what instrument, IMO. i think it should be an attribute of electric guitar ARs (perhaps other instruments? *recalls spinal tap's lead guitar, lead guitar, lead bass, lead drums lineup*) i can't say i've much experience of piano music but if strife piano is something that crops up in liner notes often, then that should be added to :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: lead/rhythm guitar
i) assume electric for rock releases. with jazz it's a little tricky, cos 'bass' general means double bass, but there are jazz bassists who use electric, to. you can usually tell by listening, though. you can also get accoustic basses, but you have to be careful as this can either mean accoustic upright bass (ie, double bass), or accoustic 'normal' bass (ie as acoustic guitar is to an electric guitar). ii) obviously a discrepancy there! i can't say what would be right - i would assume the 'all guitars bit' - maybe they just copy and pasted the 'usual' lineup. On 07/05/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: And, I forgot to mention, another couple of issues: i) if the cover says only 'bass', do I leave it like that, or add 'electric' if the band plays metal? Are there bass guitars that are not electric in rock? ii) The same link, [1] (very bottom) says All guitars played by Brennare, and then it goes on to the lineup, which includes two guitarists. What am I supposed to read from that? [1] http://www.lakeoftears.net/releases_studio.php -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. On 5/7/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: While waiting for answers, I noticed a couple other things that puzzled me: For the same album [1], please look at the notes from [2] (at the very bottom of the page). There are a couple of problems: a) Tomas Skogsberg. This is easiest: plays keyboards, so I added him as guest keyboards player. b) Tomas Skogsberg Mattias Lodmalm: play guitar solo on _track_ Greater Art [3]. I added them as guest aditional guitars, is that OK? c) Mattias Lodmalm is also credited with backing vocals (for the album). I added him as aditional guest vocal; should it have been guest Background vocal? I'm not very knowledgeable about singing, and the two sound a bit different to me. d) Cover art by Kristian Whålin. I added it as design/illustration, is that right? Should I add graphic design or art direction too? (AFAIK, they may all be implied by cover art, but I'm not sure.) [1] http://musicbrainz.org/album/9687107b-e6e9-4e33-b4ce-a9dbf11de059.html [2] http://www.lakeoftears.net/releases_studio.php [3] http://musicbrainz.org/track/939088a1-2d07-4a63-a39e-faaa546793fb.html Thanks, -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. On 5/7/06, Matt Perry [EMAIL PROTECTED] wrote: On Fri, 5 May 2006, Bogdan Butnaru wrote: Hi! I started adding ARs for http://musicbrainz.org/album/9687107b-e6e9-4e33-b4ce-a9dbf11de059.html and on http://www.metal-archives.com/release.php?id=6497 the guitars are marked as lead and rythm (though the official site http://www.lakeoftears.net/releases_studio.php doesn't make the distinction). I see the ARs don't have any option for this; should I ignore it, or should we consider adding something? I would ignore it. Lead is just a fancy way of saying I played the solos while these other people kept time. It gets more into what someone did in the song rather than what instrument they played. It would be like having an AR that someone played stride piano[1] in a song. It doesn't make sense for what we want to capture. I would just use guitar or electric guitar in the AR and leave it at that. [1] http://en.wikipedia.org/wiki/Stride_piano ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: lead/rhythm guitar
a) yep :) b) hmm, i suppose it's the best way of representing it under the current system, but i reckon we really need a 'solo' attribute to the guitar AR. c) i'd say 'guest background vocal' for sure - additional vocals could mean he sang lead vocals for one verse, or something. by using background, you're showing he only ever sang backing. d) i've always just used design/illustration. i'd prefer a more general 'artwork by' AR to be honest but i think that's what the intention was with that AR. On 07/05/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: While waiting for answers, I noticed a couple other things that puzzled me: For the same album [1], please look at the notes from [2] (at the very bottom of the page). There are a couple of problems: a) Tomas Skogsberg. This is easiest: plays keyboards, so I added him as guest keyboards player. b) Tomas Skogsberg Mattias Lodmalm: play guitar solo on _track_ Greater Art [3]. I added them as guest aditional guitars, is that OK? c) Mattias Lodmalm is also credited with backing vocals (for the album). I added him as aditional guest vocal; should it have been guest Background vocal? I'm not very knowledgeable about singing, and the two sound a bit different to me. d) Cover art by Kristian Whålin. I added it as design/illustration, is that right? Should I add graphic design or art direction too? (AFAIK, they may all be implied by cover art, but I'm not sure.) [1] http://musicbrainz.org/album/9687107b-e6e9-4e33-b4ce-a9dbf11de059.html [2] http://www.lakeoftears.net/releases_studio.php [3] http://musicbrainz.org/track/939088a1-2d07-4a63-a39e-faaa546793fb.html Thanks, -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. On 5/7/06, Matt Perry [EMAIL PROTECTED] wrote: On Fri, 5 May 2006, Bogdan Butnaru wrote: Hi! I started adding ARs for http://musicbrainz.org/album/9687107b-e6e9-4e33-b4ce-a9dbf11de059.html and on http://www.metal-archives.com/release.php?id=6497 the guitars are marked as lead and rythm (though the official site http://www.lakeoftears.net/releases_studio.php doesn't make the distinction). I see the ARs don't have any option for this; should I ignore it, or should we consider adding something? I would ignore it. Lead is just a fancy way of saying I played the solos while these other people kept time. It gets more into what someone did in the song rather than what instrument they played. It would be like having an AR that someone played stride piano[1] in a song. It doesn't make sense for what we want to capture. I would just use guitar or electric guitar in the AR and leave it at that. [1] http://en.wikipedia.org/wiki/Stride_piano ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: lead/rhythm guitar
On 07/05/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: You know, this is why we need an ontology and an RDF-based database. Too bad I don't have time to dive into this right now. Though I think we could add at least lead solo as an attribute for both performed instrument and performed vocal. seconded ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] albums and single with the same title
nah cos it's only relevant if you own both. same reason we don't append (vinyl) or (japanese release) to titles, even though there's plenty of reasons why you would want to own both. i think it's just one of those things you have to do at your end :) maybe the tagger could be made smart enough to realise when this was going to happen and ask the user if they wanted to add something to distinguish it? On 03/05/06, Brian Gurtler [EMAIL PROTECTED] wrote: i think we need a way to differentiate singles form albums with the same name. For example Morphine has an album titled Cure for Pain they also have a single Cure for Pain as well. I have both ripped and tagged but they end up in the same folder. Also if i physically move one of them to another folder they end up in the same album in my music player library anyway because they have the same title information in their tags. what can we do to prevent this from happening? can we add (single) to singles that have the same title as albums? would anyone be opposed to that? ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] x (disc 1) x (disc 2), vs x x (bonus disc) / version info for special releases
i think our handling of bonus discs needs to be clarified. currently it seems (bonus disc) is only used if it is supplied in some kind of limited quantity. IMO, if a release is reissued with another disc, *even if this 'extra' disc is included with all future pressings of the release*, it should be x x (bonus disc). the use of (disc 1) and (disc 2) implies that it is a double disc album, and i think more should be done to show that 1 disc is the *album*, the other is the 'extra'. secondly, there seems to be some discrepancy in the way we handle version info for albums. say a release has super duper version written on the cover, and the only difference between it and the vanilla version is that it comes with a bonus disc, should it be: a) x: super duper version (disc 1) x: super duper version (disc 2) - i think again this isn't so good cos it implies that it's a double disc album b) x: super duper version x: super duper version (bonus disc) - here you give the 1st disc a subtitle, despite it being technically identical to the original - there's nothing 'super' about it on it's own c) x x (bonus disc: super duper version) - strange way of handling it but i suppose it works. however if the bonus disc has a subtitle then things get a little tricky d) x x (bonus disc) - i'm inclined to go this way to be honest, and keep it simple. however we're losing title info here, but could it be argued that this is analogous to (bonus track) info that we drop? chris / gecks ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] WriterRelationshipType
New AR time!
artist {additionally} {guest} wrote {lyrics:lyrics for}OR{music:
music for} album or track
technical question: how to handle lyrics and music attributes? i've
pseudocoded it up there but i'm not sure how it would all work.
perhaps there needs to be 2 seperate subtypes to this relationship?
would be nice to avoid that if possible...
everything else should be addressed on the wiki page.
http://wiki.musicbrainz.org/WriterRelationshipType
http://bugs.musicbrainz.org/ticket/1423
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] WriterRelationshipType
the fact that they are very often credited seperately ie 'written and
composed by X' on liners should be reason enough. i tried to explain
the differences in more detail on the wiki page - hope that helps.
On 02/05/06, Simon Reinhardt [EMAIL PROTECTED] wrote:
Chris Bransden wrote:
New AR time!
artist {additionally} {guest} wrote {lyrics:lyrics for}OR{music:
music for} album or track
To me the writer of the music was always the composer.
Simon (Shepard)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] WriterRelationshipType
no. as shown on the wiki, writing is just a less involved subset of composing.
composition is like a midway point between writing and arranging.
not my words, but:
Writing is creating the most basic form - anything from the melody
idea, to the tune as a whole. Composing is like building the song from
the tune, deciding what instrument plays which bit, creating
basslines, deciding speed, etc. Arranged by is slightly less than that
- putting together all the bits and pieces of a song once it's already
been built.
Writer - Architect
Composer - Builder
Arranger - Painter Decorator
On 02/05/06, Thomas Tholén [EMAIL PROTECTED] wrote:
the fact that they are very often credited seperately ie 'written and
composed by X' on liners should be reason enough. i tried to explain
the differences in more detail on the wiki page - hope that helps.
Would that not mean that the lyrics (written) and music (composed) was written
by X?
//[bnw]
On 02/05/06, Simon Reinhardt [EMAIL PROTECTED] wrote:
Chris Bransden wrote:
New AR time!
artist {additionally} {guest} wrote {lyrics:lyrics for}OR{music:
music for} album or track
To me the writer of the music was always the composer.
Simon (Shepard)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] AR philosophy
On 02/05/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Hi, I have some questions about linking philosophy which I think need to be generally clearified because if every moderator follows their own concepts then we don't have consistent data. 1. Link performers to releases: a) always, including members of bands b) only if they are guest performers / are the line-up for a project or solo-album of an artist. a) IMO. at discogs we had a similar discussion, but although sometimes it could be considered redundant (AR for ringo starr doing drums on a beatles track, for example), it's generally useful. however people should NEVER put an AR in unless they are SURE that this guy performed role X on this track (ie liner note, confirmed source, etc) - it's a waste of everyones time if someone puts in assumed ARs (eg 'producer, written by' relationships for dance music producers that aren't actually written on the sleeves in question). 2. Link artists to releases when they performed on / wrote / engineered / otherwise worked on: a) all tracks / the whole release b) the majority of tracks c) one track and more. see my track ranges ticket @ http://bugs.musicbrainz.org/ticket/1422 - i posted this to mb-users as well today :) i think we need track ranges ASAP! album credit ARs are pretty meaningless without it. 3. For different releases of one album, link all artists to: a) all of them b) the original releases only (including special editions being released at the same time as regular editions) c) the regular original release only. - How do we link special editions to regular editions if they were released on the same day? IMO a) until there is some kind of way of linking data of the releases (more than just an AR). personally i'll add relationships to the one i own, which may not be the 'original' release, but i think it's very wrong to add ARs to releases you don't physically own as you can't be sure of a lot of things - an identicle track list doesn't neccesarily mean an identicle release. 4. Link artists to tracks they worked on: a) always b) only if there isn't a relationship of the same type between artist and release already. a) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] WriterRelationshipType
On 02/05/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: I understand, but there will be times when the user will not be able to choose (because he will not have the info). What do you suggest, then? IMO people shouldn't be adding ARs if they don't have the sleeve or some kind of factual info to go on. as well as being innacurrate it's kinda pointless to add ARs you *think* may be right, no? i can understand people want to link the beatles to these orchestra covers albums (for example) but for that case CoverRelationshipType is available for a more general relationship. as a possibly relevent aside: 'written by' is quite important as credits go, as it has many legal implications. this is why it's important to get 'right' IMO. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
