Discussion:
[mb-style] CSG compromise?
(too old to reply)
Mike Morrison
2008-02-29 05:05:26 UTC
Permalink
OK, so once we have NGS everyone can have what they want, right? We'll
have work titles and track titles. The work title can be full CSG(S),
while the track title can be what's on the cover. So each track will have
these two titles associated with it.

For now, how about if we use the track title field for one of the two
titles, and annotations for the other? We need somewhere to store the
"other" title for now anyway, right? I don't care which title goes in
which spot. If the one I like better ends up in the annotations, I'll copy
and paste it into my local files if need be.

Then when NGS is implemented, we can migrate the information from the
annotations into the appropriate field.

Mike
Aaron Cooper
2008-02-29 05:21:07 UTC
Permalink
On 27-Feb-08, at 8:10 PM, Mike Morrison wrote:

>
> OK, so once we have NGS everyone can have what they want, right?
> We'll have work titles and track titles. The work title can be full
> CSG(S), while the track title can be what's on the cover. So each
> track will have these two titles associated with it.
>
> For now, how about if we use the track title field for one of the
> two titles, and annotations for the other? We need somewhere to
> store the "other" title for now anyway, right? I don't care which
> title goes in which spot. If the one I like better ends up in the
> annotations, I'll copy and paste it into my local files if need be.
>
> Then when NGS is implemented, we can migrate the information from
> the annotations into the appropriate field.

I don't understand what we're discussing because classical works don't
have "tracks" or "track titles"?they have "work titles". A classical
recording has tracks, but what do you use as the track titles? As I
gather from your email (and those of some other similar-minded
editors) we want to put the "track title" in the "track title"
field... so we look to the track listing on the CD... and we find
"work titles" don't we? (serious question)

It's not like classical works have a work title (Symphony No. 5 in C
minor, Op. 125: I. Allegro con brio) and then also a track title
version. The way we refer to that piece is with the work title unless
we chop out the actual work name (Symphony No. 5 in C minor, Op. 125)
and just write "I. Allegro con brio".

Are we debating whether we should copy from the CD "Symphony No. 5: I.
Allegro con brio" or whether to add missing information to write
"Symphony No. 5 in C minor, Op. 125: I. Allegro con brio"?

-Aaron
Mike Morrison
2008-02-29 08:22:02 UTC
Permalink
On Thu, 28 Feb 2008, Aaron Cooper wrote:

> On 27-Feb-08, at 8:10 PM, Mike Morrison wrote:
>
>>
>> OK, so once we have NGS everyone can have what they want, right? We'll have
>> work titles and track titles. The work title can be full CSG(S), while the
>> track title can be what's on the cover. So each track will have these two
>> titles associated with it.
>>
>> For now, how about if we use the track title field for one of the two
>> titles, and annotations for the other? We need somewhere to store the
>> "other" title for now anyway, right? I don't care which title goes in which
>> spot. If the one I like better ends up in the annotations, I'll copy and
>> paste it into my local files if need be.
>>
>> Then when NGS is implemented, we can migrate the information from the
>> annotations into the appropriate field.
>
> I don't understand what we're discussing because classical works don't
> have "tracks" or "track titles"-they have "work titles.

I agree.

> A classical recording has tracks, but what do you use as the track
> titles?

Personally, I like to use full-length CSGS-style work titles on the
tracks. However, it appears that some editors want track titles which are
shorter, or which more closely match the physical release cover.

> As I gather from your email (and those of some other similar-minded
> editors) we want to put the "track title" in the "track title" field...
> so we look to the track listing on the CD... and we find "work titles"
> don't we? (serious question)

On most of the releases I own, yes. But maybe not on some releases with
less-complete cover information ("Mozart: Allegro")?

> It's not like classical works have a work title (Symphony No. 5 in C
> minor, Op. 125: I. Allegro con brio) and then also a track title
> version. The way we refer to that piece is with the work title unless
> we chop out the actual work name (Symphony No. 5 in C minor, Op. 125)
> and just write "I. Allegro con brio".
>
> Are we debating whether we should copy from the CD "Symphony No. 5: I.
> Allegro con brio" or whether to add missing information to write
> "Symphony No. 5 in C minor, Op. 125: I. Allegro con brio"?

Yes, I think that has been the thrust of the debate. I'd like to add the
additional information, but it appears that not everyone agrees. I don't
want to speak for those folks, but I think they do see the work title and
the track title as two different things.

Mike
symphonick
2008-02-29 15:36:04 UTC
Permalink
> >> OK, so once we have NGS everyone can have what they want, right? We'll have
> >> work titles and track titles. The work title can be full CSG(S), while the
> >> track title can be what's on the cover. So each track will have these two
> >> titles associated with it.
[snip]
> > As I gather from your email (and those of some other similar-minded
> > editors) we want to put the "track title" in the "track title" field...
> > so we look to the track listing on the CD... and we find "work titles"
> > don't we? (serious question)

I have to check if I understand this NGS-stuff correctly:
Many (most) classical releases have "headings" in the tracklist, wich
gives the context for the following tracks. I randomly picked
http://www.bis.se/index.php?op=album&aID=BIS-SACD-1618
I do agree that "I. Allegro" is a perfectly fine track name _in
context of the above heading_. Outside of that context, it's just any
first movement with the tempo marking "Allegro".

That tracklist would look like this with worktitles removed:
1. I. Allegro
2. II. Andante
3. III. Rondeau. Allegro
4. I. Allegro
5. II. Adagio
6. III. Rondeau. Tempo di Menuetto
7. I. Allegro
8. II. Andante
9. III. Rondeau. Allegro

& so would the webinterface & the directory on my media
player/computer. Now, am I correct in assuming that:
1) The webinterface will show the NGS-worktitle on every track - or
even better: once above a group of tracks with the same worktitle?
2) Picard will be able to attach the worktitle to title-tag & filename?

--
/symphonick
Lukáš Lalinský
2008-02-29 16:04:37 UTC
Permalink
On Pi, 2008-02-29 at 10:36 +0100, symphonick wrote:
> I have to check if I understand this NGS-stuff correctly:
> Many (most) classical releases have "headings" in the tracklist, wich
> gives the context for the following tracks. I randomly picked
> http://www.bis.se/index.php?op=album&aID=BIS-SACD-1618
> I do agree that "I. Allegro" is a perfectly fine track name _in
> context of the above heading_. Outside of that context, it's just any
> first movement with the tempo marking "Allegro".
>
> That tracklist would look like this with worktitles removed:
> 1. I. Allegro
> 2. II. Andante
> 3. III. Rondeau. Allegro
> 4. I. Allegro
> 5. II. Adagio
> 6. III. Rondeau. Tempo di Menuetto
> 7. I. Allegro
> 8. II. Andante
> 9. III. Rondeau. Allegro
>
> & so would the webinterface & the directory on my media
> player/computer. Now, am I correct in assuming that:

> 1) The webinterface will show the NGS-worktitle on every track - or
> even better: once above a group of tracks with the same worktitle?

No. In the entire NGS thread by "work title" I meant full work title
including movement, etc. Something that represents a piece of music. On
the other hand when I say "track title" I mean title used for a specific
track on a specific release. This might map to one musical work,
multiple works or a just part of it. But there are no headings, no
groups, etc. All you have is a simple list of text fields. In this
specific example it would be:

1. Concerto in E-flat major for two pianos, KV365: I. Allegro
2. Concerto in E-flat major for two pianos, KV365: II. Andante
3. Concerto in E-flat major for two pianos, KV365: III. Rondeau. Allegro
...

This represents the actual recorded music, mastered and recorded on a CD
("what is says"). This probably won't change, because MB is and probably
will be used mainly as a database for tagging/CD lookups.

But then you have a database of musical works with structure like this:

* Concerto in E-flat major for two pianos (cat#: KV365, year: 1779)
* I. Allegro
* II. Andante
* III. Rondeau. Allegro

This represents music in abstract, but structured, way ("what it is").
You can add more levels to this structure if you want, so you can list
e.g. all concertos for piano by the composer. The point is that you can
link one track to one or more works. This way you can see all recorded
tracks of a particular musical work, and you can also see which works
are played on a particular track.

Somebody in this thread mentioned that classical music has no tracks,
which I guess is the main point of confusion here. Classical music
really has no tracks, but classical releases do have tracks and do have
track titles. But again, this is no different to non-classical music. It
has no tracks either, it has songs and releases of them again have
tracks and track titles.

> 2) Picard will be able to attach the worktitle to title-tag & filename?

Probably, maybe. :)

Lukas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Toto je =?ISO-8859-1?Q?digit=E1lne?=
=?ISO-8859-1?Q?_podp=EDsan=E1?= =?UTF-8?Q?_=C4=8Das=C5=A5?=
=?ISO-8859-1?Q?_spr=E1vy?=
Url : http://lists.musicbrainz.org/pipermail/musicbrainz-style/attachments/20080229/c713c76e/attachment.pgp
Brian Schweitzer
2008-02-29 16:16:31 UTC
Permalink
> Somebody in this thread mentioned that classical music has no tracks,
> which I guess is the main point of confusion here. Classical music
> really has no tracks, but classical releases do have tracks and do have

I was with you all the way up to here Luks. Classical release do
indeed have tracks. Classical releases, however, as Frederik, myself,
and Aaron have been pointing out, do not have track titles that are no
different from non-classical. This is why when the concept of "track
title" vs "work title" even comes up, I have to ask, what is this
official classical track title that we'd be preserving until and under
NGS?

> track titles. But again, this is no different to non-classical music. It
> has no tracks either, it has songs and releases of them again have
> tracks and track titles.

It's still not the same, even when you try to turn non-classical into
what we've been describing as true for classical. None of the same
qualifiers - non-translation as the norm, COD, artist-specified
titles, etc - holds true for the non-classical. The difference here
is, the "songs on tracks on releases" on a pop or jazz or rock CD each
have a *singular clear and official* title. The "classical works on
tracks on releases" do not have that type of title, it is most often a
title descriptive of the contents; where they do, we don't apply CSG -
hence Reich, Cage, etc are unaffected by CSG.

Brian
Lukáš Lalinský
2008-02-29 16:32:10 UTC
Permalink
On Pi, 2008-02-29 at 11:16 -0500, Brian Schweitzer wrote:
> > Somebody in this thread mentioned that classical music has no tracks,
> > which I guess is the main point of confusion here. Classical music
> > really has no tracks, but classical releases do have tracks and do have
>
> I was with you all the way up to here Luks. Classical release do
> indeed have tracks. Classical releases, however, as Frederik, myself,
> and Aaron have been pointing out, do not have track titles that are no
> different from non-classical.

What is "Concerto in E-flat major for two pianos, KV365: I. Allegro",
then, if not a track title? To me it looks like a title that represents
track #1 on release "Concertos for Two and Three
Pianos" (BIS-SACD-1618).

Lukas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Toto je =?ISO-8859-1?Q?digit=E1lne?=
=?ISO-8859-1?Q?_podp=EDsan=E1?= =?UTF-8?Q?_=C4=8Das=C5=A5?=
=?ISO-8859-1?Q?_spr=E1vy?=
Url : http://lists.musicbrainz.org/pipermail/musicbrainz-style/attachments/20080229/959d12bc/attachment.pgp
Mike Morrison
2008-02-29 16:37:19 UTC
Permalink
> I have to ask, what is this official classical track title that we'd be
> preserving until and under NGS?

One possible choice: Exactly what is printed on the cover; typos,
inconsistencies, incomplete information and all. We could do this for
non-classical music too if we want. Then those of us (including me) who
want consistent titles for different recordings of the same (classical or
non-classical) composition can tag our files from the work title. Those
who want discographic adherence to the exact text printed on the cover can
tag their files from the "track titles" (perhaps better called "track
cover text" since it is not necessarily a reflection of the official
"title" of the music, as you point out.)

Mike
Leiv Hellebo
2008-03-01 17:57:47 UTC
Permalink
Mike Morrison wrote:
>> I have to ask, what is this official classical track title that we'd be
>> preserving until and under NGS?
>
> One possible choice: Exactly what is printed on the cover; typos,
> inconsistencies, incomplete information and all.

I haven't seen anyone arguing for this position.

We could do this for
> non-classical music too if we want. Then those of us (including me) who
> want consistent titles for different recordings of the same (classical or
> non-classical) composition can tag our files from the work title.

If we go for as-close-to-ArtistIntent-as-possible - which spontaneously
sounds worth having - then I doubt people will want WorkNames in the
general case. 17. century English, German and French?

(A problem here turns up, as Mozart has more than one "Konzert in Es"
etc., so at least some cataloguing info is probably needed.)

As for consistency in titles: You cannot have it all over, because
1) different recordings split tracks differently
See first mvt. of Symphony No. 9 here:
http://musicbrainz.org/release/20b937ef-ea28-45c2-b9d1-754c2673c13f.html
http://musicbrainz.org/release/57318b49-090c-4c17-9144-6c5f384aa0ed.html

(And IMO you'd be almost nuts to want all that detail from the second
into the track title of the first, but again, YMMV.)

2) A rare case: Most recordings of Mahler's 6. symphony has
II. Scherzo, but most done the last years have the Andante as movement
number two.

We might standardise in other cases, but what is so important about
consistency that MB should impose this even where the recording industry
and concert halls - which have a lot more domain knowledge than we
collectively do - have not done it?

And why do you want to remove the optional stuff from the (unofficial)
OperaTrackStyle?



Leiv
Leiv Hellebo
2008-03-01 11:22:27 UTC
Permalink
Mike Morrison wrote:
> On Thu, 28 Feb 2008, Aaron Cooper wrote:
>> On 27-Feb-08, at 8:10 PM, Mike Morrison wrote:
>>
>>>
>>> OK, so once we have NGS everyone can have what they want, right?
>>> We'll have work titles and track titles. The work title can be full
>>> CSG(S), while the track title can be what's on the cover. So each
>>> track will have these two titles associated with it.
>>>
>>> For now, how about if we use the track title field for one of the two
>>> titles, and annotations for the other? We need somewhere to store the
>>> "other" title for now anyway, right? I don't care which title goes in
>>> which spot. If the one I like better ends up in the annotations, I'll
>>> copy and paste it into my local files if need be.
>>>
>>> Then when NGS is implemented, we can migrate the information from the
>>> annotations into the appropriate field.
>>
>> I don't understand what we're discussing because classical works don't
>> have "tracks" or "track titles"-they have "work titles.
>
> I agree.
>
>> A classical recording has tracks, but what do you use as the track
>> titles?
>
> Personally, I like to use full-length CSGS-style work titles on the
> tracks. However, it appears that some editors want track titles which are
> shorter, or which more closely match the physical release cover.

Hi Mike, I think this might be a good place for me to explain my
position a little better:

The last month my focus has not been on fixing the CSG, but rather to
say that I do not want us to standardise on one way of formatting one
piece of classical (movement, lied etc.) in the CSGS pages and make this
mandatory for how we should deal with that piece.

I don't think anyone here actually disagree much on how this or that
symphony from the core classical period should be formatted. It is well
entrenched already, and it works fine:

Symphony No. 39 in E-flat major, KV 543: II. Andante con moto

(OK: Brian has standardised on "K.", where we used "KV" throughout
earlier at MB, and he also includes that it is a symphony for orchestra,
thereby getting "Symphony No. 39 for Orchestra in E-flat major, K. 543:
II. Andante con moto", but these are details so insignificant that it
feels almost pointless to discuss them.)

Further, the vaast majority of classical CDs I've encountered do include
all these details. So since I dislike the idea that we should keep our
own standards here at MB, I've been pushing the idea that the track
listing from the liners is a better common ground for solving edit wars
than the CSGS pages. (And it nicely fits in with MB practices from

(My reasons for not wanting the CSGS pages I first tried to lay out in
http://www.nabble.com/Re%3A--Clean-up-CSG--Capitalization-%28and-placement%29-of-types-and-tempos-p15259763s2885.html

I am sorry for the length of it, it's a byproduct of how my brain works.
But there are points in there which still are unanswered: How do we
resolve disagreements on what to put in the CSGS pages? A
ClassicalTrackTitleStyle is not enough, because you probably will need
to answer "how different does works have to be in order to be regarded
as separate works?" (there might be small changes in the scoring), and
you will maybe need a notion on utterly boring questions such as "How
common does a common name have to be to be included", "when do we
translate them?")

>
>> As I gather from your email (and those of some other similar-minded
>> editors) we want to put the "track title" in the "track title" field...
>> so we look to the track listing on the CD... and we find "work titles"
>> don't we? (serious question)
>
> On most of the releases I own, yes. But maybe not on some releases with
> less-complete cover information ("Mozart: Allegro")?

There's been some claims that quite a few CDs are lacking details.
Further, some say labels produce "wacky" listings, others that
rereleases very often have differing track lists. None of these claims
have been substantiated AFAICS, nor has anyone tried to fill in the
details on the significance of these differences.

Now for all I know, you may on a "Classical Chillout" release find
"Bach: Sarabande", "Bach: Sarabande from Partita", "Bach: Sarabande from
Partita No. 1", "Bach: Sarabande from Partita, BWV 1002" or something else.

The three first does lack information necessary to determine which piece
of music is included. You and I might prefer to have this information
included, thereby finding the BWV 1002 quite important, but this does
not mean that the person buying this release finds it at all helpful.
MusicBrainz is not a pedagogical site, and the track listings are not
places where MB should educate the masses.

What should we standardise on then? "Partita for Solo Violin, BWV 1002:
Sarabande", perhaps.

No movement numbers? Bach didn't number them, and because different
recordings often include the "Double" following the "Sarabande", so you
also get

"...BWV 1002: Sarabande - Double"

Further, some of Bach's music seem nearly infinitely malleable, and has
been transcribed for many different instruments (the Goldberg variations
have been recorded for the accordion, and this was a good recording of
it AFAIK).

I best shut up before people stop reading, so let me sum up by saying:
If I buy "Classical Chillout", I don't want one track title to read

"Partita for Solo Violin in B minor, BWV 1002, Transposed to A minor for
Lute: Sarabande"

(But of course, YMMV, and that's why I think the liner notes should be
the ground for settling disputes on this.)

Regards,

Leiv
Mike Morrison
2008-03-01 18:47:42 UTC
Permalink
On Sat, 1 Mar 2008, Leiv Hellebo wrote:
> The last month my focus has not been on fixing the CSG, but rather to
> say that I do not want us to standardise on one way of formatting one
> piece of classical (movement, lied etc.) in the CSGS pages and make this
> mandatory for how we should deal with that piece.

I think each user can get exactly what he or she wants with NGS. Here's
how:

The list of work titles currently known as CSGS, rather than being a
prescriptive list of the "one true way" to format each work's title, could
be structured as a database of all known classical works, with each work
title broken up into many subfields, like all the boxes and sub-boxes on

http://wiki.musicbrainz.org/BrianFreud/sandbox#CSGworkstructure

or

http://wiki.musicbrainz.org/BrianFreud/ClassicalOntology

Rather than "CSGS", I will call it the WorksDatabase.

So a given composition would have a "work type" field, a "key" field, a
"catalog number" field, etc. We could have multiple "common name" fields
for works which have more than one common name. Some or all of the fields
would have pointers to alternate translations into many languages, for
example "E minor" vs. "mi mineur".

> I've been pushing the idea that the track listing from the liners is a
> better common ground for solving edit wars than the CSGS pages.

That's great! Every track on every release can have its own track title or
"TrackCoverText", which can be as exact a copy of the text on the liner
as desired, and does not need to be consistent among different recordings
of the same composition.

However, every track on every release would also have an AR to the
WorksDatabase: "This track is a recording of the work Concerto for Piano
No. 1 in F major, K. 37: I. Allegro". This AR would be the same for every
recording of the work, although each recording's TrackCoverText can be
formatted differently.

Then, with the right software, individual users could tell their taggers
to concatenate only the fields of their choice, in the language of their
choice, in the order of their choice, and get their tracks tagged in their
preferred title style.

What if users just want their tracks to look like the cover, and not
necessarily be consistent among different recordings of the same
composition?

Then they tell their tagger to tag from the track title (TrackCoverText),
rather than the WorksDatabase.

What if they want their tracks to look generally like the liner notes, but
when there is important information missing, to add that information,
while keeping the general form of the liner notes? (Note: what is
considered "important information" can be different for each user)

Then they tell their tagger to use the TrackCoverText, but if certain
information (such as a catalog number) is missing on a given track, to go
fetch that information from the WorksDatabase and insert it as part of the
tag string.

This might require that we have semantically marked up the TrackCoverText
so it can be parsed by the tagger application in the same way as the
WorksDatabase. We can do this with hidden markup tags, without changing
the appearance of the track cover text. So if the cover says (actual
example):

"Chaconne from Partita BWV 1004
D minor/d-moll/re mineur"

(there should be an accent over "re" but my email client has encoding
problems)

this could be marked up as (example only, details could differ):

<dancetype lang="fr">Chaconne</dancetype>
<fromword lang="en">from</fromword>
<worktype lang="it">Partita</worktype>
<catalogidentifier lang="de">BWV</catalogidentifier>
<catalognumber lang="">1004</catalognumber>
<br />
<key lang="en">D</key>
<scale lang="en">minor</scale>/
<key lang="de">d</key>
<scale lang="de">-moll</scale>/
<key lang="fr">re</key>
<scale lang="fr">mineur</scale>

This semantic markup does not have to be done by newbie editors submitting
releases. It can be done by more experienced editors after the release is
submitted, or maybe by a semi-automated script.

Leiv, I think you've raised good questions. Here are my more specific
responses to some of those questions:

> How do we resolve disagreements on what to put in the CSGS pages?

We can put all the information we know about a composition into the
structured WorksDatabase. Users can set their taggers to pick and choose
which of that information goes into their local track titles.

> you probably will need to answer "how different does works have to be in
> order to be regarded as separate works?" (there might be small changes
> in the scoring)

If a consensus can't be reached on whether Op. 1a and Op. 1b are the same
or different works, let's enter them as separate works in the
WorksDatabase, and within the WorksDatabase let's link each of them to a
"parent" work Op. 1. The editors who say they are the same work can set a
user profile preference more or less specific to that work where their
tagger will tag recordings of Op. 1a and Op. 1b as if they were all Op. 1.
The editors who say they are different will set their profile preference
to tag Op. 1a and Op. 1b differently.

> you will maybe need a notion on utterly boring questions such as "How
> common does a common name have to be to be included"

Let's put every known common name in the WorksDatabase, with a "frequency
score" for each name. This score could be calculated, for example, by a
script which looks for the common name in the TrackCoverText for all
instances of the work in the MusicBrainz database. Then users can set
their taggers to require a minimum score for inclusion of a common name in
their track titles.

> "when do we translate them?"

Let's put every known translation of every work type, common name,
key/scale, etc. in the WorksDatabase, with a language code for each. Users
can set their tagger preferences to use their own language, the composer's
native language, the language of the ReleaseCountry, or whatever they
want.

> There's been some claims that quite a few CDs are lacking details.
> Further, some say labels produce "wacky" listings, others that
> rereleases very often have differing track lists. None of these claims
> have been substantiated AFAICS, nor has anyone tried to fill in the
> details on the significance of these differences.

I agree that we could benefit from some cover scans of wacky releases.
Next person who finds a "Classical Chillout" release with ambiguous track
titles, please scan it for us :)

> Now for all I know, you may on a "Classical Chillout" release find
> "Bach: Sarabande", "Bach: Sarabande from Partita", "Bach: Sarabande from
> Partita No. 1", "Bach: Sarabande from Partita, BWV 1002" or something else.
>
> The three first does lack information necessary to determine which piece
> of music is included. You and I might prefer to have this information
> included, thereby finding the BWV 1002 quite important, but this does
> not mean that the person buying this release finds it at all helpful.

I agree. You and I can set our taggers to get "BWV 1002" from the
WorksDatabase. The person buying the release can set their tagger to read
straight from the TrackCoverText if they want.

> MusicBrainz is not a pedagogical site, and the track listings are not
> places where MB should educate the masses.

While I do use MB to learn about music and I hope it can become ever more
useful for that purpose, I agree with your sentiment here. If the masses
want to use MB to learn about classical compositions, they should browse
the WorksDatabase, not the TrackCoverText.

> What should we standardise on then? "Partita for Solo Violin, BWV 1002:
> Sarabande", perhaps. No movement numbers? Bach didn't number them

When it comes to users' tags, all of this could be determined by each
user's tagger preferences. Maybe the Bach movement numbers would have a
low "authenticity score" in the WorksDatabase, indicating that they are
not the composer's own work.

When it comes to the TrackCoverText, let's go with more or less what's on
the cover.

> and because different recordings often include the "Double" following
> the "Sarabande", so you also get
>
> "...BWV 1002: Sarabande - Double"

Each track can be related to multiple movements in the WorksDatabase. The
WorksDatabase should allow subdivision of movements into submovements as
required by the releases we encounter.

> Further, some of Bach's music seem nearly infinitely malleable, and has
> been transcribed for many different instruments

Indeed. We will probably need ways to handle this, both in the
WorksDatabase and in the semantic markup of the TrackCoverText, such as
<originalinstrument> and <transcribedinstrument> markup tags.

> I best shut up before people stop reading

I better do the same :)

> so let me sum up by saying:
> If I buy "Classical Chillout", I don't want one track title to read
>
> "Partita for Solo Violin in B minor, BWV 1002, Transposed to A minor for
> Lute: Sarabande"

And I really do want my track title to say all of that. No kidding! But I
really think we can all get what we want with a
TrackCoverText/WorksDatabase/TaggerPreferences system like what I'm
describing.

Cheers,

Mike
Brian Schweitzer
2008-03-01 19:16:38 UTC
Permalink
On Sat, Mar 1, 2008 at 1:47 PM, Mike Morrison <mikemorr at umich.edu> wrote:
>
> On Sat, 1 Mar 2008, Leiv Hellebo wrote:
> > The last month my focus has not been on fixing the CSG, but rather to
> > say that I do not want us to standardise on one way of formatting one
> > piece of classical (movement, lied etc.) in the CSGS pages and make this
> > mandatory for how we should deal with that piece.
>
> I think each user can get exactly what he or she wants with NGS. Here's
> how:
>
> The list of work titles currently known as CSGS, rather than being a
> prescriptive list of the "one true way" to format each work's title, could
> be structured as a database of all known classical works, with each work
> title broken up into many subfields, like all the boxes and sub-boxes on
>
> http://wiki.musicbrainz.org/BrianFreud/sandbox#CSGworkstructure
>
> or
>
> http://wiki.musicbrainz.org/BrianFreud/ClassicalOntology
>
> Rather than "CSGS", I will call it the WorksDatabase.
<big snip>

Mike, on this concept, I wholeheartedly agree. This is exactly the
thinking I had, re: NGS, when putting the second page together. My
hope is that indeed we eventually get to a point where we can each
take all the parts and built as little or as much from them as we each
individually want. Really, when that stage of NGS comes, I think a
lot of guidelines perhaps become unneeded - OperaStyle, CSG,
PartNumberStyle, VolumeStyle, DiscNumberStyle, etc - anything that
revolves around taking all the various possibilities that exist and
putting them into a consistant structure.

The problem really is, all of these guidelines accept that NGS at that
level is still a long way off. All of CSG really is, I think, us
debating just which of the fields we're going to use/not use, in which
order, with which separators, etc. Hence some of the debates, like
the whole en-dash/em-dash/dash/hyphen thing, where at least some of us
were talking about the utility of each being used for a specific
purpose, in that it would allow the track title to then be
deconstructed; in the most basic sense, allowing the track title to be
turned into semi-separated fields that a user could use to somewhat
build up what he or she wants.

And while I do see this eventual day where we can do all this, and
under such an NGS system, I look forward to the day I can support the
RFV to eliminate CGS and the others, the question is, what are we
going to do until then? Whether we're shaping a track title under
CSG, or changing "Vol." to ", Volume", we're modifying things. We
could agree to simply leave it unchanged, to add multiple listings for
the same release with multiple languages on the liner, etc. But that
creates two problems: essentially duplicate releases, when they're
really just a single release crying out for the "one release, multiple
possible track titles" solution; and the appearance of chaos in the
data, especially classical, for all the users who like well-ordered
information within the titles.

And I think that's really what we keep coming back to with these
debates. I really don't think it's at all possible that we can come
to all agree here - some will always want "exactly as on the liner",
some will always want "as complete work identification as possible",
and some will always want something in between. One other issue,
which I don't think we've quite mentioned, is that, as more and more
music moves to online-sales, in some, and progressively many, cases,
there ceases to even be the liner to depend upon - I can easily
imagine the day where Naxos or DG is releasing direct to online, where
titles are simply user-translated-on-the-fly using their own
NGS-equivalent mappings of works.

So until that happy day of NGS support, how do we compromise? How can
we ensure that the data allows the BBC to identify the work from the
track, allows Aaron and me to tag and not find the data "quite messy",
allows Leivhe and David to tag and have complete but not "overly"
complete data, and still allows Lauri and her mother-in-law to tag and
have what she wants? (Just using us as examples of general user-base
opinions here.) If we're aiming for "as on the liner", which liner,
which translation, and what still gets fixed - caps, typos, mislisted
works, etc? If we're aiming for CSG, how complete, which languages,
and are we essentially admitting that classical track titles per
liners are descriptions and not "titles" per say? Where can we all
compromise such that the (I think majority) who wants at least some
structure in the titles isn't left waiting 1-2 years for NGS to
replace CSG, plus all the quite likely years of editing work to
actually implement it across our classical listings?

Brian
Mike Morrison
2008-03-01 22:10:09 UTC
Permalink
On Sat, 1 Mar 2008, Brian Schweitzer wrote:
> the question is, what are we going to do until then?

For now, I think each track essentially needs two title fields: one for
the TrackCoverText, and one for the CSG title. So I'm basically splitting
the userbase into two groups and proposing a way to let each group use the
title it prefers, until NGS allows for more personalized customization. If
we can't agree on two titles, we could go for three (a liner title, a CSGS
title, and a middle-ground title), but I'm hoping it won't come to that.

Here's why I think each track needs two titles for now: If anyone is going
to want to use the TrackCoverText in the future, I think we have to
preserve it somewhere now. Same thing with CSG titles as work identifiers:
if anyone is going to want to link a track to a WorksDatabase entry in the
future, I think we should leave something attached to the track now to
facilitate that.

If we decide to give each track two titles, I see two options: we could
change the database structure to allow tracks to have two TrackTitle
fields, or we could use our existing database structure.

Here's one way I can think of to use the existing structure temporarily
until we have NGS. It's not ideal, because it misuses one of our existing
fields, but here goes. Please, anyone, suggest better ways of implementing
double track titles if you can think of them:

Very few of the releases I've come across make any use of the
TrackAnnotation field. Would it be feasible to appropriate this field for
the "second title field" and write a tagger plugin to use TrackAnnotations
as track titles? Then if someone wants to add a real track annotation,
they could use ReleaseAnnotations for now, with a note saying which track
they apply to.

Alternatively, we could put all of the secondary titles in the
ReleaseAnnotation field, and put in some standardized formatting
characters to allow a tagger to parse them into track titles.

> If we're aiming for "as on the liner", which liner, which translation,
> and what still gets fixed - caps, typos, mislisted works, etc?

These are not necessarily easy questions. I think they should be decided
by the folks who want their track titles "as on the liner". I think
whatever they come up with should go in one of the two title fields for
now, and eventually in the TrackCoverText field.

> If we're aiming for CSG, how complete, which languages

Again, not necessarily easy questions, but I hope the folks who do prefer
standardization can reach some agreement. Otherwise we will need three
titles instead of two! The standardized work title would go in one of the
two title fields for now, and eventually in the WorksDatabase.

> and are we essentially admitting that classical track titles per liners
> are descriptions and not "titles" per say?

To me, yes.
For the TrackCoverText, no.
For the interim CSG titles, yes, I think.
For the eventual WorksDatabase, yes.

> Where can we all compromise such that the (I think majority) who wants
> at least some structure in the titles isn't left waiting 1-2 years for
> NGS to replace CSG, plus all the quite likely years of editing work to
> actually implement it across our classical listings?

My hope is that a choice of two titles for each track will be enough to
satisfy everyone in the interim.

Cheers,

Mike
Brian Schweitzer
2008-03-01 22:39:35 UTC
Permalink
On Sat, Mar 1, 2008 at 5:10 PM, Mike Morrison <mikemorr at umich.edu> wrote:
>
> On Sat, 1 Mar 2008, Brian Schweitzer wrote:
> > the question is, what are we going to do until then?
>
> For now, I think each track essentially needs two title fields: one for
> the TrackCoverText, and one for the CSG title. So I'm basically splitting
> the userbase into two groups and proposing a way to let each group use the
> title it prefers, until NGS allows for more personalized customization. If
> we can't agree on two titles, we could go for three (a liner title, a CSGS
> title, and a middle-ground title), but I'm hoping it won't come to that.
>
> Here's why I think each track needs two titles for now: If anyone is going
> to want to use the TrackCoverText in the future, I think we have to
> preserve it somewhere now. Same thing with CSG titles as work identifiers:
> if anyone is going to want to link a track to a WorksDatabase entry in the
> future, I think we should leave something attached to the track now to
> facilitate that.
>
> If we decide to give each track two titles, I see two options: we could
> change the database structure to allow tracks to have two TrackTitle
> fields, or we could use our existing database structure.
>
> Here's one way I can think of to use the existing structure temporarily
> until we have NGS. It's not ideal, because it misuses one of our existing
> fields, but here goes. Please, anyone, suggest better ways of implementing
> double track titles if you can think of them:
>
> Very few of the releases I've come across make any use of the
> TrackAnnotation field. Would it be feasible to appropriate this field for
> the "second title field" and write a tagger plugin to use TrackAnnotations
> as track titles? Then if someone wants to add a real track annotation,
> they could use ReleaseAnnotations for now, with a note saying which track
> they apply to.
>
> Alternatively, we could put all of the secondary titles in the
> ReleaseAnnotation field, and put in some standardized formatting
> characters to allow a tagger to parse them into track titles.
>
>
> > If we're aiming for "as on the liner", which liner, which translation,
> > and what still gets fixed - caps, typos, mislisted works, etc?
>
> These are not necessarily easy questions. I think they should be decided
> by the folks who want their track titles "as on the liner". I think
> whatever they come up with should go in one of the two title fields for
> now, and eventually in the TrackCoverText field.
>
>
> > If we're aiming for CSG, how complete, which languages
>
> Again, not necessarily easy questions, but I hope the folks who do prefer
> standardization can reach some agreement. Otherwise we will need three
> titles instead of two! The standardized work title would go in one of the
> two title fields for now, and eventually in the WorksDatabase.
>
>
> > and are we essentially admitting that classical track titles per liners
> > are descriptions and not "titles" per say?
>
> To me, yes.
> For the TrackCoverText, no.
> For the interim CSG titles, yes, I think.
> For the eventual WorksDatabase, yes.
>
>
> > Where can we all compromise such that the (I think majority) who wants
> > at least some structure in the titles isn't left waiting 1-2 years for
> > NGS to replace CSG, plus all the quite likely years of editing work to
> > actually implement it across our classical listings?
>
> My hope is that a choice of two titles for each track will be enough to
> satisfy everyone in the interim.

While I agree that it does seem two track titles are needed, I think
annotations are perhaps not the best way to go. I've worked on a few
releases where I was leaving annotation notes in each track, and to be
quite honest, if we decided to put CSG-style track titles in
annotations, I can't see even myself bothering to normally do it, let
alone your average editor who happens to be adding a classical release
every so often. It's also, as you note and as I mentioned in IRC,
essentially blocking one or the other annotation fields from being
used for the purpose those fields really are intended for.

But another possibility occurs to me, an option that actually would be
closer to NGS, would avoid the need for mega-lists in the wiki, and
would allow for annotations to not only not be blocked on the
releases/tracks, but actually, would allow for notes on a work-level,
like some of the notes I've attached around listings in the Mozart
list, to help ID exactly which one is desired. It would also map
quite well, I think, to an eventual NGS implementation.

While there's perhaps some few 20th century classical composers
someone might be able to point to, one thing classical composer
generally have in common is that they didn't actually release LPs or
CDs - or NATs. Perhaps it'd be simple to create a NAT-type of list
for use for works lists, I don't really know. That would seem most
optimal. But lacking that, could we not just use the NAT entry for
each classical composer to hold the works lists? Create a new AR,
something like "is an instance of" to link release tracks to the NAT
tracks, store the CSG-style names in NATs and whatever the
liner-liking people like in the releases? I'd think it'd be pretty
easy then to add an option to Picard/datafeed users/etc to allow them
to travel up to that NAT to get the CSG title. Then we also can more
easily use the normal editing system, as well, to vet
corrections/changes within the NAT-work lists, with the goal of those
work lists being to make them the "complete" tiles. When NGS comes
around, all the links and such already will be in place, we just
migrate them from the NAT listed track to a NGS entry for that work,
and (perhaps in some automated fashion which says "this NGS entry is
specifically the NAT entry we had over here") migrate those
work-instance links over to NGS?

It would allow the dual track titles, it would satisfy both types of
data users, it would allow us now to start really working on
correcting noted typos and errors in work lists, and it would allow
us, likely 1-2 years ahead of time, to already start working on
linking instances back to work-masters.

Brian
Mike Morrison
2008-03-01 22:56:32 UTC
Permalink
On Sat, 1 Mar 2008, Brian Schweitzer wrote:
<snip>
> While there's perhaps some few 20th century classical composers
> someone might be able to point to, one thing classical composer
> generally have in common is that they didn't actually release LPs or
> CDs - or NATs. Perhaps it'd be simple to create a NAT-type of list
> for use for works lists, I don't really know. That would seem most
> optimal. But lacking that, could we not just use the NAT entry for
> each classical composer to hold the works lists? Create a new AR,
> something like "is an instance of" to link release tracks to the NAT
> tracks, store the CSG-style names in NATs and whatever the
> liner-liking people like in the releases? I'd think it'd be pretty
> easy then to add an option to Picard/datafeed users/etc to allow them
> to travel up to that NAT to get the CSG title. Then we also can more
> easily use the normal editing system, as well, to vet
> corrections/changes within the NAT-work lists, with the goal of those
> work lists being to make them the "complete" tiles. When NGS comes
> around, all the links and such already will be in place, we just
> migrate them from the NAT listed track to a NGS entry for that work,
> and (perhaps in some automated fashion which says "this NGS entry is
> specifically the NAT entry we had over here") migrate those
> work-instance links over to NGS?
>
> It would allow the dual track titles, it would satisfy both types of
> data users, it would allow us now to start really working on
> correcting noted typos and errors in work lists, and it would allow
> us, likely 1-2 years ahead of time, to already start working on
> linking instances back to work-masters.
>
> Brian

I like this!

Mike
Aaron Cooper
2008-03-01 23:13:32 UTC
Permalink
On 1-Mar-08, at 5:56 PM, Mike Morrison wrote:

>
> On Sat, 1 Mar 2008, Brian Schweitzer wrote:
> <snip>
>> While there's perhaps some few 20th century classical composers
>> someone might be able to point to, one thing classical composer
>> generally have in common is that they didn't actually release LPs or
>> CDs - or NATs. Perhaps it'd be simple to create a NAT-type of list
>> for use for works lists, I don't really know. That would seem most
>> optimal. But lacking that, could we not just use the NAT entry for
>> each classical composer to hold the works lists? Create a new AR,
>> something like "is an instance of" to link release tracks to the NAT
>> tracks, store the CSG-style names in NATs and whatever the
>> liner-liking people like in the releases? I'd think it'd be pretty
>> easy then to add an option to Picard/datafeed users/etc to allow them
>> to travel up to that NAT to get the CSG title. Then we also can more
>> easily use the normal editing system, as well, to vet
>> corrections/changes within the NAT-work lists, with the goal of those
>> work lists being to make them the "complete" tiles. When NGS comes
>> around, all the links and such already will be in place, we just
>> migrate them from the NAT listed track to a NGS entry for that work,
>> and (perhaps in some automated fashion which says "this NGS entry is
>> specifically the NAT entry we had over here") migrate those
>> work-instance links over to NGS?
>>
>> It would allow the dual track titles, it would satisfy both types of
>> data users, it would allow us now to start really working on
>> correcting noted typos and errors in work lists, and it would allow
>> us, likely 1-2 years ahead of time, to already start working on
>> linking instances back to work-masters.
>>
>> Brian
>
> I like this!

I don't think it's a bad idea either, but I'm generally not a fan of
NATs. Just throwing the idea out there... what about creating an
album for each work? Example:

Release Title: Trio for Piano, Violin, and Cello No. 1 in E-flat
major, Op. 1 No. 1
#1 Track Title: I. Allegro
#2 Track Title: II. Adagio cantabile
#3 Track Title: III. Scherzo
#4 Track Title: IV. Finale. Presto

If we wanted ordered lists based on catalog number we could enter the
release title as something like "Op. 1 No. 1: Trio for Piano, Violin,
and Cello No. 1 in E-flat major".

Thoughts?

-Aaron (cooperaa)
Brian Schweitzer
2008-03-01 23:31:05 UTC
Permalink
On Sat, Mar 1, 2008 at 6:13 PM, Aaron Cooper <cooperaa at gmail.com> wrote:
>
> On 1-Mar-08, at 5:56 PM, Mike Morrison wrote:
>
> >
> > On Sat, 1 Mar 2008, Brian Schweitzer wrote:
> > <snip>
> >> While there's perhaps some few 20th century classical composers
> >> someone might be able to point to, one thing classical composer
> >> generally have in common is that they didn't actually release LPs or
> >> CDs - or NATs. Perhaps it'd be simple to create a NAT-type of list
> >> for use for works lists, I don't really know. That would seem most
> >> optimal. But lacking that, could we not just use the NAT entry for
> >> each classical composer to hold the works lists? Create a new AR,
> >> something like "is an instance of" to link release tracks to the NAT
> >> tracks, store the CSG-style names in NATs and whatever the
> >> liner-liking people like in the releases? I'd think it'd be pretty
> >> easy then to add an option to Picard/datafeed users/etc to allow them
> >> to travel up to that NAT to get the CSG title. Then we also can more
> >> easily use the normal editing system, as well, to vet
> >> corrections/changes within the NAT-work lists, with the goal of those
> >> work lists being to make them the "complete" tiles. When NGS comes
> >> around, all the links and such already will be in place, we just
> >> migrate them from the NAT listed track to a NGS entry for that work,
> >> and (perhaps in some automated fashion which says "this NGS entry is
> >> specifically the NAT entry we had over here") migrate those
> >> work-instance links over to NGS?
> >>
> >> It would allow the dual track titles, it would satisfy both types of
> >> data users, it would allow us now to start really working on
> >> correcting noted typos and errors in work lists, and it would allow
> >> us, likely 1-2 years ahead of time, to already start working on
> >> linking instances back to work-masters.
> >>
> >> Brian
> >
> > I like this!
>
> I don't think it's a bad idea either, but I'm generally not a fan of
> NATs. Just throwing the idea out there... what about creating an
> album for each work? Example:
>
> Release Title: Trio for Piano, Violin, and Cello No. 1 in E-flat
> major, Op. 1 No. 1
> #1 Track Title: I. Allegro
> #2 Track Title: II. Adagio cantabile
> #3 Track Title: III. Scherzo
> #4 Track Title: IV. Finale. Presto
>
> If we wanted ordered lists based on catalog number we could enter the
> release title as something like "Op. 1 No. 1: Trio for Piano, Violin,
> and Cello No. 1 in E-flat major".
>
> Thoughts?

I think the dangers of creating a separate album listing for each work would be:

* People actually tagging to those "releases" / submitting TRMs/PUIDs for them
* Massive swelling of the apparent discography listings for the composers
* You then have to actually load that entire composer's discography to
find the ones you want (already 1500+ listings for JS Bach and WA
Mozart), rather than just the NAT listing for the artist (which, iirc,
is already linked from within the artist title bar on each release)
* lots of single-track "releases" for one-movement works

Perhaps such subdivision might be best left to the real NGS, rather
than further trying to stretch it to fit a non-NGS situation?

There's one other problem, and I'm not sure either suggestion really
solves it - what to do then when you have two or more works on the
same track? You could link them each as instances, but how does
something trying to interpret that - the datafeed user or the tagger -
make sense of it? Not insurmountable, but definitely a question that
would have to be addressed.

Brian
Mike Morrison
2008-03-01 23:50:12 UTC
Permalink
On Sat, 1 Mar 2008, Brian Schweitzer wrote:
> There's one other problem, and I'm not sure either suggestion really
> solves it - what to do then when you have two or more works on the
> same track? You could link them each as instances, but how does
> something trying to interpret that - the datafeed user or the tagger -
> make sense of it? Not insurmountable, but definitely a question that
> would have to be addressed.
>
> Brian

I don't know about the datafeed, but it seems like the tagger could just
concatenate the two work titles and put a slash between them, and perhaps
eliminate any information which is doubled. So (perhaps not the most
likely example) if the first two movements of K. 37 were on the same
track, we would have

Concerto for Piano No. 1 in F major, K. 37: I. Allegro /
Concerto for Piano No. 1 in F major, K. 37: II. Andante

which would be shortened to:

Concerto for Piano No. 1 in F major, K. 37: I. Allegro / II. Andante
Brian Schweitzer
2008-03-01 23:58:36 UTC
Permalink
On Sat, Mar 1, 2008 at 6:50 PM, Mike Morrison <mikemorr at umich.edu> wrote:
>
> On Sat, 1 Mar 2008, Brian Schweitzer wrote:
>
> > There's one other problem, and I'm not sure either suggestion really
> > solves it - what to do then when you have two or more works on the
> > same track? You could link them each as instances, but how does
> > something trying to interpret that - the datafeed user or the tagger -
> > make sense of it? Not insurmountable, but definitely a question that
> > would have to be addressed.
> >
> > Brian
>
> I don't know about the datafeed, but it seems like the tagger could just
> concatenate the two work titles and put a slash between them, and perhaps
> eliminate any information which is doubled. So (perhaps not the most
> likely example) if the first two movements of K. 37 were on the same
> track, we would have
>
> Concerto for Piano No. 1 in F major, K. 37: I. Allegro /
> Concerto for Piano No. 1 in F major, K. 37: II. Andante
>
> which would be shortened to:
>
> Concerto for Piano No. 1 in F major, K. 37: I. Allegro / II. Andante

I was thinking something similar. Though perhaps we'd want to "help"
the interpretation a bit, using something specific to identify that
"split point", as well as adding an attribute to the AR to indicate
which position the works ought to be ordered in?

Something like
Concerto for Piano No. 1 in F major, K. 37|| I. Allegro
Concerto for Piano No. 1 in F major, K. 37|| II. Andante

Then the interpreter needs only to know to replace the first || with a
comma, and on the second+ instances, if everything on the left of the
| matches in both/each, leave it out and split with the slash?
(Thinking here of the fact that we do have "super-works" and
"container sections (masses)" which also use the colon as the
container separator.

And using a positional attribute then allows the tagger to make sense
of which work is in which position - they're not always from the same
overall work, nor always in chronological order...

Brian
Brian Schweitzer
2008-03-02 00:43:27 UTC
Permalink
Just to check feasibility, I asked Robert in IRC about if and how
easily a second NAT-like entry could be added to each artist, so this
"until NGS work-list-like" thing could maybe happen:

I've snipped out all but the most absolutely relevant bits, but I
figured it was relevant enough to be worth passing along as part of
this discussion:

<snip>
[19:16] <BrianFreud> Question for you. How "special" is the NAT code?
If you wanted to suddenly add a second NAT listing to every artist,
how difficult would that be to do?
[19:17] <ruaok> its pretty much a hack, IIRC
<snip>
[19:19] <ruaok> it shouldn't be too bad, really.
[19:19] <ruaok> probably a bit ugly, but doable
<snip>

Brian
Aaron Cooper
2008-03-01 23:53:23 UTC
Permalink
On 1-Mar-08, at 2:16 PM, Brian Schweitzer wrote:

<big snip>

> So until that happy day of NGS support, how do we compromise? How can
> we ensure that the data allows the BBC to identify the work from the
> track, allows Aaron and me to tag and not find the data "quite messy",
> allows Leivhe and David to tag and have complete but not "overly"
> complete data, and still allows Lauri and her mother-in-law to tag and
> have what she wants? (Just using us as examples of general user-base
> opinions here.)

<br>

> If we're aiming for "as on the liner", which liner,
> which translation, and what still gets fixed - caps, typos, mislisted
> works, etc? If we're aiming for CSG, how complete, which languages,
> and are we essentially admitting that classical track titles per
> liners are descriptions and not "titles" per say? Where can we all
> compromise such that the (I think majority) who wants at least some
> structure in the titles isn't left waiting 1-2 years for NGS to
> replace CSG, plus all the quite likely years of editing work to
> actually implement it across our classical listings?

Proposition:

a) For "chillout classical" releases where tracks are titled "Andante"
or "Allegro from Sonata No. 14" etc, enter the track titles in MB as
they appear on the CD and follow regular MB guidelines (http://wiki.musicbrainz.org/PartNumberStyle
, http://wiki.musicbrainz.org/SubTitleStyle, etc)

b) For "real classical" releases, use the CSGS lists for ease of
entering the releases and consistency.

ProbIems with this? People don't want long titles:
In the large majority of cases, very little "extra" information is
added in the CSGStandard lists over and above of what is printed on
CDs (as I mentioned in a previous email). The rare and unusual works
may have unusual track names, but oh well?how often do we listen to
those rare and unusual works compared to the more popular works?
Anyone who cares enough to listen to the rare works (and owns a copy!)
probably wants the extra information in the titles anyways.

Thoughts?

-Aaron
Lauri Watts
2008-03-02 00:44:44 UTC
Permalink
On Sun, Mar 2, 2008 at 12:53 AM, Aaron Cooper <cooperaa at gmail.com> wrote:
> On 1-Mar-08, at 2:16 PM, Brian Schweitzer wrote:
>
> <big snip>
>
>
> > So until that happy day of NGS support, how do we compromise? How can
> > we ensure that the data allows the BBC to identify the work from the
> > track, allows Aaron and me to tag and not find the data "quite messy",
> > allows Leivhe and David to tag and have complete but not "overly"
> > complete data, and still allows Lauri and her mother-in-law to tag and
> > have what she wants? (Just using us as examples of general user-base
> > opinions here.)
>
> <br>
>
>
> > If we're aiming for "as on the liner", which liner,
> > which translation, and what still gets fixed - caps, typos, mislisted
> > works, etc? If we're aiming for CSG, how complete, which languages,
> > and are we essentially admitting that classical track titles per
> > liners are descriptions and not "titles" per say? Where can we all
> > compromise such that the (I think majority) who wants at least some
> > structure in the titles isn't left waiting 1-2 years for NGS to
> > replace CSG, plus all the quite likely years of editing work to
> > actually implement it across our classical listings?
>
> Proposition:
>
> a) For "chillout classical" releases where tracks are titled "Andante"
> or "Allegro from Sonata No. 14" etc, enter the track titles in MB as
> they appear on the CD and follow regular MB guidelines (http://wiki.musicbrainz.org/PartNumberStyle
> , http://wiki.musicbrainz.org/SubTitleStyle, etc)
>
> b) For "real classical" releases, use the CSGS lists for ease of
> entering the releases and consistency.
>

Works for me, for the meantime at least.

Perhaps with a rider to say:

If you can't tell which is which, ask in the edit note (because
honestly, at this point, we don't
need a big discussion on which is which, when it can be easily solved
by asking case by case,
if common sense alone doesn't work.)

Or err in the direction of 'copy the cover', because it's easier to
fix 'incomplete -> CSGS' if necessary
than deal with completely misidentified tracks from people being
stunned like deer in headlights by
CSGS list and blindly copying anything that looks like it might be
close (if you know what
I mean, kind of the way PUID's end up assigned all over the darn place.)


Oh and someone wanted some 'ridiculous covers' as examples. I present:

http://people.fruitsalad.org/lauri/stuff/the_best_classical_album_in_the_worldever_2004_retail_cd-back.jpg

http://people.fruitsalad.org/lauri/stuff/the_classical_album_2007_2006_retail_cd-back.jpg

http://people.fruitsalad.org/lauri/stuff/the_only_classical_album_youll_ever_need_2003_retail_cd-back.jpg

Of which my personal favourite for idiocy is the last. I bet you
didn't know Pachelbel's Canon is famous because
of "Wool advertising"

Now if I may, I suggest everyone head back over to Olivier's thread
and continue dissecting
the current CSG paragraph by paragraph, it really needs it.

So do the rest of our guidelines though, and if you don't know what I
mean, think about
"Some Famous DJ & DJ Someone Else Famous pres. DJ Nobody vs. Someone More
feat Someone Entirely Else - Some track name - Some Group Name mix (radio edit)"

... bearing in mind, Some Famous DJ and DJ Someone Else are both
members of the 'Some Group Name',
and 'Someone More' could well actually be a performance name for that
group (or a group with the
exact same members, if you will). This is an only slightly contrived
example though. And you don't
really need to tell me how you'd enter it, it's just to point out, you
_have_ to be familiar with the music and
the artist to even figure out how to split it into an artist name and
a track title, guess case will likely mangle
it beyond recogition, and even then, our guidelines on the whole deal
are eyebleedingly confusing.

So though some of us rail a little at the CSG, it's not 'the CSG' that
is the problem, really, it's that we actually
expect all our users to have some familiarity with the music they own,
when they probably bought the
classical chillout album on a whim at the gas station, and they
probably got that Ibiza club album
on the airport on the way home from two weeks on the Costa del Sol,
and they know nothing about either
and us being impatient with them getting the details wrong when they
enter them in MB is not
really helping that.

--
Lauri Watts
Brian Schweitzer
2008-03-02 01:33:48 UTC
Permalink
On Sat, Mar 1, 2008 at 7:44 PM, Lauri Watts <krazykiwi at gmail.com> wrote:
>
> On Sun, Mar 2, 2008 at 12:53 AM, Aaron Cooper <cooperaa at gmail.com> wrote:
> > On 1-Mar-08, at 2:16 PM, Brian Schweitzer wrote:
> >
> > <big snip>
> >
> >
> > > So until that happy day of NGS support, how do we compromise? How can
> > > we ensure that the data allows the BBC to identify the work from the
> > > track, allows Aaron and me to tag and not find the data "quite messy",
> > > allows Leivhe and David to tag and have complete but not "overly"
> > > complete data, and still allows Lauri and her mother-in-law to tag and
> > > have what she wants? (Just using us as examples of general user-base
> > > opinions here.)
> >
> > <br>
> >
> >
> > > If we're aiming for "as on the liner", which liner,
> > > which translation, and what still gets fixed - caps, typos, mislisted
> > > works, etc? If we're aiming for CSG, how complete, which languages,
> > > and are we essentially admitting that classical track titles per
> > > liners are descriptions and not "titles" per say? Where can we all
> > > compromise such that the (I think majority) who wants at least some
> > > structure in the titles isn't left waiting 1-2 years for NGS to
> > > replace CSG, plus all the quite likely years of editing work to
> > > actually implement it across our classical listings?
> >
> > Proposition:
> >
> > a) For "chillout classical" releases where tracks are titled "Andante"
> > or "Allegro from Sonata No. 14" etc, enter the track titles in MB as
> > they appear on the CD and follow regular MB guidelines (http://wiki.musicbrainz.org/PartNumberStyle
> > , http://wiki.musicbrainz.org/SubTitleStyle, etc)
> >
> > b) For "real classical" releases, use the CSGS lists for ease of
> > entering the releases and consistency.
> >
>
> Works for me, for the meantime at least.
>
> Perhaps with a rider to say:
>
> If you can't tell which is which, ask in the edit note (because
> honestly, at this point, we don't
> need a big discussion on which is which, when it can be easily solved
> by asking case by case,
> if common sense alone doesn't work.)
>
> Or err in the direction of 'copy the cover', because it's easier to
> fix 'incomplete -> CSGS' if necessary
> than deal with completely misidentified tracks from people being
> stunned like deer in headlights by
> CSGS list and blindly copying anything that looks like it might be
> close (if you know what
> I mean, kind of the way PUID's end up assigned all over the darn place.)
>
>
> Oh and someone wanted some 'ridiculous covers' as examples. I present:
>
> http://people.fruitsalad.org/lauri/stuff/the_best_classical_album_in_the_worldever_2004_retail_cd-back.jpg
>
> http://people.fruitsalad.org/lauri/stuff/the_classical_album_2007_2006_retail_cd-back.jpg
>
> http://people.fruitsalad.org/lauri/stuff/the_only_classical_album_youll_ever_need_2003_retail_cd-back.jpg
>
> Of which my personal favourite for idiocy is the last. I bet you
> didn't know Pachelbel's Canon is famous because
> of "Wool advertising"
>
> Now if I may, I suggest everyone head back over to Olivier's thread
> and continue dissecting
> the current CSG paragraph by paragraph, it really needs it.
>
> So do the rest of our guidelines though, and if you don't know what I
> mean, think about
> "Some Famous DJ & DJ Someone Else Famous pres. DJ Nobody vs. Someone More
> feat Someone Entirely Else - Some track name - Some Group Name mix (radio edit)"
>
> ... bearing in mind, Some Famous DJ and DJ Someone Else are both
> members of the 'Some Group Name',
> and 'Someone More' could well actually be a performance name for that
> group (or a group with the
> exact same members, if you will). This is an only slightly contrived
> example though. And you don't
> really need to tell me how you'd enter it, it's just to point out, you
> _have_ to be familiar with the music and
> the artist to even figure out how to split it into an artist name and
> a track title, guess case will likely mangle
> it beyond recogition, and even then, our guidelines on the whole deal
> are eyebleedingly confusing.
>
> So though some of us rail a little at the CSG, it's not 'the CSG' that
> is the problem, really, it's that we actually
> expect all our users to have some familiarity with the music they own,
> when they probably bought the
> classical chillout album on a whim at the gas station, and they
> probably got that Ibiza club album
> on the airport on the way home from two weeks on the Costa del Sol,
> and they know nothing about either
> and us being impatient with them getting the details wrong when they
> enter them in MB is not
> really helping that.

Well, not to throw a kink in the discussion, but if we're talking
about perhaps moving to pseudo master lists now, and the more I think
about that idea, the more attractive it seems to me, then why mess
with CSG or the tracktitles (such as they are) at all?

Yes, it means we get the messiness of some of the types of titles
Lauri provided as examples. Yes it means all that messiness of
multi-language titles, or releases re-released with different titles
on different liners. But we knew that - that's exactly what a large
part of this discussion has been about, that CSG avoids. But I'll be
honest - give me some way to identify / tag to a works list, and I
suddenly care much less about the track titles on the release; let
them be just as ugly as we want. So we get "Canon in D (made famous
by this and that)" or The Well-Tempered Clavier Book I / Das
Wohltemperierte Clavier < Teil I / Le Clavier bien temp?r? > Livre I /
Il clavicenbalo ben temperato Volume I" as a track titles. But that
is, after all, what is actually on the liner. If it's important
enough that we're willing to jump the gun on NGS, as it were, and go
straight to the best we can currently pull off in terms of work lists,
then let's stick to that principle, not adding, subtracting,
correcting, etc anything, except perhaps capitalization per the
language guidelines. Chaotic? Sure. Messy? Definately. But that's
exactly why CSG came into being in the first place, as an attempt to
clean it all up. Now we have ARs, and we can implement work lists
(though not quite as flexible of ones as we'll eventually have under
NGS). Right? :)

Now, I still care as far as not duplicating needlessly, so I still
think having 3, 4, 6, 10 listings for the same release, just in
different languages, is truly wasteful. And assuming we do agree to
do something like a real work list and real linking ARs, regarding
track titles, I'm happy. But I would hope, for what's left after we
then pull CSG out from releases, we can still find some way to avoid
this needless duplication, with all the additional maintenance and AR
work it implies.

As for going back to bit-by-bit rewriting the docs, I think it makes a
huge difference what we decide here. If we do really decide to put
CSG titles into a works list, separated from the releases, then that
doc should be much more written for those doing those lists, and
cat-corner-coverage is then very important, while any
emphasis/reasoning behind making it "casual classical editor friendly"
is essentially also completely removed. A separate doc, then, apart
from "work list CSG" would be needed to guide the person entering the
actual titles for a release, addressing the types of issues I
mentioned above.

Brian
Frederic Da Vitoria
2008-03-02 13:14:34 UTC
Permalink
On Sun, Mar 2, 2008 at 2:33 AM, Brian Schweitzer <
brian.brianschweitzer at gmail.com> wrote:

> Now we have ARs, and we can implement work lists
> (though not quite as flexible of ones as we'll eventually have under
> NGS). Right? :)


I must have missed an episode, here. Which ARs are you talking about? What
is the relation to work lists?


Now, I still care as far as not duplicating needlessly, so I still
> think having 3, 4, 6, 10 listings for the same release, just in
> different languages, is truly wasteful. And assuming we do agree to
> do something like a real work list and real linking ARs, regarding
> track titles, I'm happy. But I would hope, for what's left after we
> then pull CSG out from releases, we can still find some way to avoid
> this needless duplication, with all the additional maintenance and AR
> work it implies.


Maybe by expanding the pseudo-release concept... I know it was not meant for
this, but it would technically work.

--
Frederic Da Vitoria
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-style/attachments/20080302/9ff7e04a/attachment.htm
Frederic Da Vitoria
2008-03-02 13:17:02 UTC
Permalink
On Sun, Mar 2, 2008 at 2:14 PM, Frederic Da Vitoria <davitofrg at gmail.com>
wrote:

> On Sun, Mar 2, 2008 at 2:33 AM, Brian Schweitzer <
> brian.brianschweitzer at gmail.com> wrote:
>
> > Now we have ARs, and we can implement work lists
> > (though not quite as flexible of ones as we'll eventually have under
> > NGS). Right? :)
>
>
> I must have missed an episode, here. Which ARs are you talking about? What
> is the relation to work lists?
>

Ok, I found the answer in another thread :-)


--
Frederic Da Vitoria
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-style/attachments/20080302/8240b400/attachment.htm
David K. Gasaway
2008-03-03 06:23:07 UTC
Permalink
On 1 Mar 2008 at 14:16, Brian Schweitzer wrote:

> So until that happy day of NGS support, how do we compromise? How can
> we ensure that the data allows the BBC to identify the work from the
> track, allows Aaron and me to tag and not find the data "quite messy",
> allows Leivhe and David to tag and have complete but not "overly"
> complete data, and still allows Lauri and her mother-in-law to tag and
> have what she wants?

Hey, nice to see I haven't been completely forgotten in the week I've
been away! :) You folks have covered a lot of ground in the past
week, so I won't even try to repaint it all in my own perspective.
I'll just make some general comments and move on.

I agree with the great majority of what Lauri, Leiv, Lukas, and Olivier
have been saying. Screw the "pop" classical releases. Somebody found
those crap titles adequate, obviously, and if I ever come into
possession of one of those releases, I'll fix my local tags and move
on. If Lauri gives her mother-in-law a "real" classical release, then
the CSG titles will be close to the cover, and it's all good. (I don't
I've yet seen Lauri argue against CSG, BTW, so let's not be too quick
to toss her into the "kill CSG" bucket.)

> If we're aiming for "as on the liner", which liner,
> which translation, and what still gets fixed - caps, typos, mislisted
> works, etc?

"As on the cover", rather. Of course, sometimes the cover doesn't even
get into track specifics, so we have to default to the liner. In that
case, use the language used on the cover. If someone is motivated
enough to enter another language from the liner, it's no skin off my
nose. The rest are, AFAIK, already covered by CSG and other SGs.

Now, on to the fascinating Works list RFC ...

--
-:-:- David K. Gasaway
-:-:- Email: dave at gasaway.org
-:-:- Web: dave.gasaway.org
-:-:- MusicBrainz: dkg
Loading...