[vorbis-dev] Vorbis packet #3, codebooks and their large size

[Michael Smith]

At 06:26 PM 11/9/00 -0800, you wrote:
>Hi,
>
>Am I correct in understanding that the codebooks are *not* adaptive during
>compression?  I see that Packet #3 is written to the stream in the beginning
>of the encode process with no modification.  If the codebooks are not
>adaptive, then why are codebooks included in the stream at all?  Why not
>pass the mode type (A or B or C...) instead of all the mode info and let the
>decoder load it's own mode_A/B/C... tables.  Was it done for patent reasons?
>
>The reason I ask is that vorbis becomes useless for small audio samples like
>speech because there is always that ~10K overhead for packet 3.  With
>hundreds of samples in memory (or disk), it becomes an issue.
>
>Would we be breaking any patents if we modified the encoder and decoder to
>pass just the mode type instead of the all the mode information (time_param,
>floor_param, res_param, mapping_param)?
>
>In the future (version 1.0) would the codebooks still be included in the
>vorbis stream or will they eventually be part of both the encoder and the
>decoder?
>

Some additional thoughts...

For your purposes, the first three packets (main header, comments,
codebooks) will probably always be identical (assuming you don't use the
comment header - you might, in which case things change slightly, but not
significantly), or at least one of a small set of headers (for different
sample rates, number of channels, etc.). 

What you could do is to cache the headers (after removing the ogg
encapsulation) in memory. Then, on decode, you could feed the cached
headers to the decode engine first, then the remainder of the file. Since
the encoder flushes the output stream (forcing a new page) after the
headers, this is very simple.

For on-disk storage, you could either use the full file, as normal, or just
have the headers already chopped off (making it not a complete vorbis file,
but still usable). This latter approach would only be possible if you're
sure that the headers will always be the same - it would also simplify
caching logic.

Basically, this approach means a fairly trivial amount of pre-processing
when you read the file in, and then things work as you want - essentially,
codebooks are static and unchanging. 

Michael

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