Re: [mb-style] Remove honorary titles
What is problematic for me is that the artist name will change after the title is bestowed. Then I end up with tags with distinct values. YMMV. Well, right. The same thing might happen if e.g. an artist marries. Won't all minor name variations create the same problem? So, I'm not saying that it's a non-issue. I'm merely saying that it doesn't seem like a special case. I agree. The primary artist name in MBz does not at all have to be a legal name, but is and should continue to be how the person usually is named (as artist), which may be with different kinds of titles, nicknames, etc. For example royalty will include royal titles. As a Swede I'm thinking of composer Prins Gustaf (Prince Gustav of Sweden and Norway). ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: STYLE-331add 'composite reissue' relationship (aka 'includes')
I think it can be a bit complicated or unclean with both a RG-includes-RG relation, and a Release-includes-RG relation. Still I wouldn't want to miss the possibility of indicating when only some releases have that as extra material. Thinking more about what I think the main relation here really is in the real world I'm thinking it's actually from the *mediums*. When I look at a box set like the 18cd http://musicbrainz.org/release/792fef6a-a89c-4687-a1e3-31e17c51eaec the thing that for me makes this into a boxset of earlier releases and not just a big collection, is that the individual 18 cds correspond to previously existing entities. It's not only the case that this release includes the LP Ramlösa kvarn but more specifically it is the case that *disc 2* of this release is like Ramlösa kvarn. That more specific link is useful to get links from the right places and not just a bunch of unsorted links to included RGs. The problem about linking from releases or RGs would disappear. If a particular release doesn't have a particular medium then it doesn't have that link. Even though links would be from mediums that information would be *shown* at release and RG level as well. At the display of an RG something like this includes RG1, RG2 och RG3 or some releases include RG4 could be shown. Maybe this is too far out, but I wanted to mention it anyway as an alternative way to think about this. The somewhat more exact meaning of such a link from a medium to an RG would be that this medium (together with other mediums of this release that have the same link, if any) is like a reissue of that RG. (The paren for example if one of the albums in a box set is a double album.) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: STYLE-331 add 'composite reissue' relationship -- tangent
[release]contains? includes?[release]: useage: parts of a box set are also available individually w/ identical catno, barcode Would this relationship trump the RG-RG one? Or are there reasons you could end up with both? Certainly it can be the case that only some releases include whatever is included. An example I have is http://musicbrainz.org/release-group/ac1af719-8ec5-4e1d-b0ae-66db5f74e500 where one release in this release group include a bonus cd with six tracks which is also available as its own RG http://musicbrainz.org/release-group/5701f243-5b14-4379-9773-096b992d9252 . I don't see any reason this couldn't happen with a RG that also has RG-to-RG relationships. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-2: STYLE-335: Add Box set as a primary type of Release Group
I do see the utility in supporting a repacking concept as a secondary type because that is often economical/best/only way to obtain an artists catalog. This is where I would find 2in1s, complete singles collections, complete album box sets, etc. Personally, I put these kinds of releases in a different category than best of's. Conversely, having a best of secondary type might make this distinction as well. There is indeed an interesting division between releases that might be useful as part of a somewhat complete collection (the complete decca recordings, the singles, etc) as opposed to those that are just samples that would be redundant in a bigger collection. But I don't think it would work in practice. There would be too many unclear cases inbetween. (I would rather see features in the future that automatically mark release groups that would be good additions for your collection, going from what you have and where different recordings are available. We're far away from using Musicbrainz for things like that now, when the web interface doesn't even mark releases you have.) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: STYLE-335: Add Box set as a primary type of Release Group
Some of the time it would be. Most of the box sets that I’ve seen have all-new tracklists, though I have seen a few that attempt to emulate the original tracklist and visual appearance of the source releases. I think boxes like http://musicbrainz.org/release-group/e4759ec2-685f-4b9f-bf20-a2b41bcce517 and http://musicbrainz.org/release-group/7b1abdc7-bb19-49cf-8066-a303990cdbf8 (to take two examples with Lou Reed) just collecting a bunch of albums are getting more and more common. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Sorting of fictitious names -- sort name enthusiasts unite!
I wrote that the traditional way to sort fictitious names like Scrooge McDuck is on the whole name, as Musicbrainz explicitly did earlier, and that it's bad that when Musicbrainz intended to change that and sort as real names, with RFC 203, it did it by just deleting that part of the guide, so now nothing is said about it. The traditional way is to sort even fictional human characters with clear first and last names on the whole names. That goes for characters like Blondie Bumstead nee Boopadoop (that I mentioned in my previous post), Linus van Pelt, Gerald McBoing-Boing, Bart Simpson, etc. Alex / caller#6: Can you cite a source for this? I'm not challenging your facts. I'm very interested in following prevailing practices when practical. I've tried to find sources, but it hasn't been that easy. So what I have is mostly examples. My perception may have been biased by that when I have seen fictional characters in alphabetical listings it has mosty been in books about cartoons or comics. Many of the names are like Donald Duck or Porky Pig in that they are animals with species as last name, and can perhaps be seen as joke names, but some are more obviously real names. In the index of Michael Barrier's _Hollywood Cartoons_ (1999) I find for example Betty Boop and Elmer Fudd sorted on whole name. In _Hippo in a Tutu_ by Mindy Aloff (2008) the index includes characters like Horace Horsecollar and Ichabod Crane sorted on the full name. Scott McCloud's _Reinventing Comics_ (2000) has an index with Al Flosso, Charlie Brown, Don Quixote, Ernie Weiss, Sherlock Holmes and Veronica Lodge sorted on their full names. (But, as an unexpected exception Croft, Lara!) _The Disney Studio Story_ by Holliss and Sibley (1988) makes this explicit at the beginning of the general index: Disney animated characters are indicated to *bold* type entered under their full names -- e.g., Casey Jones under C, Wise Owl under W.. _Encyclopedia of Walt Disney's Animated Characters_ by John Grant (1987) has a similar note. Except for indices sorting also is used for encyclopedical works. Books like _The Great Cartoon Stars_ by Denis Gifford (1979) do it my way. I mentioned Gerald McBoing-Boing earlier as example of a real human name that a cartoon character has. I was reminded when looking through my books that his real name is Gerald McCloy. This is one reason for full names often being better, that the real last names often aren't remembered. I have examples that go against my view too. For example _The Complete Peanuts_, a multivolume work collecting the daily strip, includes an index in each volume where you can look up for example: Brown, Charlie Brown, Sally Frieda Schroeder Shermy Van Pelt, Linus Van Pelt, Lucy Violet I find this a bit disturbing where we know the last names of some characters but not of some. (What if Violet's last name was mentioned just once somewhere?) I have a few other examples that go against me, but a lot more that I haven't mentioned that support me, so all in all the comics/cartoon world mostly does it my way at least. But when I finally tried to get away from my comics/cartoon ghetto, and went to the Encyclopedia Britannica, it didn't support me much at all. There were no stated principes about this. In the index I found for example: Brown, Charlie (cartoon character) ... Charlie Brown (cartoon character); see Brown, Charlie Don Juan (fictionary character) ... Holmes, Sherlock (fictionary character) ... Mickey Mouse (cartoon character) ... Sherlock Holmes (fictionary character); see Holmes, Sherlock (Under Juan, Don two people are mentioned, but there is no pointer to the fictionary character.) I'll add that in many cases you can in practice look up the full name, because then you'll find a title. If you want to look up Robinson Crusoe for example, that would be under C, but what you'll find is not the character but Robinson Crusoe (work by Defoe) ... - * - So I take partly back my assuredness. It seems like the usage has varied more than I have realized, even though for cartoons full names is clearly the most usual. That makes so much sense in a world where the line between names and descriptions often isn't clear. To take this into perspective I think it's clear that it's not clear how to sort these names, so something needs to be said in the style guides. On the other hand it's not a major part of Musicbrainz, so I think the best would be if we could refer to other guidelines instead of having to formalizing this ourselves. I wish Wikipedia had good guidelines on this to refer to. Then that would be my suggestion (regardless of whether those guidelines would agree with me or not). ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Sorting of fictitious names -- fictitious vs fictional
Earlier a fictitious name like Mickey Mouse should be sorted as Mickey Mouse, and not Mouse, Mickey as if it was a real person, but RFC 203 aimed to change that. I think you're conflating two issues: fictitious names vs names of fictional characters Fictional characters: Mickey Mouse is not a 'real' name. It should sort as Mickey Mouse not because he's a character, but because Mouse isn't meant to be understood as a surname. (although, yes, sometimes cartoon names are jokingly presented as given/sur-names [1]) Yes, it is. Once again my issue now is *not* that MBz has the wrong policy on sorting (even though it does :-), but that it doesn't state its policy. I'm afraid that debating the how-to-sort issue just removes attention from the issue I'm *trying* to get through, but I can't let it go. You think that having the last name Mouse is a joke when you are a mouse. Well, it was from the beginning, but as rather knowledgeable on Disney comics I can assure you that inside the Disney comics Mickey's last name is Mouse just as much as Scrooge McDuck has the last name McDuck and Gyro Gearloose has the last name Gearloose, so I should have used such an example so as to not cause confusion. * The traditional way, as done all through the 20th century at least, is to sort Scrooge McDuck under S if he appears in an index to a book. However, I would expect a fictional character called John Smith to sort as Smith, John. The traditional way is to sort even fictional human characters with clear first and last names on the whole names. That goes for characters like Blondie Bumstead nee Boopadoop (that I mentioned in my previous post), Linus van Pelt, Gerald McBoing-Boing, Bart Simpson, etc. There are lots of reasons for that. One is that last names often are obscure. One is that it's often not clear what's a last name and not. All in all users of an index are better served with sorting on whole names. But things seem to be changing. You expect something else, and you are not alone. In my last post I cited evidence of Wikipedia often doing it that way. If these things aren't clear in Sort Name Style, that's because it's a horribly written guideline :-) It's because good text was removed. I think I made that clear in my previous posts if you follow the links. There *was* a paragraph stating how to do it (which was in the traditional way/my way). RFC 203 wanted to change it (to your way), and since RFC 203 passed I think that is the currect Musicbrainz style. The problem is that RFC 203 just removed the paragraph on this without replacing it with anything, so you have to search through mailing list archives to know this now. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Sorting of fictitious names
Earlier a fictitious name like Mickey Mouse should be sorted as Mickey Mouse, and not Mouse, Mickey as if it was a real person, but RFC 203 aimed to change that. See http://lists.musicbrainz.org/pipermail/musicbrainz-style/2010-March/008876.html where that is mentioned, and http://wiki.musicbrainz.org/index.php?title=Style%2FArtist%2FSort_Namediff=37634oldid=35575 where this clause is removed. * For artist names that are ficticious names, the sort name is the same as the artist name. One problem here is that after this edit nothing is said about the sorting of names like this. I guess those supporting this RFC thought the special handling of fictitious names was a strange anomaly in the guidelines, so by removing the clause it would still be evident how to sort these names. But sorting fictitious names as we did previously is really the traditional way, so I think this needs to be explicitly stated regardless of which way we want to do it! I see that Wikipedia also normally sorts in the non-traditional way. (At http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Fictional_characters/Archive_2#DEFAULTSORT: argues against it without result.) Maybe this is the new emerging standard, but I still think you wouldn't find many books which will put Mouse, Mickey in the index, and there are still lots of old geezers like me around, so please state this new rule explicitly! ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Sorting of fictitious names
I definitely support using traditional sorting of names regardless of whether th subject is real or fictional. This is formulated in an unfortunate way, since the traditional way *is* what I wrote -- to sort fictional names without any name reversal. You will find it hard to find any book from the 20th century using anything else. What to do is a matter of opinion, but what is the traditional way is not a matter of opinion. Since I have a wide collection of books about cartoon characters I have lots of examples of this. I would probably sort Mickey Mouse as Mickey Mouse, mostly because I didn't think Mouse there was supposed to represent anything similar to a surname (does it? :/). That's one reason why the traditional way is to sort fictional characters like that. Another is that many are mostly known by their first name only, but there is a last name that is used seldomly and perhaps known only by few. (One example of that would be the comic strip character Blondie, known by most as Blondie, but with the fictional last names first Boopadoop and later Bumstead after marrying.) But that is really beside my point. I'm *not* trying to reverse the decision in 2010 to treat names of fictional characters as if they were real characters. I'm only poining out that the decision from 2010 needs to be mentioned explicitly in the guidelines. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Aliases for works
Agreed, for cases where it doesn't cause confusion (classical mostly), but here it feels problematic. I think it's hard to avoid confusion in some cases, since normal usage isn't always the same as Musicbrainz terminology. Here versions in different languages are different works, but otherwise sometimes all these are seen as versions of the same work. There are certainly well-known songs with lyrics that have been translated to different languages, where you would usually use translated names regardless of lyrics language, not just in classical music. One example is The Internationale. In an English-language text you would normally use The Internationale both for the French original and the English translation, for instance. (And not *L'Internationale for the former.)* *Actually I think Musicbrainz doesn't handle that situation very well. Is it only the the French original that should have lots of translated names? Or all versions? The latter case would be a serious case of going against DRY (Don't Repeat Yourself). The root of the problem seems to be that the entity that has all these names is something that isn't represented as one object in Musicbrainz.* ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Translated titles
When songs on a release are translated, often the original titles are given on the release as well. Sometimes they are formatted as if they are part of the title, but I think they shouldn't be, and would like this mentioned in the style guides. Often original titles are formatted in a special way, often in a smaller or different typeface. It can look like in this extract: [image: Infogad bild 1] from http://musicbrainz.org/release/7051fd1a-0b4a-4de5-b827-5591d4bf61c3 . Here a track is listed as ATT SKILJAS ÄR ATT DÖ LITE GRANN (Cryin Time) with the title in uppercase and the original title in mixed case inside parentheses. But sometimes they are just listed inside parentheses after the title, like in these examples [image: Infogad bild 2] taken from http://musicbrainz.org/release/31dd34a2-628e-4d93-9e2b-7a9a1e69fe7e . An extract: (SOLEN LYSER ÄN PÅ) MITT GAMLA BARNDOMSHEM (MY OLD KENTYCKY HOME) MITT LIV BLEV MUSIC (UNDER MY THUMB) Note in the first case how parentheses are both used in the title (Solen lyser än på) Mitt gamla barndomshem, and also used to tell us what the original version was called (My Old Kentycky Home). When I started editing, I entered these in the some titles, but then I stopped doing that, realizing that they are not actually part of the titles. (And not of what we call Extra title information either, really.) I would like some agreement and also clarification about this in style guides though. This is very common in some types of releases. blåblus.jpgjigs.jpg___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Translated titles
Actually we do have a guideline about this, in http://musicbrainz.org/doc/Style/Release (note that this is not only about release titles, but track titles too). That talks about using a pseudo-release for translations which are not derived from the release itself, but also If the release has tracks listed in multiple languages, the entry with both languages included is considered to be the official release. Now I think I worded my question wrong. It's not actually about translations of the song titles. It's about mentioning the original song that this is a (translated) version of. I have releases with translations of the titles (for the benefit of those not knowing the language). But my examples in the original post here is really something else. In MITT LIV BLEV MUSIK (UNDER MY THUMB) (which was one of my examples) it tells the reader that the this work Mitt liv blev musik is a version of the work Under My Thumb. The title is not really a translation. (Mitt liv blev musik means My life became music.) In most cases these versions are more or less free translations. Without relistening to any of the two tracks, in this case I guess the melody is just reused with a new text. Lots of Swedish hits during several decades were really foreign songs with translations or with other new texts. It must have been the same in many countries. And at least here the original songs are often mentioned like this. The reason I take this up now is because I saw http://musicbrainz.org/edit/24949120 and similar edits that add these parens where I don't like them, so I wanted to bring it up. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Aliases for works
When is a translated title of a work applicable as an alias of that work? There is a translation of the Lennon/McCartney song Yesterday into Latvian, called Vakardiena, and that is also entered as the Latvian alias of the original. I got confused by Yesterday (Vakardiena) when I was making a link to Yesterday, and now I'm trying to remove that alias, thinking that it should only be used about the translated version. Am I in the wrong here? https://musicbrainz.org/edit/24757623 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] What is the use of a work type that means everything?
However, I also agree with jesus that song should not be used for instrumental pieces/tunes (possibly just outside the pop/rock realm), as the correct term would not in any way ever be song. It could be a lilt, a waltz, a jitter-bug, a slängpolska, ... but not a song. The question I ask myself is: if I was studying music (science) at a high level, would I call this as a song? I think part of this discussion is turned upside-down when it's focusing on the word song. I think we first need to determine what ontology we want. What kind of distinctions do we want to make for work type? Then we'll find terminology to go with the distinctions we want to make. We shouldn't decide beorehand whether lyrics is important in this ontology because of what meanings a particular word has! On this question I think that lyrics isn't important. DRY (Don't repeat yourself) is a good principle, and we have that information elsewhere, since we have a special attribute for what language the lyrics of a work is in which could have a special value no lyrics. Many older records put a designation like waltz or tango or foxtrot after the title. Maybe we want to make that kind of differentiation with our work types. I think that is an open question for the moment, but if we do, that is orthogonal to the presence of lyrics, so having the presence of lyrics appear in our work type tree would complicate and make it less tree-like. We don't want to make a tree out of types like song-(with-lyrics), instrumental-without-lyrics, tango, tango-with-lyrics and tango-without-lyrics. Instead it should be just tango as a subtype of the more general type, and the presence of lyrics or not stored outside the type. (It's not always orthogonal, though. We have somewhat similar distinctions for classical music already where some (like Sonata) are instrumental, and some (like Aria) always have lyrics.) Lots of old records with jazz standards have foxtrot on the label like that, and so has for instance Rock Around the Clock, but for later pop/rock we seldom get such labels. Most of these works are just songs or tracks. Just as a waltz is a waltz regardless of whether it has lyrics these are whatever they are regardless of whether they have lyrics or not -- the two tracks on Pink Floyd's single http://musicbrainz.org/release/45f8291d-31d0-4628-8013-876444c852e3 are really of the same type, even though one has lyrics and the other one not. So what do I want? I want a work type tree in which one type is a single music work (SMW), as distinct to compound works like symphonies and song-cycles. Many work types we now have, like Cantata and Madrigal would be subtypes of this, and so would Tango and Waltz if we should add them. Unfortunately I don't know what would be a good name for this SMW. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] What is the use of a work type that means everything?
Also I'd like to avoid genre-based solutions. I agree with that! The distinction I want to make with work type is between a single melodic work, something compound like a symphony or a song cycle, and a non-music work like a poem. If song is a good name for that single melodic work or not I'll leave to the native English speakers, but surely people often talk about songs like the Beatles song 12-Bar Original without reacting to its not being a song because it isn't sung. It is interesting if it's an instrumental song instead of a song with lyrics, but that's better stored as a special value for Lyrics Language, right? In cases where there are no instruments either, we already have Poem though we could argue whether that covers hip-hop and other spoken styles. Whether instruments are used or not is not part of the work but of the arrangement. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Work-to-work ARs for same text and same music
Even though we have a work type poem I guess we don't want to add all poems we can find to MB, this being a *music* database. I think that if A has written a poem, and then later on B sets music to it, we are often only interested in the resulting work, having A as lyricist and B as composer. But if then another person, C, sets other music to the same poem, then we'd be interested in storing the poem-as-such as a work as well, since it's the common link between the two musical works. Instead of linking them directly to each other (?) we'll just link them both to the original poem. What AR should that be? is the earliest version of? I don't know of anything more specific, but it doesn't say that much. Also if there's a recording or someone reciting the original poem that would be a reason to add the poem as a MB work. That was about works with the same lyrics/text. I also sometimes don't know what to do about works with the same music. We have good ARs for translations and parodies, but sometimes a melody is just reused for a totally new text. One example would be Tom Lehrer's The Elements http://musicbrainz.org/work/1d609aa3-cc16-4b5d-98f5-5cc21b544e1c which uses the melody from Major General's Song in The Pirates of Penzance. Maybe a better example is Twinkle, Twinkle, Little Star, the Alphabet song and others: http://en.wikipedia.org/wiki/Twinkle,_Twinkle,_Little_Star#Appearances_of_the_melody Should these works link to each other? What AR? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add fictional attribute to artists
I would like it clarified what kind of information we want to store for fictional artists. As an example, currently Mylene Jenius, http://musicbrainz.org/artist/9fed5efb-6c1a-48e6-a036-8a31240d5358 http://en.wikipedia.org/wiki/Mylene_Flare_Jenius is said to be born in 2031 in Musicbrainz, because the fictional character is. I think we shouldn't store that fictional birth year, but instead when the fictional character was created. If that is so, does that go for nationality as well? A fictional Scotsman created in the United States should have country US? But their fictional gender is OK? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)
If a European release is released in Germany a couple of days earlier than in the UK, that's not that more interesting than if a US release is available in one state before another. Nor is an artist only selling their own cd on tour making a new release after every concert (regardless of whether those concerts are in the same country or not). I see no advantages at all in maintaining that two identical objects should be treated as different objects in the database because of their history, and it's already just irritating with you try to rip a cd with data from Musicbrainz and you first have to choose from a number of alternatives with the exact same name. How do you know that some of them haven't been translated into the native language of the country, necessitating a different tracklist? I don't understand this. If anyone has such a hypothetical translated release they can and will enter that. No problem. No one will object to that. That's a lot of clutter when editing and tagging and they will certainly not stay in sync. IMHO, that simply is not a price worth paying to keep machine-readable per-country release dates for what is probably one of the most pan-European there is. Totally agree. Together with the impossibility of knowing what an object you have corresponds to in MBz. Generally I think Musicbrainz gets better the more it mimics the real world and gets worse the more it deviates from it with things like well, in Musicbrainz a release is not a release but , in Musicbrainz a recording is actually not a recording, but ..., etc. Of course it is one release. Or actually it is two already. I noticed that at the official EuroVisionShop at http://www.eurovisionshop.tv/product/cd-dvd/45/434/official-2-cd-esc-2012 where it says that All customers which already bought the CD will get the new version with the correct recording of the Norwegian contender, Stay by Tooij. I wonder if the (good) release we have in MBz is the old or the new one. If you buy it from that webshop, do you get a Tuvalu release (.tv)? :-) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)
If a European release is released in Germany a couple of days earlier than in the UK, that's not that more interesting than if a US release is available in one state before another. Nor is an artist only selling their own cd on tour making a new release after every concert (regardless of whether those concerts are in the same country or not). I see no advantages at all in maintaining that two identical objects should be treated as different objects in the database because of their history, and it's already just irritating with you try to rip a cd with data from Musicbrainz and you first have to choose from a number of alternatives with the exact same name. Whether it's interesting or not is your subjective opinion. It doesn't mean the fields which are available to store this information should not be used for those who are interested. I didn't say that it's not interesting. I do find it somewhat interesting that record stores in the UK waited until Monday to sell this object. Surely it's good to store that in MBz, but not to make it unmanageable and less useful for any other purpose until there is a good way to store this. I agree that the current structure is not ideal, but it's what we have now. Destroying valid data because of it is simply not acceptable. Says you. Whereas destroying the usability of MBz because of that principle is simply not acceptable to me. The current entry for that release group is simply a lot less useful. If your principle was carried out generally for all releases it would be unwieldy for such a large part of my cds that I wouldn't use MBz anymore for ripping cds (and therefore probably not use it at all). It would simply not be useful. Generally I think Musicbrainz gets better the more it mimics the real world and gets worse the more it deviates from it with things like well, in Musicbrainz a release is not a release but , in Musicbrainz a recording is actually not a recording, but ..., etc. Of course it is one release. The real world has release events. Different stores in different countries make releases available at different times. Deal with it. Earlier I thought you agreed that the situation isn't ideal, but now I should just deal with it? The real world has both released objects (not a good term, I know) and release events. Things can be said about both of them. Certainly there are not ~50 (or even 5) different entities in the real world that happen to have the same track list, the same bar code, the same cover, etc. I wonder if the (good) release we have in MBz is the old or the new one. If you buy it from that webshop, do you get a Tuvalu release (.tv)? :-) It's tv as in television I presume. Yes, suggesting Tuvalu was a joke of course. But also a question for you. Would you like yet another release entry for the release from the official webshop? And what country would you write? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)
Surely it's good to store that in MBz, but not to make it unmanageable and less useful for any other purpose until there is a good way to store this. I would not say it makes it unmangeable and less useful. How do you think it does? If I have a cd in front of me and want to know more about it it makes it less useful because there is no entity in the database that corresponds to that cd. I have to choose one release entry and read what information there is about that cd there. Or rather look up all release entries and see what information they have about the cd, since I don't know if some information is only in one place. The current entry for that release group is simply a lot less useful. If your principle was carried out generally for all releases it would be unwieldy for such a large part of my cds that I wouldn't use MBz anymore for ripping cds (and therefore probably not use it at all). It would simply not be useful. That principle is already applied to other release groups. It's how the schema of MB currently is, like it or not. Yes, for some other release groups, but I wrote about what would happen if it was carried out generally. It's like HumHumX's comment in http://musicbrainz.org/edit/17774115 : There are currently 10,000 European releases in the database, multiplied by 50 states equals 500,000 releases. That would be 1/3 of all releases in the database. Is that worth the effort? I'm not saying you'd be doing anything wrong, it's just infinitely inconvenient compared to putting the detailed info (away) in an annotation. I noticed the 1:1 disc ID resolution was broken as soon as NGS hit. Have you not been using MusicBrainz much over the last year? Eh, yes? I've noticed lots of things that are not ideal that I haven't complained about. I say this because you seem to be saying that this event data is not worth storing and not a reflection of reality, when it is. No, I didn't say that. Or that. But also a question for you. Would you like yet another release entry for the release from the official webshop? And what country would you write? It depends if we have dates it was made available and countries they ship to. Surely there was a release of the cd there, regardless of whether we know what date it was or not. And it would surprise me a lot if they refused to ship to any country. I've already noted that Poland doesn't have a digital version of this release (and so presumably no physical either). So generalising to Europe is going overboard. There are no physical versions at all. Didn't you agree with that earlier? (Except there is, as I noted earlier.) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)
Furthermore, I often find it incredibly difficult to determine the release country of a release. Ok I deal a lot with Japanese releases, those are easy, but let's take a western example, the Putumayo label releases. If I enter a release in MB, I have this mind:. 1.) The label is British, 2.) I know for a fact the same exact CD is for sale in US and Canada. I'm in Canada, which is where I bought it. Which country should I enter? Should it be worldwide? (That's not how the majority of these releases are classified). I totally agree (except for me it's the Swedish releases that are easy). Very often I don't enter any country at all, because I really don't know. And when I want to add information on an existing release it can make me hesitant when the existing release (entry) has a specific country that really isn't mentioned on the European release I have. Did the previous editor have another version so I shouldn't add my barcode there? Or did they just write the Netherlands there because they happened to buy it there? Basically, I think the MB Release should represent the physical released medium (with a unique barcode/label/label #), and then the release events (ie release date/country) should be stored within each MB Release. I would like a MB Release of a physical object include all media, covers etc. Of course new disc means new release, but also new cover means new release. The same disc-ID can go to several releases, but if you have the (complete) object you can determine which one it is you have. (For digital releases I'm not sure where I'd like the line for new releases to go.) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC2-320: Revised Sort Name Style - identifying the problems that need fixing
Knowing what is most commonly used by music players (and websites that use MB data?) would be nice I guess. I often use Rhythmbox. I tried it now, and it sorts your example as I would expect it to, that is Garcia, Jerry before García Márquez, Gabriel (and that's not because of the accents). (I tried sorting by artist in Exaile as well, and that wasn't implemented very well. There the accent was what mattered, so i and í were not equivalent.) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: Add wikisource for lyrics
A week has gone and the RFC got +1. There has been no objections, so the suggestion isn't changed: I suggest we add wikisource.org from the Wikimedia Foundation for lyrics. Among all the documents there there are quite a few song lyrics in various languages for texts in the public domain. http://tickets.musicbrainz.org/browse/STYLE-106 This will expire on May 10th. Once the RFV has passed, permission must be obtained, in writing (email is fine), from the site which would be added to the whitelist. I'd say we (and everyone) obviously already have permission to link to wikisource.org, even though I can't find a clear-cut you may link to us quote there. The closest in writing might be at http://wikimediafoundation.org/wiki/Terms_of_use where including a) a hyperlink (where possible) or URL to the page or pages you are re-using is mentioned as a way to give credit when re-using text from Wikimedia projects. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC2-320: Revised Sort Name Style - identifying the problems that need fixing
I think caller#6's very first point was important: 1. I think it's important that there be a stated purpose to this guideline rather than just a list of rules[2] that are to be followed. I mention it because the following points are based on expected results. so I'll give it a shot to focus on the purpose and what that means: -- The purpose of sortnames for artists is to present artists for humans in an order that makes it easier to find the artists while browsing, and also sometimes to put related artists after each other. That might effect the order artists are listed when you are browsing your music library in a music player. This is done by following standard sorting principles that people hopefully are used to from other occasions (not by solving this as a totally new problem). -- I think that really is the point. But sort orders are locale specific. What does that mean? * These sortnames are _not_ meant to be just compared character-by-character but are meant to be sorted with a suitable locale. The sortname of Swedish composer Sune Östling is Östling, Sune, but then how that Ö is sorted will be different in different locales. (At least different for Swedish, Danish, English and German.) That means that I think caller#6's point 4 about the sorting between space, comma and alnums isn't valid. A nice locale-aware sort-for-humans shouldn't have quirks like that. (And it hasn't when I try to sort the given Garcia example with for example an en_US locale.) I think we would acknowledge that sorting like this is a lot less important nowadays than it used to be! Users are more and more looking up exactly what they want instead of browsing an index. When looking for tracks by The Doors you would search for doors, not caring about whether you will find what you're looking for under D or T. When people are looking for Townes Van Zandt you'll just type part of the name, not caring about if it is found under V or Z. Etc. That also means that people are less and less used to handling names sorted in the traditional way. When people look at an address list on their computer or phone, or a list or their Facebook friends, they will often be sorted as whole strings, with people with the same first name together. I think traditional sorting often even is unexpected for young people. All this doesn't mean we shouldn't do it, but that many people probably won't care about it, and that the purpose often isn't realized anyway. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC2-320: Revised Sort Name Style - identifying the problems that need fixing
* These sortnames are _not_ meant to be just compared character-by-character but are meant to be sorted with a suitable locale. The sortname of Swedish composer Sune Östling is Östling, Sune, but then how that Ö is sorted will be different in different locales. (At least different for Swedish, Danish, English and German.) My assumption has been (based on discussions last year) that we would construct sort names to work with the UCA [1]. Aha. I haven't read these discussions. Now I feel irrelevant. That means that I think caller#6's point 4 about the sorting between space, comma and alnums isn't valid. A nice locale-aware sort-for-humans shouldn't have quirks like that. (And it hasn't when I try to sort the given Garcia example with for example an en_US locale.) I'm not sure what you mean. I was trying to point out a flaw I see in the current guidelines, which is that using comma-space as a delimiter doesn't always produce the desired results. I'm testing using the ICU demo [2]. How are you testing? Just with GNU sort. $ LANG=en_US.utf8 sort names.txt Garcia, Jerry García Márquez, Gabriel I just didn't think sorting would be otherwise except when doing it by character codes, but I see that UCA indeed places whitespace before punctuation. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Add wikisource for lyrics
I suggest we add wikisource.org from the Wikimedia Foundation for lyrics. Among all the documents there there are quite a few song lyrics in various languages for texts in the public domain. http://tickets.musicbrainz.org/browse/STYLE-106 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add wikisource for lyrics
2012/5/1 Per Starbäck per.starb...@gmail.com: I suggest we add wikisource.org from the Wikimedia Foundation for lyrics. Among all the documents there there are quite a few song lyrics in various languages for texts in the public domain. http://tickets.musicbrainz.org/browse/STYLE-106 That was my first RFC here. I notice I should have included the expected expiration date as well, but I can't find what it should be. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Track artist = track artist?
Artist X Choir and as you can guess, who that choir is completely unknown. No information anywhere on the release... So in these cases, I too would like to see that artist as Artist X Choir in a player, but also I would like to see a link to [unkown] artist in db (ie: artist of the recorder should be Artist X [unknown]) Now I think it should be enough to link Artist X to Artist X and let Choir be just text in those cases. (This is possible now, with an empty artist afterwards.) I don't see when there would be any use in linking that Choir to [unknown]. If you are looking at that particular recording a non-link will also indicate that (at least to the person entering this) that Choir is unknown. I doubt anyone looking through all credits for [unknown] would benefit from knowing about this unknown Choir. I want the Artist Credit to reflect how the track is credited, and to have links wherever applicable to Artists, but links to [unknown] aren't that useful. With my current thinking I would prefer it if it was possible to have joining text also *before* the first Artist, and maybe not to have any links at all in the Artist Credit in some cases. That would meen that a Track Credit would be just a string in which there could be any number of links to Artists from non-overlapping substrings. - * - Going further there are other cases as well where I would like to link a lesser part of the Artist Credit than what is done now: * For many John Smith His Orchestra I would like to just link John Smith to John Smith and let His Orchestra be just text instead of creating an artist John Smith His Orchestra and state that John Smith is a (founding) member of it. Sometimes these credits are not really about a fixed band but about the particular group of musicians that happened to play with John Smith in this particular recording. Another recording with a similar credit might mean an orchestra that isn't really the same except for John Smith leading it so it would be just discographically wrong to combine these particular tracks from others he has made. Of course there are many well-established orchestras with names like that. I'm not talking about revising all of them, but about making it OK (and even preferrable) to not create new groups for each such credit when you don't know that it's a recurring orchestra with more or less the same members. Sometimes you know that it's not. A Swedish example is Povel Ramel who has lots of singles credited to things like Povel Ramel and his rhythmical playmates, Povel Ramel and his bulldogs, Povel Ramel and the Small Mortification Orchestra (in India) etc., often with names that have to do with the contents of that particular song, all of them different. Here it makes most sense to me to just link Povel Ramel to Povel Ramel and let the rest be just text. * Also some minor persons mentioned in artist credits that probably won't recur I think could go without Artists in the database. I'm talking about things like some known artist (John Smith again) singing with a bunch of rather anonymous preschoolers where tracks are credited as John Smith with Anne, Betty and Carol, John Smith with Betty, Carol and David, etc. I would prefer to just link John Smith to John Smith and let the rest be just text and not create artists like Betty (who sang a couple of tracks with John Smith in 1970). (Of course if Betty happened to become a famous artist that would be an Artist in the database anyway of course it would be useful to link her!) Maybe some people would handle that last case as I would like to already. I don't know. Summary: Let's me more positive about leaving parts of the texts in artist credits unlinked. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Orchestra performed vs. performed and What's an orchestra?
http://musicbrainz.org/doc/Performer_Relationship_Type says # While choirs and choruses will use the vocal version of this relationship type, orchestras # should be instead credited using the Orchestra Relationship Type. I'm not sure what the reason for that distinction is, but I guess it has to do with that when a chorus performs all participants sing, but when an orchestra performs all particants normally don't play the same instrument. But what if they do? I just entered credits for a recording http://musicbrainz.org/recording/893d02ce-2d72-48cc-a404-499e47b936cf where among several individuals playing various instruments also a balalaika orchestra is credited. (Credits say translated ... Stefan Ringbom mandolin, Anders Forsslund contrabass, balalaika orchestra Proletarij.) For me it seems much more useful to enter that they played balalaika than that they orchestra performed without saying what instruments they played. Both when looking at the page about them and for possible database queries like what recordings are there with balalaika? So that's how I entered it, in edit #17055846, but I think it might be against guidelines and want to check what people think. I'm not sure what an orchestra really is in this context. Is this balalaika orchestra an orchestra? It seems like maybe not all orchestras are orchestras since they are divided into Chamber/Symphony/Other and a jazz orchestra just might qualify for Other. So orchestra is not a synonym for an artist that is a Group here, but something more particular? If it isn't already allowed to have a Performer relationship for a Group artist with an instrument I wonder what people would think about allowing that when there is an instrument that applies for everyone in the group. Probably not everyone is actually playing the very same instrument since there are many instruments in the balalika family (there is only one balalaika in the MBz instrument tree but I think that eventually there will be more), but the credit is at exactly the same level as this item in the instrument tree. (The same could happen at a higher level, I guess, like strings.) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Track artist = track artist?
This one is probably based on following Classical and/or the proposed soundtrack style: Putting the song’s writer as the artist. (Yes, that's why I pointed out that she is the *lyricist* and not the composer.) but I ask you to take a step back and think about what the track artist field is used for. That having [unknown] pop up in your musicplayer isn't nice at all. (It's not very far from having a MUSICBRAINZ_ARTISTID popping up in that it is technical Musicbrainz stuff.) Hardly. It indicates that the artist is unknown, which is true. It's true that the indication [unknown] is not as bad as 125ec42a-7229-4250-afc5-e057484327fe would be, and my not very far was certainly an exaggeration, but it is true that [unknown] is a MBz technicality. I guess I can't prove that it isn't nice to show these internal technicalities for those who just use the data, like those who just listen to a track on their computer, but that's my opinion at least. People who listen to a track on a physical release and a track on a computer have more or less the same wants and needs when looking up the track. Same releases have really bad track listings, but they are made with a purpose and are generally fine. Technicalities are good for internal use of course! It's immensely good that track artists aren't just strings but have real objects with MBIDs. *That's* where that info you mention is. Now with NGS Artist Credits we get not only these objects but also collaborations and name variations that result in text strings (with links). These text strings don't contain the information you talk about. Well, if [unknown] was part of that text string it would be really strange if the artist [unknown] wasn't involved, but strictly speaking that text string doesn't contain that information. So what *is* that text string used for? That's what I'm talking about. It's used for showing humans, together with links to the artists in them. The artist field should contain AN ARTIST, not an arbitrary comment about the origin of the track. The artist is still there. I'm not talking about an arbitrary comment. I'm talking about how the release describes its contents. The thing that releases always have done, and that discographies, databases like MBz etc. store in different ways. Don't put the carriage before the horse. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Track artist = track artist?
So what *is* that text string used for? That's what I'm talking about. It's used for showing humans, together with links to the artists in them. OK, so consider this: What if the actual performer were discovered. For the sake of argument, say it’s The Beatles (silly, I know, but…) . Would you say that in that case it should be credited as “‘The Beatles’ as ‘Från Häng me' till Dinosaurieland’”? I would hope that you would say no, it should be credited to the artist. Why is it any different just because the artist is [unknown]? *If* it's different it's because The Beatles is a real artist, not an technicality. If your music player says The Beatles when you play the track you don't see MBz internals. Then it's something that *could* have been on the release. If we find out that The Beatles actually performed this track the most obvious thing to do is to add ARs about this. For the rest I don't know. I would want to understand why the release said something else than The Beatles to begin with. Was it just a printing mistake? Didn't they know? Were they trying to fool us? If this track was recorded anonymously by The Beatles for Häng me' till Dinosauriland and then this later release included this mystery track again before the true facts were discovered it's at least not obvious to me that MBz should show it otherwise than the releases themselves did On the release http://musicbrainz.org/release/f10e4b7a-11d5-465a-890a-d37b2c9b9a51 by Lars Hollmer there is a track called 44 sekunder köpt speldosa (= 44 seconds of a bought music box). It contains what the title says. Nothing more, nothing less. Suppose I tell you that the song on the music box really is It's a small world (after all) composed by the Sherman Brothers, would you change the track artist for that track? Or if we find out who played it for the music box would you change the track artist then? This time I would hope that you would say no. This is clearly released as a track by Lars Hollmer. I'm not talking about an arbitrary comment. I'm talking about how the release describes its contents. But that’s not what the artist field is for. The artist field is for listing the artist. Yes, and that's how the people who make the track listings for releases also think. It would be strange otherwise because this whole concept of an artist field is of course nothing new in MBz. It exists because releases (very often) have them. We are modeling them, not the other way around. In this case this track listing has extra title information as well (with a movie source or an original title of a translated song). There are title parts, extra title info parts and artist parts, all indicated graphically (in this case with text in different sizes and with parentheses). Those who made the track listing wanted to state who the artists were, and this is how they did it. There is no mistake done for us to correct. This doesn't look like an ordinary artist credit (like The Beatles) but that's for a reason. Because the original release with this track doesn't really have a release artist (from what I gather at the Swedish Media Database at http://smdb.kb.se/catalog/id/001504767 ), just like many children's records don't, and probably nothing written for individual tracks as well. So those who wrote this track listing found this the best way to indicate who the artists are, and therefore they wrote that in the artist field. Why second-guess them? Yes, it doesn't look like your typical artist credit, but that is because it *isn't* your typical artist credit. Would you see it differently if they had written artists from HMTD or The HMTD gang instead of From HMTD? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Track artist = track artist?
I don’t see using [unknown] as exposing MBz internals. It’s just a different way of writing “Unknown Artist”. It's not a way used by humans. It's not a way used by anyone except MBz as far as I know. (I think it's good that special purpose artists have strange names like that btw so you can see at once there here is something strange.) What does your player do when the artist field is blank? I don't know. Shows that blank field I would expect, that is nothing. I would assume that it’s because they didn’t know the original artist, and so they did their best to include at least some kind of reference about where it came from. I don’t take it to mean that the label is saying that the artist is called “Från Häng me' till Dinosaurieland”, though. Of course no one is saying that it's a name. Later on you said you would look differently at Artists from HMTD. That is also not a name. No name variations for [unknown] would be actual names, because if we had a name we would use that instead of [unknown]. If you are against any name variations for [unknown] you have to chance to destroy some of my recent MBz work at edit #16929733 where an old jazz recording with an unknown orchestra is credited by the release with the description used by the original 1939 release they got it from. Not a name, just a description. It takes some time to enter all that data and double-check all the name variations, but it's really easy to quickly destroy it. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Track artist = track artist?
The current edit I referred to isn't really an example of what I was talking about since that was about the *recording*, not the *track*, as SultS has pointed out to me. I'm sorry about this. It was by mistake I made that associated edit. I only meant to change the track artist and I only wanted to discuss that now. The corresponding edit for the track is still a good example of what I was talking about. The point is that with Musicbrainz as it now is there is no longer a need to display internal technicalities for ordinary use of the data like showing track info in a music player. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Catalog numbers for releases with multiple media
On 03/07/2012 03:46 PM, Per Starbäck wrote: http://musicbrainz.org/doc/Release/Catalog_Number says that [...] Is that still true now that a release can consist of several discs? Wouldn't it be better to use the catalog number that goes for the whole release instead? related thread @ http://forums.musicbrainz.org/viewtopic.php?id=3316 Thanks. So many people think it should be changed, and some people act as if it was changed. But will it change? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Track artist = track artist?
Sometimes it seems to me like Musicbrainz is somewhat stuck in habits formed before NGS and even before ARs. Habits that had good reasons back then, but that don't really have to apply anymore. (*) To know who did what we have ARs. We don't really need complicated rules about when composers should be used as release artists and track artists and when instead performers should be used for that. Weren't those rules mostly created so you could know what role the track artist (for instance) had? So you wouldn't think a composer was indicated when it actually was a pianist? Now when you want to know the composer or want to know the singer, piano player or other performers, you have ARs for that instead. (*) So what are track artists for? To show humans in a nice way how the main credits for that track are. Just like the reason for track artists being mentioned in track listings on releases. One important case is showing it in a music player (for example because you used data from MBz when you ripped a cd). (*) So show something nice there, not technical Musicbrainz stuff! Here is a current example. I recently updated the listing for a Swedish children's cd. The track listing on the cd as printed begins 1. Världens bästa Karlsson (Karlsson på taket) Karlsson 2. Lucky Luke Pinks 3. Per Olsson Mora Träsk The track listing has the usual song/artist format where the artist usually is the name of an artist (Pinks, Mora Träst). But in a few cases it's not, like in track 1 here. This is a song from the movie Världens bästa Karlsson sung by the character Karlsson in it. In MBz the track artist was Astrid Lindgren (author of the book and lyricist of the song) which I don't think should be there by any rules so should be changed. When I play that song after ripping that cd I want my music player to say Karlsson just what's on the release, so I changed it into [soundtrack] as Karlsson. Later there is this track: 27. Darwin Från Häng me' till Dinosaurieland This song Darwin is taken from an earlier children's cd called Häng me' till Dinosauriland which isn't entered in MBz and I don't know much about. Instead of a proper artist the artist field in the track listing says Från (= From) that-other-release. It was entered as [unknown] in MBz. When I play that song after ripping that cd I want my music player to say From Häng me' till Dinosauriland just what's on the release, so I kept [unknown] but made it appear as Häng me' till Dinosauriland. I've gotten negative reactions on that edit ( http://musicbrainz.org/edit/16780877 ). with a suggestion that what's actually given in the artist field in the cd track listing to be put in the *title* field instead (and presumably [unknown] be kept as it is). I think many don't agree with me (and that I risk getting more no votes by bringing this up), but I ask you to take a step back and think about what the track artist field is used for. That having [unknown] pop up in your musicplayer isn't nice at all. (It's not very far from having a MUSICBRAINZ_ARTISTID popping up in that it is technical Musicbrainz stuff.) Are there really good reasons *nowadays* for not having the appearance of track artists be like on the release? For me appearance in music players is a very important application of MBz data. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Catalog numbers for releases with multiple media
http://musicbrainz.org/doc/Release/Catalog_Number says that # 4. Some box sets will have a separate cat number for each disc, and then an overall number that appears # on the outer packaging. It is recommended that the catalog number to be entered on MBz matches each # individual disc. The number for the overall package can be noted in the release annotation if desired. Is that still true now that a release can consist of several discs? Wouldn't it be better to use the catalog number that goes for the whole release instead? If that is so, and is changed, would it be good to store catalog numbers for individual discs somewhere too? (Same goes for barcodes.) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-331: Add CD Baby Relationship Type
And we will just end up with ton of spam links that will clutter the database and web site. It doesn't necessarily need to clutter the site. When looking at a release there could be a single find this for sale button showing that info. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-Something, Vol. 2: Instrumental Attribute for Performed Relationship Type
The proposal: http://wiki.musicbrainz.org/User:Reosarevok/Performed_Relationship_Type_Instrumental_Attribute So that would mean that a version with translated lyrics is a new work, whereas an instrumental version is an instrumental performance of a work with lyrics. But if the instrumental version the original, and lyrics is added later, then the version with lyrics will be a new work. It seems plain logical to me ;-) You add something to the original (having in general a new author: lyrics, translation) = new work; you remove something (= no new author) it's a partial rendition of the original work, like for excerpts. OK, that makes sense. Except that it's not always that obvious what particular lyrics are removed from a particular instrumental version. Yes. Earliest work of course. We did that for earliest release before. Why should this be different? I saw that as a misfeature of the pre-NGS days that I thought we got rid of. Then we linked to earliest release as a canonical representative of a work, but actually we meant it was a cover of that *work*. (Yes sometimes a cover conceptually is rather a cover of a specific version, but then not necessarily the original version.) Besides this not being what we really meant, this had practical problems when it was hard to know what the earliest release was, or that particular release wasn't in Musicbrainz. The same could apply here, like I think the Swedish and English versions of ABBA's Waterloo were released the same day. But it's not one particular example that disturbs me, but more that it doesn't feel right. If I play The Model, Waterloo or The Internationale without lyrics (to repeat some examples) it just isn't true that I removed lyrics with a *particular* language. Well, even though the earliest-lyrics principle has some problems, it's possible to live with it, just as it was possible to live with the earliest-release cover principle. In both cases: Link to the original (= earliest) work. Specific cases, where this should not make sense, will be discussed and decided case by case. One other case which I'm sure is not obvious to everyone, and that isn't uncommon, should be mentioned explicitly, and that's reuse of melody for new lyrics that isn't a translation. Is an instrumental The Star-Spangled Banner an instrumental version of The Star-Spangled Banner? Or is it really a version of To Anacreon in Heaven? ( http://en.wikipedia.org/wiki/To_Anacreon_in_Heaven ), just because that's where the melody is from originally? I think it would be best if in this case at least the instrumental version isn't tracked down to original use of melody, but is seen as a version of the song that matches the title given to it. There will be borderline cases where new lyrics is partly a translation and partly new, but some cases we'll have to decide case-by-case. But normal melody reuse is so common it really ought to be mentioned. It's not like I have problems finding examples. In fact I've skipped most I thought of because they got too complicated. The cd I'm playing right now, http://musicbrainz.org/release/0ba4c48e-6aa9-4817-bd2a-87b9fbe5409c , has instrumental jazz versions of children's songs, including Swedish children song Små grodorna http://en.wikipedia.org/wiki/Sm%C3%A5_grodorna . But the melody has been tracked to French revolutionary military march, La Chanson de l’Oignon. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-Something, Vol. 2: Instrumental Attribute for Performed Relationship Type
The proposal: http://wiki.musicbrainz.org/User:Reosarevok/Performed_Relationship_Type_Instrumental_Attribute So that would mean that a version with translated lyrics is a new work, whereas an instrumental version is an instrumental performance of a work with lyrics. But if the instrumental version the original, and lyrics is added later, then the version with lyrics will be a new work. It seems a bit unnatural to if different relationships are used in those cases. Also, what work is it an instrumental version of? Always the original? Take Kraftwerk's Das Model/The Model that they've made both in German and English (two works). If Balanescu quartet's instrumental cover of that ( http://www.youtube.com/watch?v=-N7CkQ2-398 ) was entered would you need to know what version Kraftwerk released first to know what work to relate it to? Or would it depend on what title the cover has? (But there are translated songs with the same title as the original, like ABBA's Waterloo in Swedish or English.) Or maybe other context? On a release from 1922-44 with various national anthems (played without lyrics) should The Internationale be linked to the Russian language version, since it's included because it was the national anthem of the Soviet Union at the time? Or to the English because it's called The Internationale on the release? Or the French because it has the original lyrics? (OK, that made-up example is a bit convoluted.) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Use of ‘fancy’ punctuation characters
Personally, I don't think there's any utility in replacing characters which could be done with a script. Only if there's some kind of judgement call involved does it really make any sense. Cleaning up only some releases will just leave things in a seemingly inconsistent state, so I'd really prefer if any changes of this nature were made database-wide if they're going to be made at all. I don't think that's a reason to avoid doing that clean-up. You'll get that inconsistent state anyway, since newly entered releases will (preferably) be entered with U+2019 RIGHT SINGLE QUOTATION MARK for example. I'd rather think that the more edits like that are made the sooner someone will get around to doing a script that takes care of obvious cases instead. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Use of ‘fancy’ punctuation characters
At least Bogdan Butnaru has planned to write typography assisting software. See http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Mechanically-assisted-updating-of-typography-on-MusicBrainz-td5978214.html from early this year. song's title → song’s title a 'quoted' text → a ‘quoted’ text in the '90s → in the ’90s rock 'n' roll → rock ’n’ roll And since actual use often is erroneous for apostrophe at the beginning, with spellings like Rock ‘n’ Roll (I've given examples in http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Ellipses-quotation-marks-and-the-miscellaneous-guideline-td5734079i20.html#a5769484 ) I think a style guide should explicitly mention if that should be corrected (my opinion) or not. The hyphen thing is harder, because AFAIK there's no way to actually see the difference (at least in the standard font MB uses) so they're kinda hard to vote on anyway. Hopefully these will become autoedits anyway. My preference is that if you enter titles and names with ambiguous ASCII characters there should somewhere on the screen appear something like The character - is ambigous. It is usually a hyphen for hyphenated words, but sometimes a dash or a minus sign. If you are unsure just leave it as it is. [hyphen] [en dash] [em dash] [minus] ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Works and remixes/covers
Translations have been migrated as different works, they have different lyricists and we store lyricists at work level. Are covers without lyrics its own work then? Like for instance Yesterday with Oscar Peterson: http://musicbrainz.org/recording/b0da13b6-12db-4391-9a2c-1dd26fb4cf3a And is that then the same work as any other cover of the same song without lyrics, for instance http://musicbrainz.org/recording/3a21b38a-1e9a-4bfd-a229-6b4cc5a19864 with The Flame All Stars? I guess that makes sense, even though these two instrumental versions are two different covers of the original rather than two versions of the same cover. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Performance names versus artist credits
How do we decide whether to create performance names or to just use artist credits? I can think of plenty of artists which are basically the same name written slightly differently, but [...] Other examples that I think are borderline are those where just first name or just last name is used. So how do we decide? Well, what does it matter? That depends on how it is used by different software. In many cases I think it wouldn't matter. One instance where I would matter much is when release artists are used as a basis for path names. Take J. G. Thirwell http://musicbrainz.org/show/artist/relationships.html?artistid=173872 that performs as Foetus, Clint Ruin and Manorexia. Many of the Foetus releases actually have name variations like Foetus Interruptus, Foetus Inc. etc. (see http://en.wikipedia.org/wiki/Foetus_(band) ) , These are not in MB yet, but will be here with the new artist credits. I'd like them all to be put in the same directory (Foetus) if I use ARTIST/TRACK paths when ripping though, but a Manorexia release in a separate directory. When ripping programs are learned to behave that way, that might be useful as a thought experiment when deciding what's different performance names or not. Would you want to clump these releases together like that or not? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Mechanically-assisted updating of typography on MusicBrainz
I think it sounds good. A couple of points: * for the above case, skip any titles that contain words not in the dictionary for the language the word becomes in (i.e., make sure there are no non-English words in a title containing “don't”, or non-French ones in a title with “C'est” This seems overly cautious to me. What are you trying to avoid? Looking at c'est in track_name the most suspicious-looking ones would be Nous Deux C'est Pour La Vie (雨のソナタ 〜La Pluie〜French Version) 愛野美奈子（小松彩夏）/C'est La Vie〜私の中の恋する部分 C'est La Vie (σήμερα) C'est la vie 〜 私のなかの恋する部分 but there is no reason to don't exchange those, right? * depending on the success with apostrophes, I might add other tests for quotes (with appropriate tests for pairs of quotes and language), en-dashes (e.g. hyphens between things that make sense as a range, avoiding BootlegTitleStyle and the like) and em-dashes (most space-hyphen-space sequences in the database should really be em-dashes, but it may be hard to test for exceptions so much of this will be manual). Dashes are tricky, since different style guides use it differently. What's written like - in ASCII might be em+dash, or space + em-dash + space, or space + en-dash + space. depending on preferences. See http://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash . Just like a publisher can have a house style regarding this, Musicbrainz could have that, rather than mimicking different releases. (Just like a printed publication listing the same titles would use the house style of the publication all the way through.) But complicating the issue it is also language dependent. In my native Swedish you use space + en-dash + space (nowadays) according to all style guides, for instance. * I’m not sure what to do with actual hyphens. I’ve only recently found out there’s a separate Unicode character for a hyphen (U+2010), distinct from the ASCII hyphen-minus char, but I’m not sure if it’s actually preferred. (I currently type an ASCII hyphen/minus for hyphens and the other dashes as Unicode, but I might change this if I find a good reason to.) Even though I haven't used it myself yet, I think the true HYPHEN character should be used, if not for other reasons just as a statement that this HYPHEN shouldn't be exchanged by further heuristics. Anyway, there probably isn’t a lot of reason to worry about these. There are about 25k unique titles with this character, and about half of them are isolated hyphens, most of which will probably become em-dashes. There are a few that should be MINUS SIGN as well (like Liquid Cool (Space -320°F Biostatic Ambient mix)) (but just space + hyphen-minus + digits isn't enough, since there are lots of cases like Hallo Boss, Hallo -1962 as well). ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Ellipses, quotation marks, and the miscellaneous guideline
I can’t wait for the discussion about whether « ‘cause » or « ’cause » is the correct abbreviation for “because” :D Heh. Why would there be any discussion any more than there is over whether “it’s” or “it‘s” is correct? Only one of those is an apostrophe. If there will be such an issue, I expect it more often to be about 'n' like in rock 'n' roll, which in my experience quite often is written as rock ‘n’ roll. At least it didn't make me much time to find a few examples of releases that writes like that on the cover: http://musicbrainz.org/release/ab6c8085-16ac-4849-8fc3-94f35f98bccd.html http://musicbrainz.org/release/81182837-83ef-4e0a-b84a-3aa0515d833c.html http://musicbrainz.org/release/03625ca3-6cff-4c26-aca9-8791308cc104.html (My opinion would be to silently correct that to ’n’ here except in very special cases, just as we correct capitalization.) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Data tracks with music
How do you handle a cd with audio tracks as well as data tracks where the data tracks are mp3 files (or similar sound files)? As far as I can see from http://musicbrainz.org/doc/Data_Track_Style they should be handled as any other data tracks. Is that really the intention? Whatever the answer is, I think that situation should be mentioned explicitly there. An example is http://musicbrainz.org/show/release/?releaseid=1024170 (entered with only audio tracks) which has lots of mp3 files as bonus (data) tracks as mentioned at http://www.heptagon.se/ . ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] FYI: Updating Release Artist Style regarding boxset
I'm going to update the Release Artist Style (since this only a proposal and not an official guideline), to remove the following section: Sounds good, except why remove it instead of keeping the question but adding a Yes answer instead of the No answer? It would be nice to have something to point to when making such edits. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV4: Supporting Release Relationship Type
In any case, if we define a single taken from an album as simply it's a single that has a track on it which was also on album Foo, then it remains true even if the single and the album are released 10 years apart. But preferrably there'd be an AR between those *tracks* then. In that case, what is the point of this release-release relation which gives no more information? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV4: Supporting Release Relationship Type
But what we want to do with this release-group-release-group AR (that would have to be a release-release AR until we move to NGS) is to easily identify that a group of singles are related to an album, and vice-versa. That's what Wikipedia is doing e.g. here: http://en.wikipedia.org/wiki/Nevermind I see, but I was commenting on if we define a single taken from an album as simply it's a single that has a track on it which was also on album Foo, and it still seems to me that if that is what is meant, then this AR would be redundant, and just a potential source for conflicting information. http://en.wikipedia.org/wiki/Don%27t_repeat_yourself But maybe I took that quote too literally. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] What is classical music?
So…I can basically follow what the credits of the release say? If it’s credited to the performer with a subtle (Composerlastname) comment, people are obviously listening to it because of the performer; if it’s credited to the composer, people are obviously listening to it because of the composer. That actually works out pretty well, but doesn’t it pretty much negate the style guide http://musicbrainz.org/doc/Classical_Release_Artist_Style I would like musicbrainz to follow that route more. These style guides are mostly written before the ARs. Then mb needed its own somewhat stricts rules on what relation there should be between a release/track and its artist, because we would like to link to the the most important artist, and also otherwise you wouldn't know what that link meant for a particular track. Now when both performers and composers can be added with ARs I don't think we need our own rules as much, but can follow the releases more. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Writer Relationship Type (revival)
That's exactly what I fear will happen. To avoid that happening maybe the user interface should present was written by explicitly as four choices: [x] Unknown role [ ] Wrote the text [ ] Composed the music [ ] Wrote the text and composed the music so it is very clear that one choice is only applicable when you don't know more. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: - 'Add Music can be streamed for free at'
I think Artist music can be streamed for free at URL looks odd, shouldn't it be Artist's music can be streamed for free at URL? It's not possible to do that because link phrases always have a space before and after. The download and purchase links use artist music can be ... at url which is why I suggested the current wording. Doing it otherwise would probably look strange for artists whose name aren't written with the Latin alphabet anyway. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
