Re: [mb-style] Strange mail answer
2015-04-30 18:07 GMT+02:00 Calvin Walton calvin.wal...@kepstin.ca: On Wed, 2015-04-29 at 17:13 +0200, Frederic Da Vitoria wrote: Hello, I just had an issue while entering a new release and I posted a question to musicbrainz-us...@lists.musicbrainz.org. To my surprise, I got an answer from a company called InnovativeAir telling me a ticked had been entered. I checked the mail I sent and the destination was correct. Does this make any sense to any one? The musicbrainz mailing lists are public, so it is possible that there are spammers harvesting email addresses from t he mailing lists. This sounds like a simple case of an automatic spam message, and I don't think there's anything we can do about it. Your message did make it to the musicbrainz-users mailing list correctly - and I can see it - but with the low traffic on the list, it's a bit iffy whether or not you'll get a useful response. No problem, I posted again to mb-style and I got all the answers I needed. It just feels a little strange to post to a style list about a non-style issue -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Editing bug
2015-04-29 19:04 GMT+02:00 monxton musicbra...@jordan-maynard.org: On 29/04/2015 17:05, Frederic Da Vitoria wrote: Hello, I just entered release 6c73c660-f0c9-45c5-841f-f7e429d99d8d. This one disc release has been also entered previously in a multi-disc compilation. During my editing, I changed the track title for tracks 9 to 12, so that checking the recordings was a little tricky. Now I have this strange situation where clicking on track 9 leads to an empty page. How was this possible? How can I make it right? It looks OK now. There was some hanky-panky with those track previously, but it was last June, not recently. I noticed that some orphans were created back then, so I just submitted edits to merge them. Thanks. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Editing bug
Hello, I just entered release 6c73c660-f0c9-45c5-841f-f7e429d99d8d. This one disc release has been also entered previously in a multi-disc compilation. During my editing, I changed the track title for tracks 9 to 12, so that checking the recordings was a little tricky. Now I have this strange situation where clicking on track 9 leads to an empty page. How was this possible? How can I make it right? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Strange mail answer
2015-04-29 17:34 GMT+02:00 Ben Ockmore ben.s...@gmail.com: I have a feeling that the -users mailing list was closed a couple of months ago, due to low activity. May be wrong though, but that's what I remember from talk in #musicbrainz-devel. On 29 Apr 2015 16:14, Frederic Da Vitoria davito...@gmail.com wrote: Hello, I just had an issue while entering a new release and I posted a question to musicbrainz-us...@lists.musicbrainz.org. To my surprise, I got an answer from a company called InnovativeAir telling me a ticked had been entered. I checked the mail I sent and the destination was correct. Does this make any sense to any one? OK, I guess that's part of the explanation. I'll ask my question again here. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Strange mail answer
Hello, I just had an issue while entering a new release and I posted a question to musicbrainz-us...@lists.musicbrainz.org. To my surprise, I got an answer from a company called InnovativeAir telling me a ticked had been entered. I checked the mail I sent and the destination was correct. Does this make any sense to any one? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] How to enter hybrid SACD and DVD audio+video discs?
2014-11-28 15:24 GMT+01:00 Steve Martin st...@planomartins.com: On Nov 28, 2014, at 3:47 AM, MeinDummy meindu...@nurfuerspam.de wrote: But if we put the entire DVD content into a single medium wouldn't it be more consistent to split hybrid SACDs by layers, i.e. such that the medium for the SACD layer would contain the stereo and the 5.1 tracks? Currently, we split them by audio formats. Half of the SACD layer content is represented by the CD / SACD stereo disc and the other half by the SACD multichannel disc. (Why don't these represent the same content on the DVD as well?). The release split by layers would look like this: 1.) medium: hybrid SACD, title CD layer, 12 stereo tracks 2.) medium: hybrid SACD, title SACD layer, 12 stereo tracks + 12 multichannel tracks 3.) medium: DVD, title DVD or none, 12 stereo tracks + 12 multichannel tracks + 3 videos (+ [photo gallery] ???) I started off trying to do SACD's that way but got a lot of voter push back. It is apparently more acceptable for DualDiscs where the sides feel more like separate mediums. The logical separation of CD and SACD layers doesn't sit as well with people but makes sense to me. I am fine with it either way, the cases where a separate stereo track list is required for the Hybrid SACD (due to different recordings or track lists) is pretty small so your case 2.) is seldom needed, but it doesn't do any harm other than being a little more difficult to enter and does accurately represent the structure of the hybrid medium. Think about what hybrid means, it is really two different mediums combined in one physical object. If the DualDisc people had figured out how to do it on one side (with dual focussing lasers or something) they would probably be done the same way. IIRC, I have such a Dual Disc. After all, most DVDs are already double layers. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] How to enter hybrid SACD and DVD audio+video discs?
I thought you meant CD and SACD :-D 2014-11-28 16:19 GMT+01:00 Steve Martin st...@planomartins.com: Really? CD and DVD on one side. That is an oddity. What is the title? I’m surprised someone would do that because most DVD players would not have a way to specify which layer to play, and could possibly default to the CD layer. Or at least have no way to choose other than whichever layer the DVD player defaults to. It works for SACD (which is technically CD and DVD (SACD trickery) on the same side) because part of the SACD player spec is that there be an option in the player to choose the CD or the SACD layer. On Nov 28, 2014, at 8:46 AM, Frederic Da Vitoria davito...@gmail.com wrote: IIRC, I have such a Dual Disc. After all, most DVDs are already double layers. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
2014-11-05 18:59 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com: Updated this a bit, with mentions to language and double tracklists. Added movement numbering (together with keys and the rest) as info to add if it's there but not if it's not. I am not quite sure if numbering should be standardized or not. I believe your draft means yes, but some users could understand it otherwise. For example, according to http://wiki.musicbrainz.org/Style/Classical#Language-specific, Catalogues should always be preceded by comma and space. Does this mean that Sonata in E (opus 5) should be standardized into Sonata in E, op. 5? I suggest including an example to make this clear. And this makes me see that Catalogues should always be preceded by comma and space. may not always be appropriate: should we really replace Symphony Op. 5 with Symphony, Op. 5? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
2014-11-05 19:36 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com: On Wed, Nov 5, 2014 at 8:27 PM, Frederic Da Vitoria davito...@gmail.com wrote: 2014-11-05 18:59 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com: Updated this a bit, with mentions to language and double tracklists. Added movement numbering (together with keys and the rest) as info to add if it's there but not if it's not. I am not quite sure if numbering should be standardized or not. I believe your draft means yes, but some users could understand it otherwise. For example, according to http://wiki.musicbrainz.org/Style/Classical#Language-specific, Catalogues should always be preceded by comma and space. Does this mean that Sonata in E (opus 5) should be standardized into Sonata in E, op. 5? I suggest including an example to make this clear. I thought http://wiki.musicbrainz.org/Style/Classical/Language/English was clear enough with its examples. Is that not the case? (but basically, yes, that's what it means) And this makes me see that Catalogues should always be preceded by comma and space. may not always be appropriate: should we really replace Symphony Op. 5 with Symphony, Op. 5? I'd say yes. That's the basic, manual-of-style kind of correction that is (to me at least) equivalent to adding missing accents to a pop song's title. OK, you can still make it more clear later if you see that many users understand it differently. One question: this means that no standardization should be performed for languages which don't have a specific classical guideline, right? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
(How is one supposed to answer to a mail which contains both top-posting and bottom-posting?) 2014-10-30 10:43 GMT+01:00 symphonick symphon...@gmail.com: Here's my old WIP proposal from last time: http://wiki.musicbrainz.org/User:Symphonick/csg/releases/track_title I believe I put it on hold because it sounded like headings or track groups (that is, no concatenation of work title track title) could be implemented pretty soon... 2014-10-30 9:25 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com : On Thu, Oct 30, 2014 at 2:10 AM, David Gasaway d...@gasaway.org wrote: On Wed, Oct 29, 2014 at 4:10 PM, Alex Mauer ha...@hawkesnest.net wrote: I think you could do this by just using the %work% or %_recordingtitle% tags in Picard, no? %work% might, if: 1) The work has a title alias for the locale matching my release. (not likely!) That's solved easily enough by, well, adding an alias :) It might be a bit more work short-term maybe, but it should eventually need less effort anyway since they'll already be there for any other releases of the same work. 2) Picard places that alias into %work% instead of the work title. If this is not possible now, we should add a Picard ticket. Your proposal gives details about how to handle things like language, which Reosarevok's draft currently avoids. I agree this should not be left to user's preference. But I'm still not convinced there is any advantage in normalizing numbering or vocal ranges and roles. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
2014-10-30 16:45 GMT+01:00 David Gasaway d...@gasaway.org: On Thu, Oct 30, 2014 at 1:25 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: That's solved easily enough by, well, adding an alias :) It might be a bit more work short-term maybe, but it should eventually need less effort anyway since they'll already be there for any other releases of the same work. It's more than a bit more work, especially if we're talking about a opera, oratorio, or something else similarly massive. :) Anyway, let me cut to the chase. I'm not asking for a return of pre-NGS track titles or fancy features in Picard. I've long since accepted that I'm going to have to make my own titles for classical. Still, I would like to see a minimal amount of editing (punctuation and numbering, primarily) for the sake of consistency. This also makes it a lot easier to write scripts to massage the data into something closer to the end product. Doesn't this mean that we should start thinking about support for translating work and recording titles? I guess this would be a major change, and it would need a long time to implement it, but I believe will have to get there eventually, so why not start thinking about how it should be set up now? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
2014-10-29 19:39 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com: Forgot to mention, also, that part of the idea is to get rid of http://wiki.musicbrainz.org/Style/Specific_types_of_releases/Opera at the same time, since that basically only says put as much info as possible on opera track titles, even if not on the release which seems to mostly go against what we're moving towards with NGS. I'm all for removing standardization on classical track titles (apart from prepending the work name as recommended in your draft). As long as all the tracks of a release use a consistent formatting, no problem. In classical, standardizing works and recordings is enough, IMO. If a user wants to use some kind of standardization, let him do it too. BTW, your draft always puts the work first. In some releases (mostly compilations), I believe I saw the work name in the track title, like Allegro from Symphony ## or Allegro (Symphony ##). I'm not sure we should ask to standardize those. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
2014-10-29 20:53 GMT+01:00 caller#6 caller...@gmail.com: On 10/29/2014 12:47 PM, Frederic Da Vitoria wrote: 2014-10-29 19:39 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com: Forgot to mention, also, that part of the idea is to get rid of http://wiki.musicbrainz.org/Style/Specific_types_of_releases/Opera at the same time, since that basically only says put as much info as possible on opera track titles, even if not on the release which seems to mostly go against what we're moving towards with NGS. I'm all for removing standardization on classical track titles (apart from prepending the work name as recommended in your draft). As long as all the tracks of a release use a consistent formatting, no problem. Does that mean you disagree with standardizing the separators? (i.e. colon for parts, dot for movements I wouldn't put it as strongly as disagree, but yes, if I was asked to vote yes or no to track title standardization, I'd vote no. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
2014-10-29 21:17 GMT+01:00 Alex Mauer ha...@hawkesnest.net: On 10/29/2014 01:32 PM, Nicolás Tamargo de Eguren wrote: Right now it does not mention movement numbering at all. That's intentional (I feel 1. vs. I. is fairly minor and can be left to people's preference or used as on the release) but if people think it should be standardised, we can do that too, probably with one of the following: b) For movement numbers, use whatever the release has, followed by a dot (both I. Allegro and 1. Allegro are equally acceptable) I lean towards option 'b'. I’d rather not leave it to preference, because it’s better to have a definitive answer rather than edit wars or silly no-votes. Good point. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Changes to our style process (Important)
2014-10-23 22:08 GMT+02:00 Robert Bihlmeyer ro...@orcus.priv.at: On 2014-10-23 00:30, Nicolás Tamargo de Eguren wrote: For checking what changes have happened, we'll be posting on the blog (category Style) a list of implemented changes every two weeks (more or less). Can we get versioned (or time stamped) style documents? That would make it possible to look up style-as-was-fashionable-when-this-edit-was-made. It is sometimes useful to determine why an edit was done the way it was. Am I missing something or wouldn't the wiki history answer this need? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Concertmaster relationships (STYLE-328/STYLE-341)
2014-10-20 21:52 GMT+02:00 Nicolás Tamargo de Eguren reosare...@gmail.com: On Mon, Oct 20, 2014 at 10:50 PM, Rachel Dwight hibiscuskazen...@gmail.com wrote: On Oct 20, 2014, at 2:00 PM, Nicolás Tamargo de Eguren reosare...@musicbrainz.org wrote: A lot of orchestral releases give information on the orchestra's leader/concertmaster for that recording. Similarly, orchestra sites fairly often provide information about the concertmaster position. As WP says, The concertmaster [...] is the second-most significant person in an orchestra - so we probably should allow to record this information. For that I'd like to add artist-recording and artist-release concertmaster relationships, similarly to the conductor ones, plus a concertmaster attribute to the artist-artist member of relationship, to relate the people to the orchestras (since concertmasters are usually first violin or whatever, but in any case a member of the orchestra). Does anyone feel any of the two changes would be problematic, and if so, why and what would be a better way of storing this info? I don’t really see any problems with it. (Is it too soon to +1?) Well, with the new style process there's no real schedule or need for +1ing as such, although knowing that people think the change is ok is never a bad thing so I can eventually take a decision :) OK, since you asked for it: I don't see any reason for not doing this either. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Master and Performance entities
2014-09-24 23:50 GMT+02:00 symphonick symphon...@gmail.com: 2014-09-24 7:54 GMT+02:00 Frederic Da Vitoria davito...@gmail.com: 2014-09-23 23:31 GMT+02:00 symphonick symphon...@gmail.com: 2014-09-19 11:34 GMT+02:00 Frederic Da Vitoria davito...@gmail.com: 2014-09-19 11:18 GMT+02:00 Tom Crocker tomcrockerm...@gmail.com: Is this the thing we want to represent, is it definable and do we often / ever have data about it on compilations? Do we want to attach mastering credits on a per-track basis? That seems a bit backwards. Why backwards? There are certainly lots of situations where masters will come from different sources. I am of course thinking of compilations, but also of releases such as this https://musicbrainz.org/release/86d5fc27-0b65-4750-95e2-fb42d6017c4e, the second disc could be a different master. There are lots of potential sources for tracks on compilations (old vinyl, tapes, masters...) but what do we want to be able to represent? What level of complexity and what fit with reality? Do we care about the vinyl master vs. the CD master? It might be the best solution to enter a mastering credit (mastered by ... on ...) on a per track basis but if masters are much more like an ordered set of (our type of) recordings it might be best to represent them as such, and see if there's a way within that we can handle complexities like compilations. If that was at a medium level it would work with your suggested release. My preference would be for sound differences. If the CD sounds exactly like the vinyl (this is not plausible but it should be possible), then I'd expect only one Master in MB. But if the sounds differ, then I expect 2 separate Masters, even if both are on the same medium. Of course, data should be also taken into account. If a mastering engineer recreates exactly the same sound as another master, there should be 2 Masters in MB because there would be 2 Mastering Engineer ARs to enter. Percieved sound differences are in practice unusable as proof, unless we are dealing with intended differences; like 1973 version vs. 2010 remaster. But in those cases you would have liner notes or similar anyway. Yes, if we are speaking of albums. But in compilations, liner notes are often missing, so that we have to rely on our ears to decide. More than anything, if we do add something let's make sure it is simple to use and transparent to anyone who doesn't care. Yes, very important! Users who don't understand what a master is (and furthermore, what MB calls a Master) should not be tempted to enter data. But, I also think KRSCuan might be right. We have tons of stuff to fix and millions of releases to add, so I'm not sure adding another potential layer of data that most people won't care about is the best use of our time. I am not sure either, and I agree there could be more urgent things to develop (like the reliability data you wrote about above). OTOH, the volume of missing releases should not prevent us from improving existing data. Just like the fact that we will certainly never know the names of all the engineers who recorded existing tracks should not induce us to throw away the Recording Engineer AR. Regarding specific tracks; maybe a (release - release) AR which would show the master engineer @ track level when (if) you know the exact release a specific compilation track was sourced from? Otherwise some sort of headings inside the release group for specific masters maybe could work? Like: Release ... Official Foo CD Foo Vinyl *1997 remaster Foo CD *2010 remaster Foo CD probably leave deafult = unspecified = original. My suggestion would be to have no more detail than this. There must be something I am missing here: Our developers have created a quite efficient release tracks editor which enables us to enter ARs for all the tracks at the same time with almost no more work than entering a release level AR. So why not enable something similar for masters (if / when then are implemented)? Now you got me worried; it's already quite hard to find the exact recording you want when there are lots of similar recordings to choose from. How would the master-info be shown in the search boxes? You are right, I don't see a good answer to this question. Sometimes ARs would give the clue (mastering engineer, of course), but we won't always have this data, and sometimes the mastering engineer could be misleading. And of course a good data structure without an UI is useless. I still think that it would be nice to be able one day to go to Track level, and the design for Release level should IMO be made in such a way that we will be able to switch to Release level without losing data. As long as we limit ourselves to Release level masters, I think that users should not enter masters for track compilations (except for re-masters of compilations). -- Frederic Da Vitoria (davitof) Membre de l'April
Re: [mb-style] Master and Performance entities
2014-09-25 12:45 GMT+02:00 lixobix arjtap...@gmail.com: Frederic Da Vitoria wrote 2014-09-24 23:50 GMT+02:00 symphonick lt; symphonick@ gt;: 2014-09-24 7:54 GMT+02:00 Frederic Da Vitoria lt; davitofrg@ gt;: 2014-09-23 23:31 GMT+02:00 symphonick lt; symphonick@ gt;: 2014-09-19 11:34 GMT+02:00 Frederic Da Vitoria lt; davitofrg@ gt;: 2014-09-19 11:18 GMT+02:00 Tom Crocker lt; tomcrockermail@ gt;: Is this the thing we want to represent, is it definable and do we often / ever have data about it on compilations? Do we want to attach mastering credits on a per-track basis? That seems a bit backwards. Why backwards? There are certainly lots of situations where masters will come from different sources. I am of course thinking of compilations, but also of releases such as this https://musicbrainz.org/release/86d5fc27-0b65-4750-95e2-fb42d6017c4e, the second disc could be a different master. There are lots of potential sources for tracks on compilations (old vinyl, tapes, masters...) but what do we want to be able to represent? What level of complexity and what fit with reality? Do we care about the vinyl master vs. the CD master? It might be the best solution to enter a mastering credit (mastered by ... on ...) on a per track basis but if masters are much more like an ordered set of (our type of) recordings it might be best to represent them as such, and see if there's a way within that we can handle complexities like compilations. If that was at a medium level it would work with your suggested release. My preference would be for sound differences. If the CD sounds exactly like the vinyl (this is not plausible but it should be possible), then I'd expect only one Master in MB. But if the sounds differ, then I expect 2 separate Masters, even if both are on the same medium. Of course, data should be also taken into account. If a mastering engineer recreates exactly the same sound as another master, there should be 2 Masters in MB because there would be 2 Mastering Engineer ARs to enter. Percieved sound differences are in practice unusable as proof, unless we are dealing with intended differences; like 1973 version vs. 2010 remaster. But in those cases you would have liner notes or similar anyway. Yes, if we are speaking of albums. But in compilations, liner notes are often missing, so that we have to rely on our ears to decide. More than anything, if we do add something let's make sure it is simple to use and transparent to anyone who doesn't care. Yes, very important! Users who don't understand what a master is (and furthermore, what MB calls a Master) should not be tempted to enter data. But, I also think KRSCuan might be right. We have tons of stuff to fix and millions of releases to add, so I'm not sure adding another potential layer of data that most people won't care about is the best use of our time. I am not sure either, and I agree there could be more urgent things to develop (like the reliability data you wrote about above). OTOH, the volume of missing releases should not prevent us from improving existing data. Just like the fact that we will certainly never know the names of all the engineers who recorded existing tracks should not induce us to throw away the Recording Engineer AR. Regarding specific tracks; maybe a (release - release) AR which would show the master engineer @ track level when (if) you know the exact release a specific compilation track was sourced from? Otherwise some sort of headings inside the release group for specific masters maybe could work? Like: Release ... Official Foo CD Foo Vinyl *1997 remaster Foo CD *2010 remaster Foo CD probably leave deafult = unspecified = original. My suggestion would be to have no more detail than this. There must be something I am missing here: Our developers have created a quite efficient release tracks editor which enables us to enter ARs for all the tracks at the same time with almost no more work than entering a release level AR. So why not enable something similar for masters (if / when then are implemented)? Now you got me worried; it's already quite hard to find the exact recording you want when there are lots of similar recordings to choose from. How would the master-info be shown in the search boxes? You are right, I don't see a good answer to this question. Sometimes ARs would give the clue (mastering engineer, of course), but we won't always have this data, and sometimes the mastering engineer could be misleading. And of course a good data structure without an UI is useless. I still think that it would be nice to be able one day to go to Track level, and the design for Release level should IMO be made in such a way
Re: [mb-style] Master and Performance entities
2014-09-24 13:54 GMT+02:00 lixobix arjtap...@gmail.com: Frederic Da Vitoria wrote There must be something I am missing here: Our developers have created a quite efficient release tracks editor which enables us to enter ARs for all the tracks at the same time with almost no more work than entering a release level AR. So why not enable something similar for masters (if / when then are implemented)? MusicBrainz-style@.musicbrainz http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style I think the issue is that whilst there is a strong argument that master should link recordings and tracks, there is also a strong desire to display the information at release level, so that one can easily see that releases a,b, and c use x masters of the recordings, whilst releases d, e, and f use y masters. Ah, I see. Couldn't the release-level master info be computed dynamically from track-level? I mean, of course it technically could, but would it cost too much in terms of overhead? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Master and Performance entities
2014-09-23 23:31 GMT+02:00 symphonick symphon...@gmail.com: 2014-09-19 11:34 GMT+02:00 Frederic Da Vitoria davito...@gmail.com: 2014-09-19 11:18 GMT+02:00 Tom Crocker tomcrockerm...@gmail.com: Is this the thing we want to represent, is it definable and do we often / ever have data about it on compilations? Do we want to attach mastering credits on a per-track basis? That seems a bit backwards. Why backwards? There are certainly lots of situations where masters will come from different sources. I am of course thinking of compilations, but also of releases such as this https://musicbrainz.org/release/86d5fc27-0b65-4750-95e2-fb42d6017c4e, the second disc could be a different master. There are lots of potential sources for tracks on compilations (old vinyl, tapes, masters...) but what do we want to be able to represent? What level of complexity and what fit with reality? Do we care about the vinyl master vs. the CD master? It might be the best solution to enter a mastering credit (mastered by ... on ...) on a per track basis but if masters are much more like an ordered set of (our type of) recordings it might be best to represent them as such, and see if there's a way within that we can handle complexities like compilations. If that was at a medium level it would work with your suggested release. My preference would be for sound differences. If the CD sounds exactly like the vinyl (this is not plausible but it should be possible), then I'd expect only one Master in MB. But if the sounds differ, then I expect 2 separate Masters, even if both are on the same medium. Of course, data should be also taken into account. If a mastering engineer recreates exactly the same sound as another master, there should be 2 Masters in MB because there would be 2 Mastering Engineer ARs to enter. Percieved sound differences are in practice unusable as proof, unless we are dealing with intended differences; like 1973 version vs. 2010 remaster. But in those cases you would have liner notes or similar anyway. Yes, if we are speaking of albums. But in compilations, liner notes are often missing, so that we have to rely on our ears to decide. More than anything, if we do add something let's make sure it is simple to use and transparent to anyone who doesn't care. Yes, very important! Users who don't understand what a master is (and furthermore, what MB calls a Master) should not be tempted to enter data. But, I also think KRSCuan might be right. We have tons of stuff to fix and millions of releases to add, so I'm not sure adding another potential layer of data that most people won't care about is the best use of our time. I am not sure either, and I agree there could be more urgent things to develop (like the reliability data you wrote about above). OTOH, the volume of missing releases should not prevent us from improving existing data. Just like the fact that we will certainly never know the names of all the engineers who recorded existing tracks should not induce us to throw away the Recording Engineer AR. Regarding specific tracks; maybe a (release - release) AR which would show the master engineer @ track level when (if) you know the exact release a specific compilation track was sourced from? Otherwise some sort of headings inside the release group for specific masters maybe could work? Like: Release ... Official Foo CD Foo Vinyl *1997 remaster Foo CD *2010 remaster Foo CD probably leave deafult = unspecified = original. My suggestion would be to have no more detail than this. There must be something I am missing here: Our developers have created a quite efficient release tracks editor which enables us to enter ARs for all the tracks at the same time with almost no more work than entering a release level AR. So why not enable something similar for masters (if / when then are implemented)? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Master and Performance entities
2014-09-19 11:07 GMT+02:00 KRSCuan donc...@gmx.de: On 19.09.2014 10:17, Frederic Da Vitoria wrote: I've seen this in downloadable tracks from compilations (soemthing like remaster). Not very good (there could be 2 remasters the same year) but it gives an indication. Maybe we should add a reliability flag, allowing to say: these sound the same or these are the same according to credits. You gave an excellent suggestion that master data should stay out of the way for uninterested users, so that for users who are interested we can have a fairly complex UI. Thing is, we used to have those separated by them being different recordings. We then chose to throw that info away by merging different masters/remasters, even in cases where they have different information (I remember some Queen remasters having distinct ISRCs) and fingerprints. Now we try to replicate the info we've just thrown away before? Seems like a wasted effort. And I'd argue that we have more important things that need fixing. I'm not saying the earlier decision regarding masters was necessarily the best one, quite the contrary. But it's hard to row back now. And I don't know whether it's really still worth it. In most cases the information is simply not available, and most of our users probably won't care. And if they don't care, a master entity won't see any use. I agree it will be hard. I agree it would probably have been easier if we hadn't thrown away the data first. I objected when this decision was taken. But now that we are going back, I'm ready to enter the data for masters when I'm aware of it, even if this isn't the optimal path to do it. I disagree that the fact some (most?) users don't care means it won't be any use. The data that is here is useful, even if it not complete. But the UI for Masters should be out of the way so that users who don't care are not bothered by it and are not tempted to enter bad data. Is this the thing we want to represent, is it definable and do we often / ever have data about it on compilations? Do we want to attach mastering credits on a per-track basis? That seems a bit backwards. Why backwards? There are certainly lots of situations where masters will come from different sources. I am of course thinking of compilations, but also of releases such as this https://musicbrainz.org/release/86d5fc27-0b65-4750-95e2-fb42d6017c4e, the second disc could be a different master. We just got rid of lots of mastering credits on recordings, which were moved back to releases. If we try to attach these to tracks or a new kind of entity, we are again rowing backwards. If rowing backwards is the only way to go in the right direction, then let's do it, instead of persisting in rowing in the wrong direction! -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Master and Performance entities
2014-09-19 11:18 GMT+02:00 Tom Crocker tomcrockerm...@gmail.com: I think it depends what we want to represent and store. My understanding of a master pretty much fits our existing mediums. I also know you can recognise broader remastered albums and notice the same processed version of a song has been used on various compilations, though I've never come across a credit to back that up beyond reissues of the same album. I've seen this in downloadable tracks from compilations (soemthing like remaster). Not very good (there could be 2 remasters the same year) but it gives an indication. Useful to know Maybe we should add a reliability flag, allowing to say: these sound the same or these are the same according to credits. (Much) more broadly I'd love it if we could introduce a 'source' similar to wikidata, since nothing is certain and is based on stronger or weaker claims... Ah, yes, I have been hoping for something like this for a long time. Is this the thing we want to represent, is it definable and do we often / ever have data about it on compilations? Do we want to attach mastering credits on a per-track basis? That seems a bit backwards. Why backwards? There are certainly lots of situations where masters will come from different sources. I am of course thinking of compilations, but also of releases such as this https://musicbrainz.org/release/86d5fc27-0b65-4750-95e2-fb42d6017c4e, the second disc could be a different master. There are lots of potential sources for tracks on compilations (old vinyl, tapes, masters...) but what do we want to be able to represent? What level of complexity and what fit with reality? Do we care about the vinyl master vs. the CD master? It might be the best solution to enter a mastering credit (mastered by ... on ...) on a per track basis but if masters are much more like an ordered set of (our type of) recordings it might be best to represent them as such, and see if there's a way within that we can handle complexities like compilations. If that was at a medium level it would work with your suggested release. My preference would be for sound differences. If the CD sounds exactly like the vinyl (this is not plausible but it should be possible), then I'd expect only one Master in MB. But if the sounds differ, then I expect 2 separate Masters, even if both are on the same medium. Of course, data should be also taken into account. If a mastering engineer recreates exactly the same sound as another master, there should be 2 Masters in MB because there would be 2 Mastering Engineer ARs to enter. More than anything, if we do add something let's make sure it is simple to use and transparent to anyone who doesn't care. Yes, very important! Users who don't understand what a master is (and furthermore, what MB calls a Master) should not be tempted to enter data. But, I also think KRSCuan might be right. We have tons of stuff to fix and millions of releases to add, so I'm not sure adding another potential layer of data that most people won't care about is the best use of our time. I am not sure either, and I agree there could be more urgent things to develop (like the reliability data you wrote about above). OTOH, the volume of missing releases should not prevent us from improving existing data. Just like the fact that we will certainly never know the names of all the engineers who recorded existing tracks should not induce us to throw away the Recording Engineer AR. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Master and Performance entities
2014-09-19 11:32 GMT+02:00 LordSputnik ben.s...@gmail.com: KRSCuan wrote Thing is, we used to have those separated by them being different recordings. We then chose to throw that info away by merging different masters/remasters, even in cases where they have different information (I remember some Queen remasters having distinct ISRCs) and fingerprints. Now we try to replicate the info we've just thrown away before? Seems like a wasted effort. And I'd argue that we have more important things that need fixing. ISRCs should remain on the recording level, no matter what. They're simply too badly regulated and subjectively assigned for us to reliably attach them to anything else. AcoustIDs generally can't distinguish between different masters anyway, so the recording is the correct place for those. The other information you refer to should not have been lost. The recording guidelines make provisions for storing mastering information in all cases (release-level for mastering of while releases, release annotation for separately mastered tracks), until we decide on a better system. If it's the case that different mastering per-track is very rare, and people have no real need for an alternative, then I have no problem keeping the current system, where the release is also essentially the master entity. There is one situation where I would really like per-track mastering information data: I sometimes buy tracks from when I was young. Of course I'd like to get the best possible sound, but I still want to recognize the tracks. Some digital remasters are so different that I barely recognize the song (I was particularly thinking of a remaster of Jethro Tull's Locomotive Breath). If MB had Mastering information, I'd have avoided listening to many samples from many compilations to find a correct track. And even if MB hadn't had this data for this recording when I decided to buy it, I could have entered the results of my tests in MB. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Master and Performance entities
2014-09-16 19:58 GMT+02:00 LordSputnik ben.s...@gmail.com: Frederic Da Vitoria wrote I now see that another way to handle the problem would be to systematically create a different Master for each track, and later merge those we decide to consider identical. I believe that's the way MB handled this kind of situation until now. In this case, no need for an undefined status, but the editors will have to merge lots of Masters instead of creating new ones. I am not sure this is a better solution. Well, perhaps we could allow either a master and a recording to be linked to a track, bypassing the need to do anything special for undefined masters? lixobix wrote Why not both? Both have different uses. Although perhaps (1) should be approached in a broader way: as 'edition' or something, rather than master. This would allow for the grouping releases that share the same mastering, and also e.g. those that have the same track lists / bonus tracks. I'm not sure about adding Edition - this seems to overlap too much with release groups, and also in most cases there'll be a 1:1 relationship between Editions and Releases. Yes, this would be a good solution too. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Master and Performance entities
2014-09-14 14:00 GMT+02:00 LordSputnik ben.s...@gmail.com: Just over a year ago now, we redefined the MusicBrainz recording entity. Previously, it had mainly been seen as one of two different things, depending on which editor you asked - either a mix or a master. This resulted in a lot of subjective decision making when merging or splitting recordings, with arguments over whether the practically identical recordings contained unique audio. A lot of the time, decisions had to be made based on listening to the track (not always possible) or looking at AcoustID data (not always accurate). So, recording was redefined to represent distinct audio prior to final mastering (http://wiki.musicbrainz.org/recording). In most cases (for songs, anyway), this corresponds to the mix. This means that we're left with a gap in the MusicBrainz model, since there is no entity to represent audio at the master level. Back when recordings were redefined, it was agreed that masters should be implemented in some form in the future, so I've made this thread to get some ideas on what form they should take. Additionally, it would be nice to hear thoughts on a Performance entity, which was also discussed last year. My own thoughts: Master audio could be represented in one of two ways: - 1. as an entity which groups releases with identical mastering. - 2. as an entity which seamlessly fits between recordings and tracks, and allows the grouping of tracks with shared mastering. #1 seems the least complicated way of doing things, but #2 would allow for cases where mastered audio from different sources has been copied to some other release (eg. some compilations) I also think that we might be able to use the new Event entity for storing Performances - we could introduce a new recording session for or recorded at relationship to link Events to Recordings. Anyway, let me know your thoughts, and we can try to come up with some sort of plan! Ben / LordSputnik I think we don't really have a choice: it will have to be #2 for the reason you gave. One thought; many times (most of the times?) the master will be impossible to chose. This should be part of whatever we build. I believe simply allowing users to create temporary undefined masters for such situations would be dangerous. For recording from the sixties. there existed analog and digital masters. A user could later set the undefined master to digital because he saw DDD on his CD and thus store false data in MB (not all masters were digital). So IMO we should either allow for no master, or create a special kind of master which could not be edited. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] 'Studio' secondary RG type
2014-04-03 3:11 GMT+02:00 Tom Crocker tomcrockerm...@gmail.com: ~ too much work I think it's good to be explicit in a database like this where you know it's often incomplete so can't make inferences based on the absence of stuff. However, given it would apply to most releases and is usually reflected by lack of a live type I think it's too much work. I also think we'd have to define it as 'not live' which doesn't seem great. Yes, in the current situation, you can not be sure an album is studio or if nobody bothered to check live. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC add Project Gutenberg to the whitelist of sites
+1 2014-03-21 11:09 GMT+01:00 Daniel Sobey d...@dns.id.au: Expected expiration date: 4th of May 2014 Ticket: STYLE-301 http://tickets.musicbrainz.org/browse/STYLE-301 Project Gutenberg is a website providing books for free. Most books are under the public domain. For texts that are not under the public domain they are under a licence that allows the text to be redistributed. A majority of the books are out of copyright so there should not be any copyright issues. You can find more information about this on http://www.gutenberg.org/ If this site is put on the white list will allow works to be linked directly to a url where the full text is avalable. This is useful for librivox, a project where the public read these public domain texts and submit the recordings to the site.http://musicbrainz.org/label/50e2dce0-8277-4453-be76-475da4a21b95 contain some examples of these recordings in the database. This would then allow a plugin to download the text and embed this as lyrics inside the file. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-STYLE-296. remove bogus attribute work-work version TRANSLATED
2014-03-04 15:21 GMT+01:00 Frederik Freso S. Olesen freso...@gmail.com: Den 04-03-2014 12:57, Frederic Da Vitoria skrev: What I mean is that any information is only valid in a certain reference frame. Currently, we tend to record only legally confirmed data, or information which does not contradict legally confirmed data. What if an official artist stated that someone else contributed to a work or a recording? The second artist doesn't hold any rights on the recording or the work, the second artist's role is not mentioned on the release or the score, but still, the official artist did acknowledge the second artist's role. AFAIK we currently don't record such information, or not in a database way. Huh? I do. (Well, I would, not sure if I have yet. I can't remember any such cases.) I tend to err on the factual side rather than the legalese one. If there's a conflict, I would note it in the annotation. You do, but last time I read about this on MB, many users didn't. For example most users will simply enter what they see on the sleeve. That's what I do most of the time because I don't have the time to check. But this means we aren't able to tell how reliable our data is, since we can't tell where it came from afterwards. This also means no user can search on printed data or legal data or on reconstructed data alone or on combinations of those. Annotations? Yes, that's the only way to do it currently. But annotations are not searchable AFAIK. They are. Just set the type in the search to be Annotation and it'll search annotation. (Mind boggling, I know!) OK, but who will think of this when doing a search? If I search for tracks related to Artist X, most of the times I won't think of doing first a direct search, then doing a new search in the annotation, then compile both result sets. Not user-friendly to say the least. And the Annotation results will be full of unrelated data if the Artist I am looking for has a common name, not to mention annotations where the artist will have been misspelled. Edit notes are useless IMO. I agree with this though. I understand what I am suggesting is a difficult change: it would mean not only adding a new column to qualify (not sure this is the correct word in English) the data, but also probably impact quite a few parts of code. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-STYLE-273. New relationship attribute : unsure
2014-03-06 13:23 GMT+01:00 Frederik Freso S. Olesen freso...@gmail.com: Den 06-03-2014 12:33, jesus2099 skrev: could be called unsure, unverified, etc. I let the english speakers find the appropriate work. for cases like The song is sometimes co-credited to Reginald Connelly but not only -- for guesses too for instance. I'm not a huge fan of this idea. I think that unsure information should be marked in the annotation or at the very least in edit notes. How unsure do we have to be to use the unsure? If we're 98% sure about something, that's still not 100%. Do we use it? For something we just saw on a random site and thus cannot put any claim on the factualness of it what-so-ever, should it even be added to the database proper? I'm leaning towards a no to the latter. -1 This is somewhat related to another answer I posted today about telling where data comes from. I agree that unsure or unconfirmed is too vague. I'd need at least a mandatory comment explaining why the flag has been raised. -- Frederic Da Vitoria (davitof) Membre de l'April - promouvoir et défendre le logiciel libre - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-STYLE-296. remove bogus attribute work-work version TRANSLATED
2014-03-04 8:27 UTC+01:00, Rachel Dwight hibiscuskazen...@gmail.com: On Mar 3, 2014, at 3:54 PM, Frederic Da Vitoria davito...@gmail.com wrote: 2014-03-03 22:23 GMT+01:00 symphonick symphon...@gmail.com: It sounds like the old mb-classic releases vs. facts. Right :-) We can't (IMO) put incorrect information @ mb-work level. Right now I don't have any ideas except use the release annotation? or add extra release credits AND use the release annotation? I once suggested that we need to qualify the information: is it factual, it it legal, is it just plausible but unproven information? Isn't that what edit notes are for? Or do you mean something else (e.g. when there's been a lawsuit that necessitates additional credits and we state such in the annotation)? What I mean is that any information is only valid in a certain reference frame. Currently, we tend to record only legally confirmed data, or information which does not contradict legally confirmed data. What if an official artist stated that someone else contributed to a work or a recording? The second artist doesn't hold any rights on the recording or the work, the second artist's role is not mentioned on the release or the score, but still, the official artist did acknowledge the second artist's role. AFAIK we currently don't record such information, or not in a database way. This leads us to IMO silly data, like using a company as an Artist (because the company holds the rights). For example, many Beatles songs are recorded in MB indistinctly to Lennon and McCartney, although there are seemingly reliable sources of informations about who wrote what. I believe we should progressively extend the database to accomodate such discrepancies, and stop doing as if legal rights meant everything. Of course, we should still beware of lawsuits, but I believe we could record more information without taking too much chances. Annotations? Yes, that's the only way to do it currently. But annotations are not searchable AFAIK. If MB was a wiki, it would be fine, but MB is a database, and any data which lands in such free-form fields is much less useful. Edit notes are useless IMO. Edit notes disappear from the user's point of view -- Frederic Da Vitoria (davitof) Membre de l'April - promouvoir et défendre le logiciel libre - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-STYLE-296. remove bogus attribute work-work version TRANSLATED
2014-03-03 21:44 GMT+01:00 Rachel Dwight hibiscuskazen...@gmail.com: On Mar 3, 2014, at 1:57 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Mon, Mar 3, 2014 at 9:51 PM, SwissChris swissch...@gmail.com wrote: So if that means an additional line in the guidelines, saying Do only use if it really is a pretty close translation, otherwise use simply ''version of'' I could probably +1 this, too - even if I don't believe it will change much. What would the term be to use in relationships for the person that wrote the translated/adapted/different-language lyrics? I assume we'd use translator if it's a translation (plus the original lyricist as lyricist) and lyricist if it's not (without the original lyricist credited). This is what irks me. Releases give credit to original lyricists because if they didn't, said lyricist could turn around and sue for lack of credit (and accompanying royalties). It's not fair that we act any differently; one of these days some songwriter could come and sue us for not crediting him/her properly. Then IMO this means we need a new AR for this. After all, those credits usually don't say that those are translations, they only tell who wrote the original lyrics. So if they don't use the word translation, why should we? -- Frederic Da Vitoria (davitof) Membre de l'April - promouvoir et défendre le logiciel libre - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-STYLE-296. remove bogus attribute work-work version TRANSLATED
2014-03-03 22:23 GMT+01:00 symphonick symphon...@gmail.com: It sounds like the old mb-classic releases vs. facts. Right :-) We can't (IMO) put incorrect information @ mb-work level. Right now I don't have any ideas except use the release annotation? or add extra release credits AND use the release annotation? I once suggested that we need to qualify the information: is it factual, it it legal, is it just plausible but unproven information? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-STYLE-296. remove bogus attribute work-work version TRANSLATED
2014-03-01 11:10 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com: On Sat, Mar 1, 2014 at 12:03 PM, symphonick symphon...@gmail.com wrote: How are you going to connect separate between translations different lyrics without a specific relationship? ex. Melody X with lyrics A in language B / Melody X with lyrics A translated to language C / Melody X with lyrics D in language B / Melody X with lyrics E in language F / Melody Y (same title as Melody X) with lyrics A in language B / Melody Y with lyrics A translated to language C I think part of the problem here is that translation is currently used pretty much as some lyrics in a different language whether it's a translation or not (which IMO is a mistake) rendering it meaningless. If we did indicate actual translations with this attribute, and unrelated lyrics were just version or based on or whatever, I'd certainly be quite happier myself. Chris says we wouldn't always be able to tell - well if in doubt, don't claim it's a translation sounds reasonable and workable to me, dunno about others. +1 -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV STYLE-278: Add Stadium/Arena as place type
2014-02-21 0:22 GMT+01:00 jesus2099 hta3s836gzac...@jetable.org: and i will never know or remember the difference between arena and stadium as in my language there is only one word and the reasons to distingushi them are both obscure to me and not related to music altogether. it seems that the distinction may be subjective or subject to change with time (based on what sport is played in it). but it will always be a VENUE. ;) You are speaking of French, right? There are two words in French (arène and stade) which seem close to arena and stadium. But IIUC they have completely different meanings in the two languages. In English, it seems the difference is more about indoor versus outdoors. In French, the difference is more about the age of the structure, arène would better translate to bullring. The risk here is that French (other languages may have the same issue) users would mistakenly translate arène to arena. Maybe the label could be changed to indoor arena or arena (indoor) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV STYLE-278: Add Stadium/Arena as place type
2014-02-21 10:53 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com: On 21 Feb 2014 11:37, Frederic Da Vitoria davito...@gmail.com wrote: 2014-02-21 0:22 GMT+01:00 jesus2099 hta3s836gzac...@jetable.org: and i will never know or remember the difference between arena and stadium as in my language there is only one word and the reasons to distingushi them are both obscure to me and not related to music altogether. it seems that the distinction may be subjective or subject to change with time (based on what sport is played in it). but it will always be a VENUE. ;) You are speaking of French, right? There are two words in French (arène and stade) which seem close to arena and stadium. But IIUC they have completely different meanings in the two languages. In English, it seems the difference is more about indoor versus outdoors. In French, the difference is more about the age of the structure, arène would better translate to bullring. The risk here is that French (other languages may have the same issue) users would mistakenly translate arène to arena. Maybe the label could be changed to indoor arena or arena (indoor) Actually it was added as Indoor arena :) You foresaw this? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV STYLE-278: Add Stadium/Arena as place type
2014-02-21 11:03 GMT+01:00 symphonick symphon...@gmail.com: Interesting. In Swedish, an arena is a scene; stadium translates to sports arena. You mean that in Swedish, the difference is more about usage that about architecture? There is this in French too. Hm, human languages don't lend themselves to dichotomous analysis :-) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV [STYLE-290] Add Balance engineer relationship type
2014-02-18 23:55 GMT+01:00 Frederic Da Vitoria davito...@gmail.com: 2014-02-12 14:08 GMT+01:00 Frederic Da Vitoria davito...@gmail.com: 2014-02-12 12:45 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com : Added. Could you make sure it works fine, and add a couple examples (of both levels, ideally) that I can link to from the documentation? :) OK. As soon as I find one of the CDs where I saw it. Sorry it took me so long - recording level : http://musicbrainz.org/release/c6c2626e-aa5b-424c-bf93-995de19dd7ba I couldn't find an example of release level balance engineer (if you don't count releases where all tracks were engineered by the same engineer) I just spotted balance at the bottom of http://wiki.musicbrainz.org/Engineer_Relationship_Type . The last sentence should be removed. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV [STYLE-290] Add Balance engineer relationship type
2014-02-12 14:08 GMT+01:00 Frederic Da Vitoria davito...@gmail.com: 2014-02-12 12:45 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com : Added. Could you make sure it works fine, and add a couple examples (of both levels, ideally) that I can link to from the documentation? :) OK. As soon as I find one of the CDs where I saw it. Sorry it took me so long - recording level : http://musicbrainz.org/release/c6c2626e-aa5b-424c-bf93-995de19dd7ba I couldn't find an example of release level balance engineer (if you don't count releases where all tracks were engineered by the same engineer) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV [STYLE-290] Add Balance engineer relationship type
2014-02-12 12:45 GMT+01:00 Nicolás Tamargo de Eguren reosare...@gmail.com: Added. Could you make sure it works fine, and add a couple examples (of both levels, ideally) that I can link to from the documentation? :) OK. As soon as I find one of the CDs where I saw it. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC [STYLE-290] Add Balance engineer relationship type
This RFV is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. Ticket: http://tickets.musicbrainz.org/browse/STYLE-290 wiki: http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR Since the RFC, the only modification was to add that if there were conflicting translations, one should simply use the Engineer AR. Given no vetoes, this RFV will pass on 2014-07-11 (skipping the week-end) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationship type
Sorry, wrong title. I'll re-send it with the correct title. 2014-02-07 Brant Gibbard bgibb...@ca.inter.net: +1 Brant Gibbard Toronto, ON http://bgibbard.ca *From:* musicbrainz-style-boun...@lists.musicbrainz.org [mailto: musicbrainz-style-boun...@lists.musicbrainz.org] *On Behalf Of *Frederic Da Vitoria *Sent:* February-07-14 7:24 AM *To:* MusicBrainz style discussion *Subject:* [mb-style] RFC [STYLE-290] Add Balance engineer relationship type This RFV is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. Ticket: http://tickets.musicbrainz.org/browse/STYLE-290 wiki: http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR Since the RFC, the only modification was to add that if there were conflicting translations, one should simply use the Engineer AR. Given no vetoes, this RFV will pass on 2014-07-11 (skipping the week-end) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV [STYLE-290] Add Balance engineer relationship type
This RFV is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. Ticket: http://tickets.musicbrainz.org/browse/STYLE-290 wiki: http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR Since the RFC, the only modification was to add that if there were conflicting translations, one should simply use the Engineer AR. Given no vetoes, this RFV will pass on 2014-07-11 (skipping the week-end) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV [STYLE-290] Add Balance engineer relationship type
2014-02-07 Nicolás Tamargo de Eguren reosare...@gmail.com: On Fri, Feb 7, 2014 at 2:43 PM, Frederic Da Vitoria davito...@gmail.comwrote: This RFV is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. Ticket: http://tickets.musicbrainz.org/browse/STYLE-290 wiki: http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR Since the RFC, the only modification was to add that if there were conflicting translations, one should simply use the Engineer AR. Given no vetoes, this RFV will pass on 2014-07-11 (skipping the week-end) Hopefully you mean 2014-02-11 or you'd be skipping lots of weekends ;) Someone must have switched the 7 and the 2 on my keyboard :-D -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationship type
2014-01-28 Frederic Da Vitoria davito...@gmail.com: 2014-01-28 Staffan lift...@interface1.net 27 januari 2014, Frederic Da Vitoria davito...@gmail.com skrev: This RFC is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. Well, we would lose some information, but nothing that important. Considering that the definition seems to be somewhat unclear I think it would be best just to use engineer. Sorry, I don't understand your meaning. Do you mean that we shouldn't add balance engineer? Why? I don't see anything unclear in This relationship type should *only* be used if the engineering credit specifies a balance engineer role. Staffan, I'd like you to make your position more clear before I try RFV. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationship type
2014-02-04 Staffan Vilcans lift...@interface1.net: Frederic Da Vitoria skrev: Considering that the definition seems to be somewhat unclear I think it would be best just to use engineer. I'd like you to make your position more clear before I try RFV. I strike my objection since the definition now seems to be a balance engineer is what is called a balance engineer. Yes, if someone is called balance engineer on the sleeve, then enter her or him as such :-) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-285/2: more specific artist types for classical groups
2014-02-03 Nicolás Tamargo de Eguren reosare...@gmail.com: On Wed, Jan 29, 2014 at 1:10 PM, Frederic Da Vitoria davito...@gmail.comwrote: 2014-01-29 Nicolás Tamargo de Eguren reosare...@gmail.com On Wed, Jan 29, 2014 at 1:17 PM, symphonick symphon...@gmail.com wrote: Perhaps we can find a better wording than claim to be an orchestra? I think I understand what you mean, but The Oslo Philharmonic claims to be an orchestra doesn't sound right IMO. Perhaps. I'm not sure how else to define it though - an orchestra is a large instrumental ensemble, unless the ensemble calls itself an ensemble. You could say that I guess. http://www.oslofilharmonien.no/ Oslo-Filharmonien - orchestra (symphony) http://www.ricercarconsort.com/ - group (instrumental ensemble) Those seem clear. http://www.drottningholmsbarockensemble.net/ - group? They have ensemble in the name, but on the about us-page say they can present an orchestra. The group itself seems to be an ensemble. When they work as an orchestra, we can use the orchestra relationship. http://taverner.org/ The Taverner Choir, Consort Players - ?? There are more mixed choir/instrumental ensembles like this, e.g. Bach Collegium Japan. The Taverner specifically is a parent group, we can and probably should just link its parts as subgroups, and mark the choir as choir. For the BCJ and stuff like that, since they're not clearly either, Group would probably be it. http://en.wikipedia.org/wiki/Bo_Kaspers_Orkester - Group (jazz/pop band, translates to Bo Kasper's Orchestra) http://en.wikipedia.org/wiki/Glenn_Miller_Orchestra - orchestra? Claims to be an orchestra? There are many alternatives here: big band, jazz orchestra, jazz band and more. (dance orchestra was common in Swedish) Or did you mean only classical orchestras? Not necessarily but I know absolutely nothing about jazz (except that I don't enjoy it :) ), so I don't know how and if it applies there. The Glenn Miller one seems orchestra-ish enough to me... Jazz has quite different standards from classical. AFAIK, any group bigger that a dozen instruments could call itself orchestra, sometimes even fewer: Mahavishnu Orchestra were at some point as few as 4! Which raises the question: do we set a hard limit to what should be called orchestra, or do we stick to the definition claim to be an orchestra? And does calling oneself orchestra count as claiming to be one? I am not sure Mahavishnu Orchestra really claimed they were an orchestra. Well, some one-man bands call themselves orchestras. I was hoping people would just use common sense for this, which is why I didn't want to lock ourselves into any strict definition. I am usually quite OK with common sense, but here common sense might mean different things for users from different languages and definitely mean different things for users with different musical cultures. Orchestra does not mean the same this for an European classical music user and for a lover of New Orleans jazz... But we can try common sense and see if it needs adjustments later. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-285/2: more specific artist types for classical groups
2014-02-03 Nicolás Tamargo de Eguren reosare...@gmail.com: On Mon, Feb 3, 2014 at 12:10 PM, symphonick symphon...@gmail.com wrote: I agree with Frederic, an orchestra can mean a lot of different things. At least we have to explain what it means to claim to be an orchestra. I'm certainly open to suggestions, I'm just not too good at definitions. Any good ideas? :) Hm, now I really understand why you wanted to avoid giving a hard definition :-) First, must the definition be style independent? Should we use the same definition in classical and in jazz? Of course, it would be easier if we did, but could the same value be meaningful in all musical styles? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-285/2: more specific artist types for classical groups
2014-01-29 Nicolás Tamargo de Eguren reosare...@gmail.com On Wed, Jan 29, 2014 at 1:17 PM, symphonick symphon...@gmail.com wrote: Perhaps we can find a better wording than claim to be an orchestra? I think I understand what you mean, but The Oslo Philharmonic claims to be an orchestra doesn't sound right IMO. Perhaps. I'm not sure how else to define it though - an orchestra is a large instrumental ensemble, unless the ensemble calls itself an ensemble. You could say that I guess. http://www.oslofilharmonien.no/ Oslo-Filharmonien - orchestra (symphony) http://www.ricercarconsort.com/ - group (instrumental ensemble) Those seem clear. http://www.drottningholmsbarockensemble.net/ - group? They have ensemble in the name, but on the about us-page say they can present an orchestra. The group itself seems to be an ensemble. When they work as an orchestra, we can use the orchestra relationship. http://taverner.org/ The Taverner Choir, Consort Players - ?? There are more mixed choir/instrumental ensembles like this, e.g. Bach Collegium Japan. The Taverner specifically is a parent group, we can and probably should just link its parts as subgroups, and mark the choir as choir. For the BCJ and stuff like that, since they're not clearly either, Group would probably be it. http://en.wikipedia.org/wiki/Bo_Kaspers_Orkester - Group (jazz/pop band, translates to Bo Kasper's Orchestra) http://en.wikipedia.org/wiki/Glenn_Miller_Orchestra - orchestra? Claims to be an orchestra? There are many alternatives here: big band, jazz orchestra, jazz band and more. (dance orchestra was common in Swedish) Or did you mean only classical orchestras? Not necessarily but I know absolutely nothing about jazz (except that I don't enjoy it :) ), so I don't know how and if it applies there. The Glenn Miller one seems orchestra-ish enough to me... Jazz has quite different standards from classical. AFAIK, any group bigger that a dozen instruments could call itself orchestra, sometimes even fewer: Mahavishnu Orchestra were at some point as few as 4! Which raises the question: do we set a hard limit to what should be called orchestra, or do we stick to the definition claim to be an orchestra? And does calling oneself orchestra count as claiming to be one? I am not sure Mahavishnu Orchestra really claimed they were an orchestra. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationship type
2014-01-28 Staffan lift...@interface1.net 27 januari 2014, Frederic Da Vitoria davito...@gmail.com skrev: This RFC is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. Well, we would lose some information, but nothing that important. Considering that the definition seems to be somewhat unclear I think it would be best just to use engineer. Sorry, I don't understand your meaning. Do you mean that we shouldn't add balance engineer? Why? I don't see anything unclear in This relationship type should *only* be used if the engineering credit specifies a balance engineer role. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC [STYLE-290] Add Balance engineer relationship type
This RFC is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. Ticket: http://tickets.musicbrainz.org/browse/STYLE-290 See also: http://musicbrainz.1054305.n4.nabble.com/Balance-engineer-td4661714.html http://wiki.musicbrainz.org/History:Balance_Engineer_Relationship_Type http://musicbrainz.org/doc/Category:Engineer_Relationship_Class This ticket expires on 2014-02-04. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationship type
2014-01-27 ListMyCDs musicbra...@listmycds.com On 27.1.2014 18:05, Frederic Da Vitoria wrote: This RFC is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. +1 for this RFC. I forgot to give a link to the wiki: http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR The link sentences were copied from http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR . I'd feel more comfortable if someone who knows English better than me would check them. Also note that the original RFC separated balance engineer from Tonmeister. I suggest that MB does not need this distinction, especially since many releases seem to consider those as equivalent. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationshiptype
2014-01-27 Brant Gibbard bgibb...@ca.inter.net Not meaning to be a wet blanket, but I’ve just managed to located one of my CDs (Deutsche Gramophon) that does translate Tonmeister into other languages. The results are most unfortunate! Before the name of the engineer being credited is this quadrilingual statement: “Tonmeister / Recording Engineer / Ingénieur du son / Ingegnere del suono” Thus two of the four language versions use something reminiscent of Sound Engineer, which of course is a completely distinct MB term, and another uses Recording Engineer, again a distinct MB term. Brant Gibbard Toronto, ON http://bgibbard.ca *From:* musicbrainz-style-boun...@lists.musicbrainz.org [mailto: musicbrainz-style-boun...@lists.musicbrainz.org] *On Behalf Of *Frederic Da Vitoria *Sent:* January-27-14 11:24 AM *To:* MusicBrainz Style Discussion *Subject:* Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationshiptype 2014-01-27 ListMyCDs musicbra...@listmycds.com On 27.1.2014 18:05, Frederic Da Vitoria wrote: This RFC is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. +1 for this RFC. I forgot to give a link to the wiki: http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR The link sentences were copied from http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR . I'd feel more comfortable if someone who knows English better than me would check them. Also note that the original RFC separated balance engineer from Tonmeister. I suggest that MB does not need this distinction, especially since many releases seem to consider those as equivalent. I suppose this could happen with other engineering types. This means we'll have to take this type of situation into account. I suggest something like: In case of conflicting engineering types, prefer the one of the original release language, usually the first language in the order of translations. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationship type
2014-01-27 Calvin Walton calvin.wal...@kepstin.ca On Mon, 2014-01-27 at 17:24 +0100, Frederic Da Vitoria wrote: 2014-01-27 ListMyCDs musicbra...@listmycds.com On 27.1.2014 18:05, Frederic Da Vitoria wrote: This RFC is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. +1 for this RFC. I forgot to give a link to the wiki: http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR The link sentences were copied from http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR . I'd feel more comfortable if someone who knows English better than me would check them. This actually shows one of the issues with the current AR template: The link phrases shown here are not what we will be using on the Musicbrainz website itself! The ones on the website will look like: Release/Recording = balance engineer: Artist And I don't think the reverse phrase for artists is actually shown anywhere on the site; the relationship name balance engineer will be used as a header in the artist relationships table. You are probably right, but I wouldn't know how to say this correctly in the wiki. The formulation I used is quite similar to the one in http://musicbrainz.org/doc/Category:Engineer_Relationship_Class -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationshiptype
2014-01-27 Brant Gibbard bgibb...@ca.inter.net On checking some more of my European label CDs I find I have two Archiv CDs that credit a particular engineer twice on the same CD, once as “Tonmeister (Balance Engineer)” and once as “Recording Engineer”, so clearly they regard those as distinct roles (although DG doesn’t) On an EMI recording I have someone credited as “Tonmeister / Balance Engineer/ Ingénieur du son” Brant Gibbard Toronto, ON http://bgibbard.ca *From:* musicbrainz-style-boun...@lists.musicbrainz.org [mailto: musicbrainz-style-boun...@lists.musicbrainz.org] *On Behalf Of *Brant Gibbard *Sent:* January-27-14 11:46 AM *To:* 'MusicBrainz Style Discussion' *Subject:* Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationshiptype Not meaning to be a wet blanket, but I’ve just managed to located one of my CDs (Deutsche Gramophon) that does translate Tonmeister into other languages. The results are most unfortunate! Before the name of the engineer being credited is this quadrilingual statement: “Tonmeister / Recording Engineer / Ingénieur du son / Ingegnere del suono” Thus two of the four language versions use something reminiscent of Sound Engineer, which of course is a completely distinct MB term, and another uses Recording Engineer, again a distinct MB term. regarding French translations, we frenchies are rather poor regarding sound matters: AFAIK in France one can only be ingénieur du son, or use foreign words :-) IMO the fact that everything translates to Ingénieur du son does not mean only engineer should be used in MB. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationshiptype
2014-01-27 Nicolás Tamargo de Eguren reosare...@gmail.com On Mon, Jan 27, 2014 at 6:51 PM, Frederic Da Vitoria davito...@gmail.comwrote: 2014-01-27 Brant Gibbard bgibb...@ca.inter.net Not meaning to be a wet blanket, but I’ve just managed to located one of my CDs (Deutsche Gramophon) that does translate Tonmeister into other languages. The results are most unfortunate! Before the name of the engineer being credited is this quadrilingual statement: “Tonmeister / Recording Engineer / Ingénieur du son / Ingegnere del suono” Thus two of the four language versions use something reminiscent of Sound Engineer, which of course is a completely distinct MB term, and another uses Recording Engineer, again a distinct MB term. Brant Gibbard Toronto, ON http://bgibbard.ca *From:* musicbrainz-style-boun...@lists.musicbrainz.org [mailto: musicbrainz-style-boun...@lists.musicbrainz.org] *On Behalf Of *Frederic Da Vitoria *Sent:* January-27-14 11:24 AM *To:* MusicBrainz Style Discussion *Subject:* Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationshiptype 2014-01-27 ListMyCDs musicbra...@listmycds.com On 27.1.2014 18:05, Frederic Da Vitoria wrote: This RFC is to add Balance engineer to the Engineer relationship types. Balance engineers are often named in classical releases and just entering them as engineer seems to be losing valuable information. +1 for this RFC. I forgot to give a link to the wiki: http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR The link sentences were copied from http://wiki.musicbrainz.org/User:DavitoF/Balance_engineer_AR . I'd feel more comfortable if someone who knows English better than me would check them. Also note that the original RFC separated balance engineer from Tonmeister. I suggest that MB does not need this distinction, especially since many releases seem to consider those as equivalent. I suppose this could happen with other engineering types. This means we'll have to take this type of situation into account. I suggest something like: In case of conflicting engineering types, prefer the one of the original release language, usually the first language in the order of translations. Wouldn't In case of conflicting engineering types, use just 'engineer' make more sense? Yes probably. I edited the wiki accordingly. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Post-RFV poll: Stadium/Arena (please answer! :) )
2014/1/25 Nicolás Tamargo de Eguren reosare...@gmail.com Hi! I'm out for the weekend and I'm not too sure what to do with this, so I created a poll to find out what people actually think I should do. Could everyone (who has an opinion at all) vote on http://wiki.musicbrainz.org/User:Reosarevok/Place_types ? Thanks! :) +1. lixobix suggested that stadium and arena should actually be separated, but I think that this could be done at a later stage if we feel it worthwhile. It would imply a little editing work to separate the edits but I think we should add complexity to the places progressively. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-285: more specific artist types for classical groups
2014/1/22 Nicolás Tamargo de Eguren reosare...@gmail.com Why are you suddenly trying to turn a pretty simple, small scale thing into a full ontology? I mean, that can be pretty cool I guess, but it's far more complicated than what I wanted, which is just a way to mark a few of the most common things... Right, sorry, we are hijacking this RFC. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Instrument ontology (was:Re: RFC STYLE-285: more specific artist types for classical groups)
Switching to an independent thread. All this discussion comes from the following ideas: - ensembles are about to become numerous enough that putting some order in them would be an improvement - creating an ontology (even if this ontology is not implemented in the UI) can help us to find obviously missing ensemble types (I am definitely not saying that we should create all possible types) or maybe types which could be merged. 2014/1/22 symphonick symphon...@gmail.com 2014/1/22 Frederic Da Vitoria davito...@gmail.com 2014/1/21 symphonick symphon...@gmail.com 2014/1/21 Frederic Da Vitoria davito...@gmail.com 2014/1/21 symphonick symphon...@gmail.com One could also have the orchestras as sub-types of the general ensemble types. Isn't this mixing different ontologies? Instrumental (mixed / string / wind / brass) and size/complexity (symphony / chamber). I suggested that the orchestras could be sub-types of ensembles :-) The question is if it's easier for the user if there's a specific orchestra category anyway? You have a specific Wind category, although wind ensembles are often mixed woodwind + brass (+ percussion, which is a category I forgot about, also I'm not sure what to do with electronic instruments). Instruments first, size last *String ensemble **String orchestra **String quartet **String quintet **String trio *Wind ensemble **Wind orchestra *Brass ensemble **Brass quintet *Mixed ensemble **Symphony orchestra **Chamber orchestra **trio ***Piano trio ** quartet (not strings only) ** quintet (not strings only) ** orchestra (I am not suer this level is useful, or should it actually be named specified size?) Not all orchestras fit the description symphonic or chamber. Right, orchestra (others) missing I prefer Instruments first, size last, I find it easier to find my way to a specific ensemble, but size first is probably better for mixed ensembles I agree. Let's try some examples: http://www.rsno.org.uk/ - Symphony orchestra I'd check first whether this is actually a symphony or a chamber orchestra. But anyhow, once this is checked, finding the correct category should not be an issue How do you suggest the user should check that, when dealing with an orchestra that hasn't got chamber or symphony/philharmonic in its name (like The Royal Scottish National Orchestra?) Try finding the number of performers. If it can't be found (which is probably going to be often true), then use the fall back mixed ensemble if the user can tell by ear there are several kinds of instruments, if not even this (maybe entering a release from only printed data, or a recording so old that it is difficult to tell), then Unspecified ensemble, which is obviously missing from my suggestion :-P http://en.wikipedia.org/wiki/Ricercar_Consort - Mixed ensemble? http://www.ownvoice.com/palladianensemble/ - Mixed ensemble? http://www.drottningholmsbarockensemble.net/ - Mixed ensemble? The user would have to check whether these are single-instrument-type (for example string) ensembles or truly mixed. Chamber? Are these so small that they should be left into the ensemble fall back category? I don't understand the last part; a chamber ensemble could be a duo. Also, is there a point in having an ensemble category? What's the difference between ensemble and group? None that I can tell, only that in classical, I'd use ensemble instead of group, but that's only a question of word, not of meaning. Maybe there's no point in having a mixed ensemble either. You mean that simply ensemble would be enough? I don't know. I think that we need to be able to tell the difference between mixed and unspecified, which could be ensemble / mixed ensemble or unspecified ensemble / mixed ensemble or... I tend to prefer explicit formulations, so I prefer the last option http://www.ricercarconsort.com/http://en.wikipedia.org/wiki/Ricercar_Consort- chamber ensemble? http://www.ownvoice.com/palladianensemble/ - chamber ensemble Says The Gramophone apparently, so that on got easier. But can we explain why quartet is not to be used here? I don't understand your question. Your examples did not contain any quartet, but that does not mean that a quartet would not fit somehow. http://www.drottningholmsbarockensemble.net/ - chamber ensemble or chamber orchestra? Tricky because they have ensemble in the name, but on the about us-page say they can present an orchestra. We should give an indication of a limit between the size categories, something not really strict (one should not no-vote an edit because the numbers don't quite match), but which would help users to pick the correct answer. Agreed, but it is tricky. A symphony orchestra with symphony in its name can be a small symphony orchestra, around 60 musicians (or maybe less). Do you know how big a chamber orchestra can get? wikipedia puts the limit at 50. Why not. Any limit will always
Re: [mb-style] RFC STYLE-285: more specific artist types for classical groups
2014/1/21 symphonick symphon...@gmail.com Another issue is that chamber ensemble implies chamber music, which obviously doesn't suit jazz ensembles. (Note that you have to define the difference between a chamber ensemble and a chamber orchestra!) One possibility: *Orchestra **Chamber orchestra **Symphony orchestra **String orchestra **Wind orchestra *Brass ensemble **Brass quintet *String ensemble **String trio **String quartet **String quintet *Mixed ensemble **Chamber ensemble **Wind ensemble **Piano trio One could also have the orchestras as sub-types of the general ensemble types. Do we want genre-based ensembles eventually, e.g. baroque ensemble? Unfortunately, it means more documentation... Isn't this mixing different ontologies? Instrumental (mixed / string / wind / brass) and size/complexity (symphony / chamber). I'll try to reorganize this a little in a way which make more sense to me. I used at least all the categories above, but this does not mean that we would need all of those. Instruments first, size last *String ensemble **String orchestra **String quartet **String quintet **String trio *Wind ensemble **Wind orchestra *Brass ensemble **Brass quintet *Mixed ensemble **Symphony orchestra **Chamber orchestra **trio ***Piano trio ** quartet (not strings only) ** quintet (not strings only) Size first, instrumentation last * Ensemble ** orchestra (I am not suer this level is useful, or should it actually be named specified size?) *** Symphony orchestra *** Chamber orchestra quartet * String quartet quintet * Brass quintet * String quintet trio * Piano trio * String trio *** String orchestra *** Wind orchestra ** instrument ensembles of unspecified size *** Brass ensemble *** String ensemble *** Wind ensemble I prefer Instruments first, size last, I find it easier to find my way to a specific ensemble, but size first is probably better for mixed ensembles The best would probably a grid, or even sets, but of course none of these would lend itself to user input. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-285: more specific artist types for classical groups
2014/1/21 symphonick symphon...@gmail.com 2014/1/21 Frederic Da Vitoria davito...@gmail.com 2014/1/21 symphonick symphon...@gmail.com One could also have the orchestras as sub-types of the general ensemble types. Isn't this mixing different ontologies? Instrumental (mixed / string / wind / brass) and size/complexity (symphony / chamber). I suggested that the orchestras could be sub-types of ensembles :-) The question is if it's easier for the user if there's a specific orchestra category anyway? You have a specific Wind category, although wind ensembles are often mixed woodwind + brass (+ percussion, which is a category I forgot about, also I'm not sure what to do with electronic instruments). Instruments first, size last *String ensemble **String orchestra **String quartet **String quintet **String trio *Wind ensemble **Wind orchestra *Brass ensemble **Brass quintet *Mixed ensemble **Symphony orchestra **Chamber orchestra **trio ***Piano trio ** quartet (not strings only) ** quintet (not strings only) ** orchestra (I am not suer this level is useful, or should it actually be named specified size?) Not all orchestras fit the description symphonic or chamber. Right, orchestra (others) missing I prefer Instruments first, size last, I find it easier to find my way to a specific ensemble, but size first is probably better for mixed ensembles I agree. Let's try some examples: http://www.rsno.org.uk/ - Symphony orchestra I'd check first whether this is actually a symphony or a chamber orchestra. But anyhow, once this is checked, finding the correct category should not be an issue http://en.wikipedia.org/wiki/Ricercar_Consort - Mixed ensemble? http://www.ownvoice.com/palladianensemble/ - Mixed ensemble? http://www.drottningholmsbarockensemble.net/ - Mixed ensemble? The user would have to check whether these are single-instrument-type (for example string) ensembles or truly mixed. Chamber? Are these so small that they should be left into the ensemble fall back category? We should give an indication of a limit between the size categories, something not really strict (one should not no-vote an edit because the numbers don't quite match), but which would help users to pick the correct answer. http://www.pianotrio.com/ - Piano trio Bill Evans Trio http://musicbrainz.org/artist/d0630a08-3b40-4cb4-9f48-7d525262c1f6 - Piano trio Berlin RIAS Sinfonietta - chamber orchestra? I feel that a sinfonietta is closer to a symphony orchestra than to a chamber orchestra, but I don't really care. We could as well decide to put sinfonietta into the others category, simply because there isn't a really good reason to put it elsewhere. http://en.wikipedia.org/wiki/Miles_Davis_Quintet - quintet? Well, yes, why not? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-281] Add haute-contre to the vocal tree
2014/1/20 SwissChris swissch...@gmail.com - 1 quoting myself from the vocal tree discussion, brought up in 2010 by Brian Schweizer, and proposing a massive increase of the vocal types: http://wiki.musicbrainz.org/Proposal:Advanced_Vocal_Tree So what I would do: Keep the 7 basic voice types on which all manuals agree and also used by the well-documented Wiki article http://en.wikipedia.org/wiki/Voice_type Female types: – “Soprano”: including all the sub-categories from your list (but sopranista) with the “choral types” Soprano I and Soprano II and including, as in Wikipedia, the “intermediate voice types” “Dugazon” and “Falcon”. – “Mezzo-soprano”. – “Contralto (Alt)”: including the “choral types” Alto I and Alto II; thus merging the existing “alto” type into this one (The strict distinction between “Contralto” and “Alto” is not to be found in any language I checked but English; German uses “Alt” for “Contralto”). Male types: – “Countertenor”: We should use this generic term, renaming the existing “Contratenor” (which is actually not a voice type, but a historic category of the male counter voices which could be either higher (“altus”) or lower (“bassus”) than the tenor – and is btw not even recognized by the correction program in Microsoft Word). This would include all male voice types higher than “Tenor”: Sopranista, Sopranist, Castrato, the falsetto types Male Soprano and Male Alto, Treble as well as the specific countertenor (“haute contre”). – “Tenor”: including the “choral types” Tenor I and Tenor II. – “Baritone” – “Bass”: including the “choral types” Bass I and Bass II (and the “Contratenor bassus”!). “Bass-Baritone” should be merged into this one as on the Wikipedia page (see also discussion on http://en.wikipedia.org/wiki/Talk:Bass_(voice_type) ) OK, this is what you would do. Could you explain why? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-281] Add haute-contre to the vocal tree
2014/1/20 SwissChris swissch...@gmail.com See complete discussion on this initial proposal (I somehow seem unable to produce a link to the Nabble pages: it's march/april 2010). Basically Vocal Types more specific than the seven basic types above are fuzzy, language-specific, contradicting, depending on sources and thus prone to misunderstanding and edit wars. Frederic himself in his initial proposal quotes a source that sees Haute contre as a sub-category/synonym of countertenor… On Mon, Jan 20, 2014 at 1:16 PM, Frederic Da Vitoria davito...@gmail.comwrote: 2014/1/20 SwissChris swissch...@gmail.com - 1 quoting myself from the vocal tree discussion, brought up in 2010 by Brian Schweizer, and proposing a massive increase of the vocal types: http://wiki.musicbrainz.org/Proposal:Advanced_Vocal_Tree So what I would do: Keep the 7 basic voice types on which all manuals agree and also used by the well-documented Wiki article http://en.wikipedia.org/wiki/Voice_type Female types: – “Soprano”: including all the sub-categories from your list (but sopranista) with the “choral types” Soprano I and Soprano II and including, as in Wikipedia, the “intermediate voice types” “Dugazon” and “Falcon”. – “Mezzo-soprano”. – “Contralto (Alt)”: including the “choral types” Alto I and Alto II; thus merging the existing “alto” type into this one (The strict distinction between “Contralto” and “Alto” is not to be found in any language I checked but English; German uses “Alt” for “Contralto”). Male types: – “Countertenor”: We should use this generic term, renaming the existing “Contratenor” (which is actually not a voice type, but a historic category of the male counter voices which could be either higher (“altus”) or lower (“bassus”) than the tenor – and is btw not even recognized by the correction program in Microsoft Word). This would include all male voice types higher than “Tenor”: Sopranista, Sopranist, Castrato, the falsetto types Male Soprano and Male Alto, Treble as well as the specific countertenor (“haute contre”). – “Tenor”: including the “choral types” Tenor I and Tenor II. – “Baritone” – “Bass”: including the “choral types” Bass I and Bass II (and the “Contratenor bassus”!). “Bass-Baritone” should be merged into this one as on the Wikipedia page (see also discussion on http://en.wikipedia.org/wiki/Talk:Bass_(voice_type) ) OK, this is what you would do. Could you explain why? I don't *know* that this performer is here singing as a Haute-contre, or as a countertenor, or as anything (not quite true, of course, I know he is not a bass :-) ) I don't have the knowledge, and frankly, I doubt a user would take the trouble of listening to the whole release seeking for the highest and the lowest note, the voice type, the voice power and so on, to get the actual notes sung with some tool (for all those who don't have absolute pitch), and compare the results to a scale to enter the correct voice. Furthermore, if I follow your reasoning, after attentively reading https://en.wikipedia.org/wiki/Countertenor , maybe we should remove countertenor too as it seems to say that countertenor means a few different things (among other things, countertenor seems to mean different voice ranges). Did whoever decided to print haute-contre really mean something different from contreténor, or did he only do it because he thought it would help sell the release? I don't know. But when I enter a release of Lieder, I don't know the real voice range used either, I just rely on what is printed. In other words, what are we storing when we characterize a performer's voice? - his actual voice range? - his printed voice type? - something else which I haven't thought of? My point of view here would be: enter it as printed as much as possible. Thus we avoid translation and approximation issues. I tend to prefer to enter data in such a way that is easily verified. So my position would be: let it be entered with the maximum precision available. And then let those who are not interested, or who consider that two entries actually mean the same thing (which could perfectly be true here, I am not discussing whether haute-contre are actually different or not from countertenors), downscale it to whatever they want. But maybe I am wrong here: maybe there are false friends in the vocal tree, maybe for example countertenor in English does not translate to contreténor in French. If this is true, then all the voice entries I made in MB must be checked. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC [STYLE-281] Add haute-contre to the vocal tree
2014/1/20 SwissChris swissch...@gmail.com Quoting wiki: *Number of voice types* *There are many different voice types used by vocal pedagogues today in a variety of voice classification systems. Most of these types, however, are sub-types that fall under seven different major voice categories that are for the most part acknowledged across all of the major voice classification systems. Women are typically divided into three groups: soprano http://en.wikipedia.org/wiki/Soprano, mezzo-soprano http://en.wikipedia.org/wiki/Mezzo-soprano, and contralto http://en.wikipedia.org/wiki/Contralto. Men are usually divided into four groups: countertenor http://en.wikipedia.org/wiki/Countertenor, tenor http://en.wikipedia.org/wiki/Tenor, baritone http://en.wikipedia.org/wiki/Baritone, and bass http://en.wikipedia.org/wiki/Bass_(vocal_range). When considering the pre-pubescent male voice an eighth term, treble http://en.wikipedia.org/wiki/Boy_soprano, can be applied. Within each of these major categories there are several sub-categories that identify specific vocal qualities like coloratura http://en.wikipedia.org/wiki/Coloratura facility and vocal weight http://en.wikipedia.org/wiki/Vocal_weight to differentiate between voices.* So, there's a variety of voice classification systems, which differ in terminology, structure and language/culture, while the seven voice types above are for the most part acknowledged across all of the major voice classification systems. Every term which can be found printed on covers can easily be assigned to one of these types, being either a synonym, a generally accepted translation or a sub-category, *countertenor* (and it's sub-structures) being, I admit, the most controversial of all. But the example shown in the first place has a bilingual cover, and credits the singer in french and english as haute-contre/countertenor. So where's the problem? Why would you want to use the french term in this specific case, when the corresponding english translation can easily be used? While I definitely prefer the current vocal tree, I could go, eventually, for the same system we have for the instrument tree: adding a new vocal type when five appearances of a voice type, duly documented on covers, have been entered. On Mon, Jan 20, 2014 at 6:18 PM, Frederic Da Vitoria davito...@gmail.comwrote: 2014/1/20 SwissChris swissch...@gmail.com See complete discussion on this initial proposal (I somehow seem unable to produce a link to the Nabble pages: it's march/april 2010). Basically Vocal Types more specific than the seven basic types above are fuzzy, language-specific, contradicting, depending on sources and thus prone to misunderstanding and edit wars. Frederic himself in his initial proposal quotes a source that sees Haute contre as a sub-category/synonym of countertenor… On Mon, Jan 20, 2014 at 1:16 PM, Frederic Da Vitoria davito...@gmail.com wrote: 2014/1/20 SwissChris swissch...@gmail.com - 1 quoting myself from the vocal tree discussion, brought up in 2010 by Brian Schweizer, and proposing a massive increase of the vocal types: http://wiki.musicbrainz.org/Proposal:Advanced_Vocal_Tree So what I would do: Keep the 7 basic voice types on which all manuals agree and also used by the well-documented Wiki article http://en.wikipedia.org/wiki/Voice_type Female types: – “Soprano”: including all the sub-categories from your list (but sopranista) with the “choral types” Soprano I and Soprano II and including, as in Wikipedia, the “intermediate voice types” “Dugazon” and “Falcon”. – “Mezzo-soprano”. – “Contralto (Alt)”: including the “choral types” Alto I and Alto II; thus merging the existing “alto” type into this one (The strict distinction between “Contralto” and “Alto” is not to be found in any language I checked but English; German uses “Alt” for “Contralto”). Male types: – “Countertenor”: We should use this generic term, renaming the existing “Contratenor” (which is actually not a voice type, but a historic category of the male counter voices which could be either higher (“altus”) or lower (“bassus”) than the tenor – and is btw not even recognized by the correction program in Microsoft Word). This would include all male voice types higher than “Tenor”: Sopranista, Sopranist, Castrato, the falsetto types Male Soprano and Male Alto, Treble as well as the specific countertenor (“haute contre”). – “Tenor”: including the “choral types” Tenor I and Tenor II. – “Baritone” – “Bass”: including the “choral types” Bass I and Bass II (and the “Contratenor bassus”!). “Bass-Baritone” should be merged into this one as on the Wikipedia page (see also discussion on http://en.wikipedia.org/wiki/Talk:Bass_(voice_type) ) OK, this is what you would do. Could you explain why? I don't *know* that this performer is here singing as a Haute-contre, or as a countertenor, or as anything (not quite true, of course, I know
Re: [mb-style] RFC STYLE-285: more specific artist types for classical groups
2014/1/17 Maurits mfmeulenb...@gmail.com I agree with this on principle, but wouldn't the chamber orchestra sub-types become a huge list over time? With all the possible trio's, quartets, quintets and whatnot for various possible instruments. Perhaps constrict it to the number? Op vrijdag 17 januari 2014 13:24:20, ListMyCDs schreef: On 17.1.2014 13:58, Nicolás Tamargo de Eguren wrote: Now that the orchestra attribute is going away (thankfully) we should store this data where it belongs: on the artists. I would like to add a few new artist types to more clearly store this kind of info. +1 for this RFC. ...Or simply separate the most frequent types (keep a distinct string quartet but maybe not a distinct harmonica quartet) and decide by vote when to add a new distinct ensemble. I believe that for example a string quartet is so frequent that some users will want to separate string quartets from the others one day. A query to recover all the string quartets may be difficult to devise if we don't create a separate string quartet artist type. OTOH, string quartet does not necessarily mean 2 violins 1 viola and 1 cello, so that I am less sure how significant this distinction would be. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-285: more specific artist types for classical groups
2014/1/17 Nicolás Tamargo de Eguren reosare...@gmail.com On Fri, Jan 17, 2014 at 4:17 PM, Maurits mfmeulenb...@gmail.com wrote: I agree with this on principle, but wouldn't the chamber orchestra sub-types become a huge list over time? With all the possible trio's, quartets, quintets and whatnot for various possible instruments. Perhaps constrict it to the number? My idea was to just separate the most common ones (string quartet seems like the obvious choice, I'd say piano trio is probably the second most common, but that one could be kept as part of the chamber ensemble option if people are not too sure). I'd say just by number doesn't help much - if we keep both saxophone and string quartets under the same type, we might as well just keep chamber ensemble. Frederic: I'd argue the string quartets that aren't 2 violin, viola, cello are uncommon enough that we can live with that. Anyway, +1 from me too. If we are unsure about more or less detailed list, I'd prefer more detailed. It will be simple to batch the data if we later decide to make it more terse, while the other way around of course... -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-278: Add Stadium/Arena as place type
2014/1/16 Frederic Da Vitoria davito...@gmail.com 2014/1/16 Nicolás Tamargo de Eguren reosare...@gmail.com Any other opinions or feedback on this one? I think that we should use place types to give more information, although I understand that the musical relevance of this information may be dubious. I disagree with jesus2099 because a studio recording could be made in a stadium (expensive, but technically possible) just as a live performance could be recorded in a place usually used as a studio. A church for example could be used both ways. ... so, of course, +1 ! -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-278: Add Stadium/Arena as place type
2014/1/16 Nicolás Tamargo de Eguren reosare...@gmail.com Any other opinions or feedback on this one? I think that we should use place types to give more information, although I understand that the musical relevance of this information may be dubious. I disagree with jesus2099 because a studio recording could be made in a stadium (expensive, but technically possible) just as a live performance could be recorded in a place usually used as a studio. A church for example could be used both ways. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC [STYLE-281] Add haute-contre to the vocal tree
Currently, the vocal tree only offers countertenor. Wikipedia https://en.wikipedia.org/wiki/Haute-contre considers countertenor as different from haute-contre. I have a release which credits 2 performers as haute-contre http://musicbrainz.org/release/536d22e7-4a2f-4071-b43c-14cd0c1bfc7f?tport=8000. This is the only release I own which uses haute-contre, but there must be others. Some web sites ( http://operacritiques.free.fr/css/index.php?2006/06/20/283-le-contre-tenor-et-la-haute-contre-tessitures-classification-voix-taille-epoque-baroque-tessiture) consider that haute-contre can be translated as countertenor, but that countertenor actually contains haute-contre as well as other voices. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Haute-Contre
Hello, Is haute-contre missing from the vocal tree, or is it there in a translation I don't recognize? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Haute-Contre
2014/1/11 Nicolás Tamargo de Eguren reosare...@gmail.com On Sat, Jan 11, 2014 at 9:52 PM, Frederic Da Vitoria davito...@gmail.comwrote: Hello, Is haute-contre missing from the vocal tree, or is it there in a translation I don't recognize? It's missing, unless you're willing to call it a countertenor. Seems to me haute-contre and countertenor are different, and Wikipedia agrees. Hm, it has been a long time since I haven't done a RFC in MB. Let's see. This means Ticket + RFC. Finding 5 releases with a haute-contre should be pretty easy. According to http://musicbrainz.org/doc/Proposals , I should also suggest a matching documentation, but I couldn't find any wiki page for the voice parts. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-279: Add Place of Worship as place type
2014/1/2 caller#6 meatbyproduct-musicbra...@yahoo.com On 01/01/2014 04:16 AM, Nicolás Tamargo de Eguren wrote: We have over 50 churches already, and with so much classical music being recorded in them it's only going to go up. Using Other for it when it's so obviously a type seems silly, so I'd like us to add it. Ticket: http://tickets.musicbrainz.org/browse/STYLE-279 Expected RFV date: Jan 8 To me, venue is a generic term that covers pretty much anywhere music might be played for an audience (unless there's an audience in the studio during recording, I guess). It sounds like you're thinking of venue as being specifically clubs and theatres and those sorts of purpose-built places. I'm not sure finer granularity would improve what we already have. generic term that covers pretty much anywhere music might be played: Isn't this precisely where we could do better? The acoustics of a church (which weren't primarily built for music) are completely different from those of a concert hall, as well as those of an open space such as a stadium. I believe there is here something which MusicBrainz could take into account. But I must confess (no pun intended) that I hadn't thought of what Place of Worship could mean. Acoustically, an old Romanesque or Gothic church does not sound like a small hall which could be used as a place of worship'. Now if this RFC is to be taken literally, from a usage point of view instead of an acoustical point of view, then I remove my +1. I wouldn't -1 either, I just wouldn't care. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-279: Add Place of Worship as place type
2014/1/2 jesus2099 hta3s836gzac...@jetable.org -1 I would prefer keeping simple VENUE for churches (rather than STUDIO). I don’t think what important is the primary type of place. IMO the important is the used type of place, whether VENUE or STUDIO. where a VENUE place will contain more LIVE music recordings and STUDIO places will include more recording sessions. IIUC, Nicolás' point is that currently users for some reason don't use Venue in this situation but Other, so that creating an explicit Place of Worship would allow at least to collect them. Maybe simply adding a hint the interface would be enough? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-227 Add new artist type Character
+1 as a temporary measure. I agree that Rachel's attribute would be better, but waiting for the schema change means that in the meanwhile the data can't be entered correctly, while a new type would probably be much quicker to achieve and as Calvin wrote, the new type can be migrated when the attribute is created. I believe we should think in terms of improvement, not of perfection. Is this an improvement? I think so. Is this the perfect solution? Probably not, but it would be a step in the right direction. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-279: Add Place of Worship as place type
2014/1/2 Nicolás Tamargo de Eguren reosare...@gmail.com On Thu, Jan 2, 2014 at 10:55 AM, jesus2099 hta3s836gzac...@jetable.orgwrote: -1 I would prefer keeping simple VENUE for churches (rather than STUDIO). I don’t think what important is the primary type of place. IMO the important is the used type of place, whether VENUE or STUDIO. where a VENUE place will contain more LIVE music recordings and STUDIO places will include more recording sessions. That makes no sense - churches are used for lots of non-live classical recordings as well as for lives. If you only care about whether the recording is live, you have the attribute on the recording-work rel anyway. Hm, obviously I missed a (perfectly valid) part of your point :-P -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: Make instruments entities
2014/1/1 Ben Ockmore ben.s...@gmail.com I still think that similar systems should be used for Genres and Instruments (seeing as they're both tree-based systems), so I'd like to wait until the developer decide on how they'll tackle Genres before anything happens with instruments. What I'd like to see if both Instruments and Genres as entities, which aren't created by a formal add process, but are formed from tags/words entered by users - a bottom-up approach, where user input decides what instruments and genres should be in the system. I've written this down here, and we talked about it a little at the last summit, but didn't agree on anything: https://docs.google.com/document/d/1fRfpALAX5D0RAjF7upbPcaAR70OIsQk1jNOW5uuf5wQ/edit?usp=sharing I think I understand your suggestion about genres, but I fail to see the relation with instruments. Or rather, I feel instruments are sufficiently different if not structurally, at least semantically, that they would need to be studied separately. For example, I don't see when entering a tag would trigger creating an instrument entity. Reference instruments should be created manually too, because it is important to enter reference names. And I don't think a simple number of occurrences should be enough for creating an entity. If you set the limit at for example 50 occurrences (which is much higher than our current limit for instruments), I can perfectly imagine a user entering more than 50 times an instrument with the same typo, thus creating a false instrument. At least for instruments, all entity creations should be voted IMO. I don't know much about id3 or itunes genres, but would the mapping between an instrument and a genre work? Also, I think it would be interesting to think how user language might influence your idea. For example, in genres, sometimes exact translations don't exist, and words which seem to be a translation actually mean something different. So that it could be a good idea to create a set of genres for each language, with a way to link (approximately) matching genres between languages when possible. For example, I believe we Frenchies use the words Pop and Rock differently from Americans (and probably from English people too). OTOH, I don't think much translation issues would appear for instruments. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-279: Add Place of Worship as place type
2014/1/2 Ben Ockmore ben.s...@gmail.com Concert Hall Community Building/Religious Building Stadium Club Arena Outdoor Space Theatre Bandstand Are all types that could be useful to have. I don't think we should split categories based on acoustic properties here, since it's an attribute of a place, and should go towards describing the type place, not its acoustic properties. Acoustic properties can be modified, and vary considerably between places of the same type (eg. sound baffles in concert halls). I agree the acoustical properties of a place can be modified (although making a stadium sound like a real church would be tricky). But if you don't split them on acoustical properties, what useful types are left apart from those already existing? Other seems enough as it correctly describes churches. Splitting on the fact that a place is used or not for religion seems OT in MB IMO. I may be wrong, but I don't think a user will one day need an easy way to select together the cathedrals and the Buddhist temples. If not for acoustical reasons, why would we need to split Other? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: Make instruments entities
2014/1/2 Ben Ockmore ben.s...@gmail.com Of course, there wouldn't be an instrument - ID3 genre mapping! That part applies to genres only. :P For instruments, the user would enter an instrument name into a free text field, and this would be searched for among existing instrument entities. If it's not found, then the user can proceed to use their entry. If other users enter the same name, then after a certain number of submissions, by multiple users, the name would automatically get promoted to an entity, and all matching relationships would be updated to use this new entity. Users could then merge or add relationships to the instrument just like a normal entity. So basically, +1 for making instruments entities, but I'd like to see a more fluid and controlled way of creating them (rather than any old person coming along and adding an instrument with an edit, which may or may not be voted on by other editors). I don't want to limit editing instruments to a group of Instrument Editors though, because IMO that sort of system is elitist and discourages contribution. Then we need the language to be handled in some way. Else this will become a nightmare, with the instruments written in a language/script that few users know/are able to check, and the false friends (I guess most users who know French know that the English viola is the same as the French alto). It also should be able to handle homonyms (in French the same word designates the alto (viola) and the alto (voice)). If we go this way, it is going to be tricky. But interesting :-) When I stated first that we need the language to be handled in some way, I meant that - if a user enters for example alto and the word is NOT already known, the MB UI should ask the user which language. - if a user enters for example alto and the word is already known in several languages, the MB UI should detect that in different languages it has different meanings and should tell the user so, offer him to pick the meaning really intended or create one if needed. - if a user enters for example alto and the word is already known in only one language, the MB UI should tell the user so, offer him to pick this meaning if it the one really intended or create one new language/meaning if needed. We could of course state that the language should for example be the Release's language, but this would still possibly generate bad edits for multi-language releases. Also, a user could for example buy a French release, but find the specific instruments on a German site. So that I believe that the instrument input language should remain user-modifiable. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: Make instruments entities
2014/1/2 Ben Ockmore ben.s...@gmail.com I think it would be helpful if we allow Instruments to have images, and use these in search results to show graphically what each of the suggestions looks like. All of your ideas for language selection/detection are good. Perhaps we could also use the site language that the user is using (once that moves from beta to the main site). Yes, images would definitely be useful ! I don't know where what is the current situation about languages in the DB. If it is far from handling languages correctly, and if instrument entities are implemented before languages, we could temporarily restrict the instrument language to English. English is the language currently used for the instrument tree, and it is probably the language which has the most instruments translated into it. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-279: Add Place of Worship as place type
2014/1/2 caller#6 meatbyproduct-musicbra...@yahoo.com On 01/02/2014 03:30 AM, Frederic Da Vitoria wrote: 2014/1/2 Ben Ockmore ben.s...@gmail.com Concert Hall Community Building/Religious Building Stadium Club Arena Outdoor Space Theatre Bandstand Are all types that could be useful to have. I don't think we should split categories based on acoustic properties here, since it's an attribute of a place, and should go towards describing the type place, not its acoustic properties. Acoustic properties can be modified, and vary considerably between places of the same type (eg. sound baffles in concert halls). I agree the acoustical properties of a place can be modified (although making a stadium sound like a real church would be tricky). But if you don't split them on acoustical properties, what useful types are left apart from those already existing? Other seems enough as it correctly describes churches. Splitting on the fact that a place is used or not for religion seems OT in MB IMO. I may be wrong, but I don't think a user will one day need an easy way to select together the cathedrals and the Buddhist temples. If not for acoustical reasons, why would we need to split Other? I'm not sure what makes a church (or stadium) other. Maybe it's a translation thing? To me, a church is as much a venue as anything. It seems to me like finer granularity is better handled in wikidata or by some other authority (although I guess that only works for notable places, which could be a problem) From https://musicbrainz.org/doc/Place : A place that has live artistic performances as one of its primary functions, such as a concert hall or multi-purpose arena. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-279: Add Place of Worship as place type
2014/1/2 Alex Mauer ha...@hawkesnest.net On 01/02/2014 09:58 AM, Frederic Da Vitoria wrote: A place that has live artistic performances as one of its primary functions, such as a concert hall or multi-purpose arena. Is that not the case for churches? They may not be musical (though music is often included!) but I would count services and/or sermons as “live artistic performances”. I bet we even have some in the database… I don’t see a need for a separate place type for these, but I don’t mind it either I hadn't thought of that :-D Yes you are right, one could consider those as art. But I am not convinced the Vatican would agree with you, art has often been viewed as something quite questionable, at least in past times. So if the Artist's Intent is that his work is not considered as art, can we consider it as art? Just for the sake of argument, because obviously in the definition above artistic performance meant anything recorded in MB. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-279: Add Place of Worship as place type
2014/1/2 caller#6 meatbyproduct-musicbra...@yahoo.com On 01/02/2014 07:58 AM, Frederic Da Vitoria wrote: 2014/1/2 caller#6 meatbyproduct-musicbra...@yahoo.com I'm not sure what makes a church (or stadium) other. Maybe it's a translation thing? To me, a church is as much a venue as anything. From https://musicbrainz.org/doc/Place : A place that has live artistic performances as one of its primary functions, such as a concert hall or multi-purpose arena. Aha! Thanks :-) That definition is much more narrow than the casual English word. I don't know English well enough to have an opinion about this :-/ -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-276: Remove attributes from the performing orchestra relationship
2014/1/1 symphonick symphon...@gmail.com Yes, please make this go away. I'm not sure the situation Frederic describes needs fixing anymore, since different arrangements are different works now? That said, maybe there should be a members of group performed attribute, for situations where the performers are credited in that way. Good idea, a members of group performed attribute would be much better, I believe there would be much less chances of it being misused. And a happy new year to all of you. Happy new year! -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-279: Add Place of Worship as place type
2014/1/1 Nicolás Tamargo de Eguren reosare...@gmail.com We have over 50 churches already, and with so much classical music being recorded in them it's only going to go up. Using Other for it when it's so obviously a type seems silly, so I'd like us to add it. Ticket: http://tickets.musicbrainz.org/browse/STYLE-279 Expected RFV date: Jan 8 +1 -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-276: Remove attributes from the performing orchestra relationship
2013/12/27 Nicolás Tamargo de Eguren reosare...@gmail.com The option to select chamber or symphony ends up being pretty much a random well it's on the orchestra name so it will probably be right pick, and it doesn't really offer any useful info. Can we get rid of it? (I have seen many other classical editors share this opinion of the attribute, but is there anyone who thinks it's actually useful?) I would like to have an artist type orchestra and possibly also chamber orchestra and symphony orchestra, but that's a separate issue :) It's the only place where this kind of info belongs though IMO. Ticket is http://tickets.musicbrainz.org/browse/STYLE-276 Expected RFV date is Jan 3. I believe this was meant for example for (unspecified subparts of) symphony orchestras performing as a chamber orchestra of a chamber music score, as opposed to the full orchestra performing an upscaled version of the same score. Not sure I am being quite clear here. And I agree that the implementation was not very easy to understand.As long as this situation is covered in some other way, I agree with removing those attributes. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Featured artists clarification
2013/12/9 jesus2099 hta3s836gzac...@jetable.org i remove my +1, count me as *-1* now that it clearly says to changing text of tracklists from what they are printed as (“ft.”, “featuring”, “featurin’”, etc.) into “feat.” (we can now avoid this since AC). I disagree: IMO you can't -1 on a non-modification: standardizing into feat. was already part of the previous guideline (see http://wiki.musicbrainz.org/Style/Titles/Featured_artists / Guideline / 2. . You should only +1 or -1 on the changes, not on the parts which are not changed (or here: for which the meaning has not changed). -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Featured artists clarification
2013/11/29 August Janse august.ja...@gmail.com If the classical part isn't true, then clearly it should be removed. I'm not really clear on what goes in that case so if anyone feels like replacing it I guess that would be good? Or should it just be removed? Yes, it should be removed: http://wiki.musicbrainz.org/Style/Classical/Release/Title does not mention feat. or featured any more. The opening paragraph should probably be rewritten as well. Why? This is the first clear definition of featured I ever found :-) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Classical FAQ
I did a few last edits in Purpose. There is still the red this page link, which I don't know how to solve. I am guessing this is to link to the wiki once the page is transcluded, but I don't understand why the link complains in the current state. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Classical FAQ
2013/11/28 Nicolás Tamargo de Eguren reosare...@gmail.com On Thu, Nov 28, 2013 at 12:26 PM, Frederic Da Vitoria davito...@gmail.com wrote: I did a few last edits in Purpose. There is still the red this page link, which I don't know how to solve. I am guessing this is to link to the wiki once the page is transcluded, but I don't understand why the link complains in the current state. Our docs link to the original wiki page anyway, so a link there isn't needed anymore (maybe it was at some point). Removed it. Thanks. Next step: is RFC needed? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Translated titles
2013/11/27 Staffan lift...@interface1.net Tue Nov 26 2013 17:04:20 GMT+0100, monxton musicbra...@jordan-maynard.org skrev: OK. So does that mean that: a) you think that the guidelines: http://musicbrainz.org/doc/Style/Release do not apply to this release, or b) you disagree with the guidelines ? I think the closest guideline would be http://musicbrainz.org/doc/Style/Titles/Extra_title_information or possibly http://musicbrainz.org/doc/Style/Titles/Subtitles but neither it a perfect match. Take a look at http://beatle.net/wp-content/uploads/hey-jude-full-single.jpg for instance. Is the title of the track Hey Jude or Hey Jude (Lennon McCartney)? Staffan, I don't understand your example: Lennon McCartney isn't a translation, so IMO your example doesn't apply. Note that I am not saying that the translation should appear in the title, only that your example seems irrelevant. Could you explain why you think that *translations* should not be mentioned in the title? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Classical FAQ
Hello, I started creating an updated version of http://wiki.musicbrainz.org/Classical_Music_FAQ here: http://wiki.musicbrainz.org/User:DavitoF/Classical_Music_FAQ. I only ensured that the points were still relevant and their solutions up to date, but as I don't edit or vote much any more, I am probably missing quite a few things. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Classical FAQ
2013/11/27 monxton musicbra...@jordan-maynard.org On 27/11/2013 10:14, Frederic Da Vitoria wrote: I started creating an updated version of http://wiki.musicbrainz.org/Classical_Music_FAQ here: http://wiki.musicbrainz.org/User:DavitoF/Classical_Music_FAQ. I only ensured that the points were still relevant and their solutions up to date, but as I don't edit or vote much any more, I am probably missing quite a few things. I was going to moan about the linked example release being aligned with the old CSG, but then I thought better and attempted to fix it. It still has some open questions though, as you will find in my unusually loquacious edit note. Excellent! Thanks. And sorry I gave you some work. I should have seen it and chosen a better release. Maybe I should have used http://musicbrainz.org/release/9def06f7-e302-4a44-a307-35bbc84d292b -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Classical FAQ
2013/11/27 Alex Mauer ha...@hawkesnest.net On 11/27/2013 04:14 AM, Frederic Da Vitoria wrote: Hello, I started creating an updated version of http://wiki.musicbrainz.org/Classical_Music_FAQ here: http://wiki.musicbrainz.org/User:DavitoF/Classical_Music_FAQ. I only ensured that the points were still relevant and their solutions up to date, but as I don't edit or vote much any more, I am probably missing quite a few things. Looks great. Only thing I spotted was “ Until the next version of the tagger you are stuck with the format that people have decided to use for storing classical.” Not sure which “next version of the tagger” this refers to. I’m guessing it’s current Picard, where you can use scripting to assign fields more or less as-you-like. Maybe point that out You are right, and I already saw this but I forgot about it. This part comes from the previous version and obviously needs to be upgraded. Could someone who really knows what Picard is currently able to do upgrade this part? And at the same time add the Picard version this is referring to. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Classical FAQ
2013/11/27 Alex Mauer ha...@hawkesnest.net On 11/27/2013 11:36 AM, Frederic Da Vitoria wrote: You are right, and I already saw this but I forgot about it. This part comes from the previous version and obviously needs to be upgraded. Could someone who really knows what Picard is currently able to do upgrade this part? And at the same time add the Picard version this is referring to. I cleaned up the two sections that referred to new versions of the database/tagger (the ID3 section and the “is musicbrainz useless for classical” section) Thanks! -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Classical Style FAQ in conflict with style guide
2013/11/20 godIsInTheRadio herr-schneide...@wir-aus-der.eu Hi there, in the classical Style FAQ ( http://musicbrainz.org/doc/Classical_Music_FAQ http://musicbrainz.org/doc/Classical_Music_FAQ ) it says So should the artist be used for performer or composer? For the near future you should use the artist field for composer NOT performer. The performer should become part of the release title or the track title. See the Classical Style Guide for a more detailed explanation. This seems in contradiction to what is said in the Classical Style Guide The Recording Artist field should contain the most important performers who appear on that specific recording, but it is acceptable that newly-created recordings have their artist information derived from a tracklist. Use a comma between multiple artists. ( http://musicbrainz.org/doc/Style/Classical/Recording/Artist http://musicbrainz.org/doc/Style/Classical/Recording/Artist ) resp. The Release Artist of a classical Release should include the composer(s) and performers featured on the front cover (except when Various Artists is used, see below). Use only composers and performers who are featured on the front cover (or the spine); don't add artists from the back cover or the inside of the booklet or other places. ( http://musicbrainz.org/doc/Style/Classical/Release/Artist http://musicbrainz.org/doc/Style/Classical/Release/Artist ) this unfortunately leads to ambiguos / random entries to the artist field of a classical release resp. recording. CSG was amended last and using the performers as Artist for Recordings is what we currently recommend. In other words, the FAQ is obsolete. Actually, very obsolete: the word recording in the sense should be understood as the common word, not what MB calls Recording. The FAQ was written at a time when MB did not have Recordings, only Releases and Tracks. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Classical Style FAQ in conflict with style guide
2013/11/20 Nicolás Tamargo de Eguren reosare...@gmail.com Yeah. That classical FAQ is horribly outdated, and I think the best option is to simply remove it. I suggest it should only be marked as outdated and it should be updated. I don't think we have a FAQ anywhere and this is definitely something useful. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Classical Style FAQ in conflict with style guide
2013/11/20 Nicolás Tamargo de Eguren reosare...@gmail.com On Wed, Nov 20, 2013 at 3:13 PM, Frederic Da Vitoria davito...@gmail.comwrote: 2013/11/20 Nicolás Tamargo de Eguren reosare...@gmail.com Yeah. That classical FAQ is horribly outdated, and I think the best option is to simply remove it. I suggest it should only be marked as outdated and it should be updated. I don't think we have a FAQ anywhere and this is definitely something useful. Thanks for volunteering to update it ;) Yeah, I knew this would be the consequence :D OK, I'll take it. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: STYLE-262, Place-URL has OSM at
2013/10/31 Sheamus Patt musicbrainz.r...@ncf.ca On 10/21/2013 10:54 AM, Alastair Porter wrote: http://tickets.musicbrainz.org/browse/STYLE-262 RFC expires October 28 Proposing a new URL relationship to link a Place to its details on openstreetmap. Hopefully pretty straightforward. If you can locate it on OpenStreetMap, then you know it's GPS co-ordinates which can be put into MB, And, if you have the GPS co-ordinates, you can easily construct the URL. E.g. http://www.openstreetmap.org?mlat=43.630704mlon= -79.415448http://www.openstreetmap.org?mlat=43.630704mlon=%20-79.415448 (locates Ontario Place, just an arbitrary place). So, why go through the trouble of adding URLs to all of the various places with specific locations, when we could just put a (locate this place) button into the UI which will take you there using the GPS co-ordinates? ... and storing directly the coordinates should allow to easily create another button to another similar website if ever we decide to. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-261: Add primary concert venue-relationship between artist and place
2013/10/30 ListMyCDs.com musicbra...@listmycds.com On 21.10.2013 17:45, Alastair Porter wrote: Would you also expect this relationship to be used if a band has (had) a residency at a venue? Band A played at Venue B every Monday from 1980 - 1992 This would be a good use for start/end dates, but I wonder if Primary Concert Venue is the correct phrase to use for this. Hmm. Nabble doesn't have my original response to this. Better late than never and actually now got an idea from you. Yes, this relationship could be used on similar cases like you described. Better name for this relationship might be is resident at. is resident at might be more suitable for other than classical and still covers similar situations. For a non-english, is resident is much more difficult to understand than primary concert venue. So if we choose something else than primary concert venue, I suggest that we find some more universal formulation. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-261: Add primary concert venue-relationship between artist and place
2013/10/30 Nicolás Tamargo de Eguren reosare...@gmail.com No, I mean that the place we put relationship documentation now doesn't show There's no guidance - although I'm certainly not against providing explicit guidance either :) On 30 Oct 2013 13:33, Tom Crocker tomcrockerm...@gmail.com wrote: On 30 October 2013 10:38, ListMyCDs.com musicbra...@listmycds.comwrote: Explanation for dates is commonly missing on mb wiki and seems it's not always necessary. For example: http://wiki.musicbrainz.org/Performer_Relationship_Type http://wiki.musicbrainz.org/Chorus_Master_Relationship_Type I know it's often missing, but if there's an obvious use for it I'd just say that. e.g. represents the dates for which it was the primary concert venue for the artist. Reo: do you mean because it shows up in the editor it's obvious it can/should be used? I just think it's confusing to new editors to look up a definition and see: There is no guidance... I'm open for discussion and can keep this on RFC-level if discussion about it is really necessary. Feedback is always welcome, thanks for your time for my proposal. I just wanted to see you give a response to the feedback, so thank you for doing that. I think primary concert venue is a good enough phrase - as you said, 'associated venue' becomes a bit vague. Couldn't there be a default text for this? Something like date when this relationship started? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] What makes a unique release (was: RFC STYLE-93-2: Copyright, Phonographic Copyright, and Licensed relationships)
(Changing the subject) 2013/10/28 Frederik Freso S. Olesen freso...@gmail.com it should be one set of cover art per release. If the fine print on the back of the cover (or inside the booklet) differs between two versions... they should, in most cases, be two/different releases. I think most of the relationships you think of would also be reflected in (ever so slightly) different cover art. Does that mean that each cover of http://musicbrainz.org/release-group/a69a1574-dfe3-3e2a-b499-d26d5e916041 / http://www.toriamos.com/go/galleries/view/56/1/29/albums/ should be in a separate MB Release? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
