[vorbis-dev] Carrying non-audio data in an Ogg/Vorbis I stream

[Alejandro G. Belluscio]

Hello Svante,

Monday, October 28, 2002, 4:46:28 PM, you wrote:
SS> I would like to "piggy-back" other data in an Ogg/Vorbis I physical stream
SS> (i.e. file) in a manner that does not conflict with specifications and
SS> existing decoders/players/editors etc.
If you read the OGG framing:
http://www.xiph.org/ogg/vorbis/doc/oggstream.html
http://www.xiph.org/ogg/vorbis/doc/framing.html
You'll learn that Ogg is the octet stream framing spec and vorbis an
audio compression codec. Basically, in Ogg you put a series of packets
that contain any stream. And you can multiplex this streams. The only
constraint is that the ogg headers of each stream must be consecutive
and no new stream can begin until all streams have ended. So when you
concatenate any number of valid ogg files you get another valid ogg
file (which is breakable). So what you want is to define a different
ogg stream, a non vorbis stream, and multiplexit. If it's very little
data you could get awway with one or two pages, which may fit in just
two ogg pages.
Or you could actually make an ogg framed (whatever your data model is
named) and concatenate it _before_ the ogg vorbis. I'm not sure how
players would react to this, but may be usefull as a validating test.
The Theora project is working specifically on this infrastructure.You
should join their list.

SS> As far as I can see, I have some possible choices:

SS> 1 - Chaining a logical bistream at the end. If this is the way to
SS> go, two questions arise to begin with:
You could but is not the best alternative.
SS> q1a - How to identify this stream in a future-proof way? Just
SS> invent a new header, beginning with 'm' 'y' 'h' 'e' 'a' 'd' 'e'
SS> 'r' ?
Using a different ogg header. You should actually contact the Theo
Project.
SS> q1b - I have not found any specifications on how a decoder should
SS> handle this - obviously I want a silent ignore, not an error
SS> message or even worse, a failure to decode. Is this defined
SS> somewhere?
If it has a non vorbis header, it should be ignored by a vorbis player
(by specification).
SS> 2 - Inserting non-audio packets in the actual stream. This
SS> situation is defined to be decoded as 'a non-audio packet when
SS> audio is expected indicates stream corruption or a non-compliant
SS> stream. The decoder must ignore the packet and not attempt
SS> decoding it to audio.'. The second part of this is ok for my
SS> purpose, but I don't like the sound of the first part 'indicates
SS> stream corruption' etc. An overly ambitiuos decoder might flag
SS> this as an error for example.
No, niet, nicht, la, nunca.
SS> 3 - Another choice, which for various reasons feel less
SS> satisfying, is to encode it as comments. The problem with this is
SS> first of all that it may be attepmpted to be shown by
SS> decoders/players/editors, and second of all that the data in
SS> question may be *large* (i.e. significantly larger than the actual
SS> audio) - and it is unfortunate to have it at the front...
It's not the intended purpose of that field.
SS> 4 - Can I possibly just concatenate a completely separate Ogg
SS> stream at the end of the first one? This seems to violate the
SS> constraints of an Ogg/Vorbis I stream though.
No. Don't confuse vorbis and ogg. It may be a kind of solution, but
then if I concatenate variousvorbis files (like the tracks of a CD) it
may breack some stupid players. And if some of those files have your
data and some don't, you get a not very clear situation.

Regards,
Alejandro Belluscio

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.