XMLEmbedding - Revision history

Martin.leese: Made clear spec is for both XML files and XML streams

2012-06-12T17:40:44Z

Made clear spec is for both XML files and XML streams

← Older revision		Revision as of 17:40, 12 June 2012
Line 1:		Line 1:
	{{draft}}		{{draft}}
	Schemes such as [[M3F]] 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.		Schemes such as [[M3F]] 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==		==Current plans==
Line 11:		Line 11:
	* '<?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.		* '<?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.		* 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 for an xml namespace it recognizes.

	===Division into packets===		===Division into packets===

Martin.leese: MDMF -> M3F

2007-11-24T20:43:10Z

MDMF -> M3F

← Older revision		Revision as of 20:43, 24 November 2007
Line 1:		Line 1:
	{{draft}}		{{draft}}
	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.		Schemes such as [[M3F]] 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.

	==Current plans==		==Current plans==

Imalone: mime types

2007-09-21T10:47:59Z

mime types

← Older revision		Revision as of 10:47, 21 September 2007
Line 51:		Line 51:
	indicating whether the stream is continuous or secondary header only.		indicating whether the stream is continuous or secondary header only.

	==ID==		===ID===
	It seems reasonable to use the fishbone message fields in [[Ogg Skeleton]] to supply an ID to be associated		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		with each logical stream (via an "id:" message header field). The other side of this problem is how
Line 62:		Line 62:
	fields to 998 bytes (excluding CRLF) and spaces are not normally permitted in IDs, so IDs would be limited to 994		fields to 998 bytes (excluding CRLF) and spaces are not normally permitted in IDs, so IDs would be limited to 994
	bytes long.		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==		==Test Files==

Imalone: /* Test Files */ audio/x-ogg as this is a Xiph wiki and we shouldn't be using audio/ogg until approved

2007-09-21T09:41:03Z

Test Files: audio/x-ogg as this is a Xiph wiki and we shouldn't be using audio/ogg until approved

← Older revision		Revision as of 09:41, 21 September 2007
Line 66:		Line 66:
	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' served as audio/ogg. '''You may want to use your browser's''' ''save as'' '''function if you have trouble opening the links.'''		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—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—if you like the music get the originals. Please notice that filenames are mixed case

Imalone: some practicalities of putting ids in Skeleton message header fields

2007-09-21T07:42:09Z

some practicalities of putting ids in Skeleton message header fields

← Older revision		Revision as of 07:42, 21 September 2007
Line 56:		Line 56:
	these should be addressed. The physical bitstream itself shouldn't need one, but do we worry about		these should be addressed. The physical bitstream itself shouldn't need one, but do we worry about
	chained/concatenated streams?		chained/concatenated streams?

			The Skeleton section of the [http://annodex.net/TR/draft-pfeiffer-annodex-02.html#anchor8 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. [http://www.ietf.org/rfc/rfc2822.txt 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.

	==Test Files==		==Test Files==

Imalone: Silvia's message header id field suggestion. Questions about addressing schemes and chained/concatenated streams.

2007-09-20T20:50:18Z

Silvia's message header id field suggestion. Questions about addressing schemes and chained/concatenated streams.

← Older revision		Revision as of 20:50, 20 September 2007
Line 50:		Line 50:
	CMML handling. If not hijacking CMML it might be worth having a flag		CMML handling. If not hijacking CMML it might be worth having a flag
	indicating whether the stream is continuous or secondary header only.		indicating whether the stream is continuous or secondary header only.

			==ID==
			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?

	==Test Files==		==Test Files==

Imalone: /* Test Files */ now serving as audio/ogg

2007-09-20T20:06:10Z

Test Files: now serving as audio/ogg

← Older revision		Revision as of 20:06, 20 September 2007
Line 54:		Line 54:
	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—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—if you like the music get the originals. Please notice that filenames are mixed case

Imalone: /* Test Files */

2007-09-20T19:42:20Z

Test Files

← Older revision		Revision as of 19:42, 20 September 2007
Line 54:		Line 54:
	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'.		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.'''

	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		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

Imalone: /* Test Files */

2007-09-20T19:31:16Z

Test Files

Imalone: /* Granulepos mapping */

2007-09-20T19:22:21Z

Granulepos mapping

← Older revision		Revision as of 19:22, 20 September 2007
Line 43:		Line 43:
	all be zero. Time-based data, like a slideshow or 'currently playing' for radio streams, should be muxed		all be zero. Time-based data, like a slideshow or 'currently playing' for radio streams, should be muxed
	throughout the stream.		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==		==Test Files==

← Older revision		Revision as of 19:31, 20 September 2007
Line 53:		Line 53:
	==Test Files==		==Test Files==
	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'.

	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		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
Line 58:		Line 60:

	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].		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].
	* The [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.rdf.~~ogg~~ Ogg-Vorbis-XML version]		* The [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.rdf.oga 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]		* 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 [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.multi.oga 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)		* 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.oga 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.		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.
	* The XML/RDF description as a [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).xml separate document]		* 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 [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).multi.oga repeated after every fifth Vorbis page].
	* With the XML page repeated after every fifth Vorbis page and the [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).end.~~ogg~~ stream ending on a meta data page]		* With the XML page repeated after every fifth Vorbis page and the [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).end.oga stream ending on a meta data page]