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