Jump to: navigation, search


761 bytes added, 10:40, 12 June 2012
Made clear spec is for both XML files and XML streams
Schemes such as [[MDMFM3F]] require an embedding in physical Ogg streams. This page is for development of a specification for embedding XML files and XML streams in Ogg. The final version will probably look like the CMML mapping.
==Current plans==
* '<?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 for an xml namespace it recognizes.
===Division into packets===
indicating whether the stream is continuous or secondary header only.
It seems reasonable to use the fishbone message fields in [[Ogg Skeleton]] to supply an ID to be associated
with each logical stream (via an "id:" message header field). The other side of this problem is how
these should be addressed. The physical bitstream itself shouldn't need one, but do we worry about
chained/concatenated streams?
The Skeleton section of the [ Annodex bitstream format]
specifies that mandatory header fields MUST be US-ASCII encoded, but allows UTF-8 for other message fields. This
does not appear to be a problem for an ID field. [ RFC2822] limits message header
fields to 998 bytes (excluding CRLF) and spaces are not normally permitted in IDs, so IDs would be limited to 994
bytes long.
===Mime type===
For use in Skeleton. [[MIME Types and File Extensions]] gives 'text/cmml' for 'CMML without container', if that
can be used by Skeleton to describe packetized CMML in Ogg then there's no issue here; 'text/xml' or whatever
is appropriate could be used.
==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 [[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' served as audio/x-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

Navigation menu