[vorbis-dev] Monty on holiday

[Kenneth C. Arnold]

On Tue, Jun 06, 2000 at 03:07:29PM -0400, Gregory Maxwell wrote:
> The codebooks are packed at the begining of the ogg file, and could differ
> for differnt songs.

[...]

> This is what the codebook is trained against and encodes. This allows you
> to keep the codebook size small but still accuratly represent the data.
> 
> 
> The residue codebook is a bit differnt. It uses a creative 
> Amplitude&Entropy metric to segment the residue into 64 entry groups which
> are encoded by differnt books depending on their amplitude and entropy.

So the codebooks are dynamically tuned to the data? Can't be! The example
encoder feeds the library as a stream, offering no way to analyze the entire
datastream before spewing out a codebook. Thus is it possible to really
optimize the codebook? If anyone has any suggestions, I can implement things
in Vorbize (which based on the example code) and you can play around with
command line parameters and all that. Of course libvorbis's internals are
a couple miles above my head... Encoding from a file would be no problem
wrt buffering the data (the disk _is_ a buffer), but for encoding streams
of unknown length, the buffer cannot grow indefinately, so the encoder would
have to be given some point to flush the buffers (which again can be played
with using Vorbize as a test base, specifically command line parameters).
It's like most modern lossless data compression -- it has to be in blocks,
when optimal compression could be better achieved if the file is looked at
all at once -- for example, if I include the same source file 100 times in
a directory along with other stuff, and compress a tar of the directory,
gzip and bzip2 will not see all the copies if the other stuff files up its
blocks, but the optimal compressor should be able to squeeze all copies
into just the compressed size of one copy. (okay that was off on a large
tangent) Actually there is some thought in that -- Vorbis needs variable
blocksize encodings -- not for compressed space, but for sound quality.

Kenneth

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