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

[Alejandro G. Belluscio]

Hello Svante,

Monday, October 28, 2002, 5:46:40 PM, you wrote:
SS> Thanks for the fast response!
Welcome.
SS> I did read it all... I might have missed something though, but I
SS> was under the impression that "Ogg/Vorbis I" specifically meant
SS> Vorbis encoded audio carried in an Ogg stream, under some very
SS> specific restrictions, the major one here being that multiplexing
SS> of the Ogg stream is not allowed - only chaining. See the
SS> "Restrictions" section of
SS> http://www.xiph.org/ogg/vorbis/doc/vorbis-ogg.html.
SS> The point of the excercise is to bring other data in there, without
SS> breaking this specification or violating these constraints.
SS> Just doing it with Ogg as such is not the issue.
Yep. We had a little misunderstandin. Now I see that you wanted to
wanted to have a 'Vorbis I audio file'. Ok. I'll have to ate most of
what I said. Sorry for the misunderstandin.

SS> I should also clarify - it's not necessarily video I want to bring
SS> in there.
Great because they are working on close captioning (subtitles) and
other data (i guess a thumbnail would be agood metadata).

>>Using a different ogg header. You should actually contact the Theo
>>Project.
SS> That was what I meant, sorry if I was unclear. I meant using a
SS> 'private' header for the chained logical bitstream. I assume you
SS> mean the 'Theora' project when you say 'Theo' - but why should I
SS> contact them?
Ok. So you want to add a new vorbis packet. You should talk to Monty.
He's active in the theora mailing list. If you wanted to add a new ogg
stream, the magin to decide whidh header is which data is being worked
inthat project. That's why I supposed you should contact them.

>>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> Could you please point it out to me? I can't find anywhere where the
SS> behavior of a player upon encountering a non-vorbis stream chained
SS> to a vorbis-stream in an Ogg formatted stream is defined.
Ups! My mistake. (See first paragraph).

>>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.
SS> I hope I'm not confusing it... I'm specifically looking at the
SS> combination of Vorbis in an Ogg stream, as defined by
SS> "Ogg Vorbis I format specification".
SS> What you seem to be saying is that behavior is not defined for
SS> players encountering concatenated Ogg streams. Is that is so - then
SS> that idea certainly goes down the drain.
Keep in mind that I was thinking from an Ogg frameset, not a 'Vorbis I
audio file' one. I was thinking about making things that people don't
expect. In fact addinf ID3 tags breaks some players. But looking at
the specification:

-A meta-headerless Ogg file encapsulates the Vorbis I packets
-The Ogg stream may be chained, i.e. contain multiple, contigous
logical streams (links).
-The Ogg stream must be unmultiplexed (only one stream, a Vorbis audio
stream, per link).

But is seems to imply that the player for 'Vorbis I audio file' should
only expect vorbis streams. If you put them at the end. Well, may be
the player only ate it after playing the music. But by putting it
between, that's not only non compilant but downright unexpected.

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.