annotate src/libvorbis-1.3.3/doc/03-codebook.tex @ 1:05aa0afa9217

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