[mb-users] Tagging Classical Music (Scripts and more ARs for Picard?)

[Adam Golding]

This is a draft proposal for a system of tagging which addresses the
problems peculiar to classical music.  A lot of it can't be done until
Picard is given access to more ARs, and in some caes, until more info is
entered into MB or a works list system.  When these cases come up I will
mention.  The main goal is

   Sorting & Shuffling Classical Music by Many Parameters in Programs With
Limited Tag Support

By 'Limited Tag Support' I mean something like Itunes, as opposed to
foobar.  The idea is that, even if a classical listener uses foobar, it
would be nice to have a way to tag classical files which is compatible
across many players.  Let's take iTunes as the standard for which fields
should be used--if iTunes doesn't show the tag, it shouldn't be used.

The idea is to use taggerscripting to get as much information relevant to
sorting classical music into the iTunes-supported fields.  Step one is to do
away with alphabetical sorting.  Something's got to go here and alphabetical
sorting is only useful in a world without search functions anyway.  I
suggest the following:

   1. Fill all sort fields with date information
   2. Fill all sort fields corresponding to people with their birthdates
   3. Fill all sort fields corresponding to bands/groups with their founded
dates
   4. Where sort fields are not available, i.e. in the case of Producer, the
script should put birth dates right into the tag field.

That leaves the following three fields for date information related to the
composition and recording

   grouping
   albumsort
   titlesort
   date

Before discussing what to do with these date fields, let me show how I think
the grouping field should be used.   iTunes can shuffle by Album, Tracks,
*and by the grouping tag*.  With proper tag scripting, this should allow
iTunes to shuffle *by composition*.  Here's a primitive taggerscript script
to do this:

$if($in(%title%,:),

$set(grouping,

$rreplace(%title%,

:[^:]*\$,) \(%date%. $rsearch(\(%album%\),\(\\\([\.]*\\\)\$\))\)),

$set(grouping, %date%. %album%))


This should result in groups that look like this:


Symphony No. 9 in D minor, Op. 125 (1999. Berlin Philharmonic Orchestra
feat. conductor: Herbert von Karajan)

2004-11-09. Harmonium

the first is how tracks with colons in the track title would turn out, the
2nd is how a normal rock album would turn out, so you could shuffle, hear a
complete classical composition, then a complete rock album, etc.  This works
fine for non-classical albums that have multi-movement works (i.e. prog rock
albums) but will produce silly results if a non-classical work just happens
to have a colon in the title.  Can anyone suggest a better way to
distinguish multi-movement works for the script?

Also, for those of you who'd rather see a composer's catalogue number rather
than the record companies, this little script should fill in the BWV or Op
numbers (more support to be added for other composer's catalogue types):

$if($in(%title%,BWV),

$set(catalognumber,$rsearch(%title%,BWV[.\\s]*\([\\d]*[\\w]\))),

$if($in(%title%,Op),

$set(catalognumber,$rsearch(%title%,BWV[.\\s]*\([\\d]*[\\w]\))))


Now, back to dates.  We have these fields:

   grouping
   albumsort
   titlesort
   date


Ideally the grouping tag would begin with something worth sorting by, too.
There's a lot of information we could conceivably be interesting in, such as
the date a work was composed, premiered, published, or first recorded, or
the date a track or album was recorded/produced, or released.  Clearly
albumsort should have something relevant to the album, and I suggest the
album release date, since the individual tracks could be recorded/produced
at different times, but they must have been released all at once.

Now, clearly the grouping tag should take something relevant to the group,
and the titlesort and date fields could take something relevant to either
the movement or the track.  I think one should take the earliest known date
relevant specifically to that recording (i.e. the date the track was
recorded, or if that isn't know, the date it was mixed, etc.), and the other
should take the earliest known date relevant specifically to that movement
(i.e. the date that movement was composed, the date that movement was
premiered, etc.), although I'm not sure which should take which, so I'd
appreciate feedback on that.

The grouping tag, in front of what my script already puts in it, should have
the earliest known date relevant to the composition as a whole, such as the
date composed, premiered, etc.

In cases where the date is clearly a range, such as the 'date composed',
again take the earliest date of the range.  Why am I taking earliest
everywhere? Partially it's an arbitrary decision, since we could take the
latest date in all these cases, but then things like cover songs would be
harder to separate chronologically, and also it would break the pattern with
birthdates.  And switching to death-dates is no good for living people!


Most of this requires more ARs accessible in picard, and I think in some
cases, more ARs in the database.  I'm not sure if we should wait for NGS for
adding this sort of info, though.
The most we can do for the dates so far is the following

$set(albumsort,%date%)

Which clearly isn't much!



p.s.  I've also posted recently asking about last.fm scrobbling--I'd like to
advocate this script line as well, to give composers and songwriters due
credit on last.fm:

$if(%composer%,$set(artist,%composer%))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-users/attachments/20080623/345dcfb2/attachment.htm