[ogg-dev] The use for an XML based metadata format

[Silvia Pfeiffer]

What I've gotten out of this discussion so far:

1) we need to introduce a means in which to do captions; this could be
done through adding a "caption" element to CMML, or in another
time-continuous annotation format; so far I am not sure which would be
the better way

2) we need a XML annotation format for audio - in particular for music
- that is more structured than vorbiscomment (and this probably
applies to video, too)

3) we need a means to describe relationships between different logical
bitstreams; we had a discussion about this years ago, but never got to
a proper specification of this

4) we need a means to address logcial bitstreams by name; this should
be an ID attribute to be added to skeleton


These four things are all very different and separate things - number
2 may even need further structuring IMO. Yes, they interrelate and
there should be means to address one from the other. But IMO they all
need a different approach.

Silvia.

On 9/10/07, Ian Malone <ibmalone at gmail.com> wrote:
> On 09/09/2007, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
> > Daniel,
> >
>
> > A similar argument goes for the encoding quality description and digital rights.
> >
> > In contrast, the improved description of the content as in: artist,
> > band name, title, organisation involved, and people involved are
> > things that improve upon vorbiscomment and should probably be included
> > there directly.
> >
>
> There are arguments against simply using vorbiscomment for this,
> beyond simply the fact that the Vorbis spec says it should only be
> used for short 'jotted on the CD' type notes.  First it is based on
> value pairs, this makes it hard to describe relationships in detail;
> you must either choose a field name that will not be widely
> understood ('drummer', 'sound engineer', even 'composer' won't
> get you far) or use a funny way of refining it in the value (such
> as artist=(composer) Beethoven), I think cast lists for films present
> a similar problem.  There is consistency and indexability to be
> addressed (Ludvig van Beethoven; Beethoven, Ludvig van;
> Beethoven).  Finally complex relationships are even harder to
> handle such as specifying a resource's relationship to the rest
> of a collection.
>
> > All I ask for is *not* to reinvent the wheel when there are already
> > working, semi-complete metadata formats for Ogg that have been
> > carefully prepared to fit with the existing Ogg framework. It would be
> > a sheer nightmare to create another new one that does not fit with any
> > of the existing ones and is not supported by any media application.
> >
>
> Yes, any attempt to add a metadata format should leverage
> what exists already.  I see it like this: Skeleton describes the
> technical aspects of the stream, CMML splits it into temporal
> parts, but describing the contents is left to Vorbiscomments,
> which were by design only sufficient for simple descriptions
> (and are tied to a logical stream).  Looking back through
> the list archives it was always intended there should be a
> metadata format to go beyond what Vorbis comments
> could do.
>
> I suppose I should draw attention to some of the stuff I did
> before I discovered I didn't have enough time to get some
> kind of working application together:
> <http://www.imalone.co.uk/omd_background/index.html>
> <http://www.imalone.co.uk/omd_questions/index.htm>
> <http://wiki.xiph.org/index.php/Metadata>
> I got a bit sidetracked by the multiplexed streams
> compatibility stuff at the time, that and trying to learn XPCOM
> to produce a FF plugin (something which was going to take
> far more time than I had).  A Rhythmbox plugin is probably the
> easiest target, though something Windows based would get
> a wider audience, Songbird might be good as it's built on
> top of a platform which is designed to handle XML.
>
> P.S. does anyone know what XMP actually does?  Whenever
> I look at it all I can find are descriptions of how the embedding
> is done.
>
> --
> imalone
> _______________________________________________
> ogg-dev mailing list
> ogg-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/ogg-dev
>