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.

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.

−

One of the intentions of the current work on [[MIME Types and File Extensions]] is to superseede the Vorbis I spec allowing all types of metadata to be included and encouraging program writers to ignore unrecognised content in these files. The metadata embedded Ogg files below are therefore '.oga'. '''It's best to use your browser's''' ''save as'' '''function for samples other than the originals as the .oga extension currently confuses browsers.'''

+

One of the intentions of the current work on [[MIME Types and File Extensions]] is to superseede the Vorbis I spec allowing all types of metadata to be included and encouraging program writers to ignore unrecognised content in these files. The metadata embedded Ogg files below are therefore '.oga' served as audio/ogg. '''You may want to use your browser's''' ''save as'' '''function if you have trouble opening the links.'''

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&mdash;if you like the music get the originals. Please notice that filenames are mixed case

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&mdash;if you like the music get the originals. Please notice that filenames are mixed case

Revision as of 13:06, 20 September 2007

The following is a draft!

It is at best incomplete and at worst completely broken. In any case, it is not an “official” Xiph spec or codec, so use with care.

Schemes such as MDMF require an embedding in physical Ogg streams. This page is for development of a specification for embedding XML streams in Ogg. The final version will probably look like the CMML mapping.

Contents

Current plans

(taken from mailing list discussions)

Magic number?

Should we have a magic number for this? By convention the beginning of stream packet for codecs in Ogg identifies the packet, Strictly speaking we will have a magic number regardless, but should it be:

'<?xml' the opening of the XML declaration. In this instance the demuxer would pass this upwards to an XML parser which would derive from the rest of the bos packet what to do with it.

Some other sequence before the XML starts, identifying the particular stream type, probably with a version number which will imply the contents to be some form of XML. CMML does this. This may avoid the almost inevitable problem of some implementor assuming '<?xml' is always metadata, it may also reduce the difficulty of writing a demuxer. Demuxers could still peek ahead and try to look of an xml namespace it recognizes.

Division into packets

The raw XML should ideally be broken into packets in a way that the loss of some packets, while destroying information, does not result in an invalid stream. Generally this means:

The bos packet should consist of any initial processing directives, namespace declarations, and the root tag if there is one.

Subsequent packets should be valid xml stanzas, similar to the XMPP definition, which concatenated are also valid xml.

The eos packet can be empty. If there was a root tag in the bos packet, it should be closed here.

Parsers should close all open tags on encountering eos to handle truncated stream conditions. Encountering eos here means either a after processing a packet marked with the eos flag, having finished on an Ogg page with the eos flag set, or a virtual eos, implied by encountering bos flags for a new chain segment.

Granulepos mapping

The XML file is essentially the same as an unencapsulated physical bitstream.

Then there is a mapping into a logical bitstream, where some of the
default information - in particular the XML header - are split off and
put into the bos packet - nothing really needs to go into the eos
packet. There's also a magic number and a version number.

Also, use the granulepos scheme that we defined for CMML pages- you're

going to make your lives easier.

That is, use a split granulepos scheme like keyframe codecs to indicate the offset to the previous packet.
Whether this is appropriate for a given XML steam will depend on its application. Metadata that applies
to the whole stream should just be included at the beginning, like OggSkeleton, and the granulepos can just
all be zero. Time-based data, like a slideshow or 'currently playing' for radio streams, should be muxed
throughout the stream.

Given that the CMML mapping would be sensible should we simply hijack
CMML for this use (i.e. just put the metadata XML in a CMML stream?
Arguments against this: it means stream parsing is needed to find out
whether the CMML stream contains metadata too and possibly complicates
CMML handling. If not hijacking CMML it might be worth having a flag
indicating whether the stream is continuous or secondary header only.

Test Files

It is a barrier to the widespread introduction of any metadata format that the Vorbis I spec only requires players to support an unaccompanied Vorbis stream; many OggVorbis 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.

One of the intentions of the current work on MIME Types and File Extensions is to superseede the Vorbis I spec allowing all types of metadata to be included and encouraging program writers to ignore unrecognised content in these files. The metadata embedded Ogg files below are therefore '.oga' served as audio/ogg. You may want to use your browser'ssave asfunction if you have trouble opening the links.

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. Please notice that filenames are mixed case
and add a note in discussion if you find a broken link.