[ogg-dev] Feedback on XML metadata namespace

[Ian Malone]

Silvia Pfeiffer wrote:
> Daniel,
> 
> before you step over everything that has been done before, we need to
> determine what exactly is the use case for your new specification.
> 
> What concerns metadata, we currently have:
> 
> * vorbiscomment - this is a header at the beginning of a logical
> bitstream which has metadata that refers to the complete file; there
> is a specification, which has been public for a long time and is the
> de-facto standard that is (or should be) used by all software (see
> http://xiph.org/vorbis/doc/v-comment.html)
> 
> * cmml - this is a logical bitstream for time-continuous textual
> annotations (metadata) for ogg files (see
> http://wiki.xiph.org/index.php/CMML)
> 
> * skeleton - this is an extension to the ogg bitstream format, which
> has all the encapsulation-specific low-level metadata (see
> http://wiki.xiph.org/index.php/Ogg_Skeleton)
> 
> All of these are supported by xiph and may need further
> work/extensions or potentially a replacement if they are not fit to
> provide what is required.
> 
> Before throwing out more random specifications, could we please look
> at what you are trying to achieve with the new format? Can you tell us
> where the existing technologies are lacking?
> 

<So, some of this has already been covered, but it's been
sitting on my computer for two days and won't get sent if I
have to rewrite it all.>

My feeling has always been the human-relevant detailed
information is missing.  Skeleton is capable of describing
all format related information (though external metadata
descriptions of a resource may want to contain this
information too).  Vorbiscomment is good for the basics,
mainly for rock or pop music which often fits nicely into
the artist - trackname format.  CMML does the time resolved
things and clip descriptions, but not detailed relationships
between tracks.

Classical music is a rich source of examples; works are
most often associated with a composer but you may still
care who the performers or conductors were.  A piece may
be split across several movements which may be even further
broken down into tracks on the source.  However pop music
actually provides some non-trivial cases, along the same
lines but made more difficult by the fact they've been
generally ignored, the most prominent is the problem of
cover versions; you can have separate creators for the
music, lyrics and performance.  Sampled tracks are also
an issue.  Moving away from music we have plays (act,
scene, writer, director, any music credits), plus
supplementary information for multiplexed audio or video
describing the individual streams (for example, which
microphone, instrument or camera).

The above are examples of the type of information you
might want to put in that wouldn't fit well into existing
examples (with the possible exception of the pseudo-
temporal act/scene information).  But obviously only the
obsessive would want to include any of this without use
cases.  Some possibilities that come to mind: improved
cataloguing of media, for example listening to a track
and being able to get a list of songs with the same
writer but not necessarily composer.  You could do that
with Vorbiscomment, but a proper metadata format allows
you to use URIs to avoid false matches, typos etc.

Streaming radio, provision of trackback-like references to
connected resources.  You could connect to a server and it
could put out a metadata packet at intervals describing the
current track, rather than having to restart the Vorbis
stream to get a new comment header.  This richer metadata
could give links to the artists webpage or an online store.

Online album delivery.  I'd distinguish this from the
streaming case.  Here the metadata provides the equivalent
of CD liner notes (for the track rather than an entire
album, though it may refer to an external resource
describing the collection which could, in turn, be a media
metadata resource).

Running out of time, if I think of anything else I'll be
sure to mention it later.

-- 
imalone