[vorbis-dev] XML Format Suggestion

[enrique at perez.tc]

Hello,

Kenneth wrote:
>But what about streaming? What if you pick up the stream after it passes the
>tags that are equivalent to the comment headers? Your approach at face value
>won't work in that case (though it would be fine for locally-stored files).

In that case, the document could either point to stream fragments, so:
<ogg>
    <author>Beethoven</author>
    <title>kreutzer violin</title>
    <oggaudio1.1fragment>0 www.classical.com/kreutzer0</oggaudio1.1fragment>
    <oggaudio1.1fragment>1 www.classical.com/kreutzer1</oggaudio1.1fragment>
...
    <oggaudio1.1fragment>99 www.classical.com/kreutzer43</oggaudio1.1fragment>
</ogg>

or if the stream fragments are in sequence on a site:
<ogg>
    <author>Beethoven</author>
    <title>kreutzer violin</title>
    <oggaudio1.1fragments>100 www.classical.com/kreutzer</oggaudio1.1fragment4>
</ogg>

in either of the above cases, the www.classical.com site just has a lot of
static binary information and doesn't need a special streaming web server,
although the client still has to be more complicated than a basic player.

Alternately, the song could be entirely in the document, the player could start
playing once it has enough of the document that it can probably get all of the
document by the time the song stops playing. Or the streaming server can have
the header information in each page it sends.

On a related note, if for example when streaming stereo audio and the right
channel fragment arrived in time; but, the left one didn't, does the player try
to guess the left channel on the basic of the right channel?

As far as embedding binary data in an XML format is concerned, one option is to
make fake XML that looks like XML; but, can have null character, '<' and '>' in
it. These would be ignored by the ogg player because from reading the beginning
of the ogg binary information it knows when the text will begin, whereupon it
release reading of the stream to the parent XML reader.

To have real XML, the binary has to be converted in a format that doesn't have
reserved bytes. When doing this, the file is larger by a factor of at least:
log( 256 ) / log( allowable bytes )
which can be viewed as percent larger:
log( 256 ) / log( allowable bytes ) * 100% - 100%

so for 64 allowable bytes:
log( 256 ) / log( 64 ) * 100 % - 100% = 33.33% larger
for 128 allowable bytes:
log( 256 ) / log( 128 ) * 100 % - 100% = 14.29% larger
for 253 allowable bytes; all but null, '<', '>':
log( 256 ) / log( 253 ) * 100 % - 100% = 0.21% larger
for 254 allowable bytes; all but null, '<':
log( 256 ) / log( 254 ) * 100 % - 100% = 0.14% larger

in the case of a number of bytes close to 256, to reduce the decoding / encoding
time a signal byte would indicate that a signal or reserved byte is coming and
pack that information into the byte after the first signal, the file would
actually be larger by a slightly larger factor:
reserved = 256 - allowable bytes
( reserved + 1 ) * log ( reserved + 1 ) / log( 256 ) * 100%
for 253 allowable bytes:
reserved = 256 - 253 = 3
( 3 + 1 ) * log ( 3 + 1 ) / log( 256 ) * 100% = 0.39%
for 254 allowable bytes:
reserved = 256 - 254 = 2
( 2 + 1 ) * log ( 2 + 1 ) / log( 256 ) * 100% = 0.23%

which might still be worth it to make files easy to transmit or embed in
documents.

Cheers,
Enrique


-- 
Get your firstname at lastname email for FREE at http://NamePlanet.com/?su

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/