[vorbis-dev] Ogg Vorbis Framing

John Dalton johnd at southern-poro.com
Tue Aug 15 07:55:51 PDT 2000



Hi all,

Here are some thoughts on Vorbis framing, which may make it easier to
stream Vorbis in real time.  The suggested changes also move more audio data
closer to the beginning of each page.  A note in the Vorbis framing spec suggests
a simple 'bandwidth limited' mode whereby important information is placed at the
front of each page and the end of each page is discarded.  When operating
in 'bandwidth limited' mode, packets modified in this way could offer slightly
better audio quality.

This message is based on a message I sent to 'Monty' on 29/7.  He didn't
offer any comments, so I thought I would run it by this mailing list.  Does this
suggestion make sense?

POSITIONING OF LACING VALUES

The format for a Vorbis page is something like:

header,
lacing values,
data.

When building this in hardware, it is necessary to buffer all the lacing values, then
identify each data segment.  It would be easier if each lacing value appeared at the
beginning of the relevant segment, avoiding the need for buffering. ie.:

header
lacing value 0
data segment 0
lacing value 1
data segment 1
...
lacing value n
data segment n

Was there a specific reason for having the lacing values collected at the front?  Can you think of any
disadvantages to interleaving lacing values with data, and placing the lacing value for
a segment at the beginning of that segment? 

In the case of bandwidth limited transmission, where important data is at the front of a page
and pages are truncated, distributed lacing values would make better use of the bits
received, as unused lacing values would not be transmitted.

CRC POSITIONING

It is also inconvenient (from an ASIC view) having the CRC at the front of the page, as
it is necessary to buffer the entire page during encoding, then insert the CRC
at the start of the packet.  Could the CRC be moved to the rear of the packet?
In the case of bandwidth limited transmission, the CRC would be lost, but it is useless
in this case anyway. When a complete packet has not been received, it is invalid
to talk about doing a CRC calculation, as the CRC will always be wrong.

The background to this is an attempt to sketch out an Ogg Vorbis codec ASIC.
I'm not sure how useful a Vorbis codec ASIC would be (encoding a track in seconds?
encoding lots of channels in real time?) but it is an interesting exercise.  If nothing else,
it forces one to think very carefully about the algorithm, highlighting possible improvements.

Is anyone else out there looking at a Vorbis ASIC?  I guess a response to this particular
question really belongs in the 'user mailing list'.

Regards
John Dalton

john.dalton at bigfoot.com
Sydney, AU

References:
Vorbis framing spec: http://www.xiph.org/ogg/vorbis/doc/framing.html

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



More information about the Vorbis-dev mailing list