]> git.tdb.fi Git - ext/vorbisfile.git/blob - doc/03-codebook.tex
Add headers to the library component so dependencies work correctly
[ext/vorbisfile.git] / doc / 03-codebook.tex
1 % -*- mode: latex; TeX-master: "Vorbis_I_spec"; -*-
2 %!TEX root = Vorbis_I_spec.tex
3 \section{Probability Model and Codebooks} \label{vorbis:spec:codebook}
4
5 \subsection{Overview}
6
7 Unlike practically every other mainstream audio codec, Vorbis has no
8 statically configured probability model, instead packing all entropy
9 decoding configuration, VQ and Huffman, into the bitstream itself in
10 the third header, the codec setup header.  This packed configuration
11 consists of multiple 'codebooks', each containing a specific
12 Huffman-equivalent representation for decoding compressed codewords as
13 well as an optional lookup table of output vector values to which a
14 decoded Huffman value is applied as an offset, generating the final
15 decoded output corresponding to a given compressed codeword.
16
17 \subsubsection{Bitwise operation}
18 The codebook mechanism is built on top of the vorbis bitpacker. Both
19 the codebooks themselves and the codewords they decode are unrolled
20 from a packet as a series of arbitrary-width values read from the
21 stream according to \xref{vorbis:spec:bitpacking}.
22
23
24
25
26 \subsection{Packed codebook format}
27
28 For purposes of the examples below, we assume that the storage
29 system's native byte width is eight bits.  This is not universally
30 true; see \xref{vorbis:spec:bitpacking} for discussion
31 relating to non-eight-bit bytes.
32
33 \subsubsection{codebook decode}
34
35 A codebook begins with a 24 bit sync pattern, 0x564342:
36
37 \begin{Verbatim}[commandchars=\\\{\}]
38 byte 0: [ 0 1 0 0 0 0 1 0 ] (0x42)
39 byte 1: [ 0 1 0 0 0 0 1 1 ] (0x43)
40 byte 2: [ 0 1 0 1 0 1 1 0 ] (0x56)
41 \end{Verbatim}
42
43 16 bit \varname{[codebook\_dimensions]} and 24 bit \varname{[codebook\_entries]} fields:
44
45 \begin{Verbatim}[commandchars=\\\{\}]
46
47 byte 3: [ X X X X X X X X ]
48 byte 4: [ X X X X X X X X ] [codebook\_dimensions] (16 bit unsigned)
49
50 byte 5: [ X X X X X X X X ]
51 byte 6: [ X X X X X X X X ]
52 byte 7: [ X X X X X X X X ] [codebook\_entries] (24 bit unsigned)
53
54 \end{Verbatim}
55
56 Next is the \varname{[ordered]} bit flag:
57
58 \begin{Verbatim}[commandchars=\\\{\}]
59
60 byte 8: [               X ] [ordered] (1 bit)
61
62 \end{Verbatim}
63
64 Each entry, numbering a
65 total of \varname{[codebook\_entries]}, is assigned a codeword length.
66 We now read the list of codeword lengths and store these lengths in
67 the array \varname{[codebook\_codeword\_lengths]}. Decode of lengths is
68 according to whether the \varname{[ordered]} flag is set or unset.
69
70 \begin{itemize}
71 \item
72   If the \varname{[ordered]} flag is unset, the codeword list is not
73   length ordered and the decoder needs to read each codeword length
74   one-by-one.
75
76   The decoder first reads one additional bit flag, the
77   \varname{[sparse]} flag.  This flag determines whether or not the
78   codebook contains unused entries that are not to be included in the
79   codeword decode tree:
80
81 \begin{Verbatim}[commandchars=\\\{\}]
82 byte 8: [             X 1 ] [sparse] flag (1 bit)
83 \end{Verbatim}
84
85   The decoder now performs for each of the \varname{[codebook\_entries]}
86   codebook entries:
87
88 \begin{Verbatim}[commandchars=\\\{\}]
89
90   1) if([sparse] is set) \{
91
92          2) [flag] = read one bit;
93          3) if([flag] is set) \{
94
95               4) [length] = read a five bit unsigned integer;
96               5) codeword length for this entry is [length]+1;
97
98             \} else \{
99
100               6) this entry is unused.  mark it as such.
101
102             \}
103
104      \} else the sparse flag is not set \{
105
106         7) [length] = read a five bit unsigned integer;
107         8) the codeword length for this entry is [length]+1;
108
109      \}
110
111 \end{Verbatim}
112
113 \item
114   If the \varname{[ordered]} flag is set, the codeword list for this
115   codebook is encoded in ascending length order.  Rather than reading
116   a length for every codeword, the encoder reads the number of
117   codewords per length.  That is, beginning at entry zero:
118
119 \begin{Verbatim}[commandchars=\\\{\}]
120   1) [current\_entry] = 0;
121   2) [current\_length] = read a five bit unsigned integer and add 1;
122   3) [number] = read \link{vorbis:spec:ilog}{ilog}([codebook\_entries] - [current\_entry]) bits as an unsigned integer
123   4) set the entries [current\_entry] through [current\_entry]+[number]-1, inclusive,
124     of the [codebook\_codeword\_lengths] array to [current\_length]
125   5) set [current\_entry] to [number] + [current\_entry]
126   6) increment [current\_length] by 1
127   7) if [current\_entry] is greater than [codebook\_entries] ERROR CONDITION;
128     the decoder will not be able to read this stream.
129   8) if [current\_entry] is less than [codebook\_entries], repeat process starting at 3)
130   9) done.
131 \end{Verbatim}
132
133 \end{itemize}
134
135 After all codeword lengths have been decoded, the decoder reads the
136 vector lookup table.  Vorbis I supports three lookup types:
137 \begin{enumerate}
138 \item
139 No lookup
140 \item
141 Implicitly populated value mapping (lattice VQ)
142 \item
143 Explicitly populated value mapping (tessellated or 'foam'
144 VQ)
145 \end{enumerate}
146
147
148 The lookup table type is read as a four bit unsigned integer:
149 \begin{Verbatim}[commandchars=\\\{\}]
150   1) [codebook\_lookup\_type] = read four bits as an unsigned integer
151 \end{Verbatim}
152
153 Codebook decode precedes according to \varname{[codebook\_lookup\_type]}:
154 \begin{itemize}
155 \item
156 Lookup type zero indicates no lookup to be read.  Proceed past
157 lookup decode.
158 \item
159 Lookup types one and two are similar, differing only in the
160 number of lookup values to be read.  Lookup type one reads a list of
161 values that are permuted in a set pattern to build a list of vectors,
162 each vector of order \varname{[codebook\_dimensions]} scalars.  Lookup
163 type two builds the same vector list, but reads each scalar for each
164 vector explicitly, rather than building vectors from a smaller list of
165 possible scalar values.  Lookup decode proceeds as follows:
166
167 \begin{Verbatim}[commandchars=\\\{\}]
168   1) [codebook\_minimum\_value] = \link{vorbis:spec:float32:unpack}{float32\_unpack}( read 32 bits as an unsigned integer)
169   2) [codebook\_delta\_value] = \link{vorbis:spec:float32:unpack}{float32\_unpack}( read 32 bits as an unsigned integer)
170   3) [codebook\_value\_bits] = read 4 bits as an unsigned integer and add 1
171   4) [codebook\_sequence\_p] = read 1 bit as a boolean flag
172
173   if ( [codebook\_lookup\_type] is 1 ) \{
174
175      5) [codebook\_lookup\_values] = \link{vorbis:spec:lookup1:values}{lookup1\_values}(\varname{[codebook\_entries]}, \varname{[codebook\_dimensions]} )
176
177   \} else \{
178
179      6) [codebook\_lookup\_values] = \varname{[codebook\_entries]} * \varname{[codebook\_dimensions]}
180
181   \}
182
183   7) read a total of [codebook\_lookup\_values] unsigned integers of [codebook\_value\_bits] each;
184      store these in order in the array [codebook\_multiplicands]
185 \end{Verbatim}
186 \item
187 A \varname{[codebook\_lookup\_type]} of greater than two is reserved
188 and indicates a stream that is not decodable by the specification in this
189 document.
190
191 \end{itemize}
192
193
194 An 'end of packet' during any read operation in the above steps is
195 considered an error condition rendering the stream undecodable.
196
197 \paragraph{Huffman decision tree representation}
198
199 The \varname{[codebook\_codeword\_lengths]} array and
200 \varname{[codebook\_entries]} value uniquely define the Huffman decision
201 tree used for entropy decoding.
202
203 Briefly, each used codebook entry (recall that length-unordered
204 codebooks support unused codeword entries) is assigned, in order, the
205 lowest valued unused binary Huffman codeword possible.  Assume the
206 following codeword length list:
207
208 \begin{Verbatim}[commandchars=\\\{\}]
209 entry 0: length 2
210 entry 1: length 4
211 entry 2: length 4
212 entry 3: length 4
213 entry 4: length 4
214 entry 5: length 2
215 entry 6: length 3
216 entry 7: length 3
217 \end{Verbatim}
218
219 Assigning codewords in order (lowest possible value of the appropriate
220 length to highest) results in the following codeword list:
221
222 \begin{Verbatim}[commandchars=\\\{\}]
223 entry 0: length 2 codeword 00
224 entry 1: length 4 codeword 0100
225 entry 2: length 4 codeword 0101
226 entry 3: length 4 codeword 0110
227 entry 4: length 4 codeword 0111
228 entry 5: length 2 codeword 10
229 entry 6: length 3 codeword 110
230 entry 7: length 3 codeword 111
231 \end{Verbatim}
232
233
234 \begin{note}
235 Unlike most binary numerical values in this document, we
236 intend the above codewords to be read and used bit by bit from left to
237 right, thus the codeword '001' is the bit string 'zero, zero, one'.
238 When determining 'lowest possible value' in the assignment definition
239 above, the leftmost bit is the MSb.
240 \end{note}
241
242 It is clear that the codeword length list represents a Huffman
243 decision tree with the entry numbers equivalent to the leaves numbered
244 left-to-right:
245
246 \begin{center}
247 \includegraphics[width=10cm]{hufftree}
248 \captionof{figure}{huffman tree illustration}
249 \end{center}
250
251
252 As we assign codewords in order, we see that each choice constructs a
253 new leaf in the leftmost possible position.
254
255 Note that it's possible to underspecify or overspecify a Huffman tree
256 via the length list.  In the above example, if codeword seven were
257 eliminated, it's clear that the tree is unfinished:
258
259 \begin{center}
260 \includegraphics[width=10cm]{hufftree-under}
261 \captionof{figure}{underspecified huffman tree illustration}
262 \end{center}
263
264
265 Similarly, in the original codebook, it's clear that the tree is fully
266 populated and a ninth codeword is impossible.  Both underspecified and
267 overspecified trees are an error condition rendering the stream
268 undecodable.
269
270 Codebook entries marked 'unused' are simply skipped in the assigning
271 process.  They have no codeword and do not appear in the decision
272 tree, thus it's impossible for any bit pattern read from the stream to
273 decode to that entry number.
274
275 \paragraph{Errata 20150226: Single entry codebooks}
276
277 A 'single-entry codebook' is a codebook with one active codeword
278 entry. A single-entry codebook may be either a fully populated
279 codebook with only one declared entry, or a sparse codebook with only
280 one entry marked used. The Vorbis I spec provides no means to specify
281 a codeword length of zero, and as a result, a single-entry codebook is
282 inherently malformed because it is underpopulated.  The original
283 specification did not address directly the matter of single-entry
284 codebooks; they were implicitly illegal as it was not possible to
285 write such a codebook with a valid tree structure.
286
287 In r14811 of the libvorbis reference implementation, Xiph added an
288 additional check to the codebook implementation to reject
289 underpopulated Huffman trees. This change led to the discovery of
290 single-entry books used 'in the wild' when the new, stricter checks
291 rejected a number of apparently working streams.
292
293 In order to minimize breakage of deployed (if technically erroneous)
294 streams, r16073 of the reference implementation explicitly
295 special-cased single-entry codebooks to tolerate the single-entry
296 case.  Commit r16073 also added the following to the specification:
297
298 \blockquote{\sout{Take special care that a codebook with a single used
299     entry is handled properly; it consists of a single codework of
300     zero bits and â€™reading’ a value out of such a codebook always
301     returns the single used value and sinks zero bits.
302 }} 
303
304 The intent was to clarify the spec and codify current practice.
305 However, this addition is erroneously at odds with the intent of preserving
306 usability of existing streams using single-entry codebooks, disagrees
307 with the code changes that reinstated decoding, and does not address how
308 single-entry codebooks should be encoded.
309
310 As such, the above addition made in r16037 is struck from the
311 specification and replaced by the following:
312
313 \blockquote{It is possible to declare a Vorbis codebook containing a
314   single codework entry.  A single-entry codebook may be either a
315   fully populated codebook with \varname{[codebook\_entries]} set to
316   1, or a sparse codebook marking only one entry used.  Note that it
317   is not possible to also encode a \varname{[codeword\_length]} of
318   zero for the single used codeword, as the unsigned value written to
319   the stream is \varname{[codeword\_length]-1}.  Instead, encoder
320   implementations should indicate a \varname{[codeword\_length]} of 1
321   and 'write' the codeword to a stream during audio encoding by
322   writing a single zero bit.
323
324   Decoder implementations shall reject a codebook if it contains only
325   one used entry and the encoded \varname{[codeword\_length]} of that
326   entry is not 1.  'Reading' a value from single-entry codebook always
327   returns the single used codeword value and sinks one bit.  Decoders
328   should tolerate that the bit read from the stream be '1' instead of
329   '0'; both values shall return the single used codeword.}
330
331 \paragraph{VQ lookup table vector representation}
332
333 Unpacking the VQ lookup table vectors relies on the following values:
334 \begin{programlisting}
335 the [codebook\_multiplicands] array
336 [codebook\_minimum\_value]
337 [codebook\_delta\_value]
338 [codebook\_sequence\_p]
339 [codebook\_lookup\_type]
340 [codebook\_entries]
341 [codebook\_dimensions]
342 [codebook\_lookup\_values]
343 \end{programlisting}
344
345 \bigskip
346
347 Decoding (unpacking) a specific vector in the vector lookup table
348 proceeds according to \varname{[codebook\_lookup\_type]}.  The unpacked
349 vector values are what a codebook would return during audio packet
350 decode in a VQ context.
351
352 \paragraph{Vector value decode: Lookup type 1}
353
354 Lookup type one specifies a lattice VQ lookup table built
355 algorithmically from a list of scalar values.  Calculate (unpack) the
356 final values of a codebook entry vector from the entries in
357 \varname{[codebook\_multiplicands]} as follows (\varname{[value\_vector]}
358 is the output vector representing the vector of values for entry number
359 \varname{[lookup\_offset]} in this codebook):
360
361 \begin{Verbatim}[commandchars=\\\{\}]
362   1) [last] = 0;
363   2) [index\_divisor] = 1;
364   3) iterate [i] over the range 0 ... [codebook\_dimensions]-1 (once for each scalar value in the value vector) \{
365
366        4) [multiplicand\_offset] = ( [lookup\_offset] divided by [index\_divisor] using integer
367           division ) integer modulo [codebook\_lookup\_values]
368
369        5) vector [value\_vector] element [i] =
370             ( [codebook\_multiplicands] array element number [multiplicand\_offset] ) *
371             [codebook\_delta\_value] + [codebook\_minimum\_value] + [last];
372
373        6) if ( [codebook\_sequence\_p] is set ) then set [last] = vector [value\_vector] element [i]
374
375        7) [index\_divisor] = [index\_divisor] * [codebook\_lookup\_values]
376
377      \}
378
379   8) vector calculation completed.
380 \end{Verbatim}
381
382
383
384 \paragraph{Vector value decode: Lookup type 2}
385
386 Lookup type two specifies a VQ lookup table in which each scalar in
387 each vector is explicitly set by the \varname{[codebook\_multiplicands]}
388 array in a one-to-one mapping.  Calculate [unpack] the
389 final values of a codebook entry vector from the entries in
390 \varname{[codebook\_multiplicands]} as follows (\varname{[value\_vector]}
391 is the output vector representing the vector of values for entry number
392 \varname{[lookup\_offset]} in this codebook):
393
394 \begin{Verbatim}[commandchars=\\\{\}]
395   1) [last] = 0;
396   2) [multiplicand\_offset] = [lookup\_offset] * [codebook\_dimensions]
397   3) iterate [i] over the range 0 ... [codebook\_dimensions]-1 (once for each scalar value in the value vector) \{
398
399        4) vector [value\_vector] element [i] =
400             ( [codebook\_multiplicands] array element number [multiplicand\_offset] ) *
401             [codebook\_delta\_value] + [codebook\_minimum\_value] + [last];
402
403        5) if ( [codebook\_sequence\_p] is set ) then set [last] = vector [value\_vector] element [i]
404
405        6) increment [multiplicand\_offset]
406
407      \}
408
409   7) vector calculation completed.
410 \end{Verbatim}
411
412
413
414
415
416
417
418
419
420 \subsection{Use of the codebook abstraction}
421
422 The decoder uses the codebook abstraction much as it does the
423 bit-unpacking convention; a specific codebook reads a
424 codeword from the bitstream, decoding it into an entry number, and then
425 returns that entry number to the decoder (when used in a scalar
426 entropy coding context), or uses that entry number as an offset into
427 the VQ lookup table, returning a vector of values (when used in a context
428 desiring a VQ value). Scalar or VQ context is always explicit; any call
429 to the codebook mechanism requests either a scalar entry number or a
430 lookup vector.
431
432 Note that VQ lookup type zero indicates that there is no lookup table;
433 requesting decode using a codebook of lookup type 0 in any context
434 expecting a vector return value (even in a case where a vector of
435 dimension one) is forbidden.  If decoder setup or decode requests such
436 an action, that is an error condition rendering the packet
437 undecodable.
438
439 Using a codebook to read from the packet bitstream consists first of
440 reading and decoding the next codeword in the bitstream. The decoder
441 reads bits until the accumulated bits match a codeword in the
442 codebook.  This process can be though of as logically walking the
443 Huffman decode tree by reading one bit at a time from the bitstream,
444 and using the bit as a decision boolean to take the 0 branch (left in
445 the above examples) or the 1 branch (right in the above examples).
446 Walking the tree finishes when the decode process hits a leaf in the
447 decision tree; the result is the entry number corresponding to that
448 leaf.  Reading past the end of a packet propagates the 'end-of-stream'
449 condition to the decoder.
450
451 When used in a scalar context, the resulting codeword entry is the
452 desired return value.
453
454 When used in a VQ context, the codeword entry number is used as an
455 offset into the VQ lookup table.  The value returned to the decoder is
456 the vector of scalars corresponding to this offset.