Re: [Rhythmbox-devel] Total Tracks?

[Joshua Haberman <joshua haberman com>]

On Wed, 2003-10-15 at 08:28, in7y118@public.uni-hamburg.de wrote:
> There's a lot of stuff that I don't agree with, so I thought I'd share my 
> different views.
> 
> Quoting Joshua Haberman <joshua@haberman.com>:
> 
> > That was an annoying thread to read.  The people arguing against using
> > Vorbis Comments for metadata are misled, I think.
> > 
> This I actually agree with. Though metadata inside vorbis is somehow stupid. 
> Imagine if Theora video implements its own metadata, too. Do you use the 
> metadata of the audio or the metadata of the video to get the title of the 
> video?

I always wished the comments were part of the Ogg format instead of
Vorbis.  But we have what we have.

> > That gives you enough to implement a useful browser such as Rhythmbox
> > has.  All of these fields already exist, they are human-readable (and so
> > fail to succumb to the criticism of "looking like a database").  They
> > aren't rigorously defined (for example, is "Artist" performer or
> > composer?) but they don't have to be -- what you know is that whatever
> > appears as "artist" will be used for the "artist" pane of the browser.
> > 
> When you present your views you totally fail to recognize the views of others. 
> In this example that would be listeners to classical music (who differentiate 
> between performer and composer and will probably find Rhythmbox lacking until 
> it supports both)

I have quite a lot of classical music in my collection.  I am a music
student, after all.  :)

I fully conceded that the current scheme does not have the expressive
power of recognizing a difference between composer, performer, arranger,
etc.  My point was that for basic browsing of your music collection --
the kind that Rhythmbox or iTunes can reasonably support without having
an overly complex GUI -- the current scheme gives enough power to find
what you need.  Especially with the ability to specify more than one
artist per song, you could create one "artist" tag for composer, one for
performer, etc.  Then you know that you can go into your "artist" pane
and select either a performer *or* a composer.

Yes, classical music differentiates between performer and composer.  But
trying to faithfully reproduce data this specific becomes arbitrarily
complex; for example, "performer" can consist of "conductor," one or
more choirs, an orchestra, soloists, etc.  Even if there was a published
recommendation for how to put this data in individual files, do you
really trust the tags on a file you receive to be complete and correct
enough to suit you?  I know I don't, which is why I would rather that
detailed information be looked up in a community edited and moderated
database.

> (Yes I want to select tracks based on wether they were 
> orchestrated by Bruce Fowler or not.)

The desire to make queries like this is an argument in favor of a
centralized database.  The only way you are going to get meaningful
results for queries like this is if you get your data from a relational
database with well-defined semantics and unique identifiers for
people/bands/albums.  For example, here are some factors that would
prevent you from getting good results if you queried based on
information in tags:

1. you say "orchestrated," but others might tag this as "arranged" or
"composed."
2. Someone could enter Bruce Fowler's name with a middle initial or have
some other variation that would cause the query to fail.  This could be
more likely with names that have accents or hyphens in them.

Either you rely on a centralized, moderated database with built-in
semantics, or you publish a detailed document standardizing semantics
and specifying a canonical naming scheme for people, bands, etc. and
hope that everyone adheres to it vigorously.

> > To support more thorough metadata (composer, year, conductor, cover art,
> > etc) IMO the right way to do this is to have each song have a unique id
> > that links into some centralized database.  And lucky for us, this
> > already exists: Musicbrainz!
> > 
> With this you totally neglect people like my father or me when I'm on tour with 
> my ibook. We both miss an internet connection. How are we supposed to get at 
> the metadata that you failed to include in our files?

There's no reason this data can't be cached locally as part of your
local music database that Rhythmbox or iTunes maintains.  The only
difference is that you pull the data from a central and continuously
maintained database instead of having it pushed with a file you receive.

> > So the idea is: the tags on a file give you enough information that you
> > can browse your collection.  For more information, the player can look
> > up the song in the musicbrainz database, which has the benefit of being
> > constantly updated.  It doesn't make sense to try and include every
> > piece of potential metadata in a stream, since it will always be
> > incomplete or potentially erroneous.
> > 
> My idea (the one I'm implementing) is this:
> GStreamers tagging system will support so called "tag lists". Tag lists are 
> tuples of the type (tag, value). Every tag can occur multiple times.

This is exactly the model of Vorbis Comments, and it has the same
weaknesses as Vorbis Comments if you are trying to use it as a data
source for complex queries:

* there are not currently enough fields defined in the recommendation to
support complex groups of metadata, especially the type that occurs in
classical music
* even if there were, for this information to be useful you would have
to rely on every independent tagger to vigorously adhere to published
recommendations
* string-wise matching is not a sufficient way to specify a person,
album, band, etc. because of all of the ways such names can vary

Josh