History:CSGv2Proposal: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
No edit summary
Line 3: Line 3:
* [[Proposal:Multi-Track Movement Style]]
* [[Proposal:Multi-Track Movement Style]]
* [[Opera Track Style]]
* [[Opera Track Style]]
* [[ClassicalMusic]]

* [[ClassicalReleaseArtistStyleProposal]]
* [[ClassicalReleaseLanguage]]
* [[ClassicalStyleGuide]]
* [[ClassicalStyleGuideDiscussion]]
* [[ClassicalStyleGuideDiscussionHistory]]
* [[ClassicalStyleGuideline]]
* [[ClassicalStyleGuidelines]]
* [[ClassicalTrackTitlePartnumberStyle]]
* [[ClassicalTrackTitleStyle]]
* [[PrimaryArtistForClassicalReleases]]
* [[SpringCleaningClassicalReleases]]
* [[ClassicalEntriesThatNeedEditing]]





Revision as of 15:05, 26 March 2010

Pages to make History:


https://mail.google.com/mail/?shva=1#search/%22current+state+of+the%22/118ce7c23ce1b134

2008-03-20 [mb-style] Bach passions and CSG


>>> >>> > Can anyone come up with an example of music that's so-called >>> >>> classical >>> >>> > music, but would need to use this exception? >>> >>> > >>> >>> >>> >> >>> >> First two that spring to mind would be ELP's Pictures at an >>> Exhibition, >>> >> or >>> >> the several times Nirvana played whatever song it was from Carmen. >>> >> >>> >> >>> > >>> > Sorry, I was unclear again. I meant with "classical" performers. >>> Otherwise >>> > we could perhaps just say that this exception should be used only >>> when >>> > dealing with classical music arranged/transformed into other genres >>> > (jazz/pop/whatever)? >>> > >>> Yes, I think that would make it clearer. In rereading the section I >>> can >>> see why you thought it was confusing, since the literal words in the >>> definition don't really say what we mean. >>> >>> (If we really thought hard we could come up with classical->classical >>> "covers." But, we don't think of them that way. We'd call them >>> "recompositions," or something. An example would be Pseudo-Pergolesi >>> -> >>> Stravinsky's Pulcinella. Or Bach -> Stravinsky's Von Himmel Hoch >>> Variations. I don't think it's likely that anybody is going to be >>> tempted >>> to put those under Pergolesi or Bach.) >>> >> >> Speaking of covers... and speaking of Pictures at an Exhibition, there >> is >> also Moussorgsky and Ravel. This work is a nice illustration of how >> things >> are to be handled. >> >> But what about Bach / Gounod. Do we still consider the Ave Maria as >> Bach's >> work or do we put it under Gounod? > > > ... or do we credit it to both? > I think the conventional answer has been to treat it as a "collaboration" between Bach & Gounod (in which the former just happened to be dead.)

But perhaps a smarter answer would be to credit it to Gounod (as a recomposition). This source makes no bones about it:

http://imslp.info/files/imglnks/usimg/2/20/IMSLP05775-Ave_Maria.pdf

I guess the sad thing is that Bach then gets "no credit." It would be funny if we used the popular music ARs to say that it's a "cover." Maybe we can invent a "recomposition" or a "draws on" AR with CSGWorks.

> > But perhaps a smarter answer would be to credit it to Gounod (as a > recomposition). This source makes no bones about it: > > http://imslp.info/files/imglnks/usimg/2/20/IMSLP05775-Ave_Maria.pdf > > I guess the sad thing is that Bach then gets "no credit." It would be > funny if we used the popular music ARs to say that it's a > "cover." Maybe > we can invent a "recomposition" or a "draws on" AR with CSGWorks. > > -Dave Smey (bklynd) >

In this case the piece was so heavily re-worked I would be inclined to put Gounod as the track artist, but have two composition ARs, one each for Bach and Gounod. In even more heavily re-worked cases we give Bach both composition and track artist credits for his chorales even though many of them are based on hymns by Martin Luther, and we would never mark one of the movements of Appalachian Spring as [traditional] even though Copland based part of it on a Shaker hymn. The harder ones to decide are things like the Liszt piano transcriptions of the Beethoven symphonies. Liszt does it as a fairly straight transcription, so I put one of them with track and release artist as Beethoven, Beethoven composition ARs and Liszt arrangement ARs, but I'm still not sure if that was the best solution, as record stores, and the covers of the recordings generally file these things as Liszt compositions.

Well, when we have works, I'd guess we'll be relating them togther too, like everything else. Why not a 'recomposition" (or some such wording) AR, and a arranged AR, linking two works? (Just a thought, this is all kind of separate from the CSG proposal...)




Regarding punctuation:

The following appears on both http://wiki.musicbrainz.org/BrianFreud/sandbox and http://wiki.musicbrainz.org/BrianFreud/sandbox4

(quote) Standard ASCII punctuation should always be used for the space , the full-colon :, the semi-colon ;, the hyphen-minus -, single quotation marks ' ', double quotation marks " ", parenthesis ( ), square braces [ ], commas ,, periods ., and all other punctuation.

If French CSG is being used, the additional punctuation spacing rules of CapitalizationStandardFrench also apply. (unquote)

Questions and suggestions:

(1) Does this apply both to CSG-for-Works and CSG-for-Tracks?

(2) Perhaps there should be an explicit, exhaustive list of what punctuation marks are acceptable. Is the whole ASCII set acceptable, including {curly braces} ~tilde `backtick +plus *asterisk etc.?

(3) Perhaps there should be a few examples of punctuation marks that are not acceptable, although (2) above might make this superfluous. Nevertheless, I'd like to clarify for my own understanding: are guillemets, em dash, en dash, numero sign, ellipsis acceptable? [1] I am assuming "no" since it says ASCII only.

[1] http://en.wikipedia.org/wiki/Template:Punctuation_marks


Much more works, I think. Tracks I would think we'd just be going from a) what is used on the liner, then b) normal MB-general style guidelines on punctuation/etc.

(2) Perhaps there should be an explicit, exhaustive list of what > punctuation marks are acceptable. Is the whole ASCII set acceptable, > including {curly braces} ~tilde `backtick +plus *asterisk etc.?


(2) Perhaps there should be an explicit, exhaustive list of what > punctuation marks are acceptable. Is the whole ASCII set acceptable, > including {curly braces} ~tilde `backtick +plus *asterisk etc.?


Well, for punctuation that would be correct in any case, by normal guidelines, doesn't :;-'"()[],. cover it?

(3) Perhaps there should be a few examples of punctuation marks that are > not acceptable, although (2) above might make this superfluous. > Nevertheless, I'd like to clarify for my own understanding: are > guillemets, em dash, en dash, numero sign, ellipsis acceptable? [1] I am > assuming "no" since it says ASCII only. > > [1] http://en.wikipedia.org/wiki/Template:Punctuation_marks >

Coming from last year's lengthy debates on this, I would suggest only those listed should be used, no guillemots, etc.

In that case, can we change it to an explicit list? I'd change:

Standard ASCII punctuation should always be used for the space , the full-colon :, the semi-colon ;, the hyphen-minus -, single quotation marks ' ', double quotation marks " ", parenthesis ( ), square braces [ ], commas ,, periods ., and all other punctuation.

to:

Standard ASCII punctuation should always be used: the space , the full-colon :, the semi-colon ;, the hyphen-minus -, single quotation marks ' ', double quotation marks " ", parentheses ( ), square braces [ ], commas ,, and periods .. Those characters should be used in place of any other punctuation.

> > > Works for me. I'd probably add in an exclusion, though, noting that, as > mentioned in the initial section, if there is a specific title given by the > artist (say, a John Cage work), that this bit about punctuation doesn't > forbid the use of punctuation, if there is express artist intent.

Yes, let's add such an exclusion.

Since you mentioned Cage: should a track title like 4'33" use ASCII single and double quotes, or the PRIME and DOUBLE PRIME characters? If the former, maybe we should edit the lines about feet and inches on http://wiki.musicbrainz.org/MiscellaneousGuideline to also include minutes and seconds (of time, as in 4'33", and of arc, e.g. longitude/latitude).


> I know we've seen the curly quotes, and I well recall the hyphen/dash > debate... I think this section might be something that's "obvious" to > most editors, but we'd seem safer to include it, rather than not include > it, and have it come up again as an open issue later.

I remember the hyphen/dash-debate too, but I got the impression that dashes are OK. (We certainly do use non-ascii characters, and it is rather common online, so why not?) I thought the many negative reactions were directed more at the full-use-of-(possibly-enforced)-typographically-sound-rules or something.


> 3) I don't see why we would want to override language specific rules for > "No." and "Op." (same page) (e.g. Norwegian uses "op." and "nr." and can > commonly be seen on Norwegian Grieg releases. The French of course have > their "n°") > > The main goal there was to exempt those from AbbreviationStyle forcing > "No." to become "Number", and to avoid our getting a lot of "no." in > English CSG. I actually wasn't aware that some languages we were doing > lowercased. Can you think of a better way to handle this re > capitalization, preferably without our having to actually specify > specific capitalization rules for each and every different language's > version of CSG?

Capitalization Capitalization should follow standard capitalization for the language, except for titles that come from opera librettos, poems and similar. For these, the capitalization on the release should be used.

[Not mentioning major/minor No. and Op. implies that language specific rules should be used. Perhaps some examples could be included.]

Abbreviations AbbreviationStyle should be followed except for abbreviations commonly used when referring to classical works:

No. Op. Composer work list identifiers (Wwo, K, BWV, etc.)

[Not mentioning "Nr." makes all examples English. This indicates that similar abbreviations are allowed for other languages.]

> *** > > And coming to the Track Title section of sandbox4: Your Jeunehomme > examples are perhaps done in a hurry? > > 1) The movement numbers are placed in front of the whole track title. > 2) You change "E flat" into "E-flat" but leave "K 271" alone. > 3) You leave out some punctuation marks we're used to from the CSG. > > > Actually, done on purpose - following the "just as on the liner" > principles. I think our normalizing keys and "major/minor" as > lowercased is 100% safe, but anything much more than that, we start > getting back into CSG-type rules for how to normalize data. So, > ordering it just as on the liner, with 99.99% of the text unmodified, > and no punctuation added or removed.

I don't mind not normalising the keys, both "Major" and "major", "E flat" and "E-flat" is used much. My impression is that "E flat" is more in use than E-flat.

But some stylised track listings are in all upper/lower caps. For these, standard caps rules come in effect, and it is sensible then to do so also for "No." and "Op."

I think it unwise to add the movement number in front of the track title (an exception would be where there is only one symphony on the release, and the work name part can be left out, but that is for another discussion).

I think a more proper concatenation for Jeunehomme would be: Concerto for Piano and Orchestra No. 9 in E-flat major K 271 "Jeunehomme": 1. Allegro

> *** > > A statement that could be worded better: > "If each track's title is presented in multiple languages, only one > should be used". The wording implies that e.g. recitals with German and > French lieder should have only one language in the MB track listing. > > Here's what I am thinking (and this is also answering Chris B, who seems > to want us to always include all languages in the titles) > "If track titles of the release are presented in multiple languages, use > those that are most prominent (these will usually be first or formatted > in bold face.). Choice of language should be used consistently, but of > course multiple languages are allowed e.g. for releases with music by > both French and German composers." > > > I'm not sure I agree with the "most prominant" part, but the other half > I do agree with. I'm trying to say that, given "language 1 / language 2 > / language 3" titles on the liner, if you're entering using language 2, > all titles should be language 2 titles, not a mix and match. Any ideas?

Perhaps you can read my wording this way: Our advice is to follow the track listing, also for choice of language. If some random editor does choose to enter English track titles in stead of German titles (which likely are foreign-looking to him), we can inform him of the guideline (but should certainly not be required to), and we should not pepper him with negative comments.

Editors should not go around "fixing" wrong languages. It is better to add another release and hook the two up with ARs.

> **** > > I disagree with the wholly explicit sentiment that "the more information > you can get into the track titles, the better". When we get works, much > of this information can be gotten from them. Information about cadenzas > and arrangements should in most cases go into annotations I think. > > > For track CSG, I'm tending to agree - that ornamentation bit, on that > part of the guidelines, is far heavier than any of the rest; I could > live with dropping that entire section.

I would also like to have the following two removed:

"Tracks should be titled so as to be as informative as possible, per what is on the liner..."

"Please note that it is quite common for the outside cover to only include limited identification information due to space limitations. Please check inside the booklet to ensure that you are providing as informative a track title as possible."

In particular the last one: On a printed booklet page it makes sense to effectively convey much information by use of different fonts, indentation and the like. The result can still be very readable. This is

  • not* the case for MB track titles, including every tidbit can seriously

harm the readability of the titles.

This is important because one of the primary use cases for MB-data is to provide input to music players which simply show just the track title and album title. - Show quoted text -

> In my opinion, the most important thing is to identify the work, and the > second most important thing is to make that look good. > > The archetypal example of information overload is perhaps the following: > > Concerto in Mi maggiore per violino, archi e clavicembalo, Op. 8 No. 1, > RV 269 "Il cimento dell'armonia e dell'inventione: Le quattro stagioni: > La primavera": I. Allegro > > (A multiple language representation of this would be utterly > dysfunctional.) > > For many releases, one of the following would look much better, IMO: > "The Four Seasons, Concerto No. 1 "Spring": Allegro" > "Concerto in E major, RV 269 "Spring": I. Allegro" > > Of course there are others that are equally fine. > > So here's my go at an alternative wording: > > " > The basis for classical track titles should be taken from the liners. > Liner titles may vary from release to release, even when they contain > the same works. As a consequence, track titles for MusicBrainz releases > should differ accordingly. > > For one liner, several track listings may be possible. This will be the > case if the cover track listing differs from the booklet track listing, > or if the (only) track listing contains many details. The important > thing to remember here, is that the release and track titles must > identify the work(s) of the release. The identification will in general > be based on the work name, but for particular well-known works commonly > used names can be used ("The Four Seasons", "Air on a G-String" etc.) > > Since the track title you enter may be used in many various settings, > you should favour clarity, readability and brevity when you enter track > titles. > > Otherwise, we make an addition to other MusicBrainz style guidelines: > > > This goes back towards what we had in the early CSGs, 2006-2007, where > you had all sorts of optional titles. If the idea is that we want to > try to capture what's actually on the liner, at least in one language > set's worth of what's on the liner, with the idea that this as value, > then let's actually do that, and not get into editor-based judgements > about how he or she now can / should / must modify that data... because > then any value that was there in the track title is lost. > > As for the degree of detail in a work title, I think that's best kept as > we'd talked last year, saved for whatever we call them - "work > elements"/"build your own CSG"/whatever - but I think that while works > will be a soonish thing, elements may be much further off, due to the > degree of complexity in that concept...

Here's where I'm coming from:

1) Users should have the freedom choose the titles they see fit. Titles should be based on the liners and be in spirit with the liners, though. 2) Many track listings include more information than is useful for MB-track listings (see above). Therefore, brevity should be encouraged. If the user keeps the liners (perhaps because of some booklet essay), he still has access to the fully detailed listing. If not, the same details - and then some! - can in many cases easily be found online (and works can someday provide some of them). 3) In case of disputes, userA really wants "K 271" in the track titles, userB really wants to leave it out, the only fallback is the liners. If "K 271" is included but in a smaller font, perhaps I would vote against including it.

Squabbling over petty details should calmly be discouraged by seasoned editors and autoeditors, and everyone has some responsibility for maintaining a civil tone. Zealotry and redoing of edits after a fair vote should be discouraged.

I'd rather justify few and liberal rules over and over, rather than always having to justify one strict style which is bound to result in ugly track listings.

> > [I am assuming typos are handled by other guide lines] > > > If you mean for track CSG, it's right up in the top few lines. "If the > liner contains any typos, please correct them in the track title."

Yes, I took it away, assuming it was covered by other MB guide lines. I would like to have CSG track rules as small as possible and have have it integrated with the rest of the MB styles as much as possible.


On Wed, Jan 14, 2009 at 1:31 PM, Chris B <chris@whenironsattack.com> wrote: > 2009/1/14 Leiv Hellebo <leiv.hellebo@gmail.com>: >> Here's what I am thinking (and this is also answering Chris B, who seems >> to want us to always include all languages in the titles) > > non :) only if all languages are given in the *tracklisting* (ie no > the liner and not the small print). we're continuing this in kuno's > thread if you're interested...

Just to make it clear, I have seen at least one release that had the

  • tracklisting* (i.e., the list on the back cover) in four languages

(English, French, German and Italian) and in the exact same format for all of them (i.e., the cover was split in four quarters, and each quarter had a list in one of the languages, all in the same font). That is, none of the four was primary.

(Incidentally, the booklet was also in four languages, and unless I'm misremembering it actually had a *different* guy that wrote the liner notes for each language. Same for the front cover. That is, there were no translations except for the one from whatever language the composer had written on his draft sheets.)


Arietta con Variazioni for Piano in A major

Arietta variata Variation I (with a Da capa) Variation II (with a Da capa) Variation III (with a Da capa) Variation IV (with a Da capa) Variation V (with a Da capa) Variation VI (with a Da capa) Variation VII (with a Da capa) Variation VIII (with a Da capo dal segno) Variation IX (with a Da capo dal segno) Variation X (with a Da capo dal segno) Variation XI (with a Da capo dal segno) Variation XII (with a Da capo dal segno) Arietta da capo

If we were to break out the da capos and da capo dal segnos in there, it would almost immediately turn in to an incomprehensible mess.

I would suggest, as i did at the end of that edit, that we merely use the common score notations for these (generalized description of each in the parenthesis):

D.C. = Da capa (repeat movement from the beginning, up to some marked point)

D.S. = Dal segno (return to some marked point within the movement or another movement, up to some marked point)

D.C. al fine = Da capa (repeat movement from the beginning, to the end)

D.S. al fine = Dal segno (return to some marked point within the movement or another movement, to the end of the current movement)

Coda = Coda (a different closing section used in combination with a repeated section of a movement)

D.C. al coda = Da capa al Coda (Return to the beginning of the movement, play up to a marked point, then move to the alternate ending section)

D.S. al coda = Dal segno al Coda (return to some marked point, then play through to the end, using the alternate ending section)

D.C.D.S. = Da capo al segno (return to the beginning of the movement, then play through, up to the marked point)

rather than try to unravel them, as I was attempting at the beginning of that edit. So, this would become:

Arietta variata Variation I. D.C. Variation II. D.C. Variation III. D.C. Variation IV. D.C. Variation V. D.C. Variation VI. D.C. Variation VII. D.C. Variation VIII. D.C.D.S. Variation IX. D.C.D.S. Variation X. D.C.D.S. Variation XI. D.C.D.S. Variation XII. D.C.D.S. Arietta. D.C.

Which remains pretty clean, and considering this likely would have all works on a track, if / when we do have the ability to tag to track names, it'd give a much much shorter title than if we were to expand all those Da capas and Da capa dal segnos out.