Re: [mb-style] Strange mail answer
2015-04-30 18:07 GMT+02:00 Calvin Walton : > 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 : > 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 : > 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" 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?
I thought you meant CD and SACD :-D 2014-11-28 16:19 GMT+01:00 Steve Martin : > 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 > 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] How to enter hybrid SACD and DVD audio+video discs?
2014-11-28 15:24 GMT+01:00 Steve Martin : > > > On Nov 28, 2014, at 3:47 AM, MeinDummy 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] Style for classical track titles (STYLE-344)
2014-11-05 19:36 GMT+01:00 Nicolás Tamargo de Eguren : > On Wed, Nov 5, 2014 at 8:27 PM, Frederic Da Vitoria > 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)
2014-11-05 18:59 GMT+01:00 Nicolás Tamargo de Eguren : > 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-10-30 16:45 GMT+01:00 David Gasaway : > On Thu, Oct 30, 2014 at 1:25 AM, Nicolás Tamargo de Eguren > 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)
(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 : > 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 > : > >> On Thu, Oct 30, 2014 at 2:10 AM, David Gasaway wrote: >> >>> On Wed, Oct 29, 2014 at 4:10 PM, Alex Mauer >>> 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-29 21:17 GMT+01:00 Alex Mauer : > 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] Style for classical track titles (STYLE-344)
2014-10-29 20:53 GMT+01:00 caller#6 : > 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 19:39 GMT+01:00 Nicolás Tamargo de Eguren : > 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] Changes to our style process (Important)
2014-10-23 22:08 GMT+02:00 Robert Bihlmeyer : > 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 : > 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-25 12:45 GMT+02:00 lixobix : > Frederic Da Vitoria wrote > > 2014-09-24 23:50 GMT+02:00 symphonick < > > > symphonick@ > > > >: > > > >> 2014-09-24 7:54 GMT+02:00 Frederic Da Vitoria < > > > davitofrg@ > > > >: > >> > >>> 2014-09-23 23:31 GMT+02:00 symphonick < > > > symphonick@ > > > >: > >>> > >>>> 2014-09-19 11:34 GMT+02:00 Frederic Da Vitoria < > > > davitofrg@ > > > >: > >>>> > >>>>> 2014-09-19 11:18 GMT+02:00 Tom Crocker < > > > tomcrockermail@ > > > >: > >>>>> > >>>>>> 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 > >>&g
Re: [mb-style] Master and Performance entities
2014-09-24 23:50 GMT+02:00 symphonick : > 2014-09-24 7:54 GMT+02:00 Frederic Da Vitoria : > >> 2014-09-23 23:31 GMT+02:00 symphonick : >> >>> 2014-09-19 11:34 GMT+02:00 Frederic Da Vitoria : >>> >>>> 2014-09-19 11:18 GMT+02:00 Tom Crocker : >>>> >>>>> 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 rem
Re: [mb-style] Master and Performance entities
2014-09-24 13:54 GMT+02:00 lixobix : > 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 : > > 2014-09-19 11:34 GMT+02:00 Frederic Da Vitoria : > >> >> 2014-09-19 11:18 GMT+02:00 Tom Crocker : >> >>> 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:32 GMT+02:00 LordSputnik : > 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-19 11:18 GMT+02:00 Tom Crocker : > 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:07 GMT+02:00 KRSCuan : > 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 1:24 GMT+02:00 Tom Crocker : > On 14 Sep 2014 13:01, "LordSputnik" wrote: > > ... > > 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 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. 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. > 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. > 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. -- 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 : > 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-16 16:39 GMT+02:00 lixobix : > Frederic Da Vitoria wrote > > 2014-09-14 14:00 GMT+02:00 LordSputnik < > > > ben.sput@ > > > >: > > > >> 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. > >> > >> Ben / LordSputnik > >> > > > > I think we don't really have a choice: it will have to be #2 for the > > reason > > you gave. > > 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. > > http://musicbrainz.org/release/8549ce34-2349-42e0-bf28-1a773b35bcaa > http://musicbrainz.org/release/472fed21-00bc-3b35-842b-f8a44a8b9678 > > as opposed to > > http://musicbrainz.org/release/780823a5-a852-4958-bcb3-b291ceb66ea1 > > > Frederic Da Vitoria wrote > > 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. > > I'm not sure what you mean by this. If there is no information about > mastering, then the master is the same as all other undefined releases. I see no problem with using an undefined master. > The problem is that the "undefined" master may not really exist in the real world. It could be (will often be) only a wrapper for all the masters MB users don't know about. Just after creating the Master Entity (if it is to become an Entity), the situation could even be catastrophic: all the tracks made out of all Recordings could be considered as issuing from undefined Masters until we start creating the real, documented Masters. The problem I see is that if we don't mark those undefined Masters as such, some users will start adding data to them instead of creating a new Master. Imagine for example that on one Release, a user finds the DDD logo, he would start editing the undefined Master to state that it is digital. Even if some Tracks from that Master are part of vinyl Releases (I know, some vinyl tracks are digitally mastered, but you see what I mean). If later another user found mention of a Mastering engineer on another release, he would link it to the same Master, even if the engineer actually worked on an analog master. Actually, two or three Masters should be created in my example, the original undefined (which should always remain unmodified) plus 1 or 2 more depending on whether the engineer worked on the Master from which the DDD track issued or not. 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. > It's questionable whether > SPARS codes should be used at all as a reference for mastering info (I > think > not), as the mastering aspect of them refers merely to the nature of the > medium onto which the master is pressed, and bears no relation to the > processing of mixed recordings, which is what I believe we are concerned > with. There should only be a distinction between the mastering of different > media when there is clear evidence that they contain different (processed) > masters, as is often the case with modern CD / DD vs vinyl (brickwalling). > So perhaps all we need to do is to state in the guidelines that SPARS codes > are not authoritative for defining the type of mastering. > I agree. But this means that we must again insist on the fact that an MB Master is slightly different from a real world master. -- 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 : > 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] box sets etc.
2014-08-04 23:39 GMT+02:00 Alex Mauer : > On 08/04/2014 01:32 PM, bflaminio wrote: > > Intuitively I perceive a distinction between a "compilation", "box set", > and > > "anthology"; but I have no idea how to unambiguously define each. > > Might be ambiguous, but: > > Compilation: collection of recordings from a variety of sources, > possibly by several different artists. Example: “Greatest Hits”, “Love > Songs” > > Box set: collection of previously-released albums packaged together with > each approximating their original form. (So a bonus disc or bonus tracks > would not detract from the 'box set' type) > > Anthology: Collection of previously-released recordings, with an effort > towards comprehensiveness. Example: “Chronological Classics” series, > “All the Singles” > > Of course, there could be some overlap in deciding whether a given > release is a compilation or an anthology. One solution would be to > explicitly define "compilations” as meaning “Various Artists > Compilations” while “Anthology” would be any single-artist compilation, > regardless of comprehensiveness. > > On the other hand, I’m not even sure that ‘anthology’ is really an > appropriate term. https://en.wikipedia.org/wiki/Anthology doesn’t > describe anything like the description given above: “a collection of > literary works chosen by the compiler.” is so vague as to cover just > about anything, and seems to fit much better with "compilation" in > general. > I'm not sure it fits better: I feel that anthology and compilation are indeed close, but the important word in the wikipedia definition may be "chosen". I was surprised when you insisted on comprehensiveness for "anthology", for me an anthology is the reverse of comprehensiveness, it means that a careful choice was made, that some works were kept but that some were rejected. The difference between anthology and compilation may be that a compilation contains works which were well known (even if they are not really interesting), while an anthology would contain works which the compiler thinks interesting, even if they never reached fame. But maybe I'm applying French meanings to English words? -- 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 : > ~ 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 : > 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-273. New relationship attribute : "unsure"
2014-03-06 13:23 GMT+01:00 Frederik "Freso" S. Olesen : > 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 15:21 GMT+01:00 Frederik "Freso" S. Olesen : > 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-296. remove bogus attribute work-work version TRANSLATED
2014-03-04 8:27 UTC+01:00, Rachel Dwight : > > On Mar 3, 2014, at 3:54 PM, Frederic Da Vitoria > wrote: > >> 2014-03-03 22:23 GMT+01:00 symphonick : >> 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 22:23 GMT+01:00 symphonick : > 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-03 21:44 GMT+01:00 Rachel Dwight : > > 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 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-01 11:10 GMT+01:00 Nicolás Tamargo de Eguren : > > On Sat, Mar 1, 2014 at 12:03 PM, symphonick 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 11:03 GMT+01:00 symphonick : > 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-278: Add "Stadium/Arena" as place type
2014-02-21 10:53 GMT+01:00 Nicolás Tamargo de Eguren :
>
> On 21 Feb 2014 11:37, "Frederic Da Vitoria" wrote:
> >
> > 2014-02-21 0:22 GMT+01:00 jesus2099 :
> >
> >> 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 0:22 GMT+01:00 jesus2099 :
> 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-290] Add Balance engineer relationship type
2014-02-18 23:55 GMT+01:00 Frederic Da Vitoria : > 2014-02-12 14:08 GMT+01:00 Frederic Da Vitoria : > > 2014-02-12 12:45 GMT+01:00 Nicolás Tamargo de Eguren > >: >> >> 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 : > 2014-02-12 12:45 GMT+01:00 Nicolás Tamargo de Eguren >: > > 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 : > 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
Re: [mb-style] RFV [STYLE-290] Add Balance engineer relationship type
2014-02-07 Nicolás Tamargo de Eguren : > > On Fri, Feb 7, 2014 at 2:43 PM, Frederic Da Vitoria > wrote: > >> 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
[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] 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 : > +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] 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
2014-02-04 Staffan Vilcans : > > 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-290] Add Balance engineer relationship type
2014-01-28 Frederic Da Vitoria : > 2014-01-28 Staffan > > 27 januari 2014, Frederic Da Vitoria 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-285/2: more specific artist types for classical groups
2014-02-03 Nicolás Tamargo de Eguren : > On Mon, Feb 3, 2014 at 12:10 PM, symphonick 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-02-03 Nicolás Tamargo de Eguren :
> On Wed, Jan 29, 2014 at 1:10 PM, Frederic Da Vitoria
> wrote:
>
>> 2014-01-29 Nicolás Tamargo de Eguren
>>
>> On Wed, Jan 29, 2014 at 1:17 PM, symphonick 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-01-29 Nicolás Tamargo de Eguren
> On Wed, Jan 29, 2014 at 1:17 PM, symphonick 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 > 27 januari 2014, Frederic Da Vitoria 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
Re: [mb-style] RFC [STYLE-290] Add Balance engineer relationshiptype
2014-01-27 Nicolás Tamargo de Eguren > On Mon, Jan 27, 2014 at 6:51 PM, Frederic Da Vitoria > wrote: > >> 2014-01-27 Brant Gibbard >> >> 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 >>> >>> 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] RFC [STYLE-290] Add Balance engineer relationshiptype
2014-01-27 Brant Gibbard > 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 relationship type
2014-01-27 Calvin Walton > On Mon, 2014-01-27 at 17:24 +0100, Frederic Da Vitoria wrote: > > 2014-01-27 ListMyCDs > > > > > 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 > 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 > > 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 ListMyCDs > 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
[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] Post-RFV poll: Stadium/Arena (please answer! :) )
2014/1/25 Nicolás Tamargo de Eguren > > 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
[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
> 2014/1/22 Frederic Da Vitoria
>
>> 2014/1/21 symphonick
>>
>>>
>>> 2014/1/21 Frederic Da Vitoria
>>>
>>>> 2014/1/21 symphonick
>>>>
>>>>>
>>>>> 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 b
Re: [mb-style] RFC STYLE-285: more specific artist types for classical groups
2014/1/22 Nicolás Tamargo de Eguren > 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
Re: [mb-style] RFC STYLE-285: more specific artist types for classical groups
2014/1/21 symphonick
>
> 2014/1/21 Frederic Da Vitoria
>
>> 2014/1/21 symphonick
>>
>>>
>>> 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-285: more specific artist types for classical groups
2014/1/21 symphonick > 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-281] Add haute-contre to the vocal tree
2014/1/20 SwissChris > 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 > wrote: > >> 2014/1/20 SwissChris >> >>> 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 >>>> >>>>> - 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
Re: [mb-style] RFC [STYLE-281] Add haute-contre to the vocal tree
2014/1/20 SwissChris > 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 > wrote: > >> 2014/1/20 SwissChris >> >>> - 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 > - 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-285: more specific artist types for classical groups
2014/1/17 Nicolás Tamargo de Eguren > On Fri, Jan 17, 2014 at 4:17 PM, Maurits 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-285: more specific artist types for classical groups
2014/1/17 Maurits > 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-278: Add "Stadium/Arena" as place type
2014/1/16 Nicolás Tamargo de Eguren > 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
Re: [mb-style] RFC STYLE-278: Add "Stadium/Arena" as place type
2014/1/16 Frederic Da Vitoria > 2014/1/16 Nicolás Tamargo de Eguren > >> 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
[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
Re: [mb-style] Haute-Contre
2014/1/11 Nicolás Tamargo de Eguren > On Sat, Jan 11, 2014 at 9:52 PM, Frederic Da Vitoria > wrote: > >> 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
[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] RFC STYLE-279: Add "Place of Worship" as place type
2014/1/2 caller#6 > On 01/02/2014 07:58 AM, Frederic Da Vitoria wrote: > > 2014/1/2 caller#6 > >> >> 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-279: Add "Place of Worship" as place type
2014/1/2 Alex Mauer > 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 > On 01/02/2014 03:30 AM, Frederic Da Vitoria wrote: > > 2014/1/2 Ben Ockmore > >> 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-227 Add new artist type "Character"
2014/1/2 jesus2099 > IMO we will loose time with temporary devs. > We have plenty of pedning bug fix or feeature request that could be not > temporary instead… :) > Then how do you suggest characters should be entered in the meanwhile? -- 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 > 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] Pre-RFC: Make instruments entities
2014/1/2 Ben Ockmore > 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] RFC STYLE-279: Add "Place of Worship" as place type
2014/1/2 Ben Ockmore > 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/1 Ben Ockmore > 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 Nicolás Tamargo de Eguren > On Thu, Jan 2, 2014 at 10:55 AM, jesus2099 wrote: > >> -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] 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 jesus2099 > -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-279: Add "Place of Worship" as place type
2014/1/2 caller#6 > 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/1 Nicolás Tamargo de Eguren > 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
2014/1/1 symphonick > 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-276: Remove attributes from the performing orchestra relationship
2013/12/27 Nicolás Tamargo de Eguren > > 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 > 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 > 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
2013/11/28 Nicolás Tamargo de Eguren > > On Thu, Nov 28, 2013 at 12:26 PM, Frederic Da Vitoria > 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] 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/27 Alex Mauer > 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 FAQ
2013/11/27 Alex Mauer > 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 monxton > 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
[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] Translated titles
2013/11/27 Staffan > Tue Nov 26 2013 17:04:20 GMT+0100, monxton > 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
Re: [mb-style] Classical Style FAQ in conflict with style guide
2013/11/20 Nicolás Tamargo de Eguren > > On Wed, Nov 20, 2013 at 3:13 PM, Frederic Da Vitoria > wrote: > >> 2013/11/20 Nicolás Tamargo de Eguren >> >>> 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] Classical Style FAQ in conflict with style guide
2013/11/20 Nicolás Tamargo de Eguren > 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 godIsInTheRadio > 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
