From 7aea5751610f5623d020e82a991fc95288e1f157 Mon Sep 17 00:00:00 2001 From: Monty Date: Thu, 11 Aug 2011 16:58:36 +0000 Subject: [PATCH] Fix numbering in interrupted enumerate lists (eg, in floor0 curve computation pseudocode) Regenerate docs with updated/corrected fancvrb package svn path=/trunk/vorbis/; revision=18068 --- doc/06-floor0.tex | 2 +- doc/Vorbis_I_spec.css | 1 + doc/Vorbis_I_spec.html | 1295 ++++--- doc/Vorbis_I_spec.pdf | 9260 ++++++++++++++++++++++++---------------------- doc/Vorbis_I_spec.tex | 1 + doc/Vorbis_I_spec0x.png | Bin 987 -> 990 bytes doc/Vorbis_I_spec10x.png | Bin 2871 -> 2876 bytes doc/Vorbis_I_spec11x.png | Bin 3485 -> 3487 bytes doc/Vorbis_I_spec12x.png | Bin 2946 -> 2946 bytes doc/Vorbis_I_spec7x.png | Bin 1962 -> 1960 bytes doc/Vorbis_I_spec8x.png | Bin 2365 -> 2365 bytes 11 files changed, 5462 insertions(+), 5097 deletions(-) diff --git a/doc/06-floor0.tex b/doc/06-floor0.tex index 021c518..cad7004 100644 --- a/doc/06-floor0.tex +++ b/doc/06-floor0.tex @@ -160,7 +160,7 @@ Similarly, the below calculation synthesizes the output LSP curve \varname{[outp \end{enumerate} } else \varname{[floor0\_order]} is even { - \begin{enumerate} + \begin{enumerate}[resume] \item calculate \varname{[p]} and \varname{[q]} according to: \begin{eqnarray*} p & = & \frac{(1 - \cos\omega)}{2} \prod_{j=0}^{\frac{\mathtt{floor0\texttt{\_}order}-2}{2}} 4 (\cos([\mathtt{coefficients}]_{2j+1}) - \cos \omega)^2 \\ diff --git a/doc/Vorbis_I_spec.css b/doc/Vorbis_I_spec.css index aaad4be..2324982 100644 --- a/doc/Vorbis_I_spec.css +++ b/doc/Vorbis_I_spec.css @@ -134,5 +134,6 @@ div.abstract {width:100%;} span.footnote-mark sup.textsuperscript, span.footnote-mark a sup.textsuperscript{ font-size:80%; } .figure img.graphics {margin-left:10%;} P.fancyvrb {white-space: nowrap; margin:0em;} +dt.enumerate-enumitem{float:left; clear:left; margin-left:1em; margin-right:1em;} /* end css.sty */ diff --git a/doc/Vorbis_I_spec.html b/doc/Vorbis_I_spec.html index bb13ae7..7e5399b 100644 --- a/doc/Vorbis_I_spec.html +++ b/doc/Vorbis_I_spec.html @@ -7,7 +7,7 @@ - + @@ -21,8 +21,7 @@

Vorbis I specification

Xiph.Org Foundation
-
+class="cmr-17">Xiph.Org Foundation
August 11, 2011
@@ -51,11 +50,11 @@ href="#x1-110001.2" id="QQ2-1-11">Decoder Configuration href="#x1-120001.2.1" id="QQ2-1-13">Global Config
   1.2.2 Mode +
   1.2.3 Mapping -
   1.2.3 Mapping
   1.2.4 Floor
   1.2.5 Header decode and decode setup href="#x1-610004.2.1" id="QQ2-1-66">Common header decode
   4.2.2 Identification header +
   4.2.3 Comment header -
   4.2.3 Comment header
   4.2.4 Setup header
  4.3 Floor 1 format href="#x1-980007.2.1" id="QQ2-1-104">model
   7.2.2 header decode +
 8 Residue setup and decode -
 8 Residue setup and decode
  8.1 Overview
  8.2 Restrictions href="#x1-129000A.1.2" id="QQ2-1-141">MIME type
  A.2 Encapsulation +
 B Vorbis encapsulation in RTP -
 B Vorbis encapsulation in RTP -

1 1. Introduction and Description

-

1.1 1.1. Overview

This document provides a high level description of the Vorbis codec’s construction. A bit-by-bit specification appears beginning in Codec Setup and Packet Decode

-

1.1.1 1.1.1. Application

Vorbis is a general purpose perceptual audio CODEC intended to allow maximum encoder flexibility, thus allowing it to scale competitively over an exceptionally wide range of bitrates. At @@ -266,7 +265,7 @@ and higher sample rates (from 8kHz telephony to 192kHz digital masters) and a ra representations (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 discrete channels).

-

1.1.2 1.1.2. Classification

Vorbis I is a forward-adaptive monolithic transform CODEC based on the Modified Discrete Cosine Transform. The codec is structured to allow addition of a hybrid wavelet filterbank in @@ -276,7 +275,7 @@ localized time events.

-

1.1.3 1.1.3. Assumptions

The Vorbis CODEC design assumes a complex, psychoacoustically-aware encoder and simple, low-complexity decoder. Vorbis decode is computationally simpler than mp3, although it does @@ -307,7 +306,7 @@ href="#x1-126000A">Section A, “Embedding Vorbis into an Ogg stream”.

-

1.1.4 1.1.4. Codec Setup and Probability Model

Vorbis’ heritage is as a research CODEC and its current design reflects a desire to allow multiple decades of continuous encoder improvement before running out of room within the codec @@ -337,7 +336,7 @@ against current design trends (and also points out limitations in some existing designs, such as Windows’ ACM codec framework). However, we find that it does not fundamentally limit Vorbis’ suitable application space.

-

1.1.5 1.1.5. Format Specification

The Vorbis format is well-defined by its decode specification; any encoder that produces packets that are correctly decoded by the reference Vorbis decoder described below may be considered @@ -345,7 +344,7 @@ a proper Vorbis encoder. A decoder must faithfully and completely implement the specification defined below (except where noted) to be considered a proper Vorbis decoder.

-

1.1.6 1.1.6. Hardware Profile
@@ -355,7 +354,7 @@ embedded design. For this reason, embedded designs are allowed to deviate in lim the ‘full’ decode specification yet still be certified compliant. These optional omissions are labelled in the spec where relevant.

-

1.2 1.2. Decoder Configuration

Decoder setup consists of configuration of multiple, self-contained component abstractions that perform specific functions in the decode pipeline. Each different component instance of a specific @@ -374,13 +373,13 @@ src="components.png" alt="PIC" class="content">decoder pipeline configuration

-

1.2.1 1.2.1. Global Config

Global codec configuration consists of a few audio related fields (sample rate, channels), Vorbis version (always ’0’ in Vorbis I), bitrate hints, and the lists of component instances. All other configuration is in the context of specific components.

-

1.2.2 1.2.2. Mode
@@ -397,7 +396,7 @@ window, in Vorbis I), transform type (always type 0, the MDCT, in Vorbis I) and number. The mapping number specifies which mapping configuration instance to use for low-level packet decode and synthesis.

-

1.2.3 1.2.3. Mapping

A mapping contains a channel coupling description and a list of ’submaps’ that bundle sets of channel vectors together for grouped encoding and decoding. These submaps are @@ -421,7 +420,7 @@ uses a bass-only representation.

-

1.2.4 1.2.4. Floor

Vorbis encodes a spectral ’floor’ vector for each PCM channel. This vector is a low-resolution representation of the audio spectrum for the given channel in the current frame, generally used @@ -442,7 +441,7 @@ codebooks in the codebook component list. Entropy coding is thus provided as an abstraction, and each floor instance may choose from any and all available codebooks when coding/decoding.

-

1.2.5 1.2.5. Residue

The spectral residue is the fine structure of the audio spectrum once the floor curve has been subtracted out. In simplest terms, it is coded in the bitstream using cascaded (multi-pass) vector @@ -455,7 +454,7 @@ codebooks. -

1.2.6 1.2.6. Codebooks

Codebooks are a self-contained abstraction that perform entropy decoding and, optionally, use the entropy-decoded integer value as an offset into an index of output value vectors, returning @@ -467,10 +466,10 @@ codeword lengths are ordered or unordered, or the tree is sparse. the vector index is encoded as a single list of values of possible values that are then permuted into a list of n-dimensional rows (lattice VQ).

-

1.3 1.3. High-level Decode Process

-

1.3.1 1.3.1. Decode Setup

Before decoding can begin, a decoder must initialize using the bitstream headers matching the stream to be decoded. Vorbis uses three header packets; all are required, in-order, by @@ -501,49 +500,49 @@ class="cmbx-12">Setup Header The setup header includes extensive CODEC setup information as well as the complete VQ and Huffman codebooks needed for decode.

-

1.3.2 1.3.2. Decode Procedure

The decoding and synthesis procedure for all audio packets is fundamentally the same. -

    -
  1. decode packet type flag -
    2. -
  2. decode mode number -
    3. -
  3. decode window shape (long windows only) -
    4. -
  4. decode floor -
    5. -
  5. decode residue into residue vectors -
    6. -
  6. inverse channel coupling of residue vectors -
    7. -
  7. generate floor curve from decoded floor data -
    8. -
  8. compute dot product of floor and residue, producing audio spectrum vector -
    9. -
  9. inverse monolithic transform of audio spectrum vector, always an MDCT in Vorbis +
    + 1.
    decode packet type flag +
    + 2.
    decode mode number +
    + 3.
    decode window shape (long windows only) +
    + 4.
    decode floor +
    + 5.
    decode residue into residue vectors +
    + 6.
    inverse channel coupling of residue vectors +
    + 7.
    generate floor curve from decoded floor data +
    + 8.
    compute dot product of floor and residue, producing audio spectrum vector +
    + 9.
    inverse monolithic transform of audio spectrum vector, always an MDCT in Vorbis I -
    10. -
  10. overlap/add left-hand output of transform with right-hand output of previous frame -
    11. -
  11. store right hand-data from transform of current frame for future lapping -
    12. -
  12. if not first frame, return results of overlap/add as audio result of current frame
+
+ 10.
overlap/add left-hand output of transform with right-hand output of previous frame +
+ 11.
store right hand-data from transform of current frame for future lapping +
+ 12.
if not first frame, return results of overlap/add as audio result of current frame

Note that clever rearrangement of the synthesis arithmetic is possible; as an example, one can take advantage of symmetries in the MDCT to store the right-hand transform data of a partial MDCT for a 50% inter-frame buffer space savings, and then complete the transform later before @@ -756,10 +755,10 @@ PCM output offset is ’0’ (as no data has been returned yet). -

2 2. Bitpacking Convention

-

2.1 2.1. Overview

The Vorbis codec uses relatively unstructured raw packets containing arbitrary-width binary integer fields. Logically, these packets are a bitstream in which bits are coded one-by-one by the @@ -769,7 +768,7 @@ Most current binary storage arrangements group bits into a native word size of e bitpacking convention specifies the correct mapping of the logical packet bitstream into an actual representation in fixed-width words.

-

2.1.1 2.1.1. octets, bytes and words

In most contemporary architectures, a ’byte’ is synonymous with an ’octet’, that is, eight bits. This has not always been the case; seven, ten, eleven and sixteen bit ’bytes’ have been used. @@ -788,7 +787,7 @@ of example. -

2.1.2 2.1.2. bit order

A byte has a well-defined ’least significant’ bit (LSb), which is the only bit set when the byte is storing the two’s complement integer value +1. A byte’s ’most significant’ bit (MSb) is at the @@ -797,7 +796,7 @@ class="cmmi-12">n (n = 7 in an octet) for the MSb.

-

2.1.3 2.1.3. byte order

Words are native groupings of multiple bytes. Several byte orderings are possible in a word; the common ones are 3-2-1-0 (’big endian’ or ’most significant byte first’ in which the @@ -811,7 +810,7 @@ Logically, bytes are always coded and decoded in order from byte zero through by n.

-

2.1.4 2.1.4. coding bits into byte sequences

The Vorbis codec has need to code arbitrary bit-width integers, from zero to 32 bits wide, into packets. These integer fields are not aligned to the boundaries of the byte @@ -831,7 +830,7 @@ the next bit into the bit position 0 of that byte. Decoding follows the same pro as encoding, but by reading bits from the byte stream and reassembling them into integers.

-

2.1.5 2.1.5. signedness

The signedness of a specific number resulting from decode is to be interpreted by the decoder given decode context. That is, the three bit binary pattern ’b111’ can be taken to represent @@ -839,7 +838,7 @@ either ’seven’ as an unsigned integer, or ’-1’ as a sign encoder and decoder are responsible for knowing if fields are to be treated as signed or unsigned.

-

2.1.6 2.1.6. coding example

Code the 4 bit integer value ’12’ [b1100] into an empty bytestream. Bytestream result:

@@ -1621,7 +1620,7 @@ class="cmtt-8">  

-

2.1.7 2.1.7. decoding example

Reading from the beginning of the bytestream encoded in the above example:

@@ -1789,7 +1788,7 @@ are worth noting here: either as the unsigned value ’3’, or the signed value ’-1’. Signedness is dependent on decode context.

-

2.1.8 2.1.8. end-of-packet alignment

The typical use of bitpacking is to produce many independent byte-aligned packets which are embedded into a larger byte-aligned container structure, such as an Ogg transport bitstream. @@ -1808,7 +1807,7 @@ also return ’end-of-packet’.

-

2.1.9 2.1.9. reading zero bits

Reading a zero-bit-wide integer returns the value ’0’ and does not increment the stream cursor. Reading to the end of the packet (but not past, such that an ’end-of-packet’ condition has not @@ -1821,10 +1820,10 @@ shall also fail with ’end-of-packet’. -

3 3. Probability Model and Codebooks

-

3.1 3.1. Overview

Unlike practically every other mainstream audio codec, Vorbis has no statically configured probability model, instead packing all entropy decoding configuration, VQ and Huffman, into the @@ -1834,7 +1833,7 @@ compressed codewords as well as an optional lookup table of output vector values decoded Huffman value is applied as an offset, generating the final decoded output corresponding to a given compressed codeword.

-

3.1.1 3.1.1. Bitwise operation

The codebook mechanism is built on top of the vorbis bitpacker. Both the codebooks themselves and the codewords they decode are unrolled from a packet as a series of arbitrary-width values @@ -1842,7 +1841,7 @@ read from the stream according to Section 2, “Bitpacking Convention”.

-

3.2 3.2. Packed codebook format

For purposes of the examples below, we assume that the storage system’s native byte width is eight bits. This is not universally true; see

-

3.2.1 3.2.1. codebook decode

A codebook begins with a 24 bit sync pattern, 0x564342:

@@ -2580,19 +2579,19 @@ class="cmtt-8"> done.

After all codeword lengths have been decoded, the decoder reads the vector lookup table. Vorbis I supports three lookup types: -

    -
  1. No lookup -
    2. -
  2. Implicitly populated value mapping (lattice VQ) -
    3. -
  3. Explicitly populated value mapping (tessellated or ’foam’ VQ)
+
+ 1.
No lookup +
+ 2.
Implicitly populated value mapping (lattice VQ) +
+ 3.
Explicitly populated value mapping (tessellated or ’foam’ VQ)

The lookup table type is read as a four bit unsigned integer:

1  [codebook_dimensions] scalars. Lookup

1   an unsigned integer)
2   an unsigned integer)
3   and add 1
4   a boolean flag
5  
6   ) {
7  
8  ([codebook_entries], [codebook_dimensions] )
9  
10   else {
11  
12   [codebook_entries] * [codebook_dimensions]
13  
14    }
15  
16   each;
17   calculation completed.

-

3.3 3.3. Use of the codebook abstraction

The decoder uses the codebook abstraction much as it does the bit-unpacking convention; a specific codebook reads a codeword from the bitstream, decoding it into an entry number, and @@ -3610,10 +3609,10 @@ offset. -

4 4. Codec Setup and Packet Decode

-

4.1 4.1. Overview

This document serves as the top-level reference document for the bit-by-bit decode specification of Vorbis I. This document assumes a high-level understanding of the Vorbis decode @@ -3625,7 +3624,7 @@ href="#x1-360002">Section 2, href="#x1-360002">Bitpacking Convention” covers reading and writing bit fields from and to bitstream packets.

-

4.2 4.2. Header decode and decode setup

A Vorbis bitstream begins with three header packets. The header packets are, in order, the identification header, the comments header, and the setup header. All are required for decode @@ -3633,7 +3632,7 @@ compliance. An end-of-packet condition during decoding the first or third header the stream undecodable. End-of-packet decoding the comment header is a non-fatal error condition.

-

4.2.1 4.2.1. Common header decode

Each header packet begins with the same header fields.

@@ -3678,7 +3677,7 @@ header type 3 and the setup header type 5 (these types are all odd as a packet w single bit of ’0’ is an audio packet). The packets must occur in the order of identification, comment, setup.

-

4.2.2 4.2.2. Identification header

The identification header is a short header of only a few fields used to declare the stream definitively as Vorbis, and provide a few externally relevant pieces of information about the audio @@ -3839,14 +3838,14 @@ zero.

  • None set indicates the encoder does not care to speculate.

    • -

    4.2.3 4.2.3. Comment header

    Comment header decode and data specification is covered in Section 5, “comment field and header specification”.

    -

    4.2.4 4.2.4. Setup header

    Vorbis codec setup is configurable to an extreme degree:

    Codebooks -
      -
    1. + 1.
      [vorbis_codebook_count] = read eight bits as unsigned integer and add one -
      2. -
    2. Decode
      + 2.
      Decode [vorbis_codebook_count] codebooks in order as defined in Section 3, “Probability Model and Codebooks”. Save each configuration, in order, in an array of codebook configurations [vorbis_codebook_configurations].
    +class="cmtt-12">[vorbis_codebook_configurations].

    Time domain transforms These hooks are placeholders in Vorbis I. Nevertheless, the configuration placeholder values must be read to maintain bitstream sync. -

    -

      -

    1. +

      + 1.
      [vorbis_time_count] = read 6 bits as unsigned integer and add one -
      2. -
    2. read
      + 2.
      read [vorbis_time_count] 16 bit values; each value should be zero. If any value is - nonzero, this is an error condition and the stream is undecodable.
    + nonzero, this is an error condition and the stream is undecodable.

    Floors Vorbis uses two floor types; header decode is handed to the decode abstraction of the appropriate type. -

    -

      -

    1. +

      + 1.
      [vorbis_floor_count] = read 6 bits as unsigned integer and add one -
      2. -
    2. For each
      + 2.
      For each [i] of [vorbis_floor_count] floor numbers: -
        -
      1. read the floor type: vector
        + a)
        read the floor type: vector [vorbis_floor_types] element [i] = read 16 bits as unsigned integer -
        2. -
      2. If the floor type is zero, decode the floor configuration as defined in
        + b)
        If the floor type is zero, decode the floor configuration as defined in Section 6, “Floor type 0 setup and decode”; save this configuration in slot [vorbis_floor_configurations]. -
        3. -
      3. If the floor type is one, decode the floor configuration as defined in
        + c)
        If the floor type is one, decode the floor configuration as defined in Section 7, “Floor type 1 setup and decode”; save this configuration in slot [i] of the floor configuration array [vorbis_floor_configurations]. -
        4. -
      4. If the the floor type is greater than one, this stream is undecodable; ERROR - CONDITION
      -
    +
    + d)
    If the the floor type is greater than one, this stream is undecodable; ERROR + CONDITION
    +

    Residues Vorbis uses three residue types; header decode of each type is identical. -

    -

      -

    1. +

      + 1.
      [vorbis_residue_count] = read 6 bits as unsigned integer and add one -
      2. -
    2. For each of
      + 2.
      For each of [vorbis_residue_count] residue numbers: -
        -
      1. read the residue type; vector
        + a)
        read the residue type; vector [vorbis_residue_types] element [i] = read 16 bits as unsigned integer -
        2. -
      2. If the residue type is zero, one or two, decode the residue configuration as defined +
      + b)
      If the residue type is zero, one or two, decode the residue configuration as defined in Section 8, “Residue setup and decode”; save this configuration in slot [i] of the residue configuration array [vorbis_residue_configurations]. -
      3. -
    3. If the the residue type is greater than two, this stream is undecodable; ERROR - CONDITION
    - +
    + c)
    If the the residue type is greater than two, this stream is undecodable; ERROR + CONDITION
    +

    Mappings @@ -3988,44 +3987,44 @@ channel mappings. -

    -

      -

    1. +

      + 1.
      [vorbis_mapping_count] = read 6 bits as unsigned integer and add one -
      2. -
    2. For each
      + 2.
      For each [i] of [vorbis_mapping_count] mapping numbers: -
        -
      1. read the mapping type: 16 bits as unsigned integer. There’s no reason to save +
        + a)
        read the mapping type: 16 bits as unsigned integer. There’s no reason to save the mapping type in Vorbis I. -
        2. -
      2. If the mapping type is nonzero, the stream is undecodable -
        3. -
      3. If the mapping type is zero: -
          -
        1. read 1 bit as a boolean flag -
            -
          1. if set,
            + b)
            If the mapping type is nonzero, the stream is undecodable +
            + c)
            If the mapping type is zero: +
            + i.
            read 1 bit as a boolean flag +
            + A.
            if set, [vorbis_mapping_submaps] = read 4 bits as unsigned integer and add one -
            2. -
          2. if unset, [vorbis_mapping_submaps] = 1
          -
          2. -
        2. read 1 bit as a boolean flag -
            -
          1. if set, square polar channel mapping is in use: +
      + B.
      if unset, [vorbis_mapping_submaps] = 1
      +
      + ii.
      read 1 bit as a boolean flag +
      + A.
      if set, square polar channel mapping is in use:
      • [vorbis_mapping_coupling_steps] = read 8 bits as unsigned @@ -4062,124 +4061,124 @@ class="cmtt-12">[audio_channels]-1, or class="cmtt-12">[audio_channels]-1, the stream is undecodable.
      3. - -
    3. if unset, [vorbis_mapping_coupling_steps] = 0
    - -
  • read 2 bits (reserved field); if the value is nonzero, the stream is undecodable -
    • -
  • if
    + B.
    if unset, [vorbis_mapping_coupling_steps] = 0
    +
    + iii.
    read 2 bits (reserved field); if the value is nonzero, the stream is undecodable +
    + iv.
    if [vorbis_mapping_submaps] is greater than one, we read channel multiplex settings. For each [j] of [audio_channels] channels: -
      -
    1. vector
      + A.
      vector [vorbis_mapping_mux] element [j] = read 4 bits as unsigned integer -
      2. -
    2. if the value is greater than the highest numbered submap +
    + B.
    if the value is greater than the highest numbered submap ([vorbis_mapping_submaps] - 1), this in an error condition rendering - the stream undecodable
    • - -
  • for each submap +
    + v.
    for each submap [j] of [vorbis_mapping_submaps] submaps, read the floor and residue numbers for use in decoding that submap: -
      -
    1. read and discard 8 bits (the unused time configuration placeholder) -
      2. -
    2. read 8 bits as unsigned integer for the floor number; save in vector +
      + A.
      read and discard 8 bits (the unused time configuration placeholder) +
      + B.
      read 8 bits as unsigned integer for the floor number; save in vector [vorbis_mapping_submap_floor] element [j] -
      3. -
    3. verify the floor number is not greater than the highest number floor +
    + C.
    verify the floor number is not greater than the highest number floor configured for the bitstream. If it is, the bitstream is undecodable -
    • -
  • read 8 bits as unsigned integer for the residue number; save in vector +
    + D.
    read 8 bits as unsigned integer for the residue number; save in vector [vorbis_mapping_submap_residue] element [j] -
    • -
  • verify the residue number is not greater than the highest number residue - configured for the bitstream. If it is, the bitstream is undecodable
    • - -
  • save this mapping configuration in slot
    + E.
    verify the residue number is not greater than the highest number residue + configured for the bitstream. If it is, the bitstream is undecodable
    +
    + vi.
    save this mapping configuration in slot [i] of the mapping configuration array [vorbis_mapping_configurations].
    • - - +class="cmtt-12">[vorbis_mapping_configurations]. + +

    Modes -

      -
    1. + 1.
      [vorbis_mode_count] = read 6 bits as unsigned integer and add one -
      2. -
    2. For each of
      + 2.
      For each of [vorbis_mode_count] mode numbers: -
        -
      1. + a)
        [vorbis_mode_blockflag] = read 1 bit -
        2. -
      2. + b)
        [vorbis_mode_windowtype] = read 16 bits as unsigned integer -
        3. -
      3. + c)
        [vorbis_mode_transformtype] = read 16 bits as unsigned integer -
        4. -
      4. + d)
        [vorbis_mode_mapping] = read 8 bits as unsigned integer -
        5. -
      5. verify ranges; zero is the only legal value in +
      + e)
      verify ranges; zero is the only legal value in Vorbis I for [vorbis_mode_windowtype] and [vorbis_mode_transformtype]. [vorbis_mode_mapping] must not be greater than the highest number mapping in use. Any illegal values render the stream undecodable. -
      3. -
    3. save this mode configuration in slot
      + f)
      save this mode configuration in slot [i] of the mode configuration array [vorbis_mode_configurations].
    - -
  • read 1 bit as a framing flag. If unset, a framing error occurred and the stream is not - decodable.
    • +class="cmtt-12">[vorbis_mode_configurations]. +
    + 3.
    read 1 bit as a framing flag. If unset, a framing error occurred and the stream is not + decodable.

    After reading mode descriptions, setup header decode is complete.

    -

    4.3 4.3. Audio packet decode and synthesis

    Following the three header packets, all packets in a Vorbis I stream are audio. The first step of audio packet decode is to read and verify the packet type. expected indicates stream corruption or a non-compliant stream. packet and not attempt decoding it to audio.

    -

    4.3.1 4.3.1. packet type, mode and window decode
    -

    -

      -
    1. read 1 bit

      +

      + 1.
      read 1 bit [packet_type]; check that packet type is 0 (audio) -
      2. -
    2. read
      + 2.
      read ilog([vorbis_mode_count]-1) bits [mode_number] -
      3. -
    3. decode blocksize
      + 3.
      decode blocksize [n] is equal to [blocksize_0] if [vorbis_mode_blockflag] is 0, else [n] is equal to [blocksize_1]. -
      4. -
    4. perform window selection and setup; this window is used later by the inverse +
      + 4.
      perform window selection and setup; this window is used later by the inverse MDCT: -
        -
      1. if this is a long window (the
        + a)
        if this is a long window (the [vorbis_mode_blockflag] flag of this mode is set): -
          -
        1. read 1 bit for
          + i.
          read 1 bit for [previous_window_flag] -
          2. -
        2. read 1 bit for
          + ii.
          read 1 bit for [next_window_flag] -
          3. -
        3. if
          + iii.
          if [previous_window_flag] is not set, the left half of the window will be a hybrid window for lapping with a short block. See paragraph 1.3.2, href="#x1-260001.3.2">Window shape decode (long windows only)” for an illustration of overlapping dissimilar windows. Else, the left half window will have normal long shape. -
          4. -
        4. if
          + iv.
          if [next_window_flag] is not set, the right half of the window will be a hybrid window for lapping with a short block. See paragraph 1.3.2, “Window shape decode (long windows only)” for an illustration of overlapping dissimilar windows. Else, the left right window will have normal - long shape.
        -
        2. -
      2. if this is a short window, the window is always the same short-window - shape.
      -
    + long shape. +
    + b)
    if this is a short window, the window is always the same short-window + shape.
    +

    Vorbis windows all use the slope function y = sin(π2 …n− 1, but dissimilar lapping requirements can affect overall shape. Window generation proceeds as follows: -

    -

      -

    1. +

      + 1.
      [window_center] = [n] / 2 -
      2. -
    2. if (
      + 2.
      if ([vorbis_mode_blockflag] is set and [previous_window_flag] is not set) then -
        -
      1. + a)
        [left_window_start] = [n]/4 - [blocksize_0]/4 -
        2. -
      2. + b)
        [left_window_end] = [n]/4 + [blocksize_0]/4 -
        3. -
      3. + c)
        [left_n] = [blocksize_0]/2
      +class="cmtt-12">[blocksize_0]/2

      else -

        -
      1. + a)
        [left_window_start] = 0 -
        2. -
      2. + b)
        [left_window_end] = [window_center] -
        3. -
      3. + c)
        [left_n] = [n]/2
      -
      3. -
    3. if ([n]/2 +
      + 3.
      if ([vorbis_mode_blockflag] is set and [next_window_flag] is not set) then -
        -
      1. + a)
        [right_window_start] = [n]*3/4 - [blocksize_0]/4 -
        2. -
      2. + b)
        [right_window_end] = [n]*3/4 + [blocksize_0]/4 -
        3. -
      3. + c)
        [right_n] = [blocksize_0]/2
      +class="cmtt-12">[blocksize_0]/2

      else -

        -
      1. + a)
        [right_window_start] = [window_center] -
        2. -
      2. + b)
        [right_window_end] = [n] -
        3. -
      3. + c)
        [right_n] = [n]/2
      -
      4. -
    4. window from range 0 ... [n]/2 +
      + 4.
      window from range 0 ... [left_window_start]-1 inclusive is zero -
      5. -
    5. for
      + 5.
      for [i] in range [left_window_start] ... [left_window_end]-1, window([left_n] ∗π 2) ) -
      6. -
    6. window from range
      + 6.
      window from range [left_window_end] ... [right_window_start]-1 inclusive is one -
      7. -
    7. for
      + 7.
      for [i] in range [right_window_start] ... [right_window_end]-1, window( + π 2) ) -
      8. -
    8. window from range
      + 8.
      window from range [right_window_start] ... [n]-1 is zero
    +class="cmtt-12">[n]-1 is zero

    An end-of-packet condition up to this point should be considered an error that discards this packet from the stream. An end of packet condition past this point is to be considered a possible nominal occurrence. @@ -4418,7 +4417,7 @@ nominal occurrence.

    -

    4.3.2 4.3.2. floor curve decode

    From this point on, we assume out decode context is using mode number [mode_number] @@ -4432,19 +4431,19 @@ class="cmtt-12">[vorbis_mapping_configurations].

    For each floor [i] of [audio_channels] -

      -
    1. + 1.
      [submap_number] = element [i] of vector [vorbis_mapping_mux] -
      2. -
    2. + 2.
      [floor_number] = element [submap_number] of vector [vorbis_submap_floor] -
      3. -
    3. if the floor type of this floor (vector +
      + 3.
      if the floor type of this floor (vector [vorbis_floor_types] element [floor_number]) is zero then decode the floor for @@ -4452,28 +4451,28 @@ class="cmtt-12">[floor_number]) is zero then decode the floor for class="cmtt-12">[i] according to the subsubsection 6.2.2, “packet decode” -
      4. -
    4. if the type of this floor is one then decode the floor for channel
      + 4.
      if the type of this floor is one then decode the floor for channel [i] according to the paragraph 7.2.2, “packet decode” -
      5. -
    5. save the needed decoded floor information for channel for later synthesis -
      6. -
    6. if the decoded floor returned ’unused’, set vector
      + 5.
      save the needed decoded floor information for channel for later synthesis +
      + 6.
      if the decoded floor returned ’unused’, set vector [no_residue] element [i] to true, else set vector [no_residue] element [i] to false
    +class="cmtt-12">[i] to false

    An end-of-packet condition during floor decode shall result in packet decode zeroing all channel output vectors and skipping to the add/overlap output stage.

    -

    4.3.3 4.3.3. nonzero vector propagate

    A possible result of floor decode is that a specific vector is marked ’unused’ which indicates that that final output vector is all-zero values (and the floor is zero). The residue for that vector is not @@ -4486,10 +4485,10 @@ vectors.

    for each [i] from 0 ... [vorbis_mapping_coupling_steps]-1 -

    -

      -
    1. if either

      +

      + 1.
      if either [no_residue] entry for channel ([vorbis_mapping_magnitude] element [i]) or channel ([vorbis_mapping_angle] element [i]) are set to false, then both must be set to false. Note that an ’unused’ floor has no decoded floor information; it - is important that this is remembered at floor curve synthesis time.
    + is important that this is remembered at floor curve synthesis time.

    -

    4.3.4 4.3.4. residue decode

    Unlike floors, which are decoded in channel order, the residue vectors are decoded in submap order.

    for each submap [i] in order from 0 ... [vorbis_mapping_submaps]-1 -

    -

      -

    1. +

      + 1.
      [ch] = 0 -
      2. -
    2. for each channel
      + 2.
      for each channel [j] in order from 0 ... [audio_channels] - 1 -
        -
      1. if channel
        + a)
        if channel [j] in submap [i] (vector [vorbis_mapping_mux] element [j] is equal to [i]) -
          -
        1. if vector
          + i.
          if vector [no_residue] element [j] is true -
            -
          1. vector
            + A.
            vector [do_not_decode_flag] element [ch] is set
          +class="cmtt-12">[ch] is set

          else -

            -
          1. vector
            + A.
            vector [do_not_decode_flag] element [ch] is unset
          -
          2. -
        2. increment [ch]
        +class="cmtt-12">[ch] is unset
        +
      + ii.
      increment [ch]
      -
    - -
  • +
    + 3.
    [residue_number] = vector [vorbis_mapping_submap_residue] element [i] -
    • -
  • + 4.
    [residue_type] = vector [vorbis_residue_types] element [residue_number] -
    • -
  • decode
    + 5.
    decode [ch] vectors using residue [residue_number], according to type [residue_type], @@ -4571,52 +4570,52 @@ class="cmtt-12">[residue_type], class="cmtt-12">[do_not_decode_flag] to indicate which vectors in the bundle should not be decoded. Correct per-vector decode length is [n]/2. -
    • -
  • + 6.
    [ch] = 0 -
    • -
  • for each channel
    + 7.
    for each channel [j] in order from 0 ... [audio_channels] -
      -
    1. if channel
      + a)
      if channel [j] is in submap [i] (vector [vorbis_mapping_mux] element [j] is equal to [i]) -
        -
      1. residue vector for channel
        + i.
        residue vector for channel [j] is set to decoded residue vector [ch] -
        2. -
      2. increment [ch]
      -
    -
    • +
    + ii.
    increment [ch]
    + +

    -

    4.3.5 4.3.5. inverse coupling

    for each [i] from [vorbis_mapping_coupling_steps]-1 descending to 0 -

    -

      -

    1. +

      + 1.
      [magnitude_vector] = the residue vector for channel (vector [vorbis_mapping_magnitude] element [i]) -
      2. -
    2. + 2.
      [angle_vector] = the residue vector for channel (vector [vorbis_mapping_angle] @@ -4624,93 +4623,93 @@ class="cmtt-12">[vorbis_mapping_angle] element [i]) -
      3. -
    3. for each scalar value
      + 3.
      for each scalar value [M] in vector [magnitude_vector] and the corresponding scalar value [A] in vector [angle_vector]: -
        -
      1. if (
        + a)
        if ([M] is greater than zero) -
          -
        1. if (
          + i.
          if ([A] is greater than zero) -
            -
          1. + A.
            [new_M] = [M] -
            2. -
          2. + B.
            [new_A] = [M]-[A]
          +class="cmtt-12">[A]

          else -

            -
          1. + A.
            [new_A] = [M] -
            2. -
          2. + B.
            [new_M] = [M]+[A]
          -
        +class="cmtt-12">[A]
        +

      else -

        -
      1. if (
        + i.
        if ([A] is greater than zero) -
          -
        1. + A.
          [new_M] = [M] -
          2. -
        2. + B.
          [new_A] = [M]+[A]
        +class="cmtt-12">[A]

        else -

          -
        1. + A.
          [new_A] = [M] -
          2. -
        2. + B.
          [new_M] = [M]-[A]
        -
      -
      4. -
    4. set scalar value [A] + +
      + b)
      set scalar value [M] in vector [magnitude_vector] to [new_M] -
      5. -
    5. set scalar value
      + c)
      set scalar value [A] in vector [angle_vector] to [new_A]
    - +class="cmtt-12">[new_A] +

    -

    4.3.6 4.3.6. dot product

    For each channel, synthesize the floor curve from the decoded floor information, according to packet type. Note that the vector synthesis length for floor computation is

    -

    4.3.7 4.3.7. inverse MDCT

    Convert the audio spectrum vector of each channel back into time domain PCM audio via an @@ -4754,7 +4753,7 @@ available in [1]. The window function used for the MDCT is the function described earlier.

    -

    4.3.8 4.3.8. overlap_add

    Windowed MDCT output is overlapped and added with the right hand data of the previous window such that the 3/4 point of the previous window is aligned with the 1/4 point of the @@ -4783,7 +4782,7 @@ windowsize/2-1, inclusive) of the current window. encoder accounts for this priming when calculating PCM offsets; after the first frame, the proper PCM output offset is ’0’ (as no data has been returned yet).

    -

    4.3.9 4.3.9. output channel order

    Vorbis I specifies only a channel mapping type 0. In mapping type 0, channel mapping is implicitly defined as follows for standard audio applications. As of revision 16781 (20100113), the @@ -4795,7 +4794,7 @@ greater-than-eight channels remains ’left to the implementation’.

    These channel orderings refer to order within the encoded stream. It is naturally possible for a decoder to produce output with channels in any order. Any such decoder should explicitly document channel reordering behavior. -

    +

    one channel
    5 5. comment field and header specification

    -

    5.1 5.1. Overview

    The Vorbis text comment header is the second (of three) header packets that begin a Vorbis bitstream. It is meant for short text comments, not arbitrary metadata; arbitrary metadata @@ -4868,10 +4867,10 @@ eg: class="cmti-12">“I’m Still Around”, opening for Moxy Früvous, 1997.

    -

    5.2 5.2. Comment encoding

    -

    5.2.1 5.2.1. Structure

    The comment header is logically a list of eight-bit-clean vectors; the number of vectors is bounded to 2 9) done.

    -

    5.2.2 5.2.2. Content vector format

    The comment vectors are structured similarly to a UNIX environment variable. That is, comment fields consist of a field name and a corresponding value and look like: @@ -5087,7 +5086,7 @@ class="cmbx-12">Field names Below is a proposed, minimal list of standard field names with a description of intended use. No single or group of field names is mandatory; a comment header may contain one, all or none of the names in this list. -

    +

    TITLE
     Stitt

    -

    5.2.3 5.2.3. Encoding

    The comment header comprises the entirety of the second bitstream header packet. Unlike the first bitstream header packet, it is not generally the only packet on the second page and may not @@ -5223,34 +5222,34 @@ bitstream even if it is effectively empty.

    The comment header is encoded as follows (as per Ogg’s standard bitstream mapping which renders least-significant-bit of the word to be coded into the least significant available bit of the current bitstream octet first): -

    -

      -
    1. Vendor string length (32 bit unsigned quantity specifying number of octets) -
      2. -
    2. Vendor string ([vendor string length] octets coded from beginning of string to end of +

      +

      + 1.
      Vendor string length (32 bit unsigned quantity specifying number of octets) +
      + 2.
      Vendor string ([vendor string length] octets coded from beginning of string to end of string, not null terminated) -
      3. -
    3. Number of comment fields (32 bit unsigned quantity specifying number of fields) -
      4. -
    4. Comment field 0 length (if [Number of comment fields]
      + 3.
      Number of comment fields (32 bit unsigned quantity specifying number of fields) +
      + 4.
      Comment field 0 length (if [Number of comment fields] > 0; 32 bit unsigned quantity specifying number of octets) -
      5. -
    5. Comment field 0 ([Comment field 0 length] octets coded from beginning of string to +
    + 5.
    Comment field 0 ([Comment field 0 length] octets coded from beginning of string to end of string, not null terminated) - -
  • Comment field 1 length (if [Number of comment fields]
    + 6.
    Comment field 1 length (if [Number of comment fields] > 1...)... -
    • +

    This is actually somewhat easier to describe in code; implementation of the above can be found in vorbis/lib/info.c, _vorbis_unpack_comment(). -

    6 6. Floor type 0 setup and decode

    -

    6.1 6.1. Overview

    Vorbis floor type zero uses Line Spectral Pair (LSP, also alternately known as Line Spectral Frequency or LSF) representation to encode a smooth spectral envelope curve as the frequency @@ -5273,12 +5272,12 @@ response of the LSP filter. This representation is equivalent to a traditional a impulse response filter as would be used in linear predictive coding; LSP representation may be converted to LPC representation and vice-versa.

    -

    6.2 6.2. Floor 0 format

    Floor zero configuration consists of six integer fields and a list of VQ codebooks for use in coding/decoding the LSP filter coefficient values used by each frame.

    -

    6.2.1 6.2.1. header decode

    Configuration information for instances of floor zero decodes from the codec setup header (third packet). configuration decode proceeds as follows: @@ -5414,7 +5413,7 @@ class="cmtt-12">[floor0_book_list] that is greater than the maximum codebook number for this bitstream is an error condition that also renders the stream undecodable.

    -

    6.2.2 6.2.2. packet decode

    Extracting a floor0 curve from an audio packet consists of first decoding the curve amplitude and [coefficients] is to to read a total of twelve scalars be taken not to allow a buffer overflow in decode. The extra values are not used and may be ignored or discarded.

    -

    6.2.3 6.2.3. curve computation

    Given an [amplitude] integer and [output] on a log (dB) amplitude scale, mapping it to linear amplitude in the last step: -

    -

      -

    1. +

      + 1.
      [i] = 0 -
      2. -
    2. + 2.
      [ω] = π * map element [i] / [floor0_bark_map_size] -
      3. -
    3. if (
      + 3.
      if ( [floor0_order] is odd ) -
        -
      1. calculate
        + a)
        calculate [p] and [q] according to:
        @@ -5812,12 +5811,12 @@ q = -- 4(cos([coefficients ]2j) − cosω )2 " class="math-display" >
        -
      +

      else [floor0_order] is even -

        -
      1. calculate
        + b)
        calculate [p] and [q] according to:
        @@ -5831,10 +5830,10 @@ q = (1-+-cosω-) 4(cos([coefficients ]2j) − cos ω 2 j=0 " class="math-display" >
        -
      -
      4. -
    4. calculate +
      + 4.
      calculate [linear_floor_value] according to:

      -

      5. -
    5. + 5.
      [iteration_condition] = map element [i] -
      6. -
    6. + 6.
      [output] element [i] = [linear_floor_value] -
      7. -
    7. increment
      + 7.
      increment [i] -
      8. -
    8. if ( map element
      + 8.
      if ( map element [i] is equal to [iteration_condition] ) continue at step 5 -
      9. -
    9. if (
      + 9.
      if ( [i] is less than [n] ) continue at step 2 -
      10. -
    10. done
    +
    + 10.
    done
    -

    7 7. Floor type 1 setup and decode

    -

    7.1 7.1. Overview

    Vorbis floor type one uses a piecewise straight-line representation to encode a spectral envelope curve. The representation plots this curve mechanically on a linear frequency axis and a logarithmic (dB) amplitude axis. The integer plotting algorithm used is similar to Bresenham’s algorithm.

    -

    7.2 7.2. Floor 1 format

    -

    7.2.1 7.2.1. model

    Floor type one represents a spectral curve as a series of line segments. Synthesis constructs a floor curve using iterative prediction in a process roughly equivalent to the following simplified @@ -5984,7 +5983,7 @@ decode, as described later. The actual algorithm splits Y value computation and into two steps with modifications to the above algorithm to eliminate noise accumulation through integer roundoff/truncation.

    -

    7.2.2 7.2.2. header decode

    A list of floor X values is stored in the packet header in interleaved format (used in list order during packet decode and synthesis). This list is split into partitions, and each partition is @@ -7293,7 +7292,7 @@ fit.

    Although some aspects of the below algorithm look like inconsequential optimizations, implementors are warned to follow the details closely. Deviation from implementing a strictly equivalent algorithm can result in serious decoding errors. -

    +

    step 1: amplitude value synthesis
      -

    8 8. Residue setup and decode

    -

    8.1 8.1. Overview

    A residue vector represents the fine detail of the audio spectrum of one channel in an audio frame after the encoder subtracts the floor curve and performs any channel coupling. A residue vector @@ -8989,7 +8988,7 @@ bitstream packet, and then reconstructs the vectors during decode. Vorbis makes different encoding variants (numbered 0, 1 and 2) of the same basic vector encoding abstraction.

    -

    8.2 8.2. Residue format

    Residue format partitions each vector in the vector bundle into chunks, classifies each chunk, encodes the chunk classifications and finally encodes the chunks themselves @@ -9051,7 +9050,7 @@ src="residue-pack.png" alt="PIC" class="content">illustration of residue vector format

    -

    8.3 8.3. residue 0

    Residue 0 and 1 differ only in the way the values within a residue partition are interleaved during partition encoding (visually treated as a black box–or cyan box or brown box–in the above @@ -9236,7 +9235,7 @@ class="cmtt-8"> 

    It is worth mentioning at this point that no configurable value in the residue coding setup is restricted to a power of two.

    -

    8.4 8.4. residue 1

    Residue 1 does not interleave VQ encoding. It represents partition vector scalars in order. As with residue 0, however, partition length must be an integer multiple of the codebook dimension, @@ -9415,7 +9414,7 @@ class="cmtt-8"> 

    -

    8.5 8.5. residue 2

    Residue type two can be thought of as a variant of residue type 1. Rather than encoding multiple passed-in vectors as in residue type 1, the illustration of residue type 2

    -

    8.6 8.6. Residue decode

    -

    8.6.1 8.6.1. header decode

    Header decode for all three residue types is identical.

    @@ -9960,7 +9959,7 @@ set up in this stream also renders the stream undecodable. All codebooks in arra [residue_books] without a value mapping (maptype equals zero) renders the stream undecodable.

    -

    8.6.2 8.6.2. packet decode

    Format 0 and 1 packet decode is identical except for specific partition interleave. Format 2 packet decode can be built out of the format 1 decode process. Thus we describe first the decode @@ -11208,7 +11207,7 @@ class="cmtt-8"> 

    An end-of-packet condition during packet decode is to be considered a nominal occurrence. Decode returns the result of vector decode up to that point.

    -

    8.6.3 8.6.3. format 0 specifics

    Format zero decodes partitions exactly as described earlier in the ’Residue Format: residue 0’ section. The following pseudocode presents the same algorithm. Assume: @@ -11422,7 +11421,7 @@ class="cmtt-8"> 

    -

    8.6.4 8.6.4. format 1 specifics

    Format 1 decodes partitions exactly as described earlier in the ’Residue Format: residue 1’ section. The following pseudocode presents the same algorithm. Assume: @@ -11592,7 +11591,7 @@ class="cmtt-8"> 7) done

    -

    8.6.5 8.6.5. format 2 specifics

    Format 2 is reducible to format 1. It may be implemented as an additional step prior to and an additional post-decode step after a normal format 1 decode. @@ -11605,33 +11604,33 @@ the vectors are decoded. We then request normal format 1 to decode a single vect representing all output channels, rather than a vector for each channel. After decode, deinterleave the vector into independent vectors, one for each output channel. That is: -

    -

      -
    1. If all vectors 0 through

      +

      + 1.
      If all vectors 0 through ch-1 are marked ’do not decode’, allocate and clear a single vector [v]of length ch*n and skip step 2 below; proceed directly to the post-decode step. -
      2. -
    2. Rather than performing format 1 decode to produce
      + 2.
      Rather than performing format 1 decode to produce ch vectors of length n each, call format 1 decode to produce a single vector [v] of length ch*n. -
      3. -
    3. Post decode: Deinterleave the single vector
      + 3.
      Post decode: Deinterleave the single vector [v] returned by format 1 decode as described above into ch independent vectors, one for each outputchannel, according to:
      1   ... [n]-1 {
      2  
      3   ... [ch]-1 {
      4  
      5   [ch] + [j])
      6  
      7     }
      8     }
      9  
      10    4) done
      -
    +
    -

    9 9. Helper equations

    -

    9.1 9.1. Overview

    The equations below are used in multiple places by the Vorbis codec specification. Rather than cluttering up the main specification documents, they are defined here and referenced where appropriate.

    -

    9.2 9.2. Functions

    -

    9.2.1 9.2.1. ilog

    The ”ilog(x)” function returns the position number (1 through n) of the highest set bit in the two’s complement integer value  done

  • ilog(negative number) = 0;

    • -

    9.2.2 9.2.2. float32_unpack

    ”float32_unpack(x)” is intended to translate the packed binary representation of a Vorbis codebook float value into the representation used by the decoder for floating point numbers. For @@ -12014,7 +12013,7 @@ class="cmtt-8"> )

    -

    9.2.3 9.2.3. lookup1_values

    ”lookup1_values(codebook_entries,codebook_dimensions)” is used to compute the correct length of the value index for a codebook VQ lookup table of lookup type 1. @@ -12028,7 +12027,7 @@ class="cmtt-12">[codebook_dimensions] is less than or equal to [codebook_entries]’.

    -

    9.2.4 9.2.4. low_neighbor

    ”low_neighbor(v,x)” finds the position n in vector [v] element [x].

    -

    9.2.5 9.2.5. high_neighbor

    ”high_neighbor(v,x)” finds the position n in vector [v] of the lowest value scalar element for @@ -12055,7 +12054,7 @@ class="cmtt-12">[v] element [x].

    -

    9.2.6 9.2.6. render_point

    ”render_point(x0,y0,x1,y1,X)” is used to find the Y value at point X along the line specified by x0, x1, y0 and y1. This function uses an integer algorithm to solve for the point directly without @@ -12239,7 +12238,7 @@ class="cmtt-8"> 9) done

    -

    9.2.7 9.2.7. render_line

    Floor decode type one uses the integer line drawing algorithm of ”render_line(x0, y0, x1, y1, v)” to construct an integer floor curve for contiguous piecewise line segments. Note that it has not @@ -12705,10 +12704,10 @@ class="cmtt-8"> } -

    10 10. Tables

    -

    10.1 10.1. floor1_inverse_dB_table

    The vector [floor1_inverse_dB_table] is a 256 element static lookup table consiting of the @@ -13531,10 +13530,10 @@ class="cmtt-8"> 1. -

    A A. Embedding Vorbis into an Ogg stream

    -

    A.1 A.1. Overview

    This document describes using Ogg logical and physical transport streams to encapsulate Vorbis compressed audio packet data into file form. @@ -13549,7 +13548,7 @@ descriptions of Ogg transport streams. This specification document assumes a wor knowledge of the concepts covered in these named backround documents. Please read them first.

    -

    A.1.1 A.1.1. Restrictions

    The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis streams use Ogg transport streams in degenerate, unmultiplexed form only. That is: @@ -13574,7 +13573,7 @@ implement Ogg support beyond the specific support of Vorbis within a degenrate O stream (naturally, application authors are encouraged to support full multiplexed Ogg handling).

    -

    A.1.2 A.1.2. MIME type

    The MIME type of Ogg files depend on the context. Specifically, complex multimedia and applications should use audio/vorbis + audio/vorbis-config.

    -

    A.2 A.2. Encapsulation

    Ogg encapsulation of a Vorbis packet stream is straightforward.