Re: [Rhythmbox-devel] Total Tracks?

[in7y118 public uni-hamburg de]

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?

> Vorbis comments as they exist today provide 99% of what music players
> need for basic operation.  To import a new song, all you really care
> about is:
> 
> Genre
> Artist
> Album
> Song Name
> Track Number/Track Total
> 
I looked at the xiph proposal and at this mail and failed to find a clue why 
the total number of tracks might even be slightly useful to anyone. People only 
use it because it's easy to support and has always been there, so why not?
Apart from that "total tracks" is a property that belongs to the album, not the 
track. The track has 1 total tracks. It is some perverted idea to include album 
information duplicated in every single track. (These arguments are mostly a 
prelude to for what comes further down, please don't argue about them)

> 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) to such funny people like me, who actually listen to popmusic 
from casted bands because of the composer. And when I'm in a Max Martin mood 
I'd like to select tracks based on composer and get songs like Bon Jovi's It's 
My Life, Britney's Stronger or Larger Than Life by the Backstreet Boys.
And I listen to Film scores, too. Which is very close to classical from the 
tagging requirements. (Yes I want to select tracks based on wether they were 
orchestrated by Bruce Fowler or not.)

> 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?

These are three examples where our idea of what tags should do are completely 
different. I don't think anyone of us is wrong. You just look at it from the 
popmusic-listening student (no pun intended) perspective and I look at it from 
my crazy point of view.

> 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 
allows you to attach all artists to a track as seperate entities instead of 
writing "Lil Kim, Pink, Christina Aguilera & Mya" (has advantages when using 
the artist filter ;)) or attach all albums the track appeared on to said track. 
GStreamer will then include plugins that do the taglist <=> metadata conversion 
for you depending on the file. And this can then further be abstracteds for you 
app writers to just call gst_uri_set_tags (gchar *uri, GstTagList *list);
GStreamer will allow you to define your own tags for your own plugins should 
you want to do that, but it will by default try to support an awful lot of 
predefined tags. Why? Because only predefined tags can be supported by our 
plugins. And you don't want to force anyone to rewrite all those plugins. And 
because we don't know the audience that creates applications. And because there 
are people who think stupid tags like DISCTOTAL or a track image should be 
supported.


Benjamin

PS: Rereading that mail, it sounds more like a FYI collection than anything 
else, but whatever ;)