PDA

View Full Version : Classical tagging - an idea...



Robin Bowes
2008-12-05, 18:58
Hi all,

I've been tagging a whole load of classical music recently and couldn't
help but feel that it could be a whole lot easier.

I've got the initial rumblings of an idea for a classical music version
of FreeDB and have done a bit of a braindump here:

http://projects.robinbowes.com/classitag

It's a wiki, and I *think* I've enabled public editing, so feel free to
add any thoughts/ideas you might have and I'll see if I can get
something knocked up.

R.

sebp
2008-12-06, 04:53
Hi Robin,

Added my first two cents to your wiki.

Seb

JJZolx
2008-12-06, 05:51
Databases like that are a bit of a chicken and egg problem. How do you expect to populate it? In order for it to be at all useful, you'll need to convince developers of tagging and/or ripping software to integrate with it. That's going to be a tall order without many thousands of CD entries just to start.

GENRE data is going to be interesting. I suspect that if you solicit data from the public, that it's going to be all over the board for any given work. I think this is why FreeDB often returns no GENRE, and very often no YEAR when ripping a disc.

No CONDUCTOR field?

No fields for soloists? I would think distinguishing between BAND/ORCHESTRA/ENSEMBLE and individual performers would be valuable, instead of lumping them all into the ARTIST field.

You'll need an ARTISTSORT field. In fact, you need to have a sort field for any field that potentially contains a proper name, so a CONDUCTORSORT if you have a CONDUCTOR field.

sebp
2008-12-06, 06:56
I agree with JJ, there are plenty of informations that would need to be kept into the DB. Then, it would be up to the user deciding how he/she wants to forge his/her tags from these informations.
As I'm using FLAC exclusively, I would for example use a single tag for each data (eg.: one GENRE tag for "Classical" and another one for "Symphonic"), since Vorbis comments specs encourage this.

Yet another example, some people will want the "track title" tag to include some clues about the work, others won't.
Same thing with operas, when one would like the "act" and "scene" informations to appear in the "track title" tag ...

Classical works are probably the craziest music to tag correctly, accordingly with everybody's taste.
Opera works being the worst case scenario, IMHO.

Robin Bowes
2008-12-06, 10:43
I'll respond here to both yours and sepb's comments.

JJZolx wrote:
> Databases like that are a bit of a chicken and egg problem. How do you
> expect to populate it? In order for it to be at all useful, you'll
> need to convince developers of tagging and/or ripping software to
> integrate with it. That's going to be a tall order without many
> thousands of CD entries just to start.

Fair point, and one I'm thinking about. I'm not too worried at this stage.

> GENRE data is going to be interesting. I suspect that if you solicit
> data from the public, that it's going to be all over the board for any
> given work. I think this is why FreeDB often returns no GENRE, and
> very often no YEAR when ripping a disc.

I agree - genre data is problematic. However, the user will be able to
choose whether or not to use any supplied data, i.e. they will be able
to ignore the Genre information.

>
> No CONDUCTOR field?

See later...

>
> No fields for soloists? I would think distinguishing between
> BAND/ORCHESTRA/ENSEMBLE and individual performers would be valuable,
> instead of lumping them all into the ARTIST field.

See later...

> You'll need an ARTISTSORT field. In fact, you need to have a sort
> field for any field that potentially contains a proper name, so a
> CONDUCTORSORT if you have a CONDUCTOR field.

The key point I was trying to make (and failed, it would seem) is that
the data will *not* be tied to the tags.

I fully intend to have separate data for all contributors (BAND,
ORCHESTRA, CONDUCTOR, etc. etc.) The user will then be able to choose
how that data is written to their tags. So, they might choose to have
separate ARTIST tags, or one, concatenated ARTIST tag.

Using sebp's example:

"I'd prefer seeing something like conductor='Carlos Kleiber' and
ensemble='Wiener Philharmoniker' in the database, and a way to ask the
system to forge the ARTIST tag with these (say
ARTIST='%ENSEMBLE%;%CONDUCTOR%', or maybe
ARTIST='%CONDUCTORSORT%;%ENSEMBLE%' if you prefer)."

I envisage just this functionality. The DB will store conductor='Carlos
Kleiber' and ensemble='Wiener Philharmoniker' and the user will be able
to choose whether to store those tags in their files, or concatenated
them in the ARTIST tag, or both.

Another of sebp's comments:

"say some movement is lengthy, and for some reason it's been splitted on
two or more tracks on one album, but left as one on another. It would
not work."

That's not going to happen in practise; if it does, it will be
relatively uncommon. The reverse may happen (two or movements inside one
track). That eventuality is relatively easy to deal with (e.g.
concatenate both movement descriptions in the TITLE tag).


R.

sebp
2008-12-06, 11:17
Another of sebp's comments:

"say some movement is lengthy, and for some reason it's been splitted on
two or more tracks on one album, but left as one on another. It would
not work."

That's not going to happen in practise; if it does, it will be
relatively uncommon. The reverse may happen (two or movements inside one
track). That eventuality is relatively easy to deal with (e.g.
concatenate both movement descriptions in the TITLE tag).
Well, maybe it's unlikely to happen with other classical stuff, but it would be quite a different thing with operas, where the equivalence to the "movement" would be a scene in an act.
As these scenes are generally split into several tracks of the disc, it's very likely that two performances of the same work would not be split in the same way !

I'm pretty sure that if you can cope well with operas, your solution would be foolproof.

Seb

Listener
2008-12-06, 23:23
Robin,

I appreciate your making the effort to think out the problems and suggest a way forward.

Kirk McElhearn was working on an approach for classical music he called "The Well Tempered Database". His blog is at

http://www.mcelhearn.com/

He started a yahoo group which has been inactive for some time.

I thoroughly agree with you idea to store primitives that can be distributed to tags as each user wishes.

I would suggest trying to get a good problem definition before plunging into describing a solution. People often argue about a solution based on a private idea of the problem to be solved.

Bill