Difference between revisions of "Metadata"

From XiphWiki
Jump to navigation Jump to search
(Describe the need for a separate metadata format)
 
m (correct formatting)
Line 1: Line 1:
== Motivation ==
+
==Motivation==
  
 
All the Xiph.org codecs have some internal mechanism for including metadata about the current stream.
 
All the Xiph.org codecs have some internal mechanism for including metadata about the current stream.
Line 9: Line 9:
 
metadata format; one that can be interleaved with the other streams in a container.
 
metadata format; one that can be interleaved with the other streams in a container.
  
  * *Machinability* There are a number of items of metadata that a player will want to parse and take  
+
  * *Machinability* There are a number of items of metadata that a player will want to parse and take action on. While there are usually 'convention' schemes for doing this with the embedded comment headers, this is much easier if there is a separate metadata stream designed for such use, instead of having to do best-effort parsing of natural language comments. For example, a video file with multiple audio tracks can specify the language of each one; a player than can parse these reliably can match them against a language preference list configured by the user to automatically select and begin playback of the best option.
action on. While there are usually 'convention' schemes for doing this with the embedded comment headers,
 
this is much easier if there is a separate metadata stream designed for such use, instead
 
of having to do best-effort parsing of natural language comments. For example, a video file with multiple
 
audio tracks can specify the language of each one; a player than can parse these reliably can match them
 
against a language preference list configured by the user to automatically select and begin playback of
 
the best option.
 
  
  * *Kitchen Sink* There are a minority of people who care passionately about having every detail about
+
  * *Kitchen Sink* There are a minority of people who care passionately about having every detail about a track available. In the sense of conserving such information, and providing an equivalent to liner notes for online distribution, this is a goal worth supporting. However, the simple unstructured key-value pairs offered by the inline metadata are unwieldy for this level of detail. How do you tell the 2nd unit Assistant Director from the USA unit Assistant Director? How do you indicate which artist played tenor sax in the solo?
a track available. In the sense of conserving such information, and providing an equivalent to liner
 
notes for online distribution, this is a goal worth supporting. However, the simple unstructured  
 
key-value pairs offered by the inline metadata are unwieldy for this level of detail. How do you tell
 
the 2nd unit Assistant Director from the USA unit Assistant Director? How do you indicate which
 
artist played tenor sax in the solo?
 
  
  * *Addressability* The internal comment metadata headers are by necessity attached to a single content
+
  * *Addressability* The internal comment metadata headers are by necessity attached to a single content stream. This is useful for some appication, but a limitation in others. In a multiplexed stream, which set of comments refers to the collection as a whole? (By convention, in Ogg, it's the first logical bitstream occuring, but we can do better.) A separate metadata stream type must address this issue of collective metadata while still allowing description of individual streams. It should also allow temporal addressability, so that changes can be described. Because the in-stream comment metadata are part of the codec headers, it cannot change over the course of the stream, and allowing additional comment packets elsewhere in the stream presents seeking challenges. In the Ogg container this can be resolved by inserting a chain boundary, but this is a poor option for very-low-bitrate streams and unreliable transports such as RTP.
stream. This is useful for some appication, but a limitation in others. In a multiplexed stream, which
 
set of comments refers to the collection as a whole? (By convention, in Ogg, it's the first logical bitstream
 
occuring, but we can do better.) A separate metadata stream type must address this issue of collective
 
metadata while still allowing description of individual streams. It should also allow temporal addressability,
 
so that changes can be described. Because the in-stream comment metadata are part of the codec headers,
 
it cannot change over the course of the stream, and allowing additional comment packets elsewhere in the
 
stream presents seeking challenges. In the Ogg container this can be resolved by inserting a chain
 
boundary, but this is a poor option for very-low-bitrate streams and unreliable transports such as RTP.
 
  
== Proposed Solutions ==
+
==Proposed Solutions==
  
 
RDF + dublin core
 
RDF + dublin core

Revision as of 10:17, 21 September 2004

Motivation

All the Xiph.org codecs have some internal mechanism for including metadata about the current stream. Generally, this is one of the codec headers, and in the words of the vorbis spec, "It is meant for short, text comments...much like someone jotting a quick note on the bottom of a CDR."

This works well enough for most things, and can be overloaded/abused (depending on your point of view) for most other things. But there are three major requirements that point to the design of an external metadata format; one that can be interleaved with the other streams in a container.

* *Machinability* There are a number of items of metadata that a player will want to parse and take action on. While there are usually 'convention' schemes for doing this with the embedded comment headers, this is much easier if there is a separate metadata stream designed for such use, instead of having to do best-effort parsing of natural language comments. For example, a video file with multiple audio tracks can specify the language of each one; a player than can parse these reliably can match them against a language preference list configured by the user to automatically select and begin playback of the best option.
* *Kitchen Sink* There are a minority of people who care passionately about having every detail about a track available. In the sense of conserving such information, and providing an equivalent to liner notes for online distribution, this is a goal worth supporting. However, the simple unstructured key-value pairs offered by the inline metadata are unwieldy for this level of detail. How do you tell the 2nd unit Assistant Director from the USA unit Assistant Director? How do you indicate which artist played tenor sax in the solo?
* *Addressability* The internal comment metadata headers are by necessity attached to a single content stream. This is useful for some appication, but a limitation in others. In a multiplexed stream, which set of comments refers to the collection as a whole? (By convention, in Ogg, it's the first logical bitstream occuring, but we can do better.) A separate metadata stream type must address this issue of collective metadata while still allowing description of individual streams. It should also allow temporal addressability, so that changes can be described. Because the in-stream comment metadata are part of the codec headers, it cannot change over the course of the stream, and allowing additional comment packets elsewhere in the stream presents seeking challenges. In the Ogg container this can be resolved by inserting a chain boundary, but this is a poor option for very-low-bitrate streams and unreliable transports such as RTP.

Proposed Solutions

RDF + dublin core

XML-encoding (generic rdf or CMML?)

binary encoding (three-component length-encoded binary vectors)