Re: [mb-style] RFV-348: CSG Recording/Artist Credits
OK, I'm taking this back to RFC. It will expire Thursday, February 16. 2012/2/9 lorenz pressler l...@gmx.at Am 09.02.2012, 02:33 Uhr, schrieb SwissChris swissch...@gmail.com: should at least be a new RFC for this. Or you should stick with your previous proposal, which nobody so far seemed to dislike enough to veto it. There were objections, I wasn't sure what to make of it. i also think it's strange to change a proposal so fundamental that's already in RFV and nobody veto'd it. also now track artist would be composer and recording artist composer+performer? that would be equally bothersome to edit like the original RFV was.. no; track artist = recording artist = composer + featured performers these whole style routines are already very tedious and unclear already, such last minute changes during the process are making things even less transparent imho. with the current UI it is horrible to enter this data. unless the UI is improved this fact won't change unless our guidelines would say track:title/artist = recording:title/artist. we have this as status-quo with the current (pre-NGS) CSG. if we want to have easy editing, all recording:title/artist guidelines should be postponed until there is a better way of entering data. however without any direction what we want, it will be hard to design a UI that will work. so we could try a hard to edit but more elaborated style guideline, see how and if it works in terms of data representation, tagging, scrobbling, sorting and make continuative refinements if we come across problems; or: just make a sketch, wait for the classical summit and tell there our thoughts and work out a final concept and give our UI wishes to the devs and test it and if it works out fine introduce it to the main server. until then only style updates to release/track and works should be made. -- lorenz pressler PGP 0x92E9551A I don't know what do really, I'd like to be able to use MB for classical, but I see it as pointless right now. I'd prefer if we could decide on a guideline, even if it's not perfect. So let's try this: a) which of the following solutions would you prefer? b) which of the options would you veto (if any) and why? 1) Track Artist = Recording Artist = Composer + important/featured performers 2) Track Artist = Recording Artist = Important/featured performers 3) Track Artist = Composer, Recording Artist = Important/featured performers /symphonick ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
2012/2/9, lorenz pressler l...@gmx.at: Am 09.02.2012, 02:33 Uhr, schrieb SwissChris swissch...@gmail.com: should at least be a new RFC for this. Or you should stick with your previous proposal, which nobody so far seemed to dislike enough to veto it. i also think it's strange to change a proposal so fundamental that's already in RFV and nobody veto'd it. also now track artist would be composer and recording artist composer+performer? that would be equally bothersome to edit like the original RFV was.. these whole style routines are already very tedious and unclear already, such last minute changes during the process are making things even less transparent imho. with the current UI it is horrible to enter this data. unless the UI is improved this fact won't change unless our guidelines would say track:title/artist = recording:title/artist. we have this as status-quo with the current (pre-NGS) CSG. if we want to have easy editing, all recording:title/artist guidelines should be postponed until there is a better way of entering data. however without any direction what we want, it will be hard to design a UI that will work. so we could try a hard to edit but more elaborated style guideline, see how and if it works in terms of data representation, tagging, scrobbling, sorting and make continuative refinements if we come across problems; or: just make a sketch, wait for the classical summit and tell there our thoughts and work out a final concept and give our UI wishes to the devs and test it and if it works out fine introduce it to the main server. until then only style updates to release/track and works should be made. Here we go again. Lorenz is right that this proposal seems unrealistic because the current UI is not suited for this RFC. This does not mean that what this RFC tries to achieve is not desirable. I believe we are going to cycle like this as long as we don't separate long-term stable rules from short-term transitory rules.. -- 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-348: CSG Recording/Artist Credits
symphonick symphon...@gmail.com writes: I don't know what do really, I'd like to be able to use MB for classical, but I see it as pointless right now. I'd prefer if we could decide on a guideline, even if it's not perfect. So let's try this: a) which of the following solutions would you prefer? b) which of the options would you veto (if any) and why? 1) Track Artist = Recording Artist = Composer + important/featured performers 2) Track Artist = Recording Artist = Important/featured performers 3) Track Artist = Composer, Recording Artist = Important/featured performers I'm most in favour of (3), for the following reason. I think we can all agree that a single name isn't really sufficient for artist credits for a track / recording (I'll write track from now on). As such, we need to come up with a way of assigning multiple names to a track. One option is to put several into the track artist field, with rules about how to split up people with different roles. In order for client applications to reason about such data, it must be input correctly (in a free text field!), with semicolons or whatever in the right place. Then you code up some regexp based parser and cross your fingers. The other option is to have several fields for the different roles. There could be a rule that says the track artist is automatically populated from these fields if not set (maybe following your semicolon-based convention, maybe something else). Software can trivially infer peoples' roles from this, because it's been split up in advance. It also allows you to have a single THIS IS THE ARTIST FOR UR ITOONS field (we just don't have to make it manually). So I'm in favour of the latter and think the former is crazy. Of course, the MB server/schema doesn't support this yet, so we're in and a pony, please-land. However, I think options (1) and (2) create work for editors for no benefit and, in my opinion, make the only sensible long-term solution yet more painful. Rupert pgpZEEIZiwcZR.pgp Description: PGP signature ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
Frederic Da Vitoria davito...@gmail.com writes: Here we go again. Lorenz is right that this proposal seems unrealistic because the current UI is not suited for this RFC. This does not mean that what this RFC tries to achieve is not desirable. I believe we are going to cycle like this as long as we don't separate long-term stable rules from short-term transitory rules.. Hear, hear! Rupert pgpIEwEZL5WZC.pgp Description: PGP signature ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
2012/2/9 Frederic Da Vitoria davito...@gmail.com 2012/2/9, lorenz pressler l...@gmx.at: Am 09.02.2012, 02:33 Uhr, schrieb SwissChris swissch...@gmail.com: should at least be a new RFC for this. Or you should stick with your previous proposal, which nobody so far seemed to dislike enough to veto it. i also think it's strange to change a proposal so fundamental that's already in RFV and nobody veto'd it. also now track artist would be composer and recording artist composer+performer? that would be equally bothersome to edit like the original RFV was.. these whole style routines are already very tedious and unclear already, such last minute changes during the process are making things even less transparent imho. with the current UI it is horrible to enter this data. unless the UI is improved this fact won't change unless our guidelines would say track:title/artist = recording:title/artist. we have this as status-quo with the current (pre-NGS) CSG. if we want to have easy editing, all recording:title/artist guidelines should be postponed until there is a better way of entering data. however without any direction what we want, it will be hard to design a UI that will work. so we could try a hard to edit but more elaborated style guideline, see how and if it works in terms of data representation, tagging, scrobbling, sorting and make continuative refinements if we come across problems; or: just make a sketch, wait for the classical summit and tell there our thoughts and work out a final concept and give our UI wishes to the devs and test it and if it works out fine introduce it to the main server. until then only style updates to release/track and works should be made. Here we go again. Lorenz is right that this proposal seems unrealistic because the current UI is not suited for this RFC. This does not mean that what this RFC tries to achieve is not desirable. I believe we are going to cycle like this as long as we don't separate long-term stable rules from short-term transitory rules.. -- Frederic Da Vitoria (davitof) This is meant as a solution until we can get a UI more suitable for classical. (I am, however, uncertain if we can agree on what we want, and what to do with it once it's been implemented. Works was meant to solve a lot of problems in classical... Even if we get new fields and UI, it might still be impossible to achieve full compatibility with old CSG style tagging.) /symphonick ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] On publishers as artists
In some cases, especially for videogame music, the official credits for music both in covers and in official databases like JASRAC are not given to people, but to publishers (see [1] where the second line of credits at the bottom credits some of the tracks to Nintendo Co. Ltd.). I'd like to know people's opinion on this. Should we: a) Use publishers as artists when credited as such b) Use composers when they're clearly known even when the credit is given to the publisher (and in this case, who to use for artist credits for releases the publisher *is* the credited artist?) c) Always use composers even when attribution is kinda dubious. All of these options have their defenders in MB, and I'm not completely convinced on which one to settle for, so I'd love some opinions (I bring this up now because I've seen the URL relationships are being removed by some editors from the publisher artists we have, clearly as a first step to remove the artists completely - and I'm not sure if we really want that). [1] http://i.imgur.com/hLmY0.jpg -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] On publishers as artists
2012/2/9, Nicolás Tamargo de Eguren reosare...@gmail.com: In some cases, especially for videogame music, the official credits for music both in covers and in official databases like JASRAC are not given to people, but to publishers (see [1] where the second line of credits at the bottom credits some of the tracks to Nintendo Co. Ltd.). I'd like to know people's opinion on this. Should we: a) Use publishers as artists when credited as such b) Use composers when they're clearly known even when the credit is given to the publisher (and in this case, who to use for artist credits for releases the publisher *is* the credited artist?) c) Always use composers even when attribution is kinda dubious. All of these options have their defenders in MB, and I'm not completely convinced on which one to settle for, so I'd love some opinions (I bring this up now because I've seen the URL relationships are being removed by some editors from the publisher artists we have, clearly as a first step to remove the artists completely - and I'm not sure if we really want that). What would make the most sense IMO would be to use the composer in a composer AR and the publisher in the AC. We would be keeping both kinds of information and at the same time we would be using the MB database fields for their intended use. AFAIK credits don't mean the entity who composed, it only means who the royalties should be paid to. How this will appear in a client application would be the client application's responsibility, obviously it could be a user setting. -- 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] On publishers as artists
Hello, On 09/02/12 07:47, Nicolás Tamargo de Eguren wrote: In some cases, especially for videogame music, the official credits for music both in covers and in official databases like JASRAC are not given to people, but to publishers (see [1] where the second line of credits at the bottom credits some of the tracks to Nintendo Co. Ltd.). I'd like to know people's opinion on this. Should we: Obviously most of this music is composed by musicians being hired to do so (either as employees of a game development studio, as an independent contractor, or as employees of a separate audio company which is contracted by a game studio or their publisher to do the audio for a video game). In general, if someone is being paid to create a copyrighted work I think both the person(s) actually doing the work and the organization paying for it deserve some amount of credit for the resulting work. _If_ a publisher or development studio is actually credited for a particular track, or clearly credited as the artist on a release, obviously we should keep that credit in the release or track artist credits, because that's what those fields are for. However, in most cases where we have entries like that in our database it just means there was no clearly credited artist on either tracks or release, and people just used the publisher instead because usually the publisher will stick their name on stuff they publish. I also believe it is common for the audio director of a video game to be credited for work which was actually done by other employees on the audio team. So even though a single person is credited as the composer, it was actually a team effort where the audio director composes and designs the more important aspects of the audio for a video game, and other employees will compose other parts and re-arrange stuff as changes are made to other aspects of a video game in development. So, for some soundtracks it is natural to think of the development or audio studio as a band, and without knowing more about the development process of a particular video game it is difficult to determine whether you're dealing with such a situation or not. a) Use publishers as artists when credited as such b) Use composers when they're clearly known even when the credit is given to the publisher (and in this case, who to use for artist credits for releases the publisher *is* the credited artist?) c) Always use composers even when attribution is kinda dubious. I think publisher being credited is sufficiently rare that we can safely allow it in release and track artist credits. If possible, the recording should be credited to the actual persons involved. If a game development studio is clearly credited for a release or track, I would retain that in all artist credits (rg, release, track, recording) because I would consider that to be close to a band, multiple people working together on the music, etc.. If individual composers are credited, clearly we should retain that in all applicable artist credits. -- kuno / warp. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] On publishers as artists
2012/2/9, Kuno Woudt k...@frob.nl: Hello, On 09/02/12 07:47, Nicolás Tamargo de Eguren wrote: In some cases, especially for videogame music, the official credits for music both in covers and in official databases like JASRAC are not given to people, but to publishers (see [1] where the second line of credits at the bottom credits some of the tracks to Nintendo Co. Ltd.). I'd like to know people's opinion on this. Should we: Obviously most of this music is composed by musicians being hired to do so (either as employees of a game development studio, as an independent contractor, or as employees of a separate audio company which is contracted by a game studio or their publisher to do the audio for a video game). In general, if someone is being paid to create a copyrighted work I think both the person(s) actually doing the work and the organization paying for it deserve some amount of credit for the resulting work. _If_ a publisher or development studio is actually credited for a particular track, or clearly credited as the artist on a release, obviously we should keep that credit in the release or track artist credits, because that's what those fields are for. However, in most cases where we have entries like that in our database it just means there was no clearly credited artist on either tracks or release, and people just used the publisher instead because usually the publisher will stick their name on stuff they publish. I also believe it is common for the audio director of a video game to be credited for work which was actually done by other employees on the audio team. So even though a single person is credited as the composer, it was actually a team effort where the audio director composes and designs the more important aspects of the audio for a video game, and other employees will compose other parts and re-arrange stuff as changes are made to other aspects of a video game in development. So, for some soundtracks it is natural to think of the development or audio studio as a band, and without knowing more about the development process of a particular video game it is difficult to determine whether you're dealing with such a situation or not. a) Use publishers as artists when credited as such b) Use composers when they're clearly known even when the credit is given to the publisher (and in this case, who to use for artist credits for releases the publisher *is* the credited artist?) c) Always use composers even when attribution is kinda dubious. I think publisher being credited is sufficiently rare that we can safely allow it in release and track artist credits. If possible, the recording should be credited to the actual persons involved. If a game development studio is clearly credited for a release or track, I would retain that in all artist credits (rg, release, track, recording) because I would consider that to be close to a band, multiple people working together on the music, etc.. If individual composers are credited, clearly we should retain that in all applicable artist credits. In your answer you did not use the composer AR at all. Was this intentional? -- 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-348: CSG Recording/Artist Credits
2012/2/9 monxton musicbra...@jordan-maynard.org On 07/02/2012 20:20, Nicolás Tamargo de Eguren wrote: We're expecting to have a summit during 2012 in which we (well, we as in MusicBrainz + BBC + a few more people, I doubt I'll be there) will try to work on a good way to do classical in databases, see http://wiki.musicbrainz.org/MusicBrainz_Summit/2012_Mini-Summit/Notes#Classical_schema_summit_.28contributors_from:_Last.fm.2C_Naxos.3F.2C_Universal.2C_BBC.2C_IMSLP.3F.29 So if we can't right now reach any good decision on how to fix this (and it looks that way to me), it'd make sense to instead make a few proposals that we think would be the best way to represent this data (not necessarily based on current UI, if UI is what blocks the best options) for them to be evaluated and built upon on said summit. Also, it'd be great if people gave some thorough examples of how they would expect their classical to be tagged - to see how we could process the data to make that possible. And please, please, please, let's compile a list of edge cases as hard and strange as you can get, too - just put it somewhere in the wiki I guess :) Speaking of which, we would need a representative of the community for those talks. I was thinking symphonick or rswabrick or monxton maybe, but that's something the community should clearly have a say on. These are very hard problems to solve, as this debate is demonstrating. I'm seeing a lot of plunging into detail when we are a long way from consensus on what is a good outcome. This summit may be a good thing, but I am concerned that the interests of these big and wealthy consumers of the data may not always align with the community that produces the data, or at least that their priorities are different. Here are my current two-penn'orth: - People are saying that incremental change is good, and I agree. Each incremental style change tends to make migration more difficult however, and we should consider this as a factor when making these changes. - Wasn't one of the key propositions for NGS the elimination of special formatting in a text field to represent structured data? I'm quite sad to see proposals which include introducing such things. Yup. I had (approximately) as printed most highlighted performer first top to bottom in previous versions, but I assume we have to introduce a second delimiter if you want to tag by composer and we only have one field for artists (performers and composer). - There's lots of heated debate about Artist Credit, but we already have the mechanism for including that data in ARs. Some people are dismissing those because they are too difficult to edit. So the problem we should be tackling is the editor. If all this information is added to the AC, is that a tacit agreement that ARs are not going be used? Duplicating data is generally a Bad Thing. No, a future solution should definitely be based on ARs IMO. Then we can search for roles, for example. These suggestions is about making use of the current UI, not about going back to pre-AR MB. Some of the limitations of the artist fields (only one artist possible or create a new collaboration artist) were removed in NGS, so I want to update the guidelines to reflect this. But the artist concept just doesn't fit classical, and I'm hoping for a solution eventually where you can enter all ARs when entering a release, and the artist fields will get populated automatically. But we still need to decide what data these fields should contain. - I've mentioned before that ARs and ACs are not symmetrical, because ARs have a role (e.g. conductor, cello ...) and ACs do not. I like to see the role. Conversely, ACs have performance credits and ARs do not, for example the AC could be for Stephen Bishop or Stephen Kovacevich, or Stephen Bishop-Kovacevich, but the AR can only be for Stephen Kovacevich. I'd like to see this limitation removed. In that case you can't really avoid duplicating data, can you? You need an alias for this performer at release level. - At the simplest level, I really want my music player to tell me that I am listening to Beethoven, not to the performers (though I'd like to know who they are). This is perhaps the USP that brought me to MBz in the first place. For non-classical music, I want the opposite. I'm reluctantly coming round to the idea that we're going to need a style field, which may be CSG, popular or maybe others, that the taggers can employ. That can be done without breaking searching if we put performers as recording artist and the composer as track artist. Or try a CSG genre some scripting in Picard? /symphonick ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
2012/2/9, symphonick symphon...@gmail.com: 2012/2/9 monxton musicbra...@jordan-maynard.org On 07/02/2012 20:20, Nicolás Tamargo de Eguren wrote: - There's lots of heated debate about Artist Credit, but we already have the mechanism for including that data in ARs. Some people are dismissing those because they are too difficult to edit. So the problem we should be tackling is the editor. If all this information is added to the AC, is that a tacit agreement that ARs are not going be used? Duplicating data is generally a Bad Thing. No, a future solution should definitely be based on ARs IMO. Then we can search for roles, for example. These suggestions is about making use of the current UI, not about going back to pre-AR MB. Some of the limitations of the artist fields (only one artist possible or create a new collaboration artist) were removed in NGS, so I want to update the guidelines to reflect this. But the artist concept just doesn't fit classical, and I'm hoping for a solution eventually where you can enter all ARs when entering a release, and the artist fields will get populated automatically. But we still need to decide what data these fields should contain. With the current UI? I really believe this would be impossible to enforce with the current UI. I agree that the best (?) system will probably imply modifications to the database schema, but I think there are intermediate steps where the UI could be modified without any schema change in order to make these rules usable. -- 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-348: CSG Recording/Artist Credits
On 02/09/2012 03:10 AM, symphonick wrote: 1) Track Artist = Recording Artist = Composer + important/featured performers 2) Track Artist = Recording Artist = Important/featured performers 3) Track Artist = Composer, Recording Artist = Important/featured performers I would veto none of these. As long as the recording artist includes the performer, I’m happy. I’d be happier if it were *only* important/featured performers, but I don’t strongly object to including the composer *as well* I think my actual preference would be a modification of 3: * Track artist = whatever the release says (i.e. important/featured *artists*: maybe performer, maybe composer, maybe both; If the release doesn’t clearly say, use both) * Recording artist = important/featured performer(s) I’m not sure that it’s such a big problem that the guideline might state that the track artist doesn’t equal the recording artist. There will be “wrong” recordings for a long time to come anyway given that CSG-classic has been this way since forever. A few more in the interval before we get a better UI won’t hurt anything. So is there any reason we can’t *recommend* that the RecArtist be the performer, but not require everyone to change it immediately? This way the people tagging the releases would be happy, and the people who don’t want to edit the recordings would be happy. And once we have a better UI, everyone would be happy. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-346. Style/Language/Vietnamese : Punctuation change
Thanks very much Réo ! I never know if it’s correct to hotlink pics… I will make the RFV email in a day or two… or in a few days. ;) Tristan. - jesus2099 × Ti = Tristan + patate12 ÷ saucisson7 mb : http://musicbrainz.org/user/jesus2099 mb userscripts : http://userscripts.org/users/31010/scripts IMPORTANT : hta3s836gzac...@jetable.org is a fake e-mail, I don’t receive anything in this. -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-346-Style-Language-Vietnamese-Punctuation-change-tp4226419p4373497.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
2012/2/9 Frederic Da Vitoria davito...@gmail.com 2012/2/9, symphonick symphon...@gmail.com: 2012/2/9 monxton musicbra...@jordan-maynard.org On 07/02/2012 20:20, Nicolás Tamargo de Eguren wrote: - There's lots of heated debate about Artist Credit, but we already have the mechanism for including that data in ARs. Some people are dismissing those because they are too difficult to edit. So the problem we should be tackling is the editor. If all this information is added to the AC, is that a tacit agreement that ARs are not going be used? Duplicating data is generally a Bad Thing. No, a future solution should definitely be based on ARs IMO. Then we can search for roles, for example. These suggestions is about making use of the current UI, not about going back to pre-AR MB. Some of the limitations of the artist fields (only one artist possible or create a new collaboration artist) were removed in NGS, so I want to update the guidelines to reflect this. But the artist concept just doesn't fit classical, and I'm hoping for a solution eventually where you can enter all ARs when entering a release, and the artist fields will get populated automatically. But we still need to decide what data these fields should contain. With the current UI? I really believe this would be impossible to enforce with the current UI. I agree that the best (?) system will probably imply modifications to the database schema, but I think there are intermediate steps where the UI could be modified without any schema change in order to make these rules usable. -- Frederic Da Vitoria (davitof) I'm not sure I follow you. What I'm trying to say is that these fields will still be here and I assume we will have to use them, even when there's a better system in place. /symphonick ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
2012/2/9 Alex Mauer ha...@hawkesnest.net On 02/09/2012 03:10 AM, symphonick wrote: 1) Track Artist = Recording Artist = Composer + important/featured performers 2) Track Artist = Recording Artist = Important/featured performers 3) Track Artist = Composer, Recording Artist = Important/featured performers I would veto none of these. As long as the recording artist includes the performer, I’m happy. I’d be happier if it were *only* important/featured performers, but I don’t strongly object to including the composer *as well* I think my actual preference would be a modification of 3: * Track artist = whatever the release says (i.e. important/featured *artists*: maybe performer, maybe composer, maybe both; If the release doesn’t clearly say, use both) * Recording artist = important/featured performer(s) I’m not sure that it’s such a big problem that the guideline might state that the track artist doesn’t equal the recording artist. There will be “wrong” recordings for a long time to come anyway given that CSG-classic has been this way since forever. A few more in the interval before we get a better UI won’t hurt anything. So is there any reason we can’t *recommend* that the RecArtist be the performer, but not require everyone to change it immediately? The problem is that searching will be completely broken if we don't enter performers anywhere: Sonata by Mozart Sonata by Mozart Sonata by Mozart etc. /symphonick This way the people tagging the releases would be happy, and the people who don’t want to edit the recordings would be happy. And once we have a better UI, everyone would be happy. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
On 02/09/2012 09:33 AM, symphonick wrote: I assume we have to introduce a second delimiter if you want to tag by composer and we only have one field for artists (performers and composer). Why on earth are people talking about trying to parse the artist field to determine the composer and/or performers? (not really directed at you, symphonick, I know that *if* we wanted to parse the artist field we’d want different delimiters to enable this) But we have had ARs for a long, long time now. Picard can use them, and you can tag based on them. The taggerscript is as simple as: $if($in(%genre%,Classical),$set(%artist%,%composer%)) (that’s not perfect, because it will match any tag starting with “Classical”, e.g. “Classically-trained musician) But still, it’s definitely much simpler than trying to input the composer everywhere. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
On 09/02/2012 15:33, symphonick wrote: monxton wrote: - I've mentioned before that ARs and ACs are not symmetrical, because ARs have a role (e.g. conductor, cello ...) and ACs do not. I like to see the role. Conversely, ACs have performance credits and ARs do not, for example the AC could be for Stephen Bishop or Stephen Kovacevich, or Stephen Bishop-Kovacevich, but the AR can only be for Stephen Kovacevich. I'd like to see this limitation removed. In that case you can't really avoid duplicating data, can you? You need an alias for this performer at release level. Why should the limitation be set in concrete? It's a small matter of database schema to add a performance credit to the AR. - At the simplest level, I really want my music player to tell me that I am listening to Beethoven, not to the performers (though I'd like to know who they are). This is perhaps the USP that brought me to MBz in the first place. For non-classical music, I want the opposite. I'm reluctantly coming round to the idea that we're going to need a style field, which may be CSG, popular or maybe others, that the taggers can employ. That can be done without breaking searching if we put performers as recording artist and the composer as track artist. Or try a CSG genre some scripting in Picard? Yes of course this can be done by various scripts and special encoding of text fields. But we must have a solution which works naturally for people who don't know how to do such things and don't want to learn, and it's my belief that most people who listen to classical music also see the composer as the foremost item of structured data that they want associated with their music file. The more the data has to be coerced, the less likely it is that things will just work. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
2012/2/9 monxton musicbra...@jordan-maynard.org On 09/02/2012 15:33, symphonick wrote: monxton wrote: - I've mentioned before that ARs and ACs are not symmetrical, because ARs have a role (e.g. conductor, cello ...) and ACs do not. I like to see the role. Conversely, ACs have performance credits and ARs do not, for example the AC could be for Stephen Bishop or Stephen Kovacevich, or Stephen Bishop-Kovacevich, but the AR can only be for Stephen Kovacevich. I'd like to see this limitation removed. In that case you can't really avoid duplicating data, can you? You need an alias for this performer at release level. Why should the limitation be set in concrete? It's a small matter of database schema to add a performance credit to the AR. Maybe. My point is that the AR is at recording level, so you have to manually edit all instances at release level where you need a different script/spelling. /symphonick - At the simplest level, I really want my music player to tell me that I am listening to Beethoven, not to the performers (though I'd like to know who they are). This is perhaps the USP that brought me to MBz in the first place. For non-classical music, I want the opposite. I'm reluctantly coming round to the idea that we're going to need a style field, which may be CSG, popular or maybe others, that the taggers can employ. That can be done without breaking searching if we put performers as recording artist and the composer as track artist. Or try a CSG genre some scripting in Picard? Yes of course this can be done by various scripts and special encoding of text fields. But we must have a solution which works naturally for people who don't know how to do such things and don't want to learn, and it's my belief that most people who listen to classical music also see the composer as the foremost item of structured data that they want associated with their music file. The more the data has to be coerced, the less likely it is that things will just work. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] On publishers as artists
Hello, On 09/02/12 09:07, Frederic Da Vitoria wrote: In your answer you did not use the composer AR at all. Was this intentional? I do not personally use relationships much, so they're not usually my concern ;) For the composer relationship I wouldn't enter it if I didn't know who the composer was. In general I'm OK with setting the audio director of a video game as the composer for all works which together form the soundtrack of that video game. If there is proof that all of the soundtrack was a team effort and should be credited to the development studio, we should try to add additional composer relationships for the other team members. In general we rarely credit groups in relationships, usually we don't credit at all until we've figured out who the actual composers are and add relationships for those persons separately. So even when the music team inside a video game company has a name itself (like Falcom Sound Team jdk) and is credited as composer, I'd be hesitant to use such a group name in composer relationships. -- kuno / warp. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
On Thu, Feb 9, 2012 at 2:10 AM, symphonick symphon...@gmail.com wrote: I don't know what do really, I'd like to be able to use MB for classical, but I see it as pointless right now. I'd prefer if we could decide on a guideline, even if it's not perfect. So let's try this: a) which of the following solutions would you prefer? b) which of the options would you veto (if any) and why? 1) Track Artist = Recording Artist = Composer + important/featured performers 2) Track Artist = Recording Artist = Important/featured performers 3) Track Artist = Composer, Recording Artist = Important/featured performers From a data field standpoint, I'm against 1 and 3, because the composer should be linked once, through a work-level AR. From a data display standpoint, the composer should be included. This means that if we are talking about the a UI modification, I'm mostly for 1 with 3 being ok. 2 is ok, because the data field should have a consistent definition across the database. However, it will break existing taggers - or at least make them unable to automatically tag following the CSG. It may also break scrobbling. To quote: Everything is fine. Nothing is ruined. Is there a panacea? No, but the summit's discussion of the interface seems to be our best shot. Right now, I would be satisfied if I could enter a release+ARs in less than an hour. Beyond that, I'm having trouble really caring. David ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
a) which of the following solutions would you prefer? b) which of the options would you veto (if any) and why? 1) Track Artist = Recording Artist = Composer + important/featured performers 2) Track Artist = Recording Artist = Important/featured performers 3) Track Artist = Composer, Recording Artist = Important/featured performers 2) is a no go. We had a consensus on old CSG that AC should be the composer. Switching to this would mean that every single AC for classical would have to be changed and that the composer – until we can eventually make an inheritance from works or ARs – will not show anymore. I'm certainly not the only one that will veto such a proposal. 1), as said again and again, is bad: mixing composers and performers in the same field with a complex syntax is error prone and discouraging new editors (and simply wrong from a DB-structure point of view). I haven't settled my opinion on whether I'd veto such a proposal, but I certainly would be very unhappy with it. 3) on the other hand is a workaround solution that will allow searches and listings for composers and performers (whatever one fancies) until something better comes up. Of course it's not perfect, but once we reached some consensus the developers will be able to work on a better user interface for entering the data according to the guidelines. I believe this third proposal, which was the one originally submitted, would already have passed without this unnecessary last minute change ;-) Chris/chabreyflint On Thu, Feb 9, 2012 at 10:52 PM, David Hilton quercus.aeter...@gmail.comwrote: On Thu, Feb 9, 2012 at 2:10 AM, symphonick symphon...@gmail.com wrote: I don't know what do really, I'd like to be able to use MB for classical, but I see it as pointless right now. I'd prefer if we could decide on a guideline, even if it's not perfect. So let's try this: a) which of the following solutions would you prefer? b) which of the options would you veto (if any) and why? 1) Track Artist = Recording Artist = Composer + important/featured performers 2) Track Artist = Recording Artist = Important/featured performers 3) Track Artist = Composer, Recording Artist = Important/featured performers From a data field standpoint, I'm against 1 and 3, because the composer should be linked once, through a work-level AR. From a data display standpoint, the composer should be included. This means that if we are talking about the a UI modification, I'm mostly for 1 with 3 being ok. 2 is ok, because the data field should have a consistent definition across the database. However, it will break existing taggers - or at least make them unable to automatically tag following the CSG. It may also break scrobbling. To quote: Everything is fine. Nothing is ruined. Is there a panacea? No, but the summit's discussion of the interface seems to be our best shot. Right now, I would be satisfied if I could enter a release+ARs in less than an hour. Beyond that, I'm having trouble really caring. David ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
On Fri, Feb 10, 2012 at 12:39 AM, SwissChris swissch...@gmail.com wrote: a) which of the following solutions would you prefer? b) which of the options would you veto (if any) and why? 1) Track Artist = Recording Artist = Composer + important/featured performers 2) Track Artist = Recording Artist = Important/featured performers 3) Track Artist = Composer, Recording Artist = Important/featured performers 2) is a no go. We had a consensus on old CSG that AC should be the composer. Switching to this would mean that every single AC for classical would have to be changed and that the composer – until we can eventually make an inheritance from works or ARs – will not show anymore. I'm certainly not the only one that will veto such a proposal. 1), as said again and again, is bad: mixing composers and performers in the same field with a complex syntax is error prone and discouraging new editors (and simply wrong from a DB-structure point of view). I haven't settled my opinion on whether I'd veto such a proposal, but I certainly would be very unhappy with it. 3) on the other hand is a workaround solution that will allow searches and listings for composers and performers (whatever one fancies) until something better comes up. Of course it's not perfect, but once we reached some consensus the developers will be able to work on a better user interface for entering the data according to the guidelines. I believe this third proposal, which was the one originally submitted, would already have passed without this unnecessary last minute change ;-) I won't veto 3) as long as people won't vote No on adds that don't follow the AC stuff exactly, but also add all the relationships (which are the important part of all the classical mess). I can't really see the point of choosing anything now in a hurry though. CSG for NGS - Add all relationships! (I'm only half-joking). Chris/chabreyflint On Thu, Feb 9, 2012 at 10:52 PM, David Hilton quercus.aeter...@gmail.com wrote: On Thu, Feb 9, 2012 at 2:10 AM, symphonick symphon...@gmail.com wrote: I don't know what do really, I'd like to be able to use MB for classical, but I see it as pointless right now. I'd prefer if we could decide on a guideline, even if it's not perfect. So let's try this: a) which of the following solutions would you prefer? b) which of the options would you veto (if any) and why? 1) Track Artist = Recording Artist = Composer + important/featured performers 2) Track Artist = Recording Artist = Important/featured performers 3) Track Artist = Composer, Recording Artist = Important/featured performers From a data field standpoint, I'm against 1 and 3, because the composer should be linked once, through a work-level AR. From a data display standpoint, the composer should be included. This means that if we are talking about the a UI modification, I'm mostly for 1 with 3 being ok. 2 is ok, because the data field should have a consistent definition across the database. However, it will break existing taggers - or at least make them unable to automatically tag following the CSG. It may also break scrobbling. To quote: Everything is fine. Nothing is ruined. Is there a panacea? No, but the summit's discussion of the interface seems to be our best shot. Right now, I would be satisfied if I could enter a release+ARs in less than an hour. Beyond that, I'm having trouble really caring. David ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
On 02/09/2012 05:51 PM, Nicolás Tamargo de Eguren wrote: I won't veto 3) as long as people won't vote No on adds that don't follow the AC stuff exactly, but also add all the relationships (which are the important part of all the classical mess). +1 to this. If we have ARs we can deal with with the rest. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
SwissChris wrote: a) which of the following solutions would you prefer? b) which of the options would you veto (if any) and why? 1) Track Artist = Recording Artist = Composer + important/featured performers 1), as said again and again, is bad: mixing composers and performers in the same field with a complex syntax is error prone and discouraging new editors (and simply wrong from a DB-structure point of view). How is it wrong from a DB-structure point of view? The artist credits are for artists credited regardless of the role they played. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
