[vorbis-dev] Floor codebooks vs. Residue codebooks

Monty xiphmont at xiph.org
Mon Nov 20 01:29:30 PST 2000



> Why are there only 2 codebooks for floors and many more for residue values?

Residues account for the vast majority of the space taken up in a
packet, so I pay more attention to encoding them efficiently.  The
floors need only be precise, not necessarily optimally entropy
encoded.  Also, floor probabilities tend not to vary as greatly from
encoding mode to encoding mode as do residue probabilities.

> What makes the encoding of floor values fundamentally different from
> encoding residue values?

floor values are all interrelated.  Change one value in the floor, and
it affects the entire floor.  Changes in the residue are entirely
localized.  However, there's alot of residue and only a little floor,
and required residue resolution can vary greatly.

> I have a basic understanding of VQ, and looking at the floor decode
> function, it all makes sense
> 	1) Read the codebook index from the stream
> 	2) Do a straight lookup into the codebook and extract the vector
> 
> Why is the encoding and decoding of residue values so much more complicated?

Partly for arbitrary reasons and flexibility that isn't currently
actually used.  I'm trying to plan ahead.

In residue backend zero:

First, the residue is partitioned into n equally sized blocks.  These
patitions are 'classified'; that is, each block is allowed to use any
of the codebooks available in the bitstream (the encoder decides
this).  For each partition, the codebook choice is noted.  Partition
choices are grouped together and encoded (losslessly) as 'partition
words'.

The next step is what loses most people.

Each partition consists of n values.  The codebook used to encode the
partition has dimension m, where m is an integer factor of n; let's
say n is 32 and m is 4.  The first residue vector consists of values
0,8,16 and 24 from that partiton.  The second vector is values
1,9,17,25, and so on.

Note that the actual encoding sequence interleaves partition words and
the residue vectors from the partitions represented by that partition
word.  It is also the case that this is for residue mapping zero; I
intend to make an uninterleaved residue version as mapping number 1 in
beta 4 (why?  So that if we're using nonuniform or adaptive
quantization, noise is more tightly localized).

Monty

--- >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.



More information about the Vorbis-dev mailing list