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

[Adam Golding]

2008/6/23 Adam Golding <adamgolding at gmail.com>:

> 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]\))))
>


whoops, add a parenthesis to the last line of this to make it work.


>
>
> 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/cf912489/attachment-0001.htm