[Vorbis-dev] Doubts in codebook decoding

[xiphmont at xiph.org]

Hello Sanjay,


> I am writing my own version of the decoder using the documentation
> vorbis_I_spec.pdf from xiph.org . However I am facing certain hurdles in
> floor curve decoding during audio packet decode. In the spec it says that
>
> [cval] = read from packet using codebook number [so and so] in scalar
> context.(page no 43). Now please tell me the following:
>
> 1. Vorbis uses an LSB bit packer. But to decode bit-by-bit from the
> bitstream using the huffman decode tree we need the MSB of the codeword
> first. How is this issue overcome in the reference implementation? I was not
> able to understand what was going on from the reference implementation.

When reading bit-by-bit, there is no MSb/LSb, just 'first bit' and
'last bit'.  The Huffman tree is traversed from 'first bit' to last
bit'.  This is a conceptual layer above the bitpacker; all you need to
know is what order the bits come out, which happens to be LSb-first.

> 2. Currently, to keep track of unused entries and to reduce memory usage we
> have adopted the bitpacking scheme of vorbis. For example:
>
> ...00010110 implies that entry numbers 1,2 and 4 are being used whereas the
> others are not.
> entry 1: codeword 0
> entry 2: codeword 1
> entry 4: codeword 2 and so on ..
>
> This is done during setup. Later, during audio packet decode we are using
> this information during scalar context reading from codebook. So while
> reading from the audio packet and walking the huffman tree, if we encounter
> codeword 0, then the output of the scalar context read is 0x01.
> codeword 0 => output 0x01;
> codeword 2 => output 0x04  .. etc
>
> Is this right?

The terminology is slightly confusing (the difference between a
codeword of 2 and codeword number 2), but if you mean codeword number,
then yes, this is correct.  You might want to send little code or
ascii art to make sure I really do see what you're doing but I think
you've got it.

Monty

(BTW, 'doubts' is not-quite-correct usage; it implies something is
wrong with the specification, not that you're uncertain of
understanding.  Unless you are in fact asking if there is something
wrong with the spec.)