Metadata: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
(Changed tense of M3F + tidy)
 
(52 intermediate revisions by 9 users not shown)
Line 1: Line 1:
{{draft}}
This page aims to give an overview of the current state of metadata in Ogg and the ongoing projects towards improving it. The different components work in concert; for example [[Ogg Skeleton]] provides important infrastructure for [[CMML]], [[VorbisComment]] is simple to use and program, while the draft [[M3F|Multimedia Metadata Format (M3F)]] provides more sophisticated information.
==Motivation==
 
== [[VorbisComment]]s ==


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.
Generally, this is one of the codec headers, and in the words of the [http://www.xiph.org/ogg/vorbis/doc/v-comment.html vorbis spec],  
Generally, this is one of the codec headers, and in the words of the [http://www.xiph.org/vorbis/doc/v-comment.html vorbis spec],  
"It is meant for short, text comments...much like someone jotting a quick note on the bottom of a CDR."
"It is meant for short, text comments ... much like someone jotting a quick note on the bottom of a CDR." A single VorbisComment can store upto 2^64 bytes (16 exabytes).
 
VorbisComments store metadata describing the stream in key=value pairs, such as "ARTIST=Elvis", "TITLE=Blue Suede Shoes". Multiple copies of any given key are allowed (for example you can specify ARTIST several times for multiple performers). The specification has several suggested keys: TITLE, VERSION, ALBUM, TRACKNUMBER, ARTIST, PERFORMER, COPYRIGHT, LICENSE, ORGANIZATION, DESCRIPTION, GENRE, DATE, LOCATION, CONTACT, ISRC. See the [http://www.xiph.org/vorbis/doc/v-comment.html specification] for the intent of each one.
 
The [[VorbisComment]] page contains improvements to the suggested comment set.
 
== [[FLAC]] metadata blocks ==
 
Metadata is included in the FLAC codec as METADATA_BLOCK_DATA. Seven types of metadata block are defined: 
#''METADATA_BLOCK_STREAMINFO'': Sample rate, number of channels, etc.
#''METADATA_BLOCK_PADDING'': Nul padding.
#''METADATA_BLOCK_APPLICATION'': Third-party applications can register an ID. Metadata is typically 32-bit integers, but any datatypes can be specified.
#''METADATA_BLOCK_SEEKTABLE'': For one or more seek points.
#''METADATA_BLOCK_VORBIS_COMMENT'': Also known as FLAC tags, the contents of a VorbisComment packet. Note that the 32-bit field lengths are little-endian coded according to the Vorbis spec, as opposed to the usual big-endian coding of fixed-length integers in the rest of FLAC. FLAC metadata blocks are limited to 2^24 bytes (16 megabytes) and a VorbisComment packet in FLAC must fit within that limit.
#''METADATA_BLOCK_CUESHEET'': Typically, but not necessarily, for CD-DA (Red Book) cuesheets.
#''METADATA_BLOCK_PICTURE'': For binary picture data.
 
== [[Ogg Skeleton]] ==
 
[[Ogg Skeleton]] provides metadata useful for handling Ogg streams. This includes information like mime-types and mapping for granulepos which allows seeking streams without the need for the demuxer to understand them. The latest version, [[Ogg Skeleton 4]], also provides a keyframe index to enable faster seeking over high latency networks.
 
Ogg Skeleton allows for attachment of message header fields, given as name-value pairs, that contain some sort of protocol messages about the logical bitstream. This is intended for decode related stuff, such as the screen size for a video bitstream or the number of channels for an audio bitstream.
 
== [[OggKate]] ==
 
[[OggKate]] was originally designed for karaoke and text. The stream can carry text and images, and these can be animated.
 
== [[CMML]] (deprecated) ==
 
CMML is not used anymore; use [[OggKate]] instead. The [[CMML|Continuous Media Markup Language]] allowed time-based marking up of media streams, at its simplest this allowed you to divide media files into clips and provide information about each clip.


This works well enough for most things, and can be overloaded/abused (depending on your point of view)
== [[M3F]] (unused draft) ==
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.
[[M3F|Multimedia Metadata Format]] is not being developed anymore; use [[VorbisComment]] instead.


* ''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?
The format was intended to replace VorbisComments for the use of ''structured'' metadata, allowing VorbisComments to revert to its orginally intended use of "short, text comments ... much like someone jotting a quick note on the bottom of a CDR."


* ''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.
[[M3F]] for the Ogg container was a draft specification which aimed to provide metadata for media streams. The exact aims of this project were still under development, but they included being able to describe artist relationships to a piece more accurately as well as providing the structure to encourage more reliable metadata.


==Proposed Solutions==
== [[XMLEmbedding]] (unused draft) ==


RDF + dublin core
To implement XML metadata in Ogg (as for [[M3F]]), a mapping to Ogg streams is needed. The use of XML metadata will also open the way for the inclusion of technologies such as:
* RDF + dublin core
* [http://www.adobe.com/products/xmp/ XMP]
* [http://wiki.musicbrainz.org/MusicBrainzXMLMetaData MusicBrainz]
* [http://www.w3.org/Graphics/SVG/ SVG]
This specification is still not past the discussion stage.


XML-encoding (generic rdf or CMML?)
== Aims of advanced metadata ==


==Test Files==
VorbisComments work 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.
It is a barrier to the widespread introduction of any metadata format that the [http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html Vorbis I spec] only requires players to support an unaccompanied [[Vorbis]] stream; many [[Ogg]] [[Vorbis]] players will refuse to play augmented streams, especially if the content is not recognised (although many recent players do succeed). As a prelude to development of an [[Ogg]] metadata format it will be necessary to encourage developers to introduce more flexible [[Ogg]] filters.


To help with testing the following files are available, based on a speculative (and very basic) metadata format. In each case the derivative files are under the same license as the original. Two sets are provided to allow chained stream testing. On some players the seek tests produce an annoying clicking—if you like the music get the originals.
* '''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.


Original (Vorbis I): [http://music.ibiblio.org/pub/multimedia/pandora/vorbis/contrib/Debbie_Hu/Bach-Busoni_Nun_freut_euch_3.ogg Bach - Nun freut euch lieben Christen] performed by Debbie Hu, from [http://music.ibiblio.org/pub/multimedia/pandora/mp3/Read.html Pandora Records] and available under the [http://www.eff.org/IP/Open_licenses/eff_oal.php EFF OAL].
* '''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?
* The [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.rdf.ogg Ogg-Vorbis-XML version]
* The XML/RDF description as a [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.xml separate document]
* With the XML page [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.multi.ogg repeated after every fifth Vorbis page]. (This is not a suggested way to add meta data, just a way of testing how players handle seeking in the presence of an unknown stream.)
* With the XML page repeated after every fifth Vorbis page and the [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.end.ogg stream ending on a meta data page] (breaks simpler track-length strategies, again not a suggested format for metadata)


Original (Vorbis I): [http://ccmixter.org/media/files/disharmonic/2958/ On The Moon (Trip Hop mix)] by [http://ccmixter.org/media/people/disharmonic/ Disharmonic], from [http://ccmixter.org/ ccMixter] and available under the Creative Commons [http://creativecommons.org/licenses/by/2.5/ Attribution 2.5] license.
* '''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.
* The XML/RDF description as a [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).xml separate document]
* With the XML page [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).multi.ogg repeated after every fifth Vorbis page].
* With the XML page repeated after every fifth Vorbis page and the [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.end.ogg stream ending on a meta data page]

Latest revision as of 12:44, 24 July 2013

This page aims to give an overview of the current state of metadata in Ogg and the ongoing projects towards improving it. The different components work in concert; for example Ogg Skeleton provides important infrastructure for CMML, VorbisComment is simple to use and program, while the draft Multimedia Metadata Format (M3F) provides more sophisticated information.

VorbisComments

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." A single VorbisComment can store upto 2^64 bytes (16 exabytes).

VorbisComments store metadata describing the stream in key=value pairs, such as "ARTIST=Elvis", "TITLE=Blue Suede Shoes". Multiple copies of any given key are allowed (for example you can specify ARTIST several times for multiple performers). The specification has several suggested keys: TITLE, VERSION, ALBUM, TRACKNUMBER, ARTIST, PERFORMER, COPYRIGHT, LICENSE, ORGANIZATION, DESCRIPTION, GENRE, DATE, LOCATION, CONTACT, ISRC. See the specification for the intent of each one.

The VorbisComment page contains improvements to the suggested comment set.

FLAC metadata blocks

Metadata is included in the FLAC codec as METADATA_BLOCK_DATA. Seven types of metadata block are defined:

  1. METADATA_BLOCK_STREAMINFO: Sample rate, number of channels, etc.
  2. METADATA_BLOCK_PADDING: Nul padding.
  3. METADATA_BLOCK_APPLICATION: Third-party applications can register an ID. Metadata is typically 32-bit integers, but any datatypes can be specified.
  4. METADATA_BLOCK_SEEKTABLE: For one or more seek points.
  5. METADATA_BLOCK_VORBIS_COMMENT: Also known as FLAC tags, the contents of a VorbisComment packet. Note that the 32-bit field lengths are little-endian coded according to the Vorbis spec, as opposed to the usual big-endian coding of fixed-length integers in the rest of FLAC. FLAC metadata blocks are limited to 2^24 bytes (16 megabytes) and a VorbisComment packet in FLAC must fit within that limit.
  6. METADATA_BLOCK_CUESHEET: Typically, but not necessarily, for CD-DA (Red Book) cuesheets.
  7. METADATA_BLOCK_PICTURE: For binary picture data.

Ogg Skeleton

Ogg Skeleton provides metadata useful for handling Ogg streams. This includes information like mime-types and mapping for granulepos which allows seeking streams without the need for the demuxer to understand them. The latest version, Ogg Skeleton 4, also provides a keyframe index to enable faster seeking over high latency networks.

Ogg Skeleton allows for attachment of message header fields, given as name-value pairs, that contain some sort of protocol messages about the logical bitstream. This is intended for decode related stuff, such as the screen size for a video bitstream or the number of channels for an audio bitstream.

OggKate

OggKate was originally designed for karaoke and text. The stream can carry text and images, and these can be animated.

CMML (deprecated)

CMML is not used anymore; use OggKate instead. The Continuous Media Markup Language allowed time-based marking up of media streams, at its simplest this allowed you to divide media files into clips and provide information about each clip.

M3F (unused draft)

Multimedia Metadata Format is not being developed anymore; use VorbisComment instead.

The format was intended to replace VorbisComments for the use of structured metadata, allowing VorbisComments to revert to its orginally intended use of "short, text comments ... much like someone jotting a quick note on the bottom of a CDR."

M3F for the Ogg container was a draft specification which aimed to provide metadata for media streams. The exact aims of this project were still under development, but they included being able to describe artist relationships to a piece more accurately as well as providing the structure to encourage more reliable metadata.

XMLEmbedding (unused draft)

To implement XML metadata in Ogg (as for M3F), a mapping to Ogg streams is needed. The use of XML metadata will also open the way for the inclusion of technologies such as:

This specification is still not past the discussion stage.

Aims of advanced metadata

VorbisComments work 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.