I see multiple issues. The "artist" field is badly designed (dating to ID3 v1), but at least our use is generally consistent, genre-depending. Soundtracks, production music, "classical" (broadly defined), and maybe a few other genres I'm not thinking of, use composer as artist. Everything else uses performer. What you describe doing is to instead overload the artist field with nearly anyone involved in the recording, from composition to performance (yet not mixer, DJ, masterer, etc...?)
"Work displays show every recording as 'by [Composer]'." The solution would seem to be to use performer (and conductor) ARs, if 1+ are set for the recording, for the recording artist, not overloading the artist field.
"Tracks should be credited pretty much as on the release. In the case of multiple composers, you will need a different per-track credit for each one, though the performers may be the same." - This adds greatly to the tedium and difficulty of entering a classical release. I've seen many releases, classical compilations, which would become a nightmare to enter - 15 tracks, each by different composers, each performed by different sets of performers and conductors? For a release type which is most likely to be encountered by a non-CSG editor, this would make those same type of releases the hardest to enter at all.
"In general, follow the album cover for track and release titles." - The biggest issue I ran into when drafting CSGv2 was digital releases. As more and more releases become digital only, this becomes a bigger and bigger issue. Problem is, in many cases, for classical, there is no set track title. I've seen a good number of such cases at Amazon and Naxos, to name the biggest 2 where I've seen it, where I'm pretty sure that they're just getting a generic title by pointing to some entry in a local database of classical works, not based on anything specific to the release.
"Use a slash (/) where the cover separates by line break. (e.g. “The Planets Suite / St. Paul’s Suite”)" - This breaks http://wiki.musicbrainz.org/Style/Titles/Subtitles , without good rationale so far as I can tell. The example you give is a case of multiple works on a release. Yet the wording here, and the seeming cancelling of subtitle style, would give instead things like "The Best of / Mozart / His 4 greatest works / Jupiter / Requiem / Symphony 20 / Piano Concerto No. 6".
Also, the title examples given are for pretty basic cases, without being very informative as to how you get to that in all other types of cases. It was intended for works, not the short form for recordings, but this is how I got there for the CSGv2 draft: http://wiki.musicbrainz.org/Proposal:CSGv2/Work/Title/Work_and_opus_identification#Basic_Framework and http://wiki.musicbrainz.org/Proposal:CSGv2/Work/Title/Movement_identification .
"If it appears in multiple languages, use the first." - this is confusing. The first few times I read it, I thought you meant "Ok, I have this release. Track 1's title is in German, so I have to use German for every title", not "Symphony in A-sharp minor / Symphonie en la diesis minore / Symphonie in ais-Moll".
Regarding overloading "artist", though, I am completely against this. What you describe as problems that require this change *are* pretty much display issues. T"hings like “under the direction of” or “with electric accordion performed by”" ought not to be in the artist field. What you're describing is really the flattening of all AR-type credits for each recording, shoving them all into a single field. In the process, you also eliminating any usefulness of the artist field. An identical result could be obtained simply by 1) listing performance/conductor/etc AR recordings' releases on a performer/conductor/etc's listing. As a side benefit, you'd get far better ARs (ie, more specific data) while the same data is entered - and you'd not have to do it all while creating the release, but instead, it could be done as time permits (as ARs are currently). We should be moving to make adding ARs more simple/easy, useful, and encouraged, not moving people towards instead massively overloading the artist (or AC) field.
220.127.116.11 21:53, 1 December 2011 (UTC) (aka BrianFreud)