Re: [mb-style] Chinese releases
On Tue, Feb 19, 2013 at 4:45 PM, Rafa.Ctt rafael.c...@upf.edu wrote: Rachel Dwight wrote Nikki brought this thread to my attention, so here's my two cents. https://musicbrainz.org/doc/Style/Language/Chinese is mostly written by me, and my intention was that words should be grouped without spaces, as in yīnyuè. The example Bā dù kōngjiān and the link to http://www.pinyin.info/readings/zyg/rules.html points in this direction. However, I don't believe it was ever discussed at the time. While it is the correct way, there are indeed cases where it's tricky to judge what is a word. Since I don't use transliterated releases myself, I don't have a strong opinion on what the guideline says on this point. -- Philip Jägenstedt I'm relatively new to the Chinese language, so my two cents may not be worth much, but I'd normally group hanzi together as long as they collectively form a single word; otherwise they ought to be separate to prevent confusion. Consider the case with Japanese romaji; we don't place each individual character (kana, kanji or otherwise) separately because there would be a whole world of confusion. I do agree it can be difficult for those who don't know the language very well, so we'd have to keep a list of resources in the guideline page. Thank Philip and Rachel for your comments. About Japanese romanization, I'm not a Japanese speaker, so I don't have an opinion about that. But I do know that Chinese and Japanese, although they share script, are completely different linguistacally, so I don't know how clear are the criteria for wording in Japanese. But anyway, I don't think a comparison between Chinese and Japanese is helpful, precisely because they are not related languages, and grammar and syntax work in different ways. For example, I know that some Japanese kanjis are used for polysyllabic words, what already points out that this set of syllables forms an unity, a word. That's not the case in Chinese, where every character is used for a single syllable (there is a couple of extremely rare exceptions for technical language). And furthermore, the features of Chinese language makes the wording criteria really loose, basically, and this is my opinion, because Chinese grammar doesn't need the concept of word, as we know it in English, but semantic unities, which are much more flexible than words. Anyway, Philip, thank you very much for your link, I didn't know this website. I acknowledge that for acadmic publications or punctual quotations in English (or latin script) texts the separation of the sentence into individual syllables wouldn't be acceptable. However, the purpose of having a transliterated pseudo-release in MusicBrainz is, in our opinion, to make Chinese releases easily searchable for either non Chinese readers or Chinese readers who can't type Chinese for any reason. So, the goal is to have a a priori criterion so that a query of a Chinese release or track would be succesful. We are uploading in CompMusic a collection of Beijing opera to MusicBrainz. At the beginning I discussed with my Chinese colleague how could be that criterion, but almost for every example (Beijing opera arias, not written in contemporary standard Chinese) we found disagreements. So we came to the conclusion that the easiest way, and the one that would get more successful results, would be to separate each syllable. Only for CD titles and tracks, and with the goal of making the search successful. I've already uploaded some pseudo-releases according to this proposal: http://musicbrainz.org/collection/5802789e-9d58-4192-b7d3-e6e48443bb90. Please, give it a look and chek how it looks. I'll talk with my colleague again about that website. And I'll love to hear your comments. I haven't entered very many transliterated releases myself, but am not surprised that trying to group by word results in disagreements and would thus cause plenty of extra work. I had a look at http://musicbrainz.org/release/c3ce9674-36f6-45c8-8e40-26a440d328f3 and think it looks good and I would certainly vote yes to these transliterations. If anyone has the energy, it wouldn't hurt to update https://musicbrainz.org/doc/Style/Language/Chinese to be explicit about what kind of spacing is acceptable, if we can all agree. Thanks for your hard work! -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Chinese releases
On Thu, Jan 17, 2013 at 6:00 PM, CARO REPETTO, RAFAEL rafael.c...@upf.edu wrote: 2. For the transliteration of titles and tracks, and since there is no official consensus about it, we are planning to transliterate every single hanzi separately: 音乐 = yīn yuè, and not yīnyuè. As for capitals in titles and tracks, we think that only first syllables in the phrase, and those for proper names for people and places should be in capitals. Nikki brought this thread to my attention, so here's my two cents. https://musicbrainz.org/doc/Style/Language/Chinese is mostly written by me, and my intention was that words should be grouped without spaces, as in yīnyuè. The example Bā dù kōngjiān and the link to http://www.pinyin.info/readings/zyg/rules.html points in this direction. However, I don't believe it was ever discussed at the time. While it is the correct way, there are indeed cases where it's tricky to judge what is a word. Since I don't use transliterated releases myself, I don't have a strong opinion on what the guideline says on this point. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-97: Move medley to an attribute of recording of v2
On Tue, Jul 31, 2012 at 8:40 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Tue, Jul 31, 2012 at 8:57 PM, Philip Jägenstedt phi...@foolip.org wrote: On Tue, Jul 31, 2012 at 9:56 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Tue, Jul 31, 2012 at 4:56 AM, Calvin Walton calvin.wal...@kepstin.ca wrote: On Mon, 2012-07-30 at 21:52 +0200, Philip Jägenstedt wrote: http://wiki.musicbrainz.org/User:Foolip/Performance_Relationship_Type I used the definition from the previous thread. The link phrases would just have medley added, e.g. live cover medley recording of. I like the idea, but on a technical note: Do you have any plans for how the data will be migrated from the old AR to the new one? There's a couple of options here, maybe: A. Have a developer write a script to do all the conversions automatically, server-side after the AR is created. B. Have a developer write a report showing things using the 'old' medley AR; it will only be deleted once the report is empty. Either one would be fine, but you'll have to find a developer to sponsor your request :) We have around 2500, so that's a pain, but I'd go with C) convince a bot owner to run a bot for this for a couple days. My thinking was to deprecate the existing AR so that new ones can't be added, like the earliest release AR. Is that easy enough to do? Then the ARs can be converted slowly with the help of reports and/or bots. That's trivial, yeah. Great, is there anything else (other than a +1) I need before RFV, i.e. do I need to update the existing medley AR to say it's deprecated? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-97: Move medley to an attribute of recording of v2
On Tue, Jul 31, 2012 at 9:56 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Tue, Jul 31, 2012 at 4:56 AM, Calvin Walton calvin.wal...@kepstin.ca wrote: On Mon, 2012-07-30 at 21:52 +0200, Philip Jägenstedt wrote: http://wiki.musicbrainz.org/User:Foolip/Performance_Relationship_Type I used the definition from the previous thread. The link phrases would just have medley added, e.g. live cover medley recording of. I like the idea, but on a technical note: Do you have any plans for how the data will be migrated from the old AR to the new one? There's a couple of options here, maybe: A. Have a developer write a script to do all the conversions automatically, server-side after the AR is created. B. Have a developer write a report showing things using the 'old' medley AR; it will only be deleted once the report is empty. Either one would be fine, but you'll have to find a developer to sponsor your request :) We have around 2500, so that's a pain, but I'd go with C) convince a bot owner to run a bot for this for a couple days. My thinking was to deprecate the existing AR so that new ones can't be added, like the earliest release AR. Is that easy enough to do? Then the ARs can be converted slowly with the help of reports and/or bots. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-97: Move medley to an attribute of performance of
On Thu, May 17, 2012 at 6:41 AM, practik kronp...@yahoo.com wrote:
OK, here's a second attempt:
On release and recording pages, the base phrase (medley of:) would be
modified by adding any or all of the following:
live
instrumental
including covers
of parts
So if you selected all four attributes, the join phrase would be:
live instrumental medley including covers of parts of:
On work pages, the base phrase (included in medleys:) would be modified by
adding any or all of the following:
covers
partially
live
instrumental
So if you selected all four attributes, the join phrase would be:
covers partially included in live instrumental medleys:
Does that seem workable?
It also occurs to me that the wiki page for this RFC should be updated to
reflect the current wording of
http://wiki.musicbrainz.org/Performance_Relationship_Type.
I've been annoyed by the inability to set live and cover attributes
for medley many times recently and was going to suggest exactly what
Alex has suggested. Alex, have you given up on this, or are you still
waiting for feedback from the developers?
As for the proposal above, is it still intended as an extra attribute
on the recoding-work recording of AR? If so, shouldn't we just add
an attribute to is a {partial} {live} {instrumental} {cover}
recording of to arrive at is a {partial} {live} {instrumental}
{cover} {medley} recording of?
--
Philip Jägenstedt
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC STYLE-97: Move medley to an attribute of recording of v2
http://wiki.musicbrainz.org/User:Foolip/Performance_Relationship_Type I used the definition from the previous thread. The link phrases would just have medley added, e.g. live cover medley recording of. I wanted to add an example, but unfortunately I wasn't able to find a single English-language recording with medley ARs starting from http://en.wikipedia.org/wiki/List_of_musical_medleys, please let me know if you have an example. If all else fails, I'll just use an Eason Chan medley as the example: http://musicbrainz.org/recording/6370917a-ea63-4d9f-a18e-72a63a2476ee http://musicbrainz.org/recording/6bda9f82-32f7-448d-bf89-044816e30653 -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-97: Move medley to an attribute of recording of v2
On Mon, Jul 30, 2012 at 10:08 PM, Alex Mauer ha...@hawkesnest.net wrote: On 07/30/2012 02:52 PM, Philip Jägenstedt wrote: http://wiki.musicbrainz.org/User:Foolip/Performance_Relationship_Type I used the definition from the previous thread. The link phrases would just have medley added, e.g. live cover medley recording of. I wanted to add an example, but unfortunately I wasn't able to find a single English-language recording with medley ARs starting from http://en.wikipedia.org/wiki/List_of_musical_medleys, please let me know if you have an example. If all else fails, I'll just use an Eason Chan medley as the example: http://musicbrainz.org/recording/6370917a-ea63-4d9f-a18e-72a63a2476ee http://musicbrainz.org/recording/6bda9f82-32f7-448d-bf89-044816e30653 This might be a good example: http://musicbrainz.org/recording/3ce3818e-b83a-4c64-b983-639a0e399fff That has a live recording of AR in addition to the medley ARs, is that wrong or is it really a full performance of Can you hear me? followed by a medley? I figured out how to search for medley edits and added a simpler example with Madonna to the wiki page, please double-check. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFCish: Abandon Latin script sort names for Chinese artists
On Wed, Jul 25, 2012 at 10:30 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Wed, Jul 25, 2012 at 10:08 AM, jesus2099 hta3s836gzac...@jetable.org wrote: +1 no sort-names for Chinese artists +1 KATAKANA sort-names for Japanese artists at the same time Sortnames are also what we use to show latin names for artists in the inline search - changing that to work in some other way would be a pain (mostly because I can't see other way working well right now). Would it be hard to use the best Latin alias, preferring English but falling back to any available Latin-script sort name? The way I see is this happening is a human-supervised bot to reset the sort names of all Chinese artists while at the same time adding Latin-script aliases. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFCish: Abandon Latin script sort names for Chinese artists
On Mon, Jul 23, 2012 at 4:23 AM, Calvin Walton calvin.wal...@kepstin.ca wrote: On Sat, 2012-07-21 at 09:07 +0200, Philip Jägenstedt wrote: On Fri, Jul 20, 2012 at 4:02 PM, Calvin Walton calvin.wal...@kepstin.ca wrote: On Fri, 2012-07-20 at 15:07 +0200, Philip Jägenstedt wrote: http://musicbrainz.org/doc/Style/Artist/Sort_Name says: All artist sort names should be in Latin script. If the artist's name is normally written using a non-Latin script, use the Latin script translated or transliterated name by which the artist is most commonly known. For Chinese artists, this is problematic in several ways: TL;DR: Leave the artist Sort Name as Latin (if possible), and add an alias marked as Primary with the locale set to Chinese that has the correct Chinese name and an appropriate Sort Name. What is an appropriate sort name? If it is in Latin script, problems 1-3 would remain. No, the sort name for a locale alias should be in whatever script someone in that locale would expect to use when sorting. In the Japanese locale the artist name might be in either Latin or Chinese characters (Kanji), but in either case the sort name would be in Kana (Hiragana or Katakana). For example, the top two Primary aliases shown on http://musicbrainz.org/artist/b6c18308-82c7-4ec1-a42d-e8488bce6618/aliases demonstrate this. Yeah, that looks good to me, assuming that Japanese is conventionally sorted by kana and that's what people want to see in their music libraries. It will cause a Japanese artist and a Chinese artist by the same name to be sorted differently, but that is not a big problem to me at least. Many of these same issues apply to Japanese artists as well, and we've been dealing with it. Instead of answering your RFC directly, I'm going to give you a vision of what I'm hoping will come about. (I'm still working out the details, but I hope to submit a proposal for an upcoming schema change release regarding the changes.) For legacy reasons, we really can't just redefine the artist sort name field at this point. What legacy reasons are those, that make it impossible to redefine to redefine the artist sort name but possible to remove it completely? For backwards compatibility, it would probably be necessary for the sort name field in the webservice API to return a Latin sort name even if we have something better - the real sort names will be in the alias section of the response. This will likely be done by making the top-level sort name field in the API use the sort name from a prioritized list of locales that use latin script. (e.g. use the English sort name if there is one, otherwise use French, ...) This might end up not being the case - I'd love it if a Musicbrainz developer would hop in with an opinion about whether we can change that :) Clients that actually use the sort name for sorting would seem well served by getting strings useful for sorting. I guess we're worried about clients that use the sort name to get an English name? Would it be a problem if they notice that it's not working very well and that there's a new and better way to do the same thing? My motivation for all of this is being able to remove my Picard hack $set(artistsort,%artist%), so if the web service stays the same then there's no point, for me. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFCish: Abandon Latin script sort names for Chinese artists
On Fri, Jul 20, 2012 at 4:02 PM, Calvin Walton calvin.wal...@kepstin.ca wrote: On Fri, 2012-07-20 at 15:07 +0200, Philip Jägenstedt wrote: http://musicbrainz.org/doc/Style/Artist/Sort_Name says: All artist sort names should be in Latin script. If the artist's name is normally written using a non-Latin script, use the Latin script translated or transliterated name by which the artist is most commonly known. For Chinese artists, this is problematic in several ways: TL;DR: Leave the artist Sort Name as Latin (if possible), and add an alias marked as Primary with the locale set to Chinese that has the correct Chinese name and an appropriate Sort Name. What is an appropriate sort name? If it is in Latin script, problems 1-3 would remain. Many of these same issues apply to Japanese artists as well, and we've been dealing with it. Instead of answering your RFC directly, I'm going to give you a vision of what I'm hoping will come about. (I'm still working out the details, but I hope to submit a proposal for an upcoming schema change release regarding the changes.) For legacy reasons, we really can't just redefine the artist sort name field at this point. What legacy reasons are those, that make it impossible to redefine to redefine the artist sort name but possible to remove it completely? My proposal is to simply completely remove the artist name and sort-name field completely, and only use aliases. This is quite feasible now that the aliases support having the locale marked, and that we can set a Primary alias for a locale. That alias will have the appropriate locale-specific sort name attached. One additional mark will be added to aliases, to allow specifying a particular alias as being the artist's native name. Then, a preference will be added to the website to allow specifying whether you prefer to have artist names shown in your preferred locale (in which case it picks the alias marked as Primary for your locale), or whether you would like to see artist names shown in their own native languages (in which case it picks the Native locale alias). Picard could receive a similar option to allow picking which locale to grab the sort name from when tagging files. This might be a good idea, but it seems that in practice the only difference is that it allows us to assign a locale to the main artist name. Whatever we want to with sort names surely isn't affected by this? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFCish: Abandon Latin script sort names for Chinese artists
http://musicbrainz.org/doc/Style/Artist/Sort_Name says: All artist sort names should be in Latin script. If the artist's name is normally written using a non-Latin script, use the Latin script translated or transliterated name by which the artist is most commonly known. For Chinese artists, this is problematic in several ways: 1. Not all artists are known under a Latin script name at all, in which case one must be fabricated. 2. There are many romanization systems for Chinese (http://en.wikipedia.org/wiki/Chinese_romanization) and not always possible to know which is appropriate. For example, for unknown composers/lyricist on a Hong Kong artist's Mandarin release for the Taiwan market, one must guess if the person is from Hong Kong, Taiwan or somewhere else and pick a system based on that. 3. The sort names are useless for actually sorting Chinese artists, in particular for groups like 黑冥煞 (Inferno Requiem) vs 黑名單工作室 (Black List Studio) but also for artists like 劉畊宏 (Liu, Will) vs 劉德華 (Liu, Andy). 4. Sort names have traditionally been used to provide a Latin-script artist name, but that doesn't work for Chinese artists since the correct order is unknown. Tsai, Chin is customarily Tsai Chin while Tsai, Jolin is customarily Jolin Tsai. As of late, I've been giving up on setting sort names when I run into point 2, but there are many artists with bogus romanizations in the system added over the years. Point 4 hints at the solution -- aliases. Suggestion: For Chinese artists, simply use the name as the sort name and use aliases for tagging and tooltips on the web site where needed. Thoughts? Are there changes to Picard and/or the website that would be needed before making this change? Are there other locales with the same problems where it would also be beneficial to abandon Latin script sort names? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Sampling at the composition/work level
On Mon, Jul 2, 2012 at 9:16 AM, practik kronp...@yahoo.com wrote: Philip Jägenstedt wrote On Sat, Jun 30, 2012 at 10:56 PM, monxton wrote: In any case, a work-work relationship gives more information, because it tells you which of Beethoven's works is quoted. This is much more useful than just setting Beethoven as the composer. If we can agree on the work-work AR perhaps the rest will fall into place, but how broad should it be. The wording I used in the annotations was includes elements of and incorporates part of. I suppose that the AR we invent should also be used for Beethoven's variations of Mozart compositions, how would someone with a clue about classical phrase the relationship between two such works? I've had the idea of such a work-work relationship on my AR wish list for a while now. A pretty common term I've seen in the classical context is quotation,* but I personally would prefer to see us use a broader term lke adaptation. To me, quotation implies a straight reproduction of a section of the original work, without changing it, but I feel like lyricists and composers often rework the original material, at least in the pop context. An example: The line And everything depends upon how near you sleep to me, from Leonard Cohen's song Take This Longing, is quoted in Hand in Glove by The Smiths, except the word sleep is replaced by stand. It's not quotation in the strictest sense of the word, but it's still clearly a reference to Cohen. Semantically, adaptation would encompass this sort of thing nicely. And in fact, we have a suggested phrasing for such a relationship, courtesy of caller#6: [work] includes [lyrics|music] adapted from [work].** As for how broad to make it, I'd suggest using it only for works that incorporate parts of other works, and not for works that are themselves adaptations of other works, since we can use the version of relationship for that. And I'd say we shouldn't use it for medleys, although it would technically apply to them, since we have the work-work medley relationship for those. Patrick * http://en.wikipedia.org/wiki/Musical_quotation ** See http://musicbrainz.org/edit/17141710 for context. [work] includes [lyrics|music] adapted from [work] sounds good to me, at least it would work in the cases that I have encountered. Are you interested in pursuing an RFC/RFV for this? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Sampling at the composition/work level
On Sat, Jun 30, 2012 at 10:56 PM, monxton musicbra...@jordan-maynard.org wrote: On 30/06/2012 19:39, Nicolás Tamargo de Eguren wrote: On Sat, Jun 30, 2012 at 9:35 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: I don't really see a big issue with listing Beethoven as composer, although I know monxton and I won't agree on this one. As I said in the edit, there are at least two reasons why I don't like it. First, because Beethoven obviously did not compose this this work. But even if it was closer to Beethoven's work than it is, I dislike to see these mashups among the list of works that Beethoven composed - it just seems wrong, and I think it discredits the database. In any case, a work-work relationship gives more information, because it tells you which of Beethoven's works is quoted. This is much more useful than just setting Beethoven as the composer. Note that Beethoven is listed as a composer on the same level as 陳輝陽 in the music video (http://www.youtube.com/watch?v=tR20mI5LxSU) which says 作曲： 陳輝陽/貝多芬. I don't know what the booklet says, but it would be a bit weird if the two composers couldn't be deduced without ambiguity from the data we have. If we can agree on the work-work AR perhaps the rest will fall into place, but how broad should it be. The wording I used in the annotations was includes elements of and incorporates part of. I suppose that the AR we invent should also be used for Beethoven's variations of Mozart compositions, how would someone with a clue about classical phrase the relationship between two such works? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Series support discussion
On Sun, Jul 1, 2012 at 5:05 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: Hi! Sending this here mainly because it has more active users than mb-users anyway... So, in October we'll have the next schema change release, and I would like to get series support into it (or, failing that, into next May's release). For that, we'd need a new entity (which devs seem happy with) and an interface, and to decide exactly what we want our series support to be. So, let's discuss that! My current idea is a pretty simple thing: a series has an MBID, a name, and a list of things (releases or recordings [1]) in an order. Is there anything else they need? UI issues are: How to display them? My current answer is just a list, with all the stuff for editing shown only when in the /edit URL like for other entities How to edit a series? My current answer is making the edit series page a series of search fields, where you can both search for the stuff inline or (probably easier) just paste the URLs in How to add new stuff to a series? The main options are Add at the bottom (like for tracklists) or Insert button after every line. The former is cleaner, the latter might be more useful - but is it worth it? Or will we be adding stuff in order anyway in most cases? How to change the order? Drag and drop is hard, but arrows can be a pain if you can only add stuff in the end to begin with. Of course, it would be less of an issue if we decide to allow to add stuff at every position. Starting with arrows is probably simpler, with other options added post-schema-change if needed. How to remove stuff from a series? A simple X button should do, like in tracklists, I'd say. So, what have I forgotten, what sounds wrong, etc? :) [1] for video series, like http://vimeo.com/album/1656956 and standalone-recording podcast series. What's the use case? Do series correspond to some real-world concept with official standing, or is it for users to make lists of favorite songs? Can one make lists of any entity, or just recordings and releases? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Sampling at the composition/work level
http://musicbrainz.org/edit/18155855 In short, I know of at least 3 works where a well-known piece of music was sampled in a new work: http://musicbrainz.org/work/faacf69c-a008-47bf-a705-4099219c35af http://musicbrainz.org/work/1a5edc0e-a2eb-40b3-92a9-78d15fb536d4 http://musicbrainz.org/work/ed1600ee-46f0-4e5d-adc1-03341d515287 The version of work-work AR seems inappropriate, so what to do? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] What to do with High Quality?
On Thu, Jun 21, 2012 at 3:59 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: So, I think everyone agrees that the current High Quality option sucks horribly, is only good to annoy editors and should be avoided like the plague. Our whole quality system needs a re-think, really, but until that is done, I can see three main options for HQ: 1) keep as it is but rename to Protected, so it will only be used in the cases where there's any use in making editing a specific release difficult (because it's being vandalised or whatever) 2) remove the restrictions - make HQ be just an indication of the data quality 3) remove HQ altogether What sounds better? I've been using HQ for releases where every single credit that can be added from the booklet has been added and the titles are exactly as they should. That being said, I could just as well have used tags to keep track of that, since making it harder to edit was never my main objective. I would be fine with 3. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Work type documentation
On Fri, Jun 22, 2012 at 4:51 AM, Stephen step...@tungol.org wrote: On Jun 21, 2012, at 4:25 PM, practik wrote: I'm kind of in favor of 3, actually. Now that I think about it, song seems so broad as to be meaningless, so why keep it? Song does apply to some cases in non-popular music, and should be retained for those. Otherwise, I agree. I think that work type is a classification that doesn't apply to popular music, and I'd support a proposal to simply not use the field in that case. Are you interested in putting that up for RFC? Right now things are in limbo, which is very unsatisfactory. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Work type documentation
On Fri, Jun 22, 2012 at 6:30 PM, Stephen step...@tungol.org wrote: Instead of inviting confusion by insisting on a dichotomy between 'song' and 'instrumental', why not call for a way to specify 'does not have lyrics' or 'does not have vocals' on a work? That seems very reasonable. But I don't think that information really fits in work type. I think a [No lyrics] options is a good idea, I've filed http://tickets.musicbrainz.org/browse/MBS-4921 to request that. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Style/Language/Swedish
On Tue, Jun 19, 2012 at 11:26 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Sun, Jun 10, 2012 at 1:48 PM, symphonick symphon...@gmail.com wrote: 2012/6/10 Nicolás Tamargo de Eguren reosare...@gmail.com On Sat, Jun 2, 2012 at 1:50 PM, Philip Jägenstedt phi...@foolip.org wrote: On Sat, Jun 2, 2012 at 12:43 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Sat, Jun 2, 2012 at 12:24 PM, Philip Jägenstedt phi...@foolip.org wrote: On Sat, Jun 2, 2012 at 11:35 AM, symphonick symphon...@gmail.com wrote: Updated the proposal. Thanks for all suggestions. The English version doesn't say the same thing as the Swedish one now. Simple fix that doesn't go into crazy detail: Capitalize the first word of a sentence and names of e.g. people or places. I don't really think they *need* to say exactly the same (or rather, to explain it in the same detail), since I expect a Swedish editor to know what qualifies as a proper noun in Swedish... (unless the day names etc count too). Sure, but names of people or places is wrong by being too specific, I'd be fine with something more vague like names or proper nouns and trusting Swedish editors to know what that means, or having http://www.sprakradet.se/10969 as a reference. Is this ready for RFV? :) Missing a +1. Philip, Per: could you either +1 this or provide an alternative wording? :) proper nouns would probably make sense in Swedish while in English it probably should be explained more explicitly, but of course I don't know Swedish so I can't help too much there... I suggest the vaguer Capitalize the first word of a sentence and names. and would happily +1 that. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Style/Language/Swedish
On Fri, Jun 1, 2012 at 11:22 PM, Lauri Watts krazyk...@gmail.com wrote: On Fri, Jun 1, 2012 at 9:40 PM, Philip Jägenstedt phi...@foolip.org wrote: On Thu, May 31, 2012 at 11:10 PM, symphonick symphon...@gmail.com wrote: http://wiki.musicbrainz.org/Proposal:Style/Language/Swedish http://tickets.musicbrainz.org/browse/STYLE-116 The first part of the Swedish section can be simplified to: Använd versaler i början av en mening och egennamn. A matching English section could be: Capitalize the first word of a sentence and proper nouns. That's a little misleading for native english speakers, where proper nouns that are capitalised includes things like days of the week and months of the year, as well as (some) pronouns and various other things that aren't in most languages. A little precision is easier in the long term: Perhaps Capitalize the first word of a sentence and the names of people or places. That excludes the names of companies, pets, brand names and probably more. Perhaps it would be better to name the notable differences from English: Capitalize the first word of a sentence and proper nouns. Do not capitalize weekdays and months. http://www.sprakradet.se/10969 could be used as a source. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Style/Language/Swedish
On Sat, Jun 2, 2012 at 11:35 AM, symphonick symphon...@gmail.com wrote: Updated the proposal. Thanks for all suggestions. The English version doesn't say the same thing as the Swedish one now. Simple fix that doesn't go into crazy detail: Capitalize the first word of a sentence and names of e.g. people or places. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Style/Language/Swedish
On Sat, Jun 2, 2012 at 12:43 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Sat, Jun 2, 2012 at 12:24 PM, Philip Jägenstedt phi...@foolip.org wrote: On Sat, Jun 2, 2012 at 11:35 AM, symphonick symphon...@gmail.com wrote: Updated the proposal. Thanks for all suggestions. The English version doesn't say the same thing as the Swedish one now. Simple fix that doesn't go into crazy detail: Capitalize the first word of a sentence and names of e.g. people or places. I don't really think they *need* to say exactly the same (or rather, to explain it in the same detail), since I expect a Swedish editor to know what qualifies as a proper noun in Swedish... (unless the day names etc count too). Sure, but names of people or places is wrong by being too specific, I'd be fine with something more vague like names or proper nouns and trusting Swedish editors to know what that means, or having http://www.sprakradet.se/10969 as a reference. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Style/Language/Swedish
On Thu, May 31, 2012 at 11:10 PM, symphonick symphon...@gmail.com wrote: http://wiki.musicbrainz.org/Proposal:Style/Language/Swedish http://tickets.musicbrainz.org/browse/STYLE-116 The first part of the Swedish section can be simplified to: Använd versaler i början av en mening och egennamn. A matching English section could be: Capitalize the first word of a sentence and proper nouns. -- Philip Jägenstedt ___ 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)
On Mon, May 28, 2012 at 6:22 PM, Per Starbäck per.starb...@gmail.com wrote: 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)? :-) The filename of Tooji's Stay bought from eurovisionmusic.com is 32 Stay (Eurovision 2012 - Norway) **.mp3 No other song has ** in the filename so my guess is that I have the updated version. For research purposes I found an early FLAC rip of the release and compared the tracks in Audacity: http://bayimg.com/AAoNIAADN. As you can see, the MP3 is louder. After normalizing the levels I can still hear a difference, but it could just be due to more dynamic compression on the MP3. If someone has copy bought from http://www.eurovisionshop.tv/en/product/cd-and-dvd/45/434/official-2-cd-esc-2012 after the note about this track was added I could compare. If the DiscID is different I suppose a separate release and recording should be added, but assuming it still has the same packaging I don't know how to determine a release date. If two pressings can be confirmed, I obviously don't think we should have two releases for each country, that would be twice as annoying... -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Merging Eurovision Song Contest: Baku 2012 (again)
Andii disagreed, so I'd like to have a proper vote in http://musicbrainz.org/edit/17774115 The issue as I see it is whether or not we should have separate MusicBrainz releases for the same physical release sold in most of or all of Europe, where it may have been available at different dates in different countries. (Should it turn out that the release differs physically between countries then the issue is moot.) -- Philip Jägenstedt ___ 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)
On Sun, May 27, 2012 at 9:03 PM, Andii Hughes gnu_and...@member.fsf.org wrote: On 27 May 2012 19:55, Andii Hughes gnu_and...@member.fsf.org wrote: On 27 May 2012 19:12, Philip Jägenstedt phi...@foolip.org wrote: Andii disagreed, so I'd like to have a proper vote in http://musicbrainz.org/edit/17774115 The issue as I see it is whether or not we should have separate MusicBrainz releases for the same physical release sold in most of or all of Europe, where it may have been available at different dates in different countries. (Should it turn out that the release differs physically between countries then the issue is moot.) The concept of a release in MusicBrainz includes the release date. Hence, a release with a different date is a different MusicBrainz release, though they may share the same tracklisting. I've created http://tickets.musicbrainz.org/browse/MBS-4785 for what I believe is the underlying issue here; that there is no easy way to make edits to a tracklist shared by multiple releases (to my knowledge). That is not the issue, the issue is that these are (AFAIK) the same physical release. Splitting it into one release per country has consequences: * We'll need one release per European country where this is available for sale. * ARs and cover art for that physical release will have to be duplicated once per release. * Given the physical album, there's no way to tell which MusicBrainz release it corresponds to without also knowing where it was purchased. If there is a schema change solution to the problem, it would be to allow multiple pairs of release dates and countries per release. In the absence of that, I think the better trade-off is to have a single release and possibly add annotations for any interesting per-country delays of the release. -- Philip Jägenstedt ___ 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)
On Sun, May 27, 2012 at 10:14 PM, Andii Hughes gnu_and...@member.fsf.org wrote: On 27 May 2012 20:27, Philip Jägenstedt phi...@foolip.org wrote: On Sun, May 27, 2012 at 9:03 PM, Andii Hughes gnu_and...@member.fsf.org wrote: On 27 May 2012 19:55, Andii Hughes gnu_and...@member.fsf.org wrote: On 27 May 2012 19:12, Philip Jägenstedt phi...@foolip.org wrote: Andii disagreed, so I'd like to have a proper vote in http://musicbrainz.org/edit/17774115 The issue as I see it is whether or not we should have separate MusicBrainz releases for the same physical release sold in most of or all of Europe, where it may have been available at different dates in different countries. (Should it turn out that the release differs physically between countries then the issue is moot.) The concept of a release in MusicBrainz includes the release date. Hence, a release with a different date is a different MusicBrainz release, though they may share the same tracklisting. I've created http://tickets.musicbrainz.org/browse/MBS-4785 for what I believe is the underlying issue here; that there is no easy way to make edits to a tracklist shared by multiple releases (to my knowledge). That is not the issue, the issue is that these are (AFAIK) the same physical release. Releases in MB don't represent just a physical release, they represent an event. See: http://musicbrainz.org/doc/Style/Old_style_practices which explains why this was changed from listing just event data on a single release (Amazon links, etc.) We no longer have the concept of release events, just release groups and releases. http://musicbrainz.org/doc/Style/Release doesn't clearly say what a release represents. Splitting it into one release per country has consequences: * We'll need one release per European country where this is available for sale. So? That's the purpose of having releases easily created with the same tracklist. Also how do you know that the countries where this is on sale meet this ambiguous Europe setting? How do you know that some of them haven't been translated into the native language of the country, necessitating a different tracklist? You just seem to want to make a sweeping generalisation about all releases that may or may not exist for no good reason as far as I can tell. The reason we have releases and release groups is so we can have more than one release under the same title. If any country has a physically different release, that should of course be a different release in MusicBrainz. The whole premise is that the releases are in fact the same, as at least the Swedish, UK and German ones appear to be. I could be wrong, but I'd be really surprised if there are several variants of this release already. * ARs and cover art for that physical release will have to be duplicated once per release. Cover art may be different. As I say, you haven't seen all these releases. I agree we do need a way of sharing cover art. I've already raised this, but then the feature is fairly new. http://musicbrainz.org/edit/17722937 Most ARs should be either on recordings or specific to the event (e.g. Amazon links). I agree there are some that may be apply to the whole group. I raised this here: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2012-May/015408.html That wouldn't work since release groups can contain releases that are actually different, as in having different cover art, labels, masters, etc. We have no way to express that two releases are physically the same. It looks like http://tickets.musicbrainz.org/browse/MBS-2229 is the best solution to avoid duplicate ARs and cover art, the question is just what to do until that's been implemented. * Given the physical album, there's no way to tell which MusicBrainz release it corresponds to without also knowing where it was purchased. The person who bought it usually knows. And given the tracklists are shared, it doesn't seem like a huge issue to me. They are pretty interchangeable - isn't that your whole point to start with? My point is that it's weird if a single pressing of a release end up as multiple releases in MusicBrainz and that which release a copy belongs to depends on where it was shipped and sold. If there is a schema change solution to the problem, it would be to allow multiple pairs of release dates and countries per release. Which we had before NGS. It's too restrictive on those where more does differ between releases. Nobody has suggested merging releases which can be physically distinguished or going back to anything like we had before NGS. In the absence of that, I think the better trade-off is to have a single release and possibly add annotations for any interesting per-country delays of the release. Sorry but no. Moving all the release data to an annotation is not acceptable when there is a perfectly acceptable way of adding the data properly in a machine-readable
Re: [mb-style] RFV-346. Style/Language/Vietnamese : Punctuation change
On Tue, May 15, 2012 at 2:53 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Tue, May 15, 2012 at 3:44 PM, jesus2099 hta3s836gzac...@jetable.org wrote: Here is my re-phrase as now RFV-333 can be bypassed (according to Réo) : I speak of this RFV-346 compromise. :) Which is a compromise between my always space and your never space. The problem with your more recent version is that it’s less of a compromise as it systematically chooses the never space on a big amount of entities (never space on recordings, release-groups and works), letting the as is style on tracklists only. This is why I prefer the compromise version (RFV-346). Or, to the limit, your new version with the following change could be reasonably acceptable too : from « Never space on recordings, release-groups and works. » to « Never space on recordings, release-groups and works IF AND ONLY WHEN THERE IS INCONSISTENCY BETWEEN SEVERAL RELEASES/EDITIONS/VERSIONS/ETC. » This sounds reasonable to me, and easy to apply too (follow cover unless covers disagree). I could live with that as well. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-346. Style/Language/Vietnamese : Punctuation change
On Thu, May 17, 2012 at 2:13 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Thu, May 17, 2012 at 3:10 PM, Philip Jägenstedt phi...@foolip.org wrote: On Tue, May 15, 2012 at 2:53 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Tue, May 15, 2012 at 3:44 PM, jesus2099 hta3s836gzac...@jetable.org wrote: Here is my re-phrase as now RFV-333 can be bypassed (according to Réo) : I speak of this RFV-346 compromise. :) Which is a compromise between my always space and your never space. The problem with your more recent version is that it’s less of a compromise as it systematically chooses the never space on a big amount of entities (never space on recordings, release-groups and works), letting the as is style on tracklists only. This is why I prefer the compromise version (RFV-346). Or, to the limit, your new version with the following change could be reasonably acceptable too : from « Never space on recordings, release-groups and works. » to « Never space on recordings, release-groups and works IF AND ONLY WHEN THERE IS INCONSISTENCY BETWEEN SEVERAL RELEASES/EDITIONS/VERSIONS/ETC. » This sounds reasonable to me, and easy to apply too (follow cover unless covers disagree). I could live with that as well. \o/ Does this mean we have an agreement? \o/ Let's see. I've updated http://wiki.musicbrainz.org/User:Foolip/Capitalization_Standard_Vietnamese#Punctuation to say: If the cover includes space before punctuation (like in French) this should be preserved. If the punctuation style is inconsistent between releases, do not include space before punctuation in recording, release group or work titles. Tristan, is that phrasing acceptable to you? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-346. Style/Language/Vietnamese : Punctuation change
On Mon, May 14, 2012 at 9:58 AM, jesus2099 hta3s836gzac...@jetable.org wrote: UP http://musicbrainz.1054305.n4.nabble.com/RFC-346-Style-Language-Vietnamese-Punctuation-change-tp4226419p4557976.html So, Nikki, Nicolás, could this RFV be settled down and pass so we can eventually apply this compromise ? (3) Which compromise is it you want to apply? You didn't approve of the one I suggested and I'm not aware of any other. -- Philip Jägenstedt ___ 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
On Wed, May 2, 2012 at 7:28 PM, caller#6 meatbyproduct-musicbra...@yahoo.com wrote: Hi all, as discussed recently[1], there are a few problems with the logic of sort names. I'd like to identify them before starting in on a guideline revision. I haven't read all of the previous thread(s) on this topic so I'm not sure what kind of solution you're consider, but if you're looking for problems, Chinese artists have them. For Chinese, the sort name is in fact Latin-script name with added commas and is not at all useful for sorting. I have to set up Picard to use the artist name as the sort name, since Unicode order at least keeps similarly named artists together. Examples: These 3 artists with the same family name (周) end up in 3 different places because of the different romanization systems used on the mainland, in Taiwan and in Hong Kong: 周杰倫 Chou, Jay 周潤發 Chow, Yun-Fat 周迅 Zhou, Xun Here's a sample of groups with random sort order: 水木年华 Age of Water and Wood 壞女兒 Bad Daughter 黑名單工作室 Black List Studio 董事長樂團 Chairman 冷血动物 Cold Blooded Animal 冷酷仙境 Cold Fairyland 可米小子 Comic Boyz 深白色2人組 Deep White 飛輪海 Fahrenheit 鐵竹堂 Iron Bamboo 五月天 Mayday 南拳媽媽 Nan Quan Mama 自然捲 Natural Q 新裤子 New Pants 團契遊樂園 Playground 動力火車 Power Station 果味VC Super VC 超级市场 Supermarket 女子十二乐坊 Twelve Girls Band I image that any non-Latin script would have the same problems, at least those with multiple romanization systems or where the romanization does not produce the correct order anyway. -- Philip Jägenstedt ___ 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
On Sun, May 13, 2012 at 9:34 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Sun, May 13, 2012 at 10:25 AM, Philip Jägenstedt phi...@foolip.org wrote: On Wed, May 2, 2012 at 7:28 PM, caller#6 meatbyproduct-musicbra...@yahoo.com wrote: Hi all, as discussed recently[1], there are a few problems with the logic of sort names. I'd like to identify them before starting in on a guideline revision. I haven't read all of the previous thread(s) on this topic so I'm not sure what kind of solution you're consider, but if you're looking for problems, Chinese artists have them. For Chinese, the sort name is in fact Latin-script name with added commas and is not at all useful for sorting. I have to set up Picard to use the artist name as the sort name, since Unicode order at least keeps similarly named artists together. Examples: These 3 artists with the same family name (周) end up in 3 different places because of the different romanization systems used on the mainland, in Taiwan and in Hong Kong: 周杰倫 Chou, Jay 周潤發 Chow, Yun-Fat 周迅 Zhou, Xun Here's a sample of groups with random sort order: 水木年华 Age of Water and Wood 壞女兒 Bad Daughter 黑名單工作室 Black List Studio 董事長樂團 Chairman 冷血动物 Cold Blooded Animal 冷酷仙境 Cold Fairyland 可米小子 Comic Boyz 深白色2人組 Deep White 飛輪海 Fahrenheit 鐵竹堂 Iron Bamboo 五月天 Mayday 南拳媽媽 Nan Quan Mama 自然捲 Natural Q 新裤子 New Pants 團契遊樂園 Playground 動力火車 Power Station 果味VC Super VC 超级市场 Supermarket 女子十二乐坊 Twelve Girls Band I image that any non-Latin script would have the same problems, at least those with multiple romanization systems or where the romanization does not produce the correct order anyway. Philip: Language-based sorting should be possible once we release the schema change on Tuesday that will allow to set sortnames to aliases. Of course, Picard will need to be taught to use them, and they will need to be added manually, but it's a step in the right direction. (I mentioned it before but admittedly the thread is quite long now :) ) OK, I'll have to try that after the release and see if it helps. I wanted to test it on http://test.musicbrainz.org/ but bumped into http://tickets.musicbrainz.org/browse/MBS-4707 -- Philip Jägenstedt ___ 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
On Sun, May 13, 2012 at 10:12 AM, Nikki aei...@gmail.com wrote: I was wondering about that actually. How do Chinese speakers normally sort Chinese names? In the record stores in Beijing I've been I haven't been able to discern any particular order at all, things have instead been grouped by popularity, genre, record label and things like that. In HMV Singapore I remember that artists were sorted by their Hanyu Pinyin name, but still with Chinese artists separate from the non-Chinese. I don't remember what HMV in Hong Kong was like, but I was able to find things to buy! More generally, sorting in Chinese seems to be either by radical and stroke count (a traditional Chinese dictionary from Taiwan that I have) or by Hanyu Pinyin (my mainland simplified Chinese dictionary). However, both of these systems are only for sorting individual characters, sorting whole names using either system would still give the wrong result for characters that have the same romanization or same radical and stroke count. How about Japanese, are the sort names we have for those artists useful? -- Philip Jägenstedt ___ 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
On Sun, May 13, 2012 at 2:57 PM, Nikki aei...@gmail.com wrote: Philip Jägenstedt wrote: On Sun, May 13, 2012 at 10:12 AM, Nikki aei...@gmail.com wrote: In the record stores in Beijing I've been I haven't been able to discern any particular order at all, things have instead been grouped by popularity, genre, record label and things like that. In HMV Singapore I remember that artists were sorted by their Hanyu Pinyin name, but still with Chinese artists separate from the non-Chinese. I don't remember what HMV in Hong Kong was like, but I was able to find things to buy! More generally, sorting in Chinese seems to be either by radical and stroke count (a traditional Chinese dictionary from Taiwan that I have) or by Hanyu Pinyin (my mainland simplified Chinese dictionary). However, both of these systems are only for sorting individual characters, sorting whole names using either system would still give the wrong result for characters that have the same romanization or same radical and stroke count. Ah, interesting (and complicated!). What about on label sites? Japanese labels at least tend to have a sorted list of artists. Here are artist/music pages of some Taiwanese labels: http://www.jvrmusic.com/artist/ http://www.linfairrecords.com/music/index.php?type_id=1 http://www.bin-music.com/tw/ http://www.sonymusic.com.tw/pop.php AFAICT, artists simply aren't sorted by name at all, and I can't recall ever seeing a Chinese music site that uses sorting as a way of organizing things. As for music players, I suppose that people have learned to live with the Unicode sort order, at least I have by now... -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Allowing use of other databases
On Fri, May 11, 2012 at 2:16 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: +1 from me as well. (I can't think of any external applications possibly using the ibdb/iobdb ARs, so it should be fine to merge them IMO. Cool! So, people are OK with a whitelist? Then, let's see if we can agree on a first batch of pages to add to it. Let's add all the ones we think would be useful during the next two days or so to the preliminary list on http://wiki.musicbrainz.org/User:Reosarevok/Other_Databases After a couple days, I'll freeze the list and RFC for allowing the use of other databases - then if someone disagrees with a specific page I will drop it from the list (and it can be proposed separately in more detail and with better arguments later). Go add some! :) +1, and I added a link to http://isrc.ncl.edu.tw/ which I use all the time when editing Taiwan releases. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-346. Style/Language/Vietnamese : Punctuation change
On Sun, Apr 29, 2012 at 02:00, jesus2099 hta3s836gzac...@jetable.org wrote: UP http://musicbrainz.1054305.n4.nabble.com/RFC-346-Style-Language-Vietnamese-Punctuation-change-tp4226419p4557976.html So, Nikki, Nicolás, could this RFV be settled down and pass so we can eventually apply this compromise ? (2) If both of us find http://wiki.musicbrainz.org/User:Foolip/Capitalization_Standard_Vietnamese acceptable, can't we simply skip directly to RFC/RFV of that proposal? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Capitalization Standard Vietnamese (track/release titles)
http://wiki.musicbrainz.org/User:Foolip/Capitalization_Standard_Vietnamese I believe this would be the first guideline applying different rules to track and recording titles since RFC-333: Unify track/recording guidelines. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Should radio edit and similar go in recording title or annotation?
http://musicbrainz.org/edit/16971109 reminded me of this issue, which I haven't understood since the introduction of NGS. One the one hand, disambiguation comments aren't used for tagging (right?) so moving information there would produce some broken tags for people who use normalized tagging in Picard. On the other hand, disambiguation comments are shown in parenthesis after the titles everywhere on the website, which really invites moving some things in (parenthesis) to the disambiguation comments to make things look nice and tidy. http://musicbrainz.org/doc/Recording doesn't really provide any explicit guidance, only a broken link to Into the Blue (Beatmasters mix) ... -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Should radio edit and similar go in recording title or annotation?
On Mon, Apr 2, 2012 at 22:58, lorenz pressler l...@gmx.at wrote: Am 02.04.2012, 22:36 Uhr, schrieb Philip Jägenstedt phi...@foolip.org: http://musicbrainz.org/edit/16971109 reminded me of this issue, which I haven't understood since the introduction of NGS. One the one hand, disambiguation comments aren't used for tagging (right?) so moving information there would produce some broken tags for people who use normalized tagging in Picard. On the other hand, disambiguation comments are shown in parenthesis after the titles everywhere on the website, which really invites moving some things in (parenthesis) to the disambiguation comments to make things look nice and tidy. afair: recording - disamig. comment only tracklist - if its on the tracklist then it should be included in the trackname Is this documented anywhere, and is it how everyone is actually editing? Is no one using the recording-level data for tagging, or are you including disambiguation comments in all files to, well, disambiguate? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-102: Change Performance Relationship Type to Recording Relationship Type
On Wed, Mar 28, 2012 at 00:22, Nikki aei...@gmail.com wrote: Note that we're not allowed to rename relationships, so the actual name of the relationship type will need to remain as performance. The link phrases can be updated of course. Do you mean that the names in the XML Web service mustn't change, or even what the dropdown box in our UI says? If only a part of what is visible to users is changed I think that the inconsistency is worse than the problem it fixes. I really don't see the point in changing the class, but since I think we should get rid of the whole class concept (whatever it even is) anyway, I don't care enough to argue against it. Can you elaborate on this? Is it recordings we shouldn't have, or a separation between different kinds of recordings? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-102: Change Performance Relationship Type to Recording Relationship Type
On Wed, Mar 28, 2012 at 08:47, Nikki aei...@gmail.com wrote: Philip Jägenstedt wrote: On Wed, Mar 28, 2012 at 00:22, Nikki aei...@gmail.com wrote: Note that we're not allowed to rename relationships, so the actual name of the relationship type will need to remain as performance. The link phrases can be updated of course. Do you mean that the names in the XML Web service mustn't change, or even what the dropdown box in our UI says? If only a part of what is visible to users is changed I think that the inconsistency is worse than the problem it fixes. The former (the dropdowns use the link phrases, hence all the curly brackets). The name is shown on http://musicbrainz.org/admin/linktype/recording-work however. OK. I'm not sure I think changing the name partially is worth it, but I also don't care enough to argue about it. I really don't see the point in changing the class, but since I think we should get rid of the whole class concept (whatever it even is) anyway, I don't care enough to argue against it. Can you elaborate on this? Is it recordings we shouldn't have, or a separation between different kinds of recordings? Hmm? The class is just a category in the wiki with a special name. Oh, I thought you were talking about something about the schema. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Mixing simplified and traditional Chinese
If there are any editors familiar with Chinese on this list, please comment on http://musicbrainz.org/edit/13543534 and vote on http://musicbrainz.org/edit/16954814. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Featured artists: tracklists vs recordings
I was looking at http://musicbrainz.org/report/FeaturingRecordings and thought I'd fix a few of the Chinese cases, at the very end of the list. However, it turns out I really don't understand http://musicbrainz.org/doc/Style/Titles/Featured_artists and how to apply it to tracklists and recordings. Take http://musicbrainz.org/release/e6dd51ea-8ca4-4075-8338-055efff92b23 as an example, you can see the cover at http://goods.ruten.com.tw/item/show?21001190679297. The relevant track are listed on the cover as: Machi vs. 麻吉 Let it go vs. 蕭亞軒 分開旅行 vs. 劉若英 At the tracklist level, am I correct to assume that e.g. the 2nd of these should be normalized to have the title Let It Go and the artist 黃立行 vs. 蕭亞軒? At the recording level, do we normalize to use feat. as the join phrase there, or do we change it only if two releases disagree? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Featured artists: tracklists vs recordings
2012/3/5 Nicolás Tamargo de Eguren reosare...@gmail.com: Most people I know only normalise ft., featuring and the like to feat. - keeping with or vs. or any other credit like that untouched. OK, also at the recording level? I've done that to http://musicbrainz.org/release/e6dd51ea-8ca4-4075-8338-055efff92b23 with recordings now, but looking at http://musicbrainz.org/artist/f592fff4-b203-4cf9-9908-0c93c403564f/recordings I'm not sure I'd be impressed if the artist credits were a wild mix, but I guess I'll come back to that when it happens... -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-346. Style/Language/Vietnamese : Punctuation change
On Wed, Feb 29, 2012 at 15:35, Rupert Swarbrick rswarbr...@gmail.com wrote: jesus2099 Philip Jägenstedt wrote: ... lots. Guys, you have been discussing this for quite some time, frantically scoring points against each other and arguing that the other is not following a reputed source. You then both agreed that you should get input from a style leader. Nikki basically pointed out that this really doesn't matter to MusicBrainz: there are very few releases where the question makes any difference, and these have been de facto standardised. As such, your continuing discussion in this forum is off topic, as well as bitter and unpleasant. Maybe it's time to agree to disagree? Thank you for interrupting us. While this is the appropriate forum for RFC/RFV of style guidelines, I do apologize for the state of discourse. I have tried very hard to stay on topic and not do point-by-point replies for every detail I disagree with, but have not always succeeded. I believe that the references and studies I have documented will stand up to scrutiny by third parties and that the conclusion is clear. The RFV has gotten its V, so I will not reply further unless explicitly asked to do so by one of our style leaders. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-346. Style/Language/Vietnamese : Punctuation change
On Mon, Feb 27, 2012 at 18:06, Nikki aei...@gmail.com wrote: Philip Jägenstedt wrote: If deemed necessary, I can ask my wife (currently in Hanoi) to contact the ministry of education and ask what style is considered correct in higher education. It's possible that they don't know or care, of course. I leave it as an exercise to the reader to check what style they use on their website http://www.moet.gov.vn/. Although I suspect the answer is that they don't know or care, I would certainly be interested in knowing what they have to say about it, if she'd be willing to ask. Thanks for your feedback, Nikki, I've asked my wife to help me research this matter again. She does not think that the Ministry of Education would be able to help us determine offical-ness, since their mission is to teach Vietnamese, not regulate it. It is also not their mission to answer random questions from the public (my bad), so they're unlikely to escalate the issue to the required level to get a stamped official answer. However, she was able to find no less than 3 different style guides for Vietnamese, all explicitly requiring the no-spaces style: 1. http://du-an-most.hanoilug.org/MostWiki/QuyUocChinhTa#D.2BHqU-u_c.2BAOI-u This is from the Hanoi GNU/Linux Users Group. Judging by the references at the bottom, it is very well researched and trustworthy. 2. http://vi.wikipedia.org/wiki/Wikipedia:Cẩm_nang_về_cách_biên_soạn#D.E1.BA.A5u_c.C3.A2u When I last looked I couldn't find any official style of the Vietnamese Wikipedia, but here it is. That the many editors of the Vietnamese Wikipedia have collectively agreed on the issue is IMHO strong support for our current guideline. 3. http://hocmarketing.net/soan-thao-van-ban-chuan-viet-nam/ This is from marketing training material. I think that it doesn't have the weight of the two above sources, but it does show that marketing people (not only geeks) have also thought about the issue and come to the same conclusion. (http://www.tug.org/TUGboat/tb29-1/tb91thanh-vntex.pdf was also mentioned in the original RFC/RFV cycle, but it merely notes that the case without a space before punctuation is dominant.) There are not enough people who care to come to a majority decision about which way to standardise it. We have actually already standardized it, but you are correct that we cannot re-decide the issue by voting when only I and Tristan really care. There are not enough people who care about the issue to maintain the data according to such a guideline anyway. Given the small amount of data it only really takes one person. I have a script that I wrote after the guideline was originally accepted that finds instances in need of attention. There is not enough data affected to make standardisation particularly useful right now. The data we have is already in line with the guideline we have, with only 1 exception found by my script: http://musicbrainz.org/release/0c7c63b8-d9dd-4713-ac69-33204f2b419d Therefore I think the best choice right now is a compromise, i.e. to allow both forms, which is effectively what this proposal is. If the authorities in Vietnam ever publish an official style (something which explicitly talks about how to write punctuation) or if we ever have a community of Vietnamese editors who care about which style should be used, then that would be a better time to revisit it. Given that our guideline is supported by ample evidence and now 3 actual Vietnamese style guides, I don't think that we should weaken it. Should we eventually decide more generally to retain variations in capitalization, typos and punctuation in tracklists then things may be different, but for standardized titles the guideline we have is as correct as it will ever be on this issue, IMHO. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-346. Style/Language/Vietnamese : Punctuation change
On Fri, Feb 24, 2012 at 19:47, jesus2099 hta3s836gzac...@jetable.org wrote: Philip Jägenstedt wrote To clarify for everyone who wasn't around, you did not participate in the original RFC/RFV cycle, but did object after the fact I note that you are quite blatant not fair play here pretending I did not participate as you recognized I was the only one to have done so! The history of the issue is available for everyone to inspect, so this accusation carries little weight. There has been no foul play, so let's just focus on the actual issue. Philip Jägenstedt wrote I don't understand what much more official means More official means more official. My pics are from schoolbooks and from governamental propaganda. Here is a new one if you want from this month in south AN TOÀN GIAO THÔNG HẠNH PHÚC CỦA MỌI NHÀ ! (lol) http://i.imgur.com/Ybtcu.jpg There are plenty of schoolbook examples in http://wiki.musicbrainz.org/Talk:Style/Language/Vietnamese#From_an_Hanoi_Book_Store If I were still in Hanoi I could go out and find more examples of the no-spaces style in printed government materials, but I doubt that would convince you. No one is disputing that the French style can still be found, I'm just disputing that it's any more official. Philip Jägenstedt wrote every single item with print (mostly food) that I have brought back uses English style punctuation. If you want food, here you go (coffee, from my crappy phone camera) http://i.imgur.com/akneU.jpg http://i.imgur.com/RH2Sv.jpg Here are the 10 food items I found in my bag: http://wiki.musicbrainz.org/Talk:Style/Language/Vietnamese#From_food_items As with the other 3 random-ish samples that I have taken, the no-space style comes out on top, this time by a very large margin. Philip Jägenstedt wrote the evidence collected in http://wiki.musicbrainz.org/Talk:Style/Language/Vietnamese clearly show that both styles have been used in teaching materials, by the same publisher even. I suspect (but cannot prove) that spaces are used more often in materials for younger students for clarity. The only such picture (B2) is unfortunately missing. :p No, there are plenty of pictures of teaching materials at the given link, some of them from the publisher in question. Philip Jägenstedt wrote Consistency is, IMHO, one of the most valuable aspects of the MB Absolutely no need to be zealous for just a handful of tracks. Are the english used in Japanese releases consistent ? no ? does anyone die from that ? If you think arguing by analogy of http://wiki.musicbrainz.org/Capitalization_Standard/Japanese_Releases_Clarification is useful, why aren't you suggesting that the capitalization of Vietnamese releases be preserved as well? Philip Jägenstedt wrote Practically, if you and I look at the same cover scan and have different preferences, in 20% of the cases we will disagree if there is a space there or not. Is it so difficult to see a space ? or a no space ? be serious, please. Just forget of anything like narrow space etc. It’s just a matter of SPACE=YES or SPACE=NO, OK ? If you input SPACE I don’t care it’s not another sort of space. It’s what’s already done in french. I don't know why you think I'm not being serious. How should edit conflicts be resolved when one editor sees a half-width space and the other just sees glyph kerning? This *will* happen if the Vietnamese artists get enough attention from editors with opposite preferences. END OF THE OFF TOPIC CRAP Being abusive does not help your case. This is an english style no-spaces country → we see less than 5% of spaces before punctuation (not the case here). We see many spaces (more than half, and majority in official stuff) and many no-spaces (I say some) → this is not an english style no-spaces country In any random sample I have taken the results have been clear: no-spaces is the dominant style. THE RFV IS NOT VETOED AS FAR AS I AM CONCERNED. If a style leader could now confirm or infirm this, thanks. I am also looking forward to hearing from our style leader, and suggest that we stop this thread until that time. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-346. Style/Language/Vietnamese : Punctuation change
On Thu, Dec 22, 2011 at 20:38, jesus2099 hta3s836gzac...@jetable.org wrote: (sorry for my possibly awful English below) I’d like to refine last change for the Vietnamese guideline page, specifically the punctuation part of it. I object to this. From the last time this was discussed, it was fairly obvious (to me) that the English style is by a large margin the biggest both in print and online. See http://wiki.musicbrainz.org/Talk:Style/Language/Vietnamese#Reference_.28no_space.29 Having just come back from vacation in Hanoi (thus the slow reply) I can say (anecdotally) that every single item with print (mostly food) that I have brought back uses English style punctuation. I don't think it's feasible to defer to the cover for something that is so hard to judge: how much space before the punctuation is enough to justify a half-width space? The result will simply be inconsistent, with most track lists not being vetted against a cover and editors just picking the style they prefer. There is a very simple solution to this, similar to the capitalization problem: Use a Picard plugin to convert to the style you prefer while leaving the database internally consistent and consistent with common usage. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Arrange on works
On Tue, Aug 30, 2011 at 18:22, jesus2099 hta3s836gzac...@jetable.org wrote: So, in decreasing order : 1. It seems several people agree on dangers of putting arrange links on works*. 2. It seems some people would like something more complex than either work or recording links. 3. It seems a few remaining people agree on linking arrange to works. What do you think of a RFC for 1. that could be quickly applied to prevent any more damage then letting 2.’s people discuss of a better (?) or more detailed (complex?) solution. We could also make a RFC asking for orchestration on recordings, for the same reasons. * To sum up the “dangers” : A referenced artist-recording arrange link will always be correct while a, once referenced, artist-work arrange link will become incorrect on later added recordings (other versions, covers, lives, etc.). I would support an RFC to remove the arrangement AR for works, as it seems very prone to incorrect use. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Arrange on works
On Tue, Aug 30, 2011 at 22:45, Rupert Swarbrick rswarbr...@gmail.com wrote: Philip Jägenstedt phi...@foolip.org writes: I would support an RFC to remove the arrangement AR for works, as it seems very prone to incorrect use. Ok, but do you have a candidate for how to express This version of Mussorgsky's Pictures at an Exhibition is the one arranged by Ravel? Surely this is the basic and simple case we still would like to be able to express. Otherwise we have the ugly situation where a work like Bach's Air from his suite in G (IIRC) is performed by everyone from Barenboim to Procol Harum... I'd suggest handling it the same way as one would any pair of works that have the same title, composer and lyricist but still are distinctive enough to be separate works -- using disambiguation comments and annotations. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Arrange on works
On Tue, Aug 30, 2011 at 23:15, SwissChris swissch...@gmail.com wrote: On Tue, Aug 30, 2011 at 10:45 PM, Rupert Swarbrick rswarbr...@gmail.com wrote: Philip Jägenstedt phi...@foolip.org writes: On Tue, Aug 30, 2011 at 18:22, jesus2099 hta3s836gzac...@jetable.org wrote: So, in decreasing order : 1. It seems several people agree on dangers of putting arrange links on works*. 2. It seems some people would like something more complex than either work or recording links. 3. It seems a few remaining people agree on linking arrange to works. What do you think of a RFC for 1. that could be quickly applied to prevent any more damage then letting 2.’s people discuss of a better (?) or more detailed (complex?) solution. We could also make a RFC asking for orchestration on recordings, for the same reasons. * To sum up the “dangers” : A referenced artist-recording arrange link will always be correct while a, once referenced, artist-work arrange link will become incorrect on later added recordings (other versions, covers, lives, etc.). I would support an RFC to remove the arrangement AR for works, as it seems very prone to incorrect use. Ok, but do you have a candidate for how to express This version of Mussorgsky's Pictures at an Exhibition is the one arranged by Ravel? Surely this is the basic and simple case we still would like to be able to express. Otherwise we have the ugly situation where a work like Bach's Air from his suite in G (IIRC) is performed by everyone from Barenboim to Procol Harum... As said before the easiest solution would be to keep the Arrange Relation on works (it is really needed for some classical arrangements like the above – and maybe for a few in other genres), but to allow it only when you can prove that the same specific arrangement is used by at least two different recordings (by different performers). All other arrangements should be kept at recoding level. And the orchestration links should probably be treated the same way. This would at least prevent wrong work level relationships until we eventually come up with a better solution. Would changing the voting requirement to be similar to changing the quality level (failing by default) be an acceptable compromise? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] I think Arrange on works were allowed too quickly without proper thinking
On Sat, Aug 20, 2011 at 01:24, jesus2099 hta3s836gzac...@jetable.org wrote: I think Arrange on works were allowed too quickly without proper thinking Without having read the threads that led up to that change, I have to agree. What is the use case for arrangement ARs on the work level? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-333: Unify track/recording guidelines
2011/8/6 Lukáš Lalinský lalin...@gmail.com: It's been more than a week since the RFC and to my surprise there has been only one negative feedback, which I don't think is justifiable, because it ignores the basic problems that motivated me to propose these changes, which I mentioned in the initial email. All MB editors I know, except for jesus2099, agree with these changes. So, considering the +1s I got on the ML, here is the RFV. You can read the original threads here: http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/11600 (my random thoughts) http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/11724 (RFC) To summarize the changes, the style guidelines that we now have for recording and release group titles will apply also to track and release titles. 1) Style guidelines discussing track and release titles will be removed. http://wiki.musicbrainz.org/Style/Track_and_release_titles 2) Style guidelines discussing recording and release group titles will be changed to just titles as they refer to all titles we have in the database. I'd prefer to rename the wiki page to Style/Titles. http://wiki.musicbrainz.org/Style/Recording_and_release_group_titles +1 for giving up on the exactly as on cover approach. I haven't read all of the original thread, so apologies if these questions have been answered: 1. Will this RFV also add guidelines for what ETI should be included in track titles but not in release titles? 2. Do you intend to submit a feature request for applying edits to both track and recording simultaneously, in the rather common case of fixing a typo or capitalization that applies to both? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-333: Unify track/recording guidelines
On Sat, Aug 6, 2011 at 11:39, Andii Hughes gnu_and...@member.fsf.org wrote: On 6 August 2011 10:09, Philip Jägenstedt phi...@foolip.org wrote: 1. Will this RFV also add guidelines for what ETI should be included in track titles but not in release titles? Can you give an example of this? As Lukáš pointed out, I meant recording titles, not release titles. An example I edited yesterday is http://musicbrainz.org/release/e84a413a-8daa-4d8e-b01f-31a0f215e9d7 On track 5, the cover says (translated) theme song of 2003 Solar Project. Other typical examples would be commercial for X or from film X. These kinds of things can make sense in context for compilations of commercial tunes or songs from films, but are not part of the proper title. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-326: Add Artist Type Other
On Mon, Jul 11, 2011 at 22:02, Johannes Weißl jar...@molb.org wrote: Hello list, I propose to add Other to the list of artist types [1]. Many artists don't fit into the Group/Person scheme, e.g.: 1. Some fictional characters (animals, mythical creatures, ...) 2. Some fictional artists that are purely created to keep a series together 3. Companies that were created to credit them in a relationship, but that are not labels There are probably more categories. Because all of them are pretty rare compared to Person/Group and are not really in the focus of this database, I suggest a catch-all type Other for them. Using Unknown is not a really good alternative, because 1. Searching for Unknown artists should only show artists where further research will eventually result in another type 2. Unknown artists can be changed to any type as auto-edit, so if someone wants to leave an artist Unknown on purpose, anybody can change the type without vote Wiki page: http://wiki.musicbrainz.org/Proposal:Artist_Type_Other Expiration date: Mon, 18 Jul 2011 20:00 UTC This RFC is inspired by all the recent RFCs (empty barcode, empty Cat.Nr.), that allow us to differentiate between unknown/blank and none/other. [1] http://wiki.musicbrainz.org/Artist_Type Sounds good, I guess we'd make most special purpose artists into other. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Use of recording comment
On Thu, Jul 7, 2011 at 07:49, Aurélien Mino a.m...@free.fr wrote: On 07/07/2011 01:36 AM, Alex Mauer wrote: I for one would move the following to the comment, or in some cases possibly to the work. It’s a pretty big list… * radio/single/album/studio/single/TV/film/acoustic/abridged/extended/long/short/long/revised/alternate/alternative/revised version/edit * [Language] version * [instrument] version * [performing cast] version * alternate version (many need further disambiguation as well) * alternative version * demo version * Orchestral version * instrumental version * [format] version (12-inch/LP/gramophone version, etc.) * [adjective] take (alternate, early, out, etc.) * [adjective] mix (not referring to a remix but to an alternative audio mixing arrangement) * version [number] +1 This is exactly how I'm editing since NGS release. Would anyone editing along these lines we willing to try writing it up in a guideline? IMO, this list is big enough that people, by looking at the data, will conclude that effectively anything in brackets should be moved to the comment. Because comments can contain basically anything, I certainly don't consider it part of a normalized title, just like for artists. I'll be voting no on edits like this where I come across them until there's a style guideline in place. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Use of recording comment
On Thu, Jul 7, 2011 at 16:20, Alex Mauer ha...@hawkesnest.net wrote: On 7/7/2011 3:47 AM, Andii Hughes wrote: If it was decided that the comment was to *only* be used for ETI data, I could live with it. Though it means a large number of users will have to move this data back into the title for tagging, it solves the parsing problem of distinguishing ETI from the main title. But that only works if the comment is just for that or a new ETI field is introduced. If the comment remains an undefined freeform field for any text, it shouldn't be used for ETI data as it presents a nightmare for those of us who want to keep this useful title information distinct from random comments. Is there some misunderstanding as to the purpose of the comment field? It's not a place to put random information like 'this is the best track on the album' or something. The problem is when it's used for disambiguating recordings which didn't have any ETI on the cover. A common case is where one release is missing the intro. It's not at all helpful to see (with intro) or (without intro) in your tags. The same goes for remasters, you certainly don't want (2004 remaster) on every single track of a remaster. So, while not exactly being random information, the comments will contain information which doesn't belong in tags, normalized or otherwise. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Use of recording comment
On Thu, Jul 7, 2011 at 19:19, Alex Mauer ha...@hawkesnest.net wrote: On 2011-07-07 1:27, Philip Jägenstedt wrote: Would anyone editing along these lines we willing to try writing it up in a guideline? IMO, this list is big enough that people, by looking at the data, will conclude that effectively anything in brackets should be moved to the comment. I'll give it a shot: No artist's Recordings tab should list the same title twice with no disambiguation comment. If an artist has multiple recordings with the same title, and any release on which one of them appears lists the title with no Extra Title Information, the disambiguation comment should use the most prevalent Extra Title Information. If no ETI is prevalent, pick one. If no ETI is available, use the best information you have to disambiguate. This doesn't sound all too crazy. By this standard, I think that http://musicbrainz.org/edit/14779672 is correct but I'm not sure about http://musicbrainz.org/edit/14779686 and http://musicbrainz.org/edit/14779684 Is it your intention that if a recording has been released on a crappy compilation with ETI omitted which are on all releases closer to the artist, that ETI still be left out of the recording title? How about a compilation released by the artists own label? Making this kind of distinction kind of tricky. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Use of recording comment
On Fri, Jul 8, 2011 at 00:33, Alex Mauer ha...@hawkesnest.net wrote: On 2011-07-07 16:17, Philip Jägenstedt wrote: On Thu, Jul 7, 2011 at 19:19, Alex Mauerha...@hawkesnest.net wrote: I'll give it a shot: No artist's Recordings tab should list the same title twice with no disambiguation comment. If an artist has multiple recordings with the same title, and any release on which one of them appears lists the title with no Extra Title Information, the disambiguation comment should use the most prevalent Extra Title Information. If no ETI is prevalent, pick one. If no ETI is available, use the best information you have to disambiguate. This doesn't sound all too crazy. By this standard, I think that http://musicbrainz.org/edit/14779672 is correct but I'm not sure about http://musicbrainz.org/edit/14779686 and http://musicbrainz.org/edit/14779684 Agreed. I've cancelled the latter two. Is it your intention that if a recording has been released on a crappy compilation with ETI omitted which are on all releases closer to the artist, that ETI still be left out of the recording title? How about a compilation released by the artists own label? Making this kind of distinction kind of tricky. Well, without concrete examples based on artists whose recordings have been fully cleaned up and merged it's a little hard to say for sure. The only artist I'm that confident of is Jonathan Coulton, and he doesn't have any weird compilations like you mention, so that doesn't help. Also, I think the use cases for tagging from various combinations of (tracklist/recording/recording comment/work/work comment) are yet to be developed and we may need to wait for that before it can be said for sure whether this guideline works perfectly or needs some tweaking. Examples: http://musicbrainz.org/recording/ab0a495f-39da-4479-abad-ba38d91ce1ea http://musicbrainz.org/recording/1c323012-2d65-47ce-a4a6-8a311b690806 http://musicbrainz.org/recording/34c08851-9517-4150-9622-6166d4403d0b http://musicbrainz.org/recording/1c28de94-4fe3-4c95-a64d-0077ea1a85a7 These are just cross-faded slightly different. crickets and dogs is something I made up, since on the compilation cover there was no indication that it is different. (I think it may even have the same ISRC.) http://musicbrainz.org/recording/7579eb21-0752-4b82-ae5a-d1436353835b http://musicbrainz.org/recording/42839cb5-d7cd-445f-918d-29fb1538a0cb A similar situation, I had to make something up (“醬油又沒啦”版) just for disambiguation. http://musicbrainz.org/recording/3b2a8867-8e8e-4496-93c0-beeace04fe2f http://musicbrainz.org/recording/634189b1-9195-4372-8053-a02bbcb09a8b Again, shorter cut was something I had to pull out of my hat. http://musicbrainz.org/recording/d8a9d8a2-3768-4481-9d6e-f7e81497feda http://musicbrainz.org/recording/1198c4e3-d2b3-45b5-b8a7-8ca8cebe1481 More of the same. These are examples from a single artist that I spent time listening to while cleaning up. This kind of situation is probably more common than one would think. I don't have examples of crappy compilations, but assume there are plenty of them. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Use of recording comment
http://musicbrainz.org/edit/14779672 Right after NGS went live went live I made a few edits like this myself, but soon stopped because it seems to be destroying information for tagging. In the case where you have multiple recordings of the same song that were never decorated with (new version) or similar on the cover, we're going to have to make something up as a disambiguation comment. In such a case, I certainly would not want to see that comment in my normalized tag. How are others using the recording comment? I consider it just like the artist and release comments, i.e. something not covered by strict guidelines for disambiguation purposes only, not for tagging. http://musicbrainz.org/doc/Style/Recording does not provide any guidance. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Adding pirated download links to releases as can be downloaded for free from... relationships
On Tue, Jul 5, 2011 at 05:35, Magda Stremeski magda.streme...@gmail.com wrote: Hi all, I'm having a debate right now about how appropriate it is to add links to releases that tell a user where the release can be downloaded from. Edits in question: http://musicbrainz.org/edit/14739612 http://musicbrainz.org/edit/14739579 and a few others that have to do with the soundtracks of LucasArts computer games. The games never had an official soundtrack release. Some people created high quality rips of the soundtrack direct from the game and uploaded the bootleg. So, without a doubt, these are unofficial releases - bootlegs. This is not being contested. I'm OK with these releases being on MB (although there are other outstanding questions like, what is the real song title? But that aside...) It's more to do with the URLs being attached to the releases. MusicBrainz clearly states on its About page: Copyright infringement MusicBrainz provides data about recordings, not the music itself. MusicBrainz does not condone copyright infringement and will not help you find a place to illegally download copyrighted works. Regarding copyright infringement, I've heard (could be wrong) that the only way someone could get away with bootlegging content is as a protest because that content was not available legally. So it's possible that these bootlegs could be considered as protests. However, given that LucasArts has asked this bootlegger to takedown all the Star Wars and Indiana Jones soundtrack content, then maybe this is just out and out copyright infringement after all (forum link here this is discussed in edit). The bootlegger claims (although hasn't offered any evidence) that LucasArts was okay with him distributing these soundtrack files, so long as it wasn't Star Wars or Indiana Jones content. I think that makes it clear then that this *is* copyright infringing material but FOR NOW, LucasArts have chosen not to fight it. I voted to have these links removed. The editor in question has suggested that because LucasArts hasn't taken it down, then these links are okay. I'm not convinced, especially since games like Sam Max and Monkey Island are now being remade by another company - Telltale Games, who ARE actually releasing official soundtracks for their games. These soundtracks obviously have some of the same songs (the theme songs in particular). While LucasArts may have been okay about the distribution in the past, we don't know that Telltale will be, or that LucasArts won't change their mind. I think that MusicBrainz risks legal action for providing links to bootlegged material (isn't this partly why we are against copyright infringement in the About page?). I don't think this risk is worth it, just for having complete metadata about a release. I think this risk is still there, even if LucasArts has not actively pursued the original bootlegger. I'd like some comments from the community - do you agree with what I said in the last paragraph? Would content like this still count as copyright infringing material and if so, does MusicBrainz's rule about never condoning or helping find such material still apply? The editor seems quite keen to have me change my vote to No or Abstain. The edit is valid for another week. I'm hesitant to let this edit pass so can we discuss this soon please? Thanks, Magda If it were a link to a crappy torrent site that is going to be dead in just a few months I'd agree that such links are not appropriate. However, in this case it appears to be fan sites, and I don't think MusicBrainz needs to worry about the legality of the things it links to, only that which it hosts. If someone complains it's easy to remove the links again. so I'm voting yes to these edits. -- Philip Jägenstedt ___ 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
On Thu, Jun 16, 2011 at 12:53, Piotr Szotkowski chast...@chastell.net wrote: Yeah, me again. Still most grateful fot MusicBrainz. :) While I was on a recent Picard-powered metadata-cleanup spree on my music I noticed http://musicbrainz.org/doc/Style/Miscellaneous saying that ‘typographically-correct punctuation is preferred’, so I started updating MB with my local fixes to punctuation (such as replacing U+0027 APOSTROPHE with U+2019 RIGHT SINGLE QUOTATION MARK). Is this welcome or just a noise to the MB database? If it’s welcome, how far should it be taken? Replacing U+0027 with U+2019 (where appropriate) seems to fit the spirit of the guide, but what about replacing U+002D HYPHEN-MINUS with U+2010 HYPHEN, such as in renaming Ska-P to Ska‐P and New York Ska-Jazzi Ensemble to New York Ska‐Jazz Ensemble? 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. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: volume numbers normalization only for release groups
All the discussion happened in another thread and was all over the place. We seem to have very divergent ideas about what kind of normalization we're going to have in NGS. I could go ahead and push in the direction I think we should be going, but I fear the end result will be horribly inconsistent as some ideas go through and some do not. I think what we really need to make any sense of NGS is a rough consensus on the overall normalization scheme, and have that first codified in http://wiki.musicbrainz.org/Style/Principle or some other central place. Philip On Sun, Jun 12, 2011 at 06:11, Nikki aei...@gmail.com wrote: It's been more than a week, you can send an RFV now. Nikki Philip Jägenstedt wrote: http://wiki.musicbrainz.org/User:Foolip/Volume_numbers See the editing history for a clear diff. The essence of the change is to not normalize the release titles at all, only the release group titles. This is a similar split to track/recording. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Normalization of release-level data NGS
After loads of editing and discussion on this list since NGS started I still can't see any clear direction. People have very divergent ideas about what we should make of NGS, and the style guidelines aren't providing much guidance. Before diving into improving small parts of the puzzle I think we really need to reach some kind of conclusion about what level of normalization we want and where. Points to consider: * difficulty of entering new releases in line with the guidelines * for a huge portion of our data, we will never have the chance to see the cover again, so it will remain as it is now (normalized) * usefulness of the data for tagging The point where people seem to disagree most is the release-level data: release titles, track titles and track artists. For the purposes of discussion, I'll make an initial no normalization suggestion to work from: Release-level data should be entered as close as possible to what is on the release. All captialization should be preserved. All typos should be preserved. Anything written in proximity to the track title should be entered, no matter how long-winded or irrelevant. Track artists should only diverge from the release artist if there is a clear split between titles and artists on the cover and the way the artist is credited can be recreated exactly with an artist credit. Otherwise, the artist should be part of the track title. http://wiki.musicbrainz.org/Style/Principle needs to be rewritten for NGS, since there can't possibly be artist intent for both the release level and the recording/work levels. I'm suggesting (in a devil's advocate kind of way) that it updated to define release-level data and say that No normalization whatsoever should be applied to release-level data. Now, please disagree, and tell me what we should do instead. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] feat. style and track/recording artist
On Thu, Jun 9, 2011 at 12:10, Kuno Woudt k...@frob.nl wrote: Hello, On 05/06/11 21:06, Philip Jägenstedt wrote: 2011/6/5 Nicolás Tamargo de Egurenreosare...@gmail.com: The problem is in interpreting the cover. What is the distinction between an artist being mentioned in a comment on the sleeve and being credited as an artist. Consider these (fictional) examples: * Song A (feat. Artist Y) * Song A (Artist X + Artist Y) * Song A (rap by Artist X) * Song A (Artist X on keyboard) * Song A (Artist X合唱) How is one supposed to create a combined artist credit in the last 3 cases? There needn't be much difference between the nature of the collaborations in these examples, just a difference in how it's presented on the cover. The 'rap by' and 'on keyboard' examples are basically relationships. The track title retains how they are credited on the cover, for recording I think those should not appear on either the recording title or the artist credit, they should just be relationships. Alternatively, add the relationships but still credit those artists in the artist credits, example: on cover: Song A (Artist X on keyboard) - Artist Y recording title: Song A artist credit: Artist Y, Artist X relationship: Artist X performs keyboard on Song A Again, I see no need to retain the 'rap by' or 'on keyboard' in either recording title or artist credit when we have a good relationships for that information. The other examples seem quite suitable for artist credits already. Normalizing on the recording level sounds perfectly reasonable, no argument there. It also sounds like you're agreeing (in this case at least) that the parts in parenthesis should be left in the track titles. I guess you'd want to normalize capitalization as well, I'm really not sure about that bit... -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] feat. style and track/recording artist
On Thu, Jun 9, 2011 at 20:07, Philip Jägenstedt phi...@foolip.org wrote: I guess you'd want to normalize capitalization as well, I'm really not sure about that bit... Disregard that bit, I think it's luks that's been arguing for that :) -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Artist sort name for a fairly special case
On Thu, Jun 9, 2011 at 20:47, Nikki aei...@gmail.com wrote: Philip Jägenstedt wrote: IMO, the sortname is useless for non-Latin scripts, or at least for Chinese. In order to get anything like a sane sorting you'd have to use the same transliteration system (say Hanyu Pinyin) for all artists, but that makes no sense for Hong Kong artists whose native names are in Cantonese, not Mandarin. Even if you did consistently apply Hanyu Pinyin, you'd still get the surnames 张 and 章 mixed together. I completely agree, which is why I opened http://tickets.musicbrainz.org/browse/MBS-1485 some time ago. By the way, how are Chinese names normally sorted? There appears to be several methods. At the HMV in Singapore the records were sorted alphabetically by their pinyin transliterations. In record stores I've been to in Beijing there's no obvious order at all, but I could be mistaken. There are a few different ways to order Chinese dictionaries as well (e.g. by radical/stroke count) so I assume one could use that also. I just use the Unicode order, which is completely random but still possible to memorize where some common characters tend to end up... -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] VolumeNumberStyle in NGS?
On Wed, Jun 8, 2011 at 01:56, StoneyBoh js...@mindless.com wrote: Release groups are a little less clear on their benefits. They are basically containers, which are required to organize the data, but don't normally provide too much additional information in and of themselves. That is why it seems strange to me that we would split the normalization rules to apply to release groups but not releases. That seems like a very arbitrary distinction to me. In that instance, I would think whatever we decide on normalization, it should apply to releases and release groups - just my opinion. Of course, that leaves the possibility that different releases within a group will have different what's on the covers, and thus make it difficult to determine what to call the release group. That's another reason why my preference would be to maintain the normalization across the board... If you look at http://bayimg.com/faIfhAAdi it's quite clear that the plan for Picard is to offer As on cover or Normalized for both tracks, artists and the release. For the artist and tracks, it's quite clear where this data should come from. However, for the releases, the only place this distinction should come from is between release groups and releases. As with most things, my motivation for wanting this is Chinese and Swedish releases. When they use something like Release VOL. 2 on the cover, it's very unnatural (IMO) to expand that to Release, Volume 2 as the English looks foreign and weird in this context. It is of course a problem with any change to stop normalizing on a certain level that the vast majority of our data will remain as it is essentially forever, making it just seem inconsistent when some releases are normalized and others are not. I'm not sure how to weigh this against the hypothetical I want it exactly as on the cover user. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Artist sort name for a fairly special case
2011/6/8 Yin Izanami yind...@gmail.com: The artist AAA is literally and physically sorted as TORIPURU-EE / Triple A in Japan. You can see this in Japanese bookstores and on avexnet's listing of all its artists - it is sorted under the TO character, not A or E or the like. I realize artist sort name is not supposed to be used for pronunciation, and AAA is also already in Latin script. However, this would not be the first time that the artist name and sort name don't actually say the same thing - for example, 蔡宜翎 (Tsai Yi Ling) is sorted as Tsai, Jolin 周杰倫 (Chou Jie Lin) is sorted as simply Chou, Jay, with no indication of the 3rd character. If you agree / disagree with this sortname doesn't match Latin-for-Latin to the artist name, then I'd like to hear what others think about it. http://musicbrainz.org/edit/14592861 is the edit to vote on, everyone. Quoting from http://wiki.musicbrainz.org/Sortname_Style All artist sort names should be in Latin script. If the artist's name is normally written using a non-Latin script, use the Latin script translated or transliterated name by which the artist is most commonly known. This is why many Chinese artists have sortnames that aren't transcriptions. Both Jolin Tsai and Jay Chou are the names used by the artists themselves in some contexts. IMO, the sortname is useless for non-Latin scripts, or at least for Chinese. In order to get anything like a sane sorting you'd have to use the same transliteration system (say Hanyu Pinyin) for all artists, but that makes no sense for Hong Kong artists whose native names are in Cantonese, not Mandarin. Even if you did consistently apply Hanyu Pinyin, you'd still get the surnames 张 and 章 mixed together. I assume that the sortname is equally useless for sorting Japanese artists (who must also have same-sounding but different surnames), so it's not really worthwhile trying to get canonical Japanese sorting using MusicBrainz. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] feat. style and track/recording artist
2011/6/6 Nicolás Tamargo de Eguren reosare...@gmail.com: On Tue, Jun 7, 2011 at 12:24 AM, Philip Jägenstedt phi...@foolip.org wrote: 2011/6/6 Nicolás Tamargo de Eguren reosare...@gmail.com: On Tue, Jun 7, 2011 at 12:06 AM, Philip Jägenstedt phi...@foolip.org wrote: On Mon, Jun 6, 2011 at 22:45, Simon Austin chi...@auzsoft.net wrote: Contraiwise NGS also added a split between recording and track title, with the ability to standardise the recording title and make the track title more like the cover. The cover for Basement Jaxx's Kish Kash is practically a blueprint for the old Track (feat. Person) style http://www.discogs.com/viewimages?release=189933 but recent edits have made all the track and recording titles into Track by Basement Jaxx feat. Person. http://musicbrainz.org/release/242e5f1c-2755-3217-ad0d-f9b1b5652b15 Huh. I haven't seen the cover of that release, but I'm fairly certain I wouldn't want it that way. Moving the feat. phrasing to the artist field only works in extremely simple cases, I can't see how one would move it to the track artist in a situation like this while still staying true to the cover: 1. Song A (Featuring Dudeson) 2. Song E (rap by Tyra) 3. Bla bla (Artist A + Artist B) You wouldn't, not in the tracks (except maybe for 3). You would if the cover said Artist A feat. B - Song A, which is pretty common. Moving the artist of only track 3 would certainly look inconsistent in a case like this. Would the criteria be that the release artist is mentioned again at the track list? It's rather random if Artist A is mentioned again or not at the track level on a release by Artist A. (I assume it's rather uncommon, because it's redundant.) It might be uncommon (on one artist releases, it is quite common on compilations) but I've seen it several times in electronic music and hip hop. Sure, every possible mutation appears in the wild somewhere :) Do you have an example of such a cover that we could look at? Perhaps the result wouldn't be the weird inconsistent mess that I expect. Or perhaps you could weight in on this release I added yesterday: http://musicbrainz.org/release/a0626e29-8f5d-4a58-a343-836c42209a15 The tracklist is now exactly as it appears on the cover/disc. Clearly a distinction has been made between featuring and duet with. Do you think that any of these should be moved to the artist credit on the track level? How would you format the artist credit on the recording level? (I've already done something here, please consider the question without looking at what I've done.) Whatever rules we come up with for the track level, they must be simple enough that most editors would get it right by guessing, because it's impossible to verify it without the physical release or a cover scan. It's good that we might be getting cover scans soon, then. But I'd say follow the cover is the simplest rule ever: if the cover says A + B, A feat. B, whatever, then use that. If it says Track (with B), Track (feat. B), then use that. I'm sure it could go wrong, but it seems quite simple… Are we getting a cover scan feature? Do you have more information about this? That would be extremely helpful for proof-reading edits. In the area that I edit the most (Chinese) the main artist mentioned again rule doesn't really seem very simple. Often you'll see things in parenthesis like hot new duet between Main Artist and Featured Artist. That seems impossible to convert to a artist credit. I guess what I'm leaning towards is that unless the cover is clearly and consistently split between artist names and track title, then the artist should be the release artist and everything else should go into the track title. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] feat. style and track/recording artist
On Tue, Jun 7, 2011 at 15:12, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: On 7 June 2011 08:04, lorenz pressler l...@gmx.at wrote: i think in your edit-discussion you came to an agreeable solution for a future guideline. - on recording lvl: move all (feat. X) to artist credits - on release lvl: as close to cover/sleeve as possible (feat. X in tracktitel included) imho it's a pity not to use these new artists credit possibilities on tracklvl (since i think the feat. is only appended to the trackname on covers since there is normally no artist column; it is written in smaller letters though most of the time to indicate its separation from the tracktitel) but i guess the above would make most people happy? No, the final decision was to have: Where have decisions been made? If there are already answers for these issues, please point to them! On recording: The featured artist properly credited as an artist credit with the feat. join string. So X (feat.Y) by Z becomes X by Z feat. Y On tracklistings: Retain the previous feat. style for now to retain backwards compatibility. ws/1 (the old web service layer from pre-NGS still used by most clients) exposes the artist name at track level, not recording level. So recording level changes won't affect ws/1 but track level changes will, and use of feat. artist credits there would cause the creation of new pseudo-feat. artists for external data users, exactly what feat. artist style tried to avoid. The intention is to eventually follow the cover at tracklist level and have artist credits where appropriate, but at present this would mess up ws/1 users who haven't yet adapted to NGS, a change which is still under a month old. Is this your personal opinion, or have is there actually a policy or style guideline to back this up? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Tagger Script documentation
Google first brought me to http://musicbrainz.org/doc/Tagger_Script I fixed http://wiki.musicbrainz.org/Tagger_Script to redirect where I actually wanted to go, but who has the power to update the musicbrainz.org/doc? If It makes things simpler, I volunteer to be a transclusion editor. As a side note, I wonder if we actually need to take static copies of the wiki any longer. Wouldn't it be simpler to just not change the stable guidelines in the wiki and just use those? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] feat. style and track/recording artist
On Mon, Jun 6, 2011 at 22:45, Simon Austin chi...@auzsoft.net wrote: Contraiwise NGS also added a split between recording and track title, with the ability to standardise the recording title and make the track title more like the cover. The cover for Basement Jaxx's Kish Kash is practically a blueprint for the old Track (feat. Person) style http://www.discogs.com/viewimages?release=189933 but recent edits have made all the track and recording titles into Track by Basement Jaxx feat. Person. http://musicbrainz.org/release/242e5f1c-2755-3217-ad0d-f9b1b5652b15 Huh. I haven't seen the cover of that release, but I'm fairly certain I wouldn't want it that way. Moving the feat. phrasing to the artist field only works in extremely simple cases, I can't see how one would move it to the track artist in a situation like this while still staying true to the cover: 1. Song A (Featuring Dudeson) 2. Song E (rap by Tyra) 3. Bla bla (Artist A + Artist B) (Still waiting for a hint from the NGS masterminds about what they had in mind, if anything.) -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] feat. style and track/recording artist
2011/6/6 Nicolás Tamargo de Eguren reosare...@gmail.com: On Tue, Jun 7, 2011 at 12:06 AM, Philip Jägenstedt phi...@foolip.org wrote: On Mon, Jun 6, 2011 at 22:45, Simon Austin chi...@auzsoft.net wrote: Contraiwise NGS also added a split between recording and track title, with the ability to standardise the recording title and make the track title more like the cover. The cover for Basement Jaxx's Kish Kash is practically a blueprint for the old Track (feat. Person) style http://www.discogs.com/viewimages?release=189933 but recent edits have made all the track and recording titles into Track by Basement Jaxx feat. Person. http://musicbrainz.org/release/242e5f1c-2755-3217-ad0d-f9b1b5652b15 Huh. I haven't seen the cover of that release, but I'm fairly certain I wouldn't want it that way. Moving the feat. phrasing to the artist field only works in extremely simple cases, I can't see how one would move it to the track artist in a situation like this while still staying true to the cover: 1. Song A (Featuring Dudeson) 2. Song E (rap by Tyra) 3. Bla bla (Artist A + Artist B) You wouldn't, not in the tracks (except maybe for 3). You would if the cover said Artist A feat. B - Song A, which is pretty common. Moving the artist of only track 3 would certainly look inconsistent in a case like this. Would the criteria be that the release artist is mentioned again at the track list? It's rather random if Artist A is mentioned again or not at the track level on a release by Artist A. (I assume it's rather uncommon, because it's redundant.) Whatever rules we come up with for the track level, they must be simple enough that most editors would get it right by guessing, because it's impossible to verify it without the physical release or a cover scan. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] feat. style and track/recording artist
2011/6/5 Nicolás Tamargo de Eguren reosare...@gmail.com: On Sun, Jun 5, 2011 at 9:52 AM, Philip Jägenstedt phi...@foolip.org wrote: Since NGS I'm often finding myself trying to decide what to do with tracks/recordings performed by multiple artists. As an example see track 1-11 of http://musicbrainz.org/release/8144cf86-4619-4125-bec0-3d45badc9ff3 It clearly needs a guideline change. On the cover this says Light Of My Life (與Lara Fabian合唱), where (與Lara Fabian合唱) means (sung with Lara Fabian). For the track level, there are 2 options: 1. Artist 王力宏 (Wang Leehom) and title Light Of My Life (與Lara Fabian合唱) This. As on cover for track level. (In both ways: if the artist was X feat. Y, I'd add it as X feat. Y, not move it to the title). I agree, at least for this example. 2. Artist 王力宏 Lara Fabian and title Light Of My Life For the recording level, there are 2 options: 1. Artist 王力宏 (Wang Leehom) and title Light of My Life (feat. Lara Fabian) 2. Artist 王力宏 Lara Fabian and title Light of My Life This (although I would probably use / instead of unless the album says , but that might be just me). This might appear in a Lara Fabian album as Light of My Life (feat. Wang Leehom), and it would be really random to have it go to the recording Light of My Life (feat. Lara Fabian). For consistency (and to make feat. recordings appear in the recordings for the featured artist), I would say this should be applied like that at recording level regardless of whether it has been credited to the two artists as main artists at some point or not (after all, we can use feat. as the link phrase if we want to. Crediting the release to both artists works for collaborations that are equal and where both artists have released the recording on their own albums, but for cases where one artist is clearly a guest performer, it would be weird to normalize the recording artists like this, IMO. Now, repeat these questions for all kinds of variations in how things are presented on the cover. A few issues: * Should feat. be part of the normalized title, or put in the disambiguation comment? When you say normalized you mean recording? I'd always move it to the artist field. I mean in the recording, yes. How would you normalize Stan (feat. Dido) by Eminem (http://musicbrainz.org/recording/60d2246d-2761-4e1f-b30b-2784f00565b1)? I certainly would ever want to see the track artist as Eminem feat. Dido here, but have problems seeing what I *would* want too. * Should we always just write what's on the cover and credit the track to the release artist, even if the cover says Song Foo - Artist Bar + Artist Baz? What about VA releases? As cover. If the cover says X + Y, X + Y it should be. The problem is in interpreting the cover. What is the distinction between an artist being mentioned in a comment on the sleeve and being credited as an artist. Consider these (fictional) examples: * Song A (feat. Artist Y) * Song A (Artist X + Artist Y) * Song A (rap by Artist X) * Song A (Artist X on keyboard) * Song A (Artist X合唱) How is one supposed to create a combined artist credit in the last 3 cases? There needn't be much difference between the nature of the collaborations in these examples, just a difference in how it's presented on the cover. * What is the recording artist supposed to represent? The main performer? Even if they weren't credited as such on any cover? I would say so. But please give an example of the they weren't credited as such on any cover thingy. Duets between two famous artists which are not credited as such on the cover. The most blatant example I know of is http://test.musicbrainz.org/recording/6f874356-bd28-4c59-b8b5-64bc2ce78f59 where 費玉清's appearance is quite a big deal, yet it isn't credited on the cover. If we create artist credits with both artists even in cases like this, what kind of criteria should we have for recording artist? So, to summarize, there are mainly 2 issues that I can see: 1. What kind of phrasing on cover merits a joined artist credit on track and/or release level? 2. On the release level, what are the criteria for which artists go into the artist credit? This seems set up for an inconsistent mess, so I'm perhaps leaning towards *not* moving featured artists to the artist credit on the recording level. It would be interesting to hear the NGS masterminds' thinking about this issue. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] VolumeNumberStyle in NGS?
Is volume number style still relevant with NGS? Based on what I've seen from the NGS-enabled Picard it seems like going forward we will start treating the release group titles as the normalized titles, and then let the release titles reflect the cover. Is this correct? Is it OK to start changing release titles to things like Beloved Music Box Vol.5 right now? IMO, this would make perfect sense, but does of course need some getting used to. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: volume numbers normalization only for release groups
http://wiki.musicbrainz.org/User:Foolip/Volume_numbers See the editing history for a clear diff. The essence of the change is to not normalize the release titles at all, only the release group titles. This is a similar split to track/recording. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] VolumeNumberStyle in NGS?
On Sat, Jun 4, 2011 at 21:41, Frederic Da Vitoria davito...@gmail.com wrote: 2011/6/4 Nicolás Tamargo de Eguren reosare...@gmail.com On Sat, Jun 4, 2011 at 7:59 PM, Philip Jägenstedt phi...@foolip.org wrote: Is volume number style still relevant with NGS? Based on what I've seen from the NGS-enabled Picard it seems like going forward we will start treating the release group titles as the normalized titles, and then let the release titles reflect the cover. Is this correct? Is it OK to start changing release titles to things like Beloved Music Box Vol.5 right now? IMO, this would make perfect sense, but does of course need some getting used to. I would fully support this. Normalization would still apply to the RGs, wouldn't it? Yes, please see the RFC I sent out and see if that is clear enough on this point (and otherwise reasonable). -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Release Country: What's preferred, Europe or all countries we can find even small evidence for?
On Mon, May 30, 2011 at 07:37, jacobbrett jacobbr...@hotmail.com wrote: Philip Jägenstedt wrote: On Fri, May 27, 2011 at 22:02, Simon Austin chi...@auzsoft.net wrote: In this edit, http://musicbrainz.org/edit/14510889 some want to move an existing German release event to Europe, and keep only one Europe release. I would disagree, but more eyes on it the better. I encounter the same problem when editing Chinese releases. Some albums have been released in Taiwan, Hong Kong and Singapore with the same label and barcode. Sometimes they're printed in different places, but are otherwise identical. Having separate releases for these is way overkill IMO, as sometimes you'll have no way of telling from the physical release which MusicBrainz release it matches. As a general guideline, I'd want releases that have the same barcode, catalog number and track listing to only have one release in MusicBrainz. If it was released in multiple countries/regions, this should be represented in some other way than duplicating the whole release. I think that if they are distinguishable, for example, by being printed/manufactured in different locations for those different release countries, then they may be worth adding as separate releases. I disagree. I've seen releases which have the exact same packaging, barcode, catalog number and content but say Manufactured and printed in Taiwan vs Singapore or Hong Kong. Then there are some that are printed in Taiwan but have stickers that say only for sale in Hong Kong or Malaysia. While I wouldn't mind keeping track of the fact that something was released in several regions, duplicating releases in this situation seems way overkill to me. For now, I'm putting additional regions in annotations, and have even entered edits to merge releases like this: http://musicbrainz.org/edit/14527547 IMO, the strongest reason for this is that any change to one release would have be duplicated on the other, since the tracklisting, booklet and everything is identical. The only way to distinguish them is to buy one copy from each region and look at the fine print. Though, if it's the exact same pressing released in several neighbouring countries, then I consider that one release area and would recommend simply adding (in order): * Europe (if applicable to most of Europe), * the artist's country (if it is one of the countries that printing is released in), * the largest market/country of distribution (if released on the same date), or * the country of earliest release. I agree, and since there's no region for Hong Kong, Macau, Taiwan and Singapore, I usually just use the artists region of origin. I think the correct fix here is to allow for several countries per release, but that annotations is perfectly acceptable. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Release Country: What's preferred, Europe or all countries we can find even small evidence for?
On Mon, May 30, 2011 at 14:24, Simon Austin chi...@auzsoft.net wrote: On 30/05/2011 07:38, Philip Jägenstedt wrote: While I wouldn't mind keeping track of the fact that something was released in several regions, duplicating releases in this situation seems way overkill to me. For now, I'm putting additional regions in annotations, and have even entered edits to merge releases like this: http://musicbrainz.org/edit/14527547 IMO, the strongest reason for this is that any change to one release would have be duplicated on the other, since the tracklisting, booklet and everything is identical. The only way to distinguish them is to buy one copy from each region and look at the fine print. We're not duplicating releases though - at least no more than before. None of the edits I've seen have been rejecting new release events, just removing old ones. Perhaps the cause is because the release event is now higher in the chain... previously they were after the tracklist; now they're before - but in a list with all other tracklists for that release. To me what this boils down to is that you're deleting information because you don't like how it's displayed. And I don't think that should be the first option here, especially not so soon after NGS has been released. This is not really new for NGS, but it is true that it was cheaper to have multiple release events before NGS, so there was less motivation to clean up incorrect or redundant release events. In my vocabulary, there really is just 1 release when two copies are identical in all respects (content, packaging, barcode, label, catalog number) except for where it was printed and sold. This is really different pressings/printings of the same release, not separate releases. I think the correct fix is to allow multiple countries on a single release, and have filed a feature request for that: http://tickets.musicbrainz.org/browse/MBS-2417 Until we have that, I think it is better, on balance, to keep this information in annotations. You're of course free to vote no to http://musicbrainz.org/edit/14527547 if you disagree. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Release Country: What's preferred, Europe or all countries we can find even small evidence for?
On Fri, May 27, 2011 at 22:02, Simon Austin chi...@auzsoft.net wrote: In this edit, http://musicbrainz.org/edit/14510889 some want to move an existing German release event to Europe, and keep only one Europe release. I would disagree, but more eyes on it the better. I encounter the same problem when editing Chinese releases. Some albums have been released in Taiwan, Hong Kong and Singapore with the same label and barcode. Sometimes they're printed in different places, but are otherwise identical. Having separate releases for these is way overkill IMO, as sometimes you'll have no way of telling from the physical release which MusicBrainz release it matches. As a general guideline, I'd want releases that have the same barcode, catalog number and track listing to only have one release in MusicBrainz. If it was released in multiple countries/regions, this should be represented in some other way than duplicating the whole release. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging multi-language releases?
On Sun, May 22, 2011 at 22:53, Kuno Woudt k...@frob.nl wrote: Hello, On 22/05/11 15:53, Philip Jägenstedt wrote: Before NGS I added some releases where both English and Chinese titles appear on the cover. I created one release for each language. http://musicbrainz.org/release/0a4a71ed-b7d9-44f9-91dd-5cacec86060e and http://musicbrainz.org/release/a78902cf-4ed1-414b-ae34-80076f6142f9 is one such pair. With NGS it feels unclear to have multiple releases where there is only one physical release, so I've tried to merge these in http://musicbrainz.org/edit/14491834 and http://musicbrainz.org/edit/14491847 Is this an approach that people agree with? The languages are joined in a very peculiar manner here, with _. What should one do when two languages appear on the cover in a more independent fashion, as in http://musicbrainz.org/edit/7588058 (I only added the Chinese variants for this, see cover at http://www.114bt.com/btimg/2007/1/6/682751.jpg)? In that cover image one of the languages is clearly the main tracklist, with the other just supplemental. IF you were to merge those my suggestion would be to use this format: 1. Primary Language (Secondary Language) That seems the most common format used elsewhere. It seems sane tagging will be made harder by merging these, because almost no one will want both languages, I'm guessing. Should we perhaps just use pseudo-releases for tracklists on a usable form and leave the official releases in their original true-to-the-cover form? I wouldn't strongly object to combining both languages in a single release, but I would prefer not to start doing that just yet. I think we should just keep doing what we've been doing before NGS, so two releases in our database - link them with translation relationships and mark both official. And formulate how we think translations _should_ work, then I can start coding that feature and we can have this sorted properly soonish :D Since I wasn't very happy with the result, I reverted the change in http://musicbrainz.org/edit/14503147 Going forward, I think that it would be nice if perhaps recordings could have aliases by language. Perhaps there should be some attribute for official translations, if there is such a thing. With such a scheme, we could get rid of lots of pseudo-releases and wouldn't have to duplicate release events or any AR:s on those. Or should translations be on the tracklist level perhaps? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Separate works for instrumental version?
On Sun, May 22, 2011 at 20:45, Nikki aei...@gmail.com wrote: Philip Jägenstedt wrote: That sounds pretty good, but it wouldn't really be accurate for karaoke tracks where the background singers are usually left in and only the lead singer is left out. Perhaps a karaoke attribute would work, but I'm not sure if it's going to be possible to draw a line between the two in general. By the way, we have a recording-recording relationship for linking karaoke tracks to the corresponding vocal track, so we do already have a way to identify those. Thanks, I didn't know that! I've started using that now. I like the idea of an instrumental attribute for the performance relationship for things which aren't karaoke versions. It's one of the things I was already thinking would be nice to have. I don't really know what to do about proper instrumental performances, karaoke versions without backing vocals and karaoke versions with backing vocals though... It seems difficult to make a distinction without confusing people. Indeed, the distinction between karaoke is not clear at all, in many cases the distinction would seem to be only what it's *for* rather than what it *is*, and I'm not sure how those debates could be resolved. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Capitalization in NGS
On Tue, May 24, 2011 at 01:52, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: On 23 May 2011 07:21, Frederic Da Vitoria davito...@gmail.com wrote: 2011/5/22 Dr Andrew John Hughes gnu_and...@member.fsf.org I really don't see why we want to retain all covers verbatim; I thought MusicBrainz was a database, not a cover archive. Maybe because the MB database could store what IS as well as what users would want to be? Or because what you want is not necessarily what other users want. And because NGS is able to store both the standardized and the printed titles. So that tracks would capture as much information as possible from the physical release (no, no color info :-) ) while the recording and the release would contain a standardized title. Also, sticking to the cover has the advantage that it minimizes the amount of knowledge needed to enter new releases in MB. And if you want to speak technically of databases, wouldn't normalizing track titles make them identical to recording titles, which would be data redundancy, one of the bad things database designers are advised to avoid as much as possible? Just because it can doesn't mean it should. I really don't see a great value in keeping lots of data about covers. I get that apparently some 'other users' want this, but I haven't seen a convincing argument from them yet. Users have always managed to enter releases without following guidelines, and more experienced users have just ended up cleaning them up, so I don't see how this would suddenly make things easier for the novices. The extra recording layer makes things more complicated, and they are still going to enter the titles there in a non-standard way. Write what's on the cover is quite obviously easier than read these guidelines about capitalization, feat. style, extra title information, etc. People who care can then standardize the recordings, not the tracklists. Usually, a database is created to not only store information, but to allow it to be used for some purpose. It makes it very hard to get useful information from MusicBrainz if titles are varying based on what someone chose to do on the cover. Wait until the next Picard release and then you can (allegedly) chose if you want normalized titles or not. How does MusicBrainz become less useful by storing both standardized titles and the as-on-cover titles? It does become harder to verify that the titles are correct if you don't have the physical release, but if you worry about that you can just use the (normalized) recording titles. Yes, track titles are superfluous if they are standardised to be the same as recording titles. This is why I would just use the recording titles in tracklists and not have separate track titles. All I'm seeing so far is a lot of additional work being created by these track titles (every title change now needs two edits and the new interface isn't very speedy) and no advantages. If you think that we just shouldn't have the separation between tracklist titles and recording titles, will you file a bug to remove the feature from MusicBrainz? If they should really be the same, then having the separation is actively harmful and a waste of time. IMO, we should put tracklists to good use by storing as-on-cover titles in them. While variations in capitalization usually isn't interesting, there are cases where it is and it is simpler to say write what's on the cover than write what's on the cover but normalize capitalization taking artist intent and consistent original data into consideration. To give an example where merging track and recording names would be harmful is the Hong Kong group my little airport: http://musicbrainz.org/artist/ea6185ea-0138-4b8c-a81a-e8fb90d7c680 This group consistently uses lower case letters in their name and release/track titles, both on the physical releases and their website. This is reflected in the official releases already. However, on the compilation/VA releases from outside Hong Kong that capitalization has not been followed. Someone who only has the compilation will almost certainly not want the capitalization to be lowercased just because that's the way they are on the original releases. Likewise, people who only have the original release will want that capitalization, not the bastardized capitalization from a foreign compilation. The only way to allow this while still merging recordings is of course to have separate titles in the tracks and recordings. (It's almost as if NGS was designed specifically to solve this problem...) -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging multi-language releases?
On Tue, May 24, 2011 at 09:48, Kuno Woudt k...@frob.nl wrote: Hello, On 24/05/11 09:28, Philip Jägenstedt wrote: Going forward, I think that it would be nice if perhaps recordings could have aliases by language. Perhaps there should be some attribute for official translations, if there is such a thing. With such a scheme, we could get rid of lots of pseudo-releases and wouldn't have to duplicate release events or any AR:s on those. Or should translations be on the tracklist level perhaps? Translations at the tracklist level sounds sensible. I think it's OK to keep a single canonical name at the recording level. I guess that one downside of tracklist level translations is that you don't get translations of the same recordings if they appear on multiple releases for free. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
On Tue, May 24, 2011 at 14:34, Brian Schweitzer brian.brianschweit...@gmail.com wrote: For a few reasons, I've been silent here for the past while. However, I feel I have to at least comment on the change in guidelines that has taken place. I may not be commenting on the list, but I do still at least skim the style list to see what's happening. Thus, when I saw an edit note citing something in an entirely rewritten guideline, I was rather surprised. Based on nikki's announcement ( http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011267.html ), it looked like a rewrite in progress, not a RFC, let alone a RFC that changed every single style guideline. I looked at the time with the understanding that this was a work in progress, not something just days away from being official. Yet the change to the pages from being available for review at User:kuno/Style to those same pages suddenly being the official guidelines took place only 6 days later and with no RFC/RFV/etc, only http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011369.html . So how did such a major and complete rewrite skip RFC/RFV, and become official within 6 days of being announced (if you count nikki's May 10 email as being the RFC, though not mentioned in the email's subject). I won't email again, but this is important enough that I couldn't not say something. Every single style guideline has been changed, and there's more than a few of the new guidelines which have dropped important items and/or changed things counter to how they were decided back during RFCs for the individual guidelines. Brian I'll let nikki and kuno speak for themselves, but just wanted to note that I support the complete overhaul and that the normal process has been circumvented. Most of the old guidelines don't make sense with NGS, and doing such a big change by RFC/RFV would have been extremely painful. I think we're much better off taking the rewrite and working from there. Getting people in sync with the changes is another matter, but I expect we'll sort it out. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Bonus discs?
http://musicbrainz.org/edit/14491791 azertus is asking if we should have a way to record the fact that a disc is considered bonus. It does seem that this ability was lost in the move to NGS, but I'm not sure I think it's important. Thoughts? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Capitalization in NGS
http://wiki.musicbrainz.org/Style/Track_and_release_titles This documentation isn't terribly clear, it doesn't say if the normal case is to use the capitalization on the release, only Follow the appropriate Capitalization Standard when the track listing on the release does not distinguish between upper and lower case. Is the intention that the original capitalization should be used except if it is in all uppercase? Do we assume that all lowercase is intentional while all uppercase is just a matter of style? Further, the examples table is not at all clear about this example: All Is Full Of Love and all is full of love = All is Full of Love Does this mean that if *both* of these capitalizations are used on a release, then it should be normalized? Or does it mean that if the release says only All Is Full Of Love (very common) it should still be normalized? What I'm hoping the general idea is that we should follow the original capitalization, except where that would be ridiculous, e.g. if it was all uppercase. Even though I don't like the style, I hope we should preserve something like All Is Full Of Love. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Merging multi-language releases?
Before NGS I added some releases where both English and Chinese titles appear on the cover. I created one release for each language. http://musicbrainz.org/release/0a4a71ed-b7d9-44f9-91dd-5cacec86060e and http://musicbrainz.org/release/a78902cf-4ed1-414b-ae34-80076f6142f9 is one such pair. With NGS it feels unclear to have multiple releases where there is only one physical release, so I've tried to merge these in http://musicbrainz.org/edit/14491834 and http://musicbrainz.org/edit/14491847 Is this an approach that people agree with? The languages are joined in a very peculiar manner here, with _. What should one do when two languages appear on the cover in a more independent fashion, as in http://musicbrainz.org/edit/7588058 (I only added the Chinese variants for this, see cover at http://www.114bt.com/btimg/2007/1/6/682751.jpg)? It seems sane tagging will be made harder by merging these, because almost no one will want both languages, I'm guessing. Should we perhaps just use pseudo-releases for tracklists on a usable form and leave the official releases in their original true-to-the-cover form? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging multi-language releases?
On Sun, May 22, 2011 at 15:53, Philip Jägenstedt phi...@foolip.org wrote: Is this an approach that people agree with? To get an idea of the alternative, have a look at this release group that I split before NGS: http://musicbrainz.org/release-group/3c981710-92b6-3de0-90ba-baa655e06630 The official releases here aren't very useful at all, their only redeeming value is that they reflect the truth. Is the correct solution here to have multiple recording titles annotated with language+script, so that taggers can set a preference? What are the general plans for providing clean tags using the recording and work titles? I've already started making my tags inconsistent in style after changing some titles to reflect the actual covers, and I'm not sure I'd want me entire collection to be like that... -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Separate works for instrumental version?
How should we handle recordings that differ from the original only in that some or all of the vocals have been removed? This would be the case for both instrumental versions and for karaoke tracks. It seems rather silly to have separate works, but it also seems silly that the instrumental versions should get a lyricist relationship if they are linked to the single work. Ideas? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Capitalization in NGS
Hmm, so why do we have the separation between tracklist and recordings at all in NGS? If we want to always use the canonical name, then we can just have tracks, like pre-NGS. Wasn't part of the idea here to resolve the tension between what it says and what it is? It's clear that there are different interpretations here and that the documentation needs to be updated so that it leaves little or no room for interpretation. Philip On Sun, May 22, 2011 at 16:39, SwissChris swissch...@gmail.com wrote: I don't think this is a good approach. All Is Full Of Love and all is full of love both are IMHO ridiculous. We had this discussion before: cover graphics (including Capitalization) are graphic designers intent, not artist intent. We don't store the size nor he color of the letters, we don't store information like italic or bold characters either, so why would we want to keep absurd capitalizations. To see how a cover really looks we always can report to a cover-AR-pic… On Sun, May 22, 2011 at 3:28 PM, Philip Jägenstedt phi...@foolip.org wrote: http://wiki.musicbrainz.org/Style/Track_and_release_titles This documentation isn't terribly clear, it doesn't say if the normal case is to use the capitalization on the release, only Follow the appropriate Capitalization Standard when the track listing on the release does not distinguish between upper and lower case. Is the intention that the original capitalization should be used except if it is in all uppercase? Do we assume that all lowercase is intentional while all uppercase is just a matter of style? Further, the examples table is not at all clear about this example: All Is Full Of Love and all is full of love = All is Full of Love Does this mean that if *both* of these capitalizations are used on a release, then it should be normalized? Or does it mean that if the release says only All Is Full Of Love (very common) it should still be normalized? What I'm hoping the general idea is that we should follow the original capitalization, except where that would be ridiculous, e.g. if it was all uppercase. Even though I don't like the style, I hope we should preserve something like All Is Full Of Love. -- Philip Jägenstedt ___ 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 -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Separate works for instrumental version?
On Sun, May 22, 2011 at 18:37, Aurélien Mino a.m...@free.fr wrote: On 05/22/2011 04:41 PM, Philip Jägenstedt wrote: It seems rather silly to have separate works, but it also seems silly that the instrumental versions should get a lyricist relationship if they are linked to the single work. Ideas? What about an instrumental attribute to the performance AR? Recording is an instrumental performance of Work That sounds pretty good, but it wouldn't really be accurate for karaoke tracks where the background singers are usually left in and only the lead singer is left out. Perhaps a karaoke attribute would work, but I'm not sure if it's going to be possible to draw a line between the two in general. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Capitalization in NGS
On Sun, May 22, 2011 at 19:07, Aurélien Mino a.m...@free.fr wrote: On 05/22/2011 06:51 PM, Dr Andrew John Hughes wrote: On 22 May 2011 15:39, SwissChrisswissch...@gmail.com wrote: I don't think this is a good approach. All Is Full Of Love and all is full of love both are IMHO ridiculous. We had this discussion before: cover graphics (including Capitalization) are graphic designers intent, not artist intent. We don't store the size nor he color of the letters, we don't store information like italic or bold characters either, so why would we want to keep absurd capitalizations. To see how a cover really looks we always can report to a cover-AR-pic… I agree with this, and I don't remember any discussion about relaxing the title requirements. Exactly my thought. So I ask again, if we are still normalizing the titles, what is the purpose of separating tracklists from recordings? If you read http://wiki.musicbrainz.org/Style/Track_and_release_titles it's quite obvious that it's implied that there are some cases where the original capitalization is followed. The requirements have already changed from pre-NGS, the question is only what the new guideline is supposed to mean. It seems to have been written by kuno, so perhaps he would like to chime in? It would be a pity if with NGS we *still* can't satisfy both people who want the titles from the cover and those who want only normalized titles, no? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Artist country
http://wiki.musicbrainz.org/Style/Artist says: For people, use the country where they were born and raised. I've already encountered two artists where I'm not sure how to interpret this: http://ngs.musicbrainz.org/artist/96e2e78e-1e22-45b5-af33-7d79a91ee308 (Laleh) http://ngs.musicbrainz.org/artist/ca264abf-3eb6-4d53-827b-6ab16988a4a3 (Cornelis Vreeswijk) Both of these artists were born in another but moved to Sweden during their childhoold, at age 1 and 12 respectively. Should the country be the country of birth or Sweden? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Capitalization Standard For Transliterations
http://lists.musicbrainz.org/pipermail/musicbrainz-style/2010-June/009718.html On Fri, Jun 25, 2010 at 23:25, Brian Schweitzer brian.brianschweit...@gmail.com wrote: Only difficulty I see is that there wasn't (as far as I can see) an official RFV; perhaps one ought to occur before this is declared passed? Sorry to be out of touch to the list of late; my net has been out for the past week, and for the next few weeks I'll be travelling, and frequently without net access. I'll be back on the 16th of July however; in the meantime, if proposers could just make sure to also update the Proposals page themselves. :) Brian On Mon, Jun 21, 2010 at 10:36 AM, Philip Jägenstedt phi...@foolip.org wrote: On Sat, Jun 5, 2010 at 17:18, Philip Jägenstedt phi...@foolip.org wrote: http://wiki.musicbrainz.org/User:Foolip/Capitalization_Standard_For_Transliterations This changed a bit during RFC, so please read it again if you haven't already done so. Note specifically that the scope is limited to pseudo-releases, for reasons outlined in the previous thread: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2010-April/009527.html Over two weeks have passed and I'm declaring this passed. There were some comments which were addressed with minor changes and the conclusion by Frederic Da Vitoria that this needs to be revisited after NGS, which I agree with. -- Philip Jägenstedt ___ 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 -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] NGS: purpose of length on recording?
I see that in NGS beta 2 recordings can have a length set in the edit UI. However, this doesn't seem to be related to the track length in release listings. What's the purpose of the field? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Capitalization Standard For Transliterations
On Sat, Jun 5, 2010 at 17:18, Philip Jägenstedt phi...@foolip.org wrote: http://wiki.musicbrainz.org/User:Foolip/Capitalization_Standard_For_Transliterations This changed a bit during RFC, so please read it again if you haven't already done so. Note specifically that the scope is limited to pseudo-releases, for reasons outlined in the previous thread: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2010-April/009527.html Over two weeks have passed and I'm declaring this passed. There were some comments which were addressed with minor changes and the conclusion by Frederic Da Vitoria that this needs to be revisited after NGS, which I agree with. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] A proposal has passed (was RFV: Capitalization Standard Chinese)
Done. It wasn't under Proposal: to begin with, so that wasn't a problem. Philip On Thu, Jun 10, 2010 at 15:38, Brian Schweitzer brian.brianschweit...@gmail.com wrote: The RFV period having expired with no vetos having been heard, this proposal has passed. Thanks all! Philip, do you mind making the needed changes (removing the proposal header, adding the caps standard header, etc) to the proposal page? Navap can help you with renaming the page away from the Proposal: namespace. :) Brian On Sun, Jun 6, 2010 at 1:08 PM, Philip Jägenstedt phi...@foolip.org wrote: Oh right, I changed this from RFC to RFV before sending but forgot to update the text. So RFV it is. As for Transliterations, people actually have comments on that, so let's leave that alone. Philip On Sun, Jun 6, 2010 at 09:52, Brian Schweitzer brian.brianschweit...@gmail.com wrote: Done; technically this has already been in RFC since 2010-04-07, so I guess we can move it to RFV, with the RFV earliest close/passage date being 2010-06-07 (or, since today's almost over, let's make it 2010-06-08). Did you want to do the same with RFC-286: Capitalization Standard Transliterations? It too has been in that same RFC state since 2010-04-07. Thanks, Brian On Sat, Jun 5, 2010 at 5:13 AM, Philip Jägenstedt phi...@foolip.org wrote: http://wiki.musicbrainz.org/Capitalization_Standard_Chinese This ought to be fairly uncontroversial, assuming no issues it will move to RFV and be accepted without further ado. Brian, can you fill in the dates? -- Philip Jägenstedt ___ 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 -- Philip Jägenstedt ___ 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 -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Capitalization Standard For Transliterations
On Mon, Jun 7, 2010 at 19:07, Frederic Da Vitoria davito...@gmail.com wrote: 2010/6/7, Frederic Da Vitoria davito...@gmail.com: 2010/6/7, Philip Jägenstedt phi...@foolip.org: On Mon, Jun 7, 2010 at 10:26, Frederic Da Vitoria davito...@gmail.com wrote: 2010/6/7, Frederic Da Vitoria davito...@gmail.com: 2010/6/7, Frederic Da Vitoria davito...@gmail.com: 2010/6/7, Philip Jägenstedt phi...@foolip.org: On Sun, Jun 6, 2010 at 22:57, Frederic Da Vitoria davito...@gmail.com wrote: 2010/6/6 Philip Jägenstedt phi...@foolip.org On Sat, Jun 5, 2010 at 20:59, Frederic Da Vitoria davito...@gmail.com wrote: 2010/6/5 Philip Jägenstedt phi...@foolip.org http://wiki.musicbrainz.org/User:Foolip/Capitalization_Standard_For_Transliterations This changed a bit during RFC, so please read it again if you haven't already done so. Note specifically that the scope is limited to pseudo-releases, for reasons outlined in the previous thread: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2010-April/009527.html Transliterated pseudo-releases should conform to the rules of the transliteration system used. I suggest using something like Transliterated pseudo-releases should conform to the rules of the end-language. I don't think this is good because it is in fact the rules of the transliteration system and not the language which is to be used. For example, when transliterating to the Chinese language using Hanyu Pinyin, it is the rules of Hanyu Pinyin that are relevant, not those of Chinese. I see. Thanks or the explanation. I suggest also inserting an explanation of why this is limitated to pseudo-releases. The reason is that NGS is soon here, and we don't want people going around applying this guideline to official releases which happen to be transliterations, making them much different from what's on the cover. For example, the title of http://musicbrainz.org/release/d82bf795-0b1e-4ab2-9b5b-7997cf252701.html is now Shuang Jie Kun (Nun-Chuks) but would be Shuāngjiégùn (Nun-Chuks) if normalized as per Capitalization Standard Chinese. I doubt anyone who actually has the release would see that as an improvement. I'm not sure how to put this into the guideline in a sane way, any concrete suggestion? At the time this StyleGuide is being adopted, NGS is getting close. In NGS, official releases should not be Capitalized. This StyleGuide is limited to pseudo-releases in order to avoid destructive capitalization. I hope I haven't misunderstood the NGS restriction! Now added in a note. Good. I still have a problem understanding the RFC: Some languages (sorry, wrong button :-P ) 1 - Conform (sorry, wrong button again !!! GMail is definitely not meant for keyboard users) I was writing that I still have a problem understanding the RFC: 1- conform to transliteration system 2- some languages have specific guidelines 3- for any other script that has a transliteration system... here I am lost other than what? Other than 2- or other than 1- and 2-? I exclusively use latin script (because I don't know enough of any other), where do I fit? Not 2-, obviously... The general rule is to follow whatever rules the transliteration system has, the rest is just some guidance for how to do that. The RFC's rule 1 (your 2) is just a few instances where those rules are actually documented in a MusicBrainz guide line, for reference. The RFC's rule 2 (your 3) is the fallback, working on the assumption that sentence caps will work for all cases not already covered. If you are transliterating e.g. Chinese into Latin, that would fall under rule 1. If you are transliterating Hindi to Latin, that would fall under rule 2 as we don't have any specific rules for it. I was hoping you would answer this. I already agree with the current formulation, but I'd be even happier if you'd replace (sigh) - For any other transliterations to scripts that have a capitalization concept with - For transliteration to scripts that have a capitalization concept but don't fall under the two situations above +1 But it's not two situations mentioned above, it's a general guideline with some specifics for certain languages. If one must apply some structure here, both Some languages and For any other transliterations are both a subset of the general rule. If the objective is just to avoid the phrase have a capitalization concept I would agree with that, but don't know how to change it to anything that makes sense. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
