[Vorbis] metadata

[Ralph Giles]

On Tue, Sep 27, 2005 at 11:42:33PM +0100, Ian Malone wrote:

> The most recent discussion on /comments/ was to suggest making a
> collection of unofficial ones.  It would be useful to see how other
> people have "overloaded/abused (depending on your point of view) for
> most other things."

Yes. If you want something informal, something like Greg's suggestion
will work fine. We just don't think (officially speaking) it's worth
trying to achieve machinability at that kind of level of detail using
the vorbis comment header metadata.

As you are distinguishing, we've always recommended using something
more sophisticated in a separate, "interleaved" Ogg logical bitstream.
This can also be whatever you want, of course, but I've not seen 
anything I thought was cool enough to bless a priori.

As you suggest, some sort of xml representation is an obvious choice.
Candidates include RDF+Dublin Core, Musicbrainz, and CMML. The latter
actually has an explicit embedding on Ogg, but is a little weak on
the kitchen sink description. :)

Half the problem, really, is that I kept hoping someone would come up
with something less horrifying than RDF-in-XML, but it's clear now
that it's not going away.

> To some degree the Dublin Core (DC) stuff looks useful, but it is
> still heavily directed towards publications: there is no analogue
> for the Vorbis suggested comment 'LOCATION', and in both the above
> examples you would have to have a lot of qualified 'contributor'
> elements and decide on the difference between creator and contributor.
> The most helpful thing they have is listings of the possible
> restricted vocabularies; pointers to standards for specifying
> locations, dates, etc.

You can do location in DC. Look at the 'spatial' qualifier of the 
'extent' element. There's also a handfull of standard types defined
for the element's value.

It's true that there was a bias toward publications, especially at
the beginning, but DC is evolving into a general resource classification
system for library holdings. Probably since librarians are the only
ones seriously trying to solve this problem. I also like it because
it's an amazingly sane committee standard.

> On top of this: multiple performers, qualified so cast, conductor,
> etc. [...]

So, the RDF data model is much more capable than the (key, value)
pairs the vorbis comment header uses. It defines a graph, where
nodes (which represent things) and connected by named edges that
specify a relationship.

Since you can have a general graph, not just a star like the vorbis
comment header, the metadata can describe not just the bundled audio 
stream, but refine its own annotations. So you can say that so and so 
was a performer on the piece, but also that they were a performer on a 
defined subset of the piece, and when and where that performer was born, 
and what instrument they played and so onand on. Or for film, you could 
dump whatever fraction of the imdb you felt was relevent, or indeed 
represent all of it.

For interoperability though, you need some standard way of labelling and 
interpreting both nodes and edges. The Dublin Core elements provide
a starting place for that, but obviously one can ask for more detail,
and that's why things like the Musicbrainz schema exist. So you use
DC for as much as you can, and build your own extensions on top. Also, 
the qualification mechanism provides a way to make your metadata 
'dumb down' so a foreign reader can still get something out of the DC 
elements even if it doesn't follow the details of the jazz influences 
on a particular riff starting at 3:54.

This whole framework is what I was referring to when I wrote 
"RDF + dublincore" in the wiki. IMO this is the best option
within which to develop a "kitchen sink" metadata stream for
Ogg.

FWIW,
 -r