Vorbis_I_spec.html - Android社区 - https://www.androidos.net.cn/

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
 "http://www.w3.org/TR/html4/loose.dtd"> 
<html > 
<head><title>Vorbis I specification</title> 
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> 
<meta name="generator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)"> 
<meta name="originator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)"> 
 
<meta name="src" content="Vorbis_I_spec.tex"> 
<meta name="date" content="2010-02-03 17:32:00"> 
<link rel="stylesheet" type="text/css" href="Vorbis_I_spec.css"> 
</head><body 
>
<div class="maketitle">

<h2 class="titleHead">Vorbis I specification</h2>
<div class="author" >Xiph.org Foundation</div>
 
<div class="date" >February 3, 2010</div>
</div>
<h3 class="likesectionHead"><a 
 id="x1-1000"></a>Contents</h3>
<div class="tableofcontents">
 1 <a 
href="#x1-20001" id="QQ2-1-2">Introduction and Description</a>
   1.1 <a 
href="#x1-30001.1" id="QQ2-1-3">Overview</a>
    1.1.1 <a 
href="#x1-40001.1.1" id="QQ2-1-4">Application</a>
    1.1.2 <a 
href="#x1-50001.1.2" id="QQ2-1-5">Classification</a>
    1.1.3 <a 
href="#x1-60001.1.3" id="QQ2-1-6">Assumptions</a>
    1.1.4 <a 
href="#x1-70001.1.4" id="QQ2-1-7">Codec Setup and Probability Model</a>
    1.1.5 <a 
href="#x1-90001.1.5" id="QQ2-1-9">Format Specification</a>
    1.1.6 <a 
href="#x1-100001.1.6" id="QQ2-1-10">Hardware Profile</a>
   1.2 <a 
href="#x1-110001.2" id="QQ2-1-11">Decoder Configuration</a>
    1.2.1 <a 
href="#x1-120001.2.1" id="QQ2-1-13">Global Config</a>
    1.2.2 <a 
href="#x1-130001.2.2" id="QQ2-1-14">Mode</a>

1.2.3 <a 
href="#x1-140001.2.3" id="QQ2-1-15">Mapping</a>
    1.2.4 <a 
href="#x1-150001.2.4" id="QQ2-1-16">Floor</a>
    1.2.5 <a 
href="#x1-160001.2.5" id="QQ2-1-17">Residue</a>
    1.2.6 <a 
href="#x1-170001.2.6" id="QQ2-1-18">Codebooks</a>
   1.3 <a 
href="#x1-180001.3" id="QQ2-1-19">High-level Decode Process</a>
    1.3.1 <a 
href="#x1-190001.3.1" id="QQ2-1-20">Decode Setup</a>
    1.3.2 <a 
href="#x1-230001.3.2" id="QQ2-1-24">Decode Procedure</a>
  2 <a 
href="#x1-360002" id="QQ2-1-39">Bitpacking Convention</a>
   2.1 <a 
href="#x1-370002.1" id="QQ2-1-40">Overview</a>
    2.1.1 <a 
href="#x1-380002.1.1" id="QQ2-1-41">octets, bytes and words</a>
    2.1.2 <a 
href="#x1-390002.1.2" id="QQ2-1-42">bit order</a>
    2.1.3 <a 
href="#x1-400002.1.3" id="QQ2-1-43">byte order</a>
    2.1.4 <a 
href="#x1-410002.1.4" id="QQ2-1-44">coding bits into byte sequences</a>
    2.1.5 <a 
href="#x1-420002.1.5" id="QQ2-1-45">signedness</a>
    2.1.6 <a 
href="#x1-430002.1.6" id="QQ2-1-46">coding example</a>
    2.1.7 <a 
href="#x1-440002.1.7" id="QQ2-1-47">decoding example</a>
    2.1.8 <a 
href="#x1-450002.1.8" id="QQ2-1-48">end-of-packet alignment</a>
    2.1.9 <a 
href="#x1-460002.1.9" id="QQ2-1-49">reading zero bits</a>
  3 <a 
href="#x1-470003" id="QQ2-1-50">Probability Model and Codebooks</a>
   3.1 <a 
href="#x1-480003.1" id="QQ2-1-51">Overview</a>
    3.1.1 <a 
href="#x1-490003.1.1" id="QQ2-1-52">Bitwise operation</a>
   3.2 <a 
href="#x1-500003.2" id="QQ2-1-53">Packed codebook format</a>
    3.2.1 <a 
href="#x1-510003.2.1" id="QQ2-1-54">codebook decode</a>
   3.3 <a 
href="#x1-570003.3" id="QQ2-1-62">Use of the codebook abstraction</a>
  4 <a 
href="#x1-580004" id="QQ2-1-63">Codec Setup and Packet Decode</a>
   4.1 <a 
href="#x1-590004.1" id="QQ2-1-64">Overview</a>
   4.2 <a 
href="#x1-600004.2" id="QQ2-1-65">Header decode and decode setup</a>
    4.2.1 <a 
href="#x1-610004.2.1" id="QQ2-1-66">Common header decode</a>
    4.2.2 <a 
href="#x1-620004.2.2" id="QQ2-1-67">Identification header</a>

4.2.3 <a 
href="#x1-630004.2.3" id="QQ2-1-68">Comment header</a>
    4.2.4 <a 
href="#x1-640004.2.4" id="QQ2-1-69">Setup header</a>
   4.3 <a 
href="#x1-710004.3" id="QQ2-1-77">Audio packet decode and synthesis</a>
    4.3.1 <a 
href="#x1-720004.3.1" id="QQ2-1-78">packet type, mode and window decode</a>
    4.3.2 <a 
href="#x1-730004.3.2" id="QQ2-1-79">floor curve decode</a>
    4.3.3 <a 
href="#x1-740004.3.3" id="QQ2-1-80">nonzero vector propagate</a>
    4.3.4 <a 
href="#x1-750004.3.4" id="QQ2-1-81">residue decode</a>
    4.3.5 <a 
href="#x1-760004.3.5" id="QQ2-1-82">inverse coupling</a>
    4.3.6 <a 
href="#x1-770004.3.6" id="QQ2-1-83">dot product</a>
    4.3.7 <a 
href="#x1-780004.3.7" id="QQ2-1-84">inverse MDCT</a>
    4.3.8 <a 
href="#x1-790004.3.8" id="QQ2-1-85">overlap˙add</a>
    4.3.9 <a 
href="#x1-800004.3.9" id="QQ2-1-86">output channel order</a>
  5 <a 
href="#x1-810005" id="QQ2-1-87">comment field and header specification</a>
   5.1 <a 
href="#x1-820005.1" id="QQ2-1-88">Overview</a>
   5.2 <a 
href="#x1-830005.2" id="QQ2-1-89">Comment encoding</a>
    5.2.1 <a 
href="#x1-840005.2.1" id="QQ2-1-90">Structure</a>
    5.2.2 <a 
href="#x1-850005.2.2" id="QQ2-1-91">Content vector format</a>
    5.2.3 <a 
href="#x1-880005.2.3" id="QQ2-1-94">Encoding</a>
  6 <a 
href="#x1-890006" id="QQ2-1-95">Floor type 0 setup and decode</a>
   6.1 <a 
href="#x1-900006.1" id="QQ2-1-96">Overview</a>
   6.2 <a 
href="#x1-910006.2" id="QQ2-1-97">Floor 0 format</a>
    6.2.1 <a 
href="#x1-920006.2.1" id="QQ2-1-98">header decode</a>
    6.2.2 <a 
href="#x1-930006.2.2" id="QQ2-1-99">packet decode</a>
    6.2.3 <a 
href="#x1-940006.2.3" id="QQ2-1-100">curve computation</a>
  7 <a 
href="#x1-950007" id="QQ2-1-101">Floor type 1 setup and decode</a>
   7.1 <a 
href="#x1-960007.1" id="QQ2-1-102">Overview</a>
   7.2 <a 
href="#x1-970007.2" id="QQ2-1-103">Floor 1 format</a>
    7.2.1 <a 
href="#x1-980007.2.1" id="QQ2-1-104">model</a>
    7.2.2 <a 
href="#x1-990007.2.2" id="QQ2-1-109">header decode</a>

8 <a 
href="#x1-1020008" id="QQ2-1-112">Residue setup and decode</a>
   8.1 <a 
href="#x1-1030008.1" id="QQ2-1-113">Overview</a>
   8.2 <a 
href="#x1-1040008.2" id="QQ2-1-114">Residue format</a>
   8.3 <a 
href="#x1-1050008.3" id="QQ2-1-116">residue 0</a>
   8.4 <a 
href="#x1-1060008.4" id="QQ2-1-117">residue 1</a>
   8.5 <a 
href="#x1-1070008.5" id="QQ2-1-118">residue 2</a>
   8.6 <a 
href="#x1-1080008.6" id="QQ2-1-120">Residue decode</a>
    8.6.1 <a 
href="#x1-1090008.6.1" id="QQ2-1-121">header decode</a>
    8.6.2 <a 
href="#x1-1100008.6.2" id="QQ2-1-122">packet decode</a>
    8.6.3 <a 
href="#x1-1110008.6.3" id="QQ2-1-123">format 0 specifics</a>
    8.6.4 <a 
href="#x1-1120008.6.4" id="QQ2-1-124">format 1 specifics</a>
    8.6.5 <a 
href="#x1-1130008.6.5" id="QQ2-1-125">format 2 specifics</a>
  9 <a 
href="#x1-1140009" id="QQ2-1-126">Helper equations</a>
   9.1 <a 
href="#x1-1150009.1" id="QQ2-1-127">Overview</a>
   9.2 <a 
href="#x1-1160009.2" id="QQ2-1-128">Functions</a>
    9.2.1 <a 
href="#x1-1170009.2.1" id="QQ2-1-129">ilog</a>
    9.2.2 <a 
href="#x1-1180009.2.2" id="QQ2-1-130">float32˙unpack</a>
    9.2.3 <a 
href="#x1-1190009.2.3" id="QQ2-1-131">lookup1˙values</a>
    9.2.4 <a 
href="#x1-1200009.2.4" id="QQ2-1-132">low˙neighbor</a>
    9.2.5 <a 
href="#x1-1210009.2.5" id="QQ2-1-133">high˙neighbor</a>
    9.2.6 <a 
href="#x1-1220009.2.6" id="QQ2-1-134">render˙point</a>
    9.2.7 <a 
href="#x1-1230009.2.7" id="QQ2-1-135">render˙line</a>
  10 <a 
href="#x1-12400010" id="QQ2-1-136">Tables</a>
   10.1 <a 
href="#x1-12500010.1" id="QQ2-1-137">floor1_inverse_dB_table</a>
  A <a 
href="#x1-126000A" id="QQ2-1-138">Embedding Vorbis into an Ogg stream</a>
   A.1 <a 
href="#x1-127000A.1" id="QQ2-1-139">Overview</a>
    A.1.1 <a 
href="#x1-128000A.1.1" id="QQ2-1-140">Restrictions</a>
    A.1.2 <a 
href="#x1-129000A.1.2" id="QQ2-1-141">MIME type</a>
   A.2 <a 
href="#x1-130000A.2" id="QQ2-1-142">Encapsulation</a>

B <a 
href="#x1-132000B" id="QQ2-1-144">Vorbis encapsulation in RTP</a>
</div>

<h3 class="sectionHead">1 <a 
 id="x1-20001"></a>Introduction and Description</h3>

<h4 class="subsectionHead">1.1 <a 
 id="x1-30001.1"></a>Overview</h4>
This document provides a high level description of the Vorbis codec’s construction. A bit-by-bit
specification appears beginning in <a 
href="#x1-580004">Section 4</a>, “<a 
href="#x1-580004">Codec Setup and Packet Decode</a>”. The later
sections assume a high-level understanding of the Vorbis decode process, which is provided
here.

<h5 class="subsubsectionHead">1.1.1 <a 
 id="x1-40001.1.1"></a>Application</h5>
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
the high quality/bitrate end of the scale (CD or DAT rate stereo, 16/24 bits) it is in the same
league as MPEG-2 and MPC. Similarly, the 1.0 encoder can encode high-quality CD and DAT
rate stereo at below 48kbps without resampling to a lower rate. Vorbis is also intended for lower
and higher sample rates (from 8kHz telephony to 192kHz digital masters) and a range of channel
representations (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255
discrete channels).

<h5 class="subsubsectionHead">1.1.2 <a 
 id="x1-50001.1.2"></a>Classification</h5>
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
Vorbis II to offer better transient response and reproduction using a transform better suited to
localized time events.

<h5 class="subsubsectionHead">1.1.3 <a 
 id="x1-60001.1.3"></a>Assumptions</h5>
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
require more working memory as Vorbis has no static probability model; the vector codebooks
used in the first stage of decoding from the bitstream are packed in their entirety into the Vorbis
bitstream headers. In packed form, these codebooks occupy only a few kilobytes; the extent to
which they are pre-decoded into a cache is the dominant factor in decoder memory
usage.
Vorbis provides none of its own framing, synchronization or protection against errors; it
is solely a method of accepting input audio, dividing it into individual frames and
compressing these frames into raw, unformatted ’packets’. The decoder then accepts
these raw packets in sequence, decodes them, synthesizes audio frames from them, and
reassembles the frames into a facsimile of the original audio stream. Vorbis is a free-form
variable bit rate (VBR) codec and packets have no minimum size, maximum size, or
fixed/expected size. Packets are designed that they may be truncated (or padded)
and remain decodable; this is not to be considered an error condition and is used
extensively in bitrate management in peeling. Both the transport mechanism and
decoder must allow that a packet may be any size, or end before or after packet decode
expects.
Vorbis packets are thus intended to be used with a transport mechanism that provides free-form
framing, sync, positioning and error correction in accordance with these design assumptions, such
as Ogg (for file transport) or RTP (for network multicast). For purposes of a few examples in this
document, we will assume that Vorbis is to be embedded in an Ogg stream specifically,
although this is by no means a requirement or fundamental assumption in the Vorbis
design.
The specification for embedding Vorbis into an Ogg transport stream is in <a 
href="#x1-126000A">Section A</a>,
“<a 
href="#x1-126000A">Embedding Vorbis into an Ogg stream</a>”.

<h5 class="subsubsectionHead">1.1.4 <a 
 id="x1-70001.1.4"></a>Codec Setup and Probability Model</h5>
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
specification. For these reasons, configurable aspects of codec setup intentionally lean toward the
extreme of forward adaptive.

The single most controversial design decision in Vorbis (and the most unusual for a Vorbis
developer to keep in mind) is that the entire probability model of the codec, the Huffman and
VQ codebooks, is packed into the bitstream header along with extensive CODEC setup
parameters (often several hundred fields). This makes it impossible, as it would be with
MPEG audio layers, to embed a simple frame type flag in each audio packet, or begin
decode at any frame in the stream without having previously fetched the codec setup
header.
<a 
 id="x1-80001.1.4"></a>Note: Vorbis can initiate decode at any arbitrary packet within a bitstream so long as the codec
has been initialized/setup with the setup headers.
Thus, Vorbis headers are both required for decode to begin and relatively large as bitstream
headers go. The header size is unbounded, although for streaming a rule-of-thumb of 4kB or less
is recommended (and Xiph.Org’s Vorbis encoder follows this suggestion).
Our own design work indicates the primary liability of the required header is in mindshare; it is
an unusual design and thus causes some amount of complaint among engineers as this runs
against current design trends (and also points out limitations in some existing software/interface
designs, such as Windows’ ACM codec framework). However, we find that it does not
fundamentally limit Vorbis’ suitable application space.

<h5 class="subsubsectionHead">1.1.5 <a 
 id="x1-90001.1.5"></a>Format Specification</h5>
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
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.

<h5 class="subsubsectionHead">1.1.6 <a 
 id="x1-100001.1.6"></a>Hardware Profile</h5>

Although Vorbis decode is computationally simple, it may still run into specific limitations of an
embedded design. For this reason, embedded designs are allowed to deviate in limited ways from
the ‘full’ decode specification yet still be certified compliant. These optional omissions are
labelled in the spec where relevant.

<h4 class="subsectionHead">1.2 <a 
 id="x1-110001.2"></a>Decoder Configuration</h4>
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
type is semantically interchangeable; decoder configuration consists both of internal component
configuration, as well as arrangement of specific instances into a decode pipeline. Componentry
arrangement is roughly as follows:
<div class="center" 
>

<img 
src="components.png" alt="PIC" 
>
 <div class="caption" 
>Figure 1: decoder pipeline configuration</div>
</div>

<h5 class="subsubsectionHead">1.2.1 <a 
 id="x1-120001.2.1"></a>Global Config</h5>
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.

<h5 class="subsubsectionHead">1.2.2 <a 
 id="x1-130001.2.2"></a>Mode</h5>

Each Vorbis frame is coded according to a master ’mode’. A bitstream may use one or many
modes.
The mode mechanism is used to encode a frame according to one of multiple possible
methods with the intention of choosing a method best suited to that frame. Different
modes are, e.g. how frame size is changed from frame to frame. The mode number of a
frame serves as a top level configuration switch for all other specific aspects of frame
decode.
A ’mode’ configuration consists of a frame size setting, window type (always 0, the Vorbis
window, in Vorbis I), transform type (always type 0, the MDCT, in Vorbis I) and a mapping
number. The mapping number specifies which mapping configuration instance to use for low-level
packet decode and synthesis.

<h5 class="subsubsectionHead">1.2.3 <a 
 id="x1-140001.2.3"></a>Mapping</h5>
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
not references to external components; the submap list is internal and specific to a
mapping.
A ’submap’ is a configuration/grouping that applies to a subset of floor and residue vectors
within a mapping. The submap functions as a last layer of indirection such that specific special
floor or residue settings can be applied not only to all the vectors in a given mode, but also
specific vectors in a specific mode. Each submap specifies the proper floor and residue
instance number to use for decoding that submap’s spectral floor and spectral residue
vectors.
As an example:
Assume a Vorbis stream that contains six channels in the standard 5.1 format. The sixth
channel, as is normal in 5.1, is bass only. Therefore it would be wasteful to encode a
full-spectrum version of it as with the other channels. The submapping mechanism can be used
to apply a full range floor and residue encoding to channels 0 through 4, and a bass-only
representation to the bass channel, thus saving space. In this example, channels 0-4 belong to
submap 0 (which indicates use of a full-range floor) and channel 5 belongs to submap 1, which
uses a bass-only representation.

<h5 class="subsubsectionHead">1.2.4 <a 
 id="x1-150001.2.4"></a>Floor</h5>
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
akin to a whitening filter. It is named a ’floor’ because the Xiph.Org reference encoder has
historically used it as a unit-baseline for spectral resolution.
A floor encoding may be of two types. Floor 0 uses a packed LSP representation on a dB
amplitude scale and Bark frequency scale. Floor 1 represents the curve as a piecewise linear
interpolated representation on a dB amplitude scale and linear frequency scale. The two floors
are semantically interchangeable in encoding/decoding. However, floor type 1 provides more
stable inter-frame behavior, and so is the preferred choice in all coupled-stereo and
high bitrate modes. Floor 1 is also considerably less expensive to decode than floor
0.
Floor 0 is not to be considered deprecated, but it is of limited modern use. No known Vorbis
encoder past Xiph.org’s own beta 4 makes use of floor 0.
The values coded/decoded by a floor are both compactly formatted and make use of entropy
coding to save space. For this reason, a floor configuration generally refers to multiple
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.

<h5 class="subsubsectionHead">1.2.5 <a 
 id="x1-160001.2.5"></a>Residue</h5>
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
quantization according to one of three specific packing/coding algorithms numbered
0 through 2. The packing algorithm details are configured by residue instance. As
with the floor components, the final VQ/entropy encoding is provided by external
codebook instances and each residue instance may choose from any and all available
codebooks.

<h5 class="subsubsectionHead">1.2.6 <a 
 id="x1-170001.2.6"></a>Codebooks</h5>
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
the indicated vector of values.
The entropy coding in a Vorbis I codebook is provided by a standard Huffman binary tree
representation. This tree is tightly packed using one of several methods, depending on whether
codeword lengths are ordered or unordered, or the tree is sparse.
The codebook vector index is similarly packed according to index characteristic. Most commonly,
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).

<h4 class="subsectionHead">1.3 <a 
 id="x1-180001.3"></a>High-level Decode Process</h4>

<h5 class="subsubsectionHead">1.3.1 <a 
 id="x1-190001.3.1"></a>Decode Setup</h5>
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
this specification. Once set up, decode may begin at any audio packet belonging to
the Vorbis stream. In Vorbis I, all packets after the three initial headers are audio
packets.
The header packets are, in order, the identification header, the comments header, and the setup
header.
<a 
 id="x1-200001.3.1"></a>Identification Header
The identification header identifies the bitstream as Vorbis, Vorbis version, and the simple audio
characteristics of the stream such as sample rate and number of channels.

<a 
 id="x1-210001.3.1"></a>Comment Header
The comment header includes user text comments (“tags”) and a vendor string for the
application/library that produced the bitstream. The encoding and proper use of the comment
header is described in <a 
href="#x1-810005">Section 5</a>, “<a 
href="#x1-810005">comment field and header specification</a>”.
<a 
 id="x1-220001.3.1"></a>Setup Header
The setup header includes extensive CODEC setup information as well as the complete VQ and
Huffman codebooks needed for decode.

<h5 class="subsubsectionHead">1.3.2 <a 
 id="x1-230001.3.2"></a>Decode Procedure</h5>
The decoding and synthesis procedure for all audio packets is fundamentally the same.
 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-23002x1">decode packet type flag
 </li>
 <li 
 class="enumerate" id="x1-23004x2">decode mode number
 </li>
 <li 
 class="enumerate" id="x1-23006x3">decode window shape (long windows only)
 </li>
 <li 
 class="enumerate" id="x1-23008x4">decode floor
 </li>
 <li 
 class="enumerate" id="x1-23010x5">decode residue into residue vectors
 </li>
 <li 
 class="enumerate" id="x1-23012x6">inverse channel coupling of residue vectors
 </li>
 <li 
 class="enumerate" id="x1-23014x7">generate floor curve from decoded floor data
 </li>
 <li 
 class="enumerate" id="x1-23016x8">compute dot product of floor and residue, producing audio spectrum vector
 </li>
 <li 
 class="enumerate" id="x1-23018x9">inverse monolithic transform of audio spectrum vector, always an MDCT in Vorbis
 I

</li>
 <li 
 class="enumerate" id="x1-23020x10">overlap/add left-hand output of transform with right-hand output of previous frame
 </li>
 <li 
 class="enumerate" id="x1-23022x11">store right hand-data from transform of current frame for future lapping
 </li>
 <li 
 class="enumerate" id="x1-23024x12">if not first frame, return results of overlap/add as audio result of current frame</li></ol>
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
overlap/add with the next frame. This optimization produces entirely equivalent output and is
naturally perfectly legal. The decoder must be entirely mathematically equivalent to the
specification, it need not be a literal semantic implementation.
<a 
 id="x1-240001.3.2"></a>Packet type decode
Vorbis I uses four packet types. The first three packet types mark each of the three Vorbis
headers described above. The fourth packet type marks an audio packet. All other packet types
are reserved; packets marked with a reserved type should be ignored.
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; a non-audio packet when audio is
expected indicates stream corruption or a non-compliant stream. The decoder must ignore the
packet and not attempt decoding it to audio.
<a 
 id="x1-250001.3.2"></a>Mode decode
Vorbis allows an encoder to set up multiple, numbered packet ’modes’, as described earlier, all of
which may be used in a given Vorbis stream. The mode is encoded as an integer used as a direct
offset into the mode instance index.
<a 
 id="x1-260001.3.2"></a>Window shape decode (long windows only)
Vorbis frames may be one of two PCM sample sizes specified during codec setup. In Vorbis I,
legal frame sizes are powers of two from 64 to 8192 samples. Aside from coupling, Vorbis
handles channels as independent vectors and these frame sizes are in samples per
channel.

Vorbis uses an overlapping transform, namely the MDCT, to blend one frame into the next,
avoiding most inter-frame block boundary artifacts. The MDCT output of one frame is windowed
according to MDCT requirements, overlapped 50% with the output of the previous frame and
added. The window shape assures seamless reconstruction.
This is easy to visualize in the case of equal sized-windows:
<div class="center" 
>

<img 
src="window1.png" alt="PIC" 
>
 <div class="caption" 
>Figure 2: overlap of two equal-sized windows</div>
</div>
And slightly more complex in the case of overlapping unequal sized windows:
<div class="center" 
>

<img 
src="window2.png" alt="PIC" 
>
 <div class="caption" 
>Figure 3: overlap of a long and a short window</div>
</div>
In the unequal-sized window case, the window shape of the long window must be modified for
seamless lapping as above. It is possible to correctly infer window shape to be applied to the
current window from knowing the sizes of the current, previous and next window. It is legal for a
decoder to use this method. However, in the case of a long window (short windows require no
modification), Vorbis also codes two flag bits to specify pre- and post- window shape. Although
not strictly necessary for function, this minor redundancy allows a packet to be fully decoded to
the point of lapping entirely independently of any other packet, allowing easier abstraction of
decode layers as well as allowing a greater level of easy parallelism in encode and
decode.
A description of valid window functions for use with an inverse MDCT can be found in [<a 
href="#XSporer/Brandenburg/Edler">1</a>].
Vorbis windows all use the slope function
<center class="math-display" >
<img 
src="Vorbis_I_spec0x.png" alt="y = sin (.5 ∗ π sin2((x + .5)∕n ∗ π)).

" class="math-display" ></center>

<a 
 id="x1-270001.3.2"></a>floor decode
Each floor is encoded/decoded in channel order, however each floor belongs to a ’submap’ that
specifies which floor configuration to use. All floors are decoded before residue decode
begins.
<a 
 id="x1-280001.3.2"></a>residue decode
Although the number of residue vectors equals the number of channels, channel coupling may
mean that the raw residue vectors extracted during decode do not map directly to specific
channels. When channel coupling is in use, some vectors will correspond to coupled magnitude or
angle. The coupling relationships are described in the codec setup and may differ from frame to
frame, due to different mode numbers.
Vorbis codes residue vectors in groups by submap; the coding is done in submap order from
submap 0 through n-1. This differs from floors which are coded using a configuration provided by
submap number, but are coded individually in channel order.
<a 
 id="x1-290001.3.2"></a>inverse channel coupling
A detailed discussion of stereo in the Vorbis codec can be found in the document
<a 
href="stereo.html" >Stereo Channel Coupling in the Vorbis CODEC</a>. Vorbis is not limited to only stereo
coupling, but the stereo document also gives a good overview of the generic coupling
mechanism.
Vorbis coupling applies to pairs of residue vectors at a time; decoupling is done in-place a
pair at a time in the order and using the vectors specified in the current mapping
configuration. The decoupling operation is the same for all pairs, converting square polar
representation (where one vector is magnitude and the second angle) back to Cartesian
representation.
After decoupling, in order, each pair of vectors on the coupling list, the resulting residue vectors
represent the fine spectral detail of each output channel.

<a 
 id="x1-300001.3.2"></a>generate floor curve
The decoder may choose to generate the floor curve at any appropriate time. It is reasonable to
generate the output curve when the floor data is decoded from the raw packet, or it
can be generated after inverse coupling and applied to the spectral residue directly,
combining generation and the dot product into one step and eliminating some working
space.
Both floor 0 and floor 1 generate a linear-range, linear-domain output vector to be multiplied
(dot product) by the linear-range, linear-domain spectral residue.
<a 
 id="x1-310001.3.2"></a>compute floor/residue dot product
This step is straightforward; for each output channel, the decoder multiplies the floor curve and
residue vectors element by element, producing the finished audio spectrum of each
channel.
One point is worth mentioning about this dot product; a common mistake in a fixed point
implementation might be to assume that a 32 bit fixed-point representation for floor and
residue and direct multiplication of the vectors is sufficient for acceptable spectral depth
in all cases because it happens to mostly work with the current Xiph.Org reference
encoder.
However, floor vector values can span ∼140dB (∼24 bits unsigned), and the audio spectrum
vector should represent a minimum of 120dB (∼21 bits with sign), even when output is to a 16
bit PCM device. For the residue vector to represent full scale if the floor is nailed
to −140dB, it must be able to span 0 to +140dB. For the residue vector to reach
full scale if the floor is nailed at 0dB, it must be able to represent −140dB to +0dB.
Thus, in order to handle full range dynamics, a residue vector may span −140dB to
+140dB entirely within spec. A 280dB range is approximately 48 bits with sign; thus the
residue vector must be able to represent a 48 bit range and the dot product must
be able to handle an effective 48 bit times 24 bit multiplication. This range may be
achieved using large (64 bit or larger) integers, or implementing a movable binary point
representation.
<a 
 id="x1-320001.3.2"></a>inverse monolithic transform (MDCT)
The audio spectrum is converted back into time domain PCM audio via an inverse Modified
Discrete Cosine Transform (MDCT). A detailed description of the MDCT is available in
[<a 
href="#XSporer/Brandenburg/Edler">1</a>].
Note that the PCM produced directly from the MDCT is not yet finished audio; it must be

lapped with surrounding frames using an appropriate window (such as the Vorbis window) before
the MDCT can be considered orthogonal.
<a 
 id="x1-330001.3.2"></a>overlap/add data
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
current window (as illustrated in the window overlap diagram). At this point, the audio data
between the center of the previous frame and the center of the current frame is now finished and
ready to be returned.
<a 
 id="x1-340001.3.2"></a>cache right hand data
The decoder must cache the right hand portion of the current frame to be lapped with the left
hand portion of the next frame.
<a 
 id="x1-350001.3.2"></a>return finished audio data
The overlapped portion produced from overlapping the previous and current frame data
is finished data to be returned by the decoder. This data spans from the center of
the previous window to the center of the current window. In the case of same-sized
windows, the amount of data to return is one-half block consisting of and only of the
overlapped portions. When overlapping a short and long window, much of the returned
range is not actually overlap. This does not damage transform orthogonality. Pay
attention however to returning the correct data range; the amount of data to be returned
is:

<div class="fancyvrb" id="fancyvrb1">
<a 
 id="x1-35002r1"></a>1  window_blocksize(previous_window)/4+window_blocksize(current_window)/4
</div>
from the center of the previous window to the center of the current window.
Data is not returned from the first frame; it must be used to ’prime’ the decode engine. The
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).

<h3 class="sectionHead">2 <a 
 id="x1-360002"></a>Bitpacking Convention</h3>

<h4 class="subsectionHead">2.1 <a 
 id="x1-370002.1"></a>Overview</h4>
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
encoder and then read one-by-one in the same monotonically increasing order by the decoder.
Most current binary storage arrangements group bits into a native word size of eight bits
(octets), sixteen bits, thirty-two bits or, less commonly other fixed word sizes. The Vorbis
bitpacking convention specifies the correct mapping of the logical packet bitstream into an actual
representation in fixed-width words.

<h5 class="subsubsectionHead">2.1.1 <a 
 id="x1-380002.1.1"></a>octets, bytes and words</h5>
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.
For purposes of the bitpacking convention, a byte implies the native, smallest integer
storage representation offered by a platform. On modern platforms, this is generally
assumed to be eight bits (not necessarily because of the processor but because of the
filesystem/memory architecture. Modern filesystems invariably offer bytes as the fundamental
atom of storage). A ’word’ is an integer size that is a grouped multiple of this smallest
size.
The most ubiquitous architectures today consider a ’byte’ to be an octet (eight bits) and a word
to be a group of two, four or eight bytes (16, 32 or 64 bits). Note however that the Vorbis
bitpacking convention is still well defined for any native byte size; Vorbis uses the native
bit-width of a given storage system. This document assumes that a byte is one octet for purposes
of example.

<h5 class="subsubsectionHead">2.1.2 <a 
 id="x1-390002.1.2"></a>bit order</h5>
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
opposite end of the byte. Bits in a byte are numbered from zero at the LSb to n (n = 7 in an
octet) for the MSb.

<h5 class="subsubsectionHead">2.1.3 <a 
 id="x1-400002.1.3"></a>byte order</h5>
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
highest-valued byte comes first), 0-1-2-3 (’little endian’ or ’least significant byte first’ in
which the lowest value byte comes first) and less commonly 3-1-2-0 and 0-2-1-3 (’mixed
endian’).
The Vorbis bitpacking convention specifies storage and bitstream manipulation at the byte, not
word, level, thus host word ordering is of a concern only during optimization when writing high
performance code that operates on a word of storage at a time rather than by byte.
Logically, bytes are always coded and decoded in order from byte zero through byte
n.

<h5 class="subsubsectionHead">2.1.4 <a 
 id="x1-410002.1.4"></a>coding bits into byte sequences</h5>
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
representation; the next field is written at the bit position at which the previous field
ends.
The encoder logically packs integers by writing the LSb of a binary integer to the logical
bitstream first, followed by next least significant bit, etc, until the requested number of bits
have been coded. When packing the bits into bytes, the encoder begins by placing
the LSb of the integer to be written into the least significant unused bit position of
the destination byte, followed by the next-least significant bit of the source integer
and so on up to the requested number of bits. When all bits of the destination byte
have been filled, encoding continues by zeroing all bits of the next byte and writing
the next bit into the bit position 0 of that byte. Decoding follows the same process

as encoding, but by reading bits from the byte stream and reassembling them into
integers.

<h5 class="subsubsectionHead">2.1.5 <a 
 id="x1-420002.1.5"></a>signedness</h5>
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
either ’seven’ as an unsigned integer, or ’-1’ as a signed, two’s complement integer. The
encoder and decoder are responsible for knowing if fields are to be treated as signed or
unsigned.

<h5 class="subsubsectionHead">2.1.6 <a 
 id="x1-430002.1.6"></a>coding example</h5>
Code the 4 bit integer value ’12’ [b1100] into an empty bytestream. Bytestream result:

<div class="fancyvrb" id="fancyvrb2">
<a 
 id="x1-43002r1"></a>1                |
 <a 
 id="x1-43004r2"></a>2                V
 <a 
 id="x1-43006r3"></a>3  
 <a 
 id="x1-43008r4"></a>4          7 6 5 4 3 2 1 0
 <a 
 id="x1-43010r5"></a>5  byte 0 [0 0 0 0 1 1 0 0]  <-
 <a 
 id="x1-43012r6"></a>6  byte 1 [               ]
 <a 
 id="x1-43014r7"></a>7  byte 2 [               ]
 <a 
 id="x1-43016r8"></a>8  byte 3 [               ]
 <a 
 id="x1-43018r9"></a>9               ...
 <a 
 id="x1-43020r10"></a>10  byte n [               ]  bytestream length == 1 byte
 <a 
 id="x1-43022r11"></a>11  
</div>
Continue by coding the 3 bit integer value ’-1’ [b111]:

<div class="fancyvrb" id="fancyvrb3">
<a 
 id="x1-43024r1"></a>1          |
 <a 
 id="x1-43026r2"></a>2          V
 <a 
 id="x1-43028r3"></a>3  
 <a 
 id="x1-43030r4"></a>4          7 6 5 4 3 2 1 0
 <a 
 id="x1-43032r5"></a>5  byte 0 [0 1 1 1 1 1 0 0]  <-
 <a 
 id="x1-43034r6"></a>6  byte 1 [               ]

<a 
 id="x1-43036r7"></a>7  byte 2 [               ]
 <a 
 id="x1-43038r8"></a>8  byte 3 [               ]
 <a 
 id="x1-43040r9"></a>9               ...
 <a 
 id="x1-43042r10"></a>10  byte n [               ]  bytestream length == 1 byte
</div>
Continue by coding the 7 bit integer value ’17’ [b0010001]:

<div class="fancyvrb" id="fancyvrb4">
<a 
 id="x1-43044r1"></a>1            |
 <a 
 id="x1-43046r2"></a>2            V
 <a 
 id="x1-43048r3"></a>3  
 <a 
 id="x1-43050r4"></a>4          7 6 5 4 3 2 1 0
 <a 
 id="x1-43052r5"></a>5  byte 0 [1 1 1 1 1 1 0 0]
 <a 
 id="x1-43054r6"></a>6  byte 1 [0 0 0 0 1 0 0 0]  <-
 <a 
 id="x1-43056r7"></a>7  byte 2 [               ]
 <a 
 id="x1-43058r8"></a>8  byte 3 [               ]
 <a 
 id="x1-43060r9"></a>9               ...
 <a 
 id="x1-43062r10"></a>10  byte n [               ]  bytestream length == 2 bytes
 <a 
 id="x1-43064r11"></a>11                            bit cursor == 6
</div>
Continue by coding the 13 bit integer value ’6969’ [b110 11001110 01]:

<div class="fancyvrb" id="fancyvrb5">
<a 
 id="x1-43066r1"></a>1                  |
 <a 
 id="x1-43068r2"></a>2                  V
 <a 
 id="x1-43070r3"></a>3  
 <a 
 id="x1-43072r4"></a>4          7 6 5 4 3 2 1 0
 <a 
 id="x1-43074r5"></a>5  byte 0 [1 1 1 1 1 1 0 0]
 <a 
 id="x1-43076r6"></a>6  byte 1 [0 1 0 0 1 0 0 0]
 <a 
 id="x1-43078r7"></a>7  byte 2 [1 1 0 0 1 1 1 0]
 <a 
 id="x1-43080r8"></a>8  byte 3 [0 0 0 0 0 1 1 0]  <-
 <a 
 id="x1-43082r9"></a>9               ...
 <a 
 id="x1-43084r10"></a>10  byte n [               ]  bytestream length == 4 bytes
 <a 
 id="x1-43086r11"></a>11  
</div>

<h5 class="subsubsectionHead">2.1.7 <a 
 id="x1-440002.1.7"></a>decoding example</h5>
Reading from the beginning of the bytestream encoded in the above example:

<div class="fancyvrb" id="fancyvrb6">

<a 
 id="x1-44002r1"></a>1                        |
 <a 
 id="x1-44004r2"></a>2                        V
 <a 
 id="x1-44006r3"></a>3  
 <a 
 id="x1-44008r4"></a>4          7 6 5 4 3 2 1 0
 <a 
 id="x1-44010r5"></a>5  byte 0 [1 1 1 1 1 1 0 0]  <-
 <a 
 id="x1-44012r6"></a>6  byte 1 [0 1 0 0 1 0 0 0]
 <a 
 id="x1-44014r7"></a>7  byte 2 [1 1 0 0 1 1 1 0]
 <a 
 id="x1-44016r8"></a>8  byte 3 [0 0 0 0 0 1 1 0]  bytestream length == 4 bytes
 <a 
 id="x1-44018r9"></a>9  
</div>
We read two, two-bit integer fields, resulting in the returned numbers ’b00’ and ’b11’. Two things
are worth noting here:
 <ul class="itemize1">
 <li class="itemize">Although these four bits were originally written as a single four-bit integer, reading
 some other combination of bit-widths from the bitstream is well defined. There are
 no artificial alignment boundaries maintained in the bitstream.
 </li>
 <li class="itemize">The second value is the two-bit-wide integer ’b11’. This value may be interpreted
 either as the unsigned value ’3’, or the signed value ’-1’. Signedness is dependent on
 decode context.</li></ul>

<h5 class="subsubsectionHead">2.1.8 <a 
 id="x1-450002.1.8"></a>end-of-packet alignment</h5>
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.
Externally, each bytestream (encoded bitstream) must begin and end on a byte boundary. Often,
the encoded bitstream is not an integer number of bytes, and so there is unused (uncoded) space
in the last byte of a packet.
Unused space in the last byte of a bytestream is always zeroed during the coding process. Thus,
should this unused space be read, it will return binary zeroes.
Attempting to read past the end of an encoded packet results in an ’end-of-packet’ condition.
End-of-packet is not to be considered an error; it is merely a state indicating that there is
insufficient remaining data to fulfill the desired read size. Vorbis uses truncated packets as a
normal mode of operation, and as such, decoders must handle reading past the end of a packet as
a typical mode of operation. Any further read operations after an ’end-of-packet’ condition shall
also return ’end-of-packet’.

<h5 class="subsubsectionHead">2.1.9 <a 
 id="x1-460002.1.9"></a>reading zero bits</h5>
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
triggered) and then reading a zero bit integer shall succeed, returning 0, and not trigger an
end-of-packet condition. Reading a zero-bit-wide integer after a previous read sets ’end-of-packet’
shall also fail with ’end-of-packet’.

<h3 class="sectionHead">3 <a 
 id="x1-470003"></a>Probability Model and Codebooks</h3>

<h4 class="subsectionHead">3.1 <a 
 id="x1-480003.1"></a>Overview</h4>
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
bitstream itself in the third header, the codec setup header. This packed configuration consists of
multiple ’codebooks’, each containing a specific Huffman-equivalent representation for decoding
compressed codewords as well as an optional lookup table of output vector values to which a
decoded Huffman value is applied as an offset, generating the final decoded output corresponding
to a given compressed codeword.

<h5 class="subsubsectionHead">3.1.1 <a 
 id="x1-490003.1.1"></a>Bitwise operation</h5>
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
read from the stream according to <a 
href="#x1-360002">Section 2</a>, “<a 
href="#x1-360002">Bitpacking Convention</a>”.

<h4 class="subsectionHead">3.2 <a 
 id="x1-500003.2"></a>Packed codebook format</h4>
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 <a 
href="#x1-360002">Section 2</a>, “<a 
href="#x1-360002">Bitpacking Convention</a>” for discussion
relating to non-eight-bit bytes.

<h5 class="subsubsectionHead">3.2.1 <a 
 id="x1-510003.2.1"></a>codebook decode</h5>
A codebook begins with a 24 bit sync pattern, 0x564342:

<div class="fancyvrb" id="fancyvrb7">
<a 
 id="x1-51002r1"></a>1  byte 0: [ 0 1 0 0 0 0 1 0 ] (0x42)
 <a 
 id="x1-51004r2"></a>2  byte 1: [ 0 1 0 0 0 0 1 1 ] (0x43)
 <a 
 id="x1-51006r3"></a>3  byte 2: [ 0 1 0 1 0 1 1 0 ] (0x56)
</div>
16 bit [codebook_dimensions] and 24 bit [codebook_entries] fields:

<div class="fancyvrb" id="fancyvrb8">
<a 
 id="x1-51008r1"></a>1  
 <a 
 id="x1-51010r2"></a>2  byte 3: [ X X X X X X X X ]
 <a 
 id="x1-51012r3"></a>3  byte 4: [ X X X X X X X X ] [codebook_dimensions] (16 bit unsigned)
 <a 
 id="x1-51014r4"></a>4  
 <a 
 id="x1-51016r5"></a>5  byte 5: [ X X X X X X X X ]
 <a 
 id="x1-51018r6"></a>6  byte 6: [ X X X X X X X X ]
 <a 
 id="x1-51020r7"></a>7  byte 7: [ X X X X X X X X ] [codebook_entries] (24 bit unsigned)
 <a 
 id="x1-51022r8"></a>8  
</div>
Next is the [ordered] bit flag:

<div class="fancyvrb" id="fancyvrb9">
<a 
 id="x1-51024r1"></a>1  
 <a 
 id="x1-51026r2"></a>2  byte 8: [               X ] [ordered] (1 bit)
 <a 
 id="x1-51028r3"></a>3  
</div>
Each entry, numbering a total of [codebook_entries], is assigned a codeword length.
We now read the list of codeword lengths and store these lengths in the array
[codebook_codeword_lengths]. Decode of lengths is according to whether the [ordered] flag
is set or unset.
 <ul class="itemize1">
 <li class="itemize">If the [ordered] flag is unset, the codeword list is not length ordered and the decoder
 needs to read each codeword length one-by-one.
 The decoder first reads one additional bit flag, the [sparse] flag. This flag determines
 whether or not the codebook contains unused entries that are not to be included in

the codeword decode tree:
 
 <div class="fancyvrb" id="fancyvrb10">
<a 
 id="x1-51030r1"></a>1  byte 8: [             X 1 ] [sparse] flag (1 bit)
</div>
 The decoder now performs for each of the [codebook_entries] codebook entries:
 
 <div class="fancyvrb" id="fancyvrb11">
<a 
 id="x1-51032r1"></a>1  
 <a 
 id="x1-51034r2"></a>2    1) if([sparse] is set) {
 <a 
 id="x1-51036r3"></a>3  
 <a 
 id="x1-51038r4"></a>4           2) [flag] = read one bit;
 <a 
 id="x1-51040r5"></a>5           3) if([flag] is set) {
 <a 
 id="x1-51042r6"></a>6  
 <a 
 id="x1-51044r7"></a>7                4) [length] = read a five bit unsigned integer;
 <a 
 id="x1-51046r8"></a>8                5) codeword length for this entry is [length]+1;
 <a 
 id="x1-51048r9"></a>9  
 <a 
 id="x1-51050r10"></a>10              } else {
 <a 
 id="x1-51052r11"></a>11  
 <a 
 id="x1-51054r12"></a>12                6) this entry is unused.  mark it as such.
 <a 
 id="x1-51056r13"></a>13  
 <a 
 id="x1-51058r14"></a>14              }
 <a 
 id="x1-51060r15"></a>15  
 <a 
 id="x1-51062r16"></a>16       } else the sparse flag is not set {
 <a 
 id="x1-51064r17"></a>17  
 <a 
 id="x1-51066r18"></a>18          7) [length] = read a five bit unsigned integer;
 <a 
 id="x1-51068r19"></a>19          8) the codeword length for this entry is [length]+1;
 <a 
 id="x1-51070r20"></a>20  
 <a 
 id="x1-51072r21"></a>21       }
 <a 
 id="x1-51074r22"></a>22  
</div>
 </li>
 <li class="itemize">If the [ordered] flag is set, the codeword list for this codebook is encoded in
 ascending length order. Rather than reading a length for every codeword, the
 encoder reads the number of codewords per length. That is, beginning at entry
 zero:
 
 <div class="fancyvrb" id="fancyvrb12">
<a 
 id="x1-51076r1"></a>1    1) [current_entry] = 0;
 <a 
 id="x1-51078r2"></a>2    2) [current_length] = read a five bit unsigned integer and add 1;
 <a 
 id="x1-51080r3"></a>3    3) [number] = read <a 
href="#x1-1170009.2.1">ilog</a>([codebook_entries] - [current_entry]) bits as an unsigned integer
 <a 
 id="x1-51082r4"></a>4    4) set the entries [current_entry] through [current_entry]+[number]-1, inclusive,
 <a 
 id="x1-51084r5"></a>5      of the [codebook_codeword_lengths] array to [current_length]
 <a 
 id="x1-51086r6"></a>6    5) set [current_entry] to [number] + [current_entry]
 <a 
 id="x1-51088r7"></a>7    6) increment [current_length] by 1
 <a 
 id="x1-51090r8"></a>8    7) if [current_entry] is greater than [codebook_entries] ERROR CONDITION;
 <a 
 id="x1-51092r9"></a>9      the decoder will not be able to read this stream.
 <a 
 id="x1-51094r10"></a>10    8) if [current_entry] is less than [codebook_entries], repeat process starting at 3)
 <a 
 id="x1-51096r11"></a>11    9) done.

</div>
 </li></ul>
After all codeword lengths have been decoded, the decoder reads the vector lookup table. Vorbis
I supports three lookup types:
 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-51098x1">No lookup
 </li>
 <li 
 class="enumerate" id="x1-51100x2">Implicitly populated value mapping (lattice VQ)
 </li>
 <li 
 class="enumerate" id="x1-51102x3">Explicitly populated value mapping (tessellated or ’foam’ VQ)</li></ol>
The lookup table type is read as a four bit unsigned integer:
<div class="fancyvrb" id="fancyvrb13">
<a 
 id="x1-51104r1"></a>1    1) [codebook_lookup_type] = read four bits as an unsigned integer
</div>
Codebook decode precedes according to [codebook_lookup_type]:
 <ul class="itemize1">
 <li class="itemize">Lookup type zero indicates no lookup to be read. Proceed past lookup decode.
 </li>
 <li class="itemize">Lookup types one and two are similar, differing only in the number of lookup values to
 be read. Lookup type one reads a list of values that are permuted in a set pattern to
 build a list of vectors, each vector of order [codebook_dimensions] scalars. Lookup
 type two builds the same vector list, but reads each scalar for each vector explicitly,
 rather than building vectors from a smaller list of possible scalar values. Lookup
 decode proceeds as follows:
 
 <div class="fancyvrb" id="fancyvrb14">
<a 
 id="x1-51106r1"></a>1    1) [codebook_minimum_value] = <a 
href="#x1-1180009.2.2">float32_unpack</a>( read 32 bits as an unsigned integer)
 <a 
 id="x1-51108r2"></a>2    2) [codebook_delta_value] = <a 
href="#x1-1180009.2.2">float32_unpack</a>( read 32 bits as an unsigned integer)
 <a 
 id="x1-51110r3"></a>3    3) [codebook_value_bits] = read 4 bits as an unsigned integer and add 1
 <a 
 id="x1-51112r4"></a>4    4) [codebook_sequence_p] = read 1 bit as a boolean flag
 <a 
 id="x1-51114r5"></a>5  
 <a 
 id="x1-51116r6"></a>6    if ( [codebook_lookup_type] is 1 ) {
 <a 
 id="x1-51118r7"></a>7  
 <a 
 id="x1-51120r8"></a>8       5) [codebook_lookup_values] = <a 
href="#x1-1190009.2.3">lookup1_values</a>([codebook_entries], [codebook_dimensions] )
 <a 
 id="x1-51122r9"></a>9  
 <a 
 id="x1-51124r10"></a>10    } else {
 <a 
 id="x1-51126r11"></a>11  
 <a 
 id="x1-51128r12"></a>12       6) [codebook_lookup_values] = [codebook_entries] * [codebook_dimensions]
 <a 
 id="x1-51130r13"></a>13  
 <a 
 id="x1-51132r14"></a>14    }
 <a 
 id="x1-51134r15"></a>15  
 <a 
 id="x1-51136r16"></a>16    7) read a total of [codebook_lookup_values] unsigned integers of [codebook_value_bits] each;

<a 
 id="x1-51138r17"></a>17       store these in order in the array [codebook_multiplicands]
</div>
 </li>
 <li class="itemize">A [codebook_lookup_type] of greater than two is reserved and indicates a stream that is
 not decodable by the specification in this document.
 </li></ul>
An ’end of packet’ during any read operation in the above steps is considered an error condition
rendering the stream undecodable.
<a 
 id="x1-520003.2.1"></a>Huffman decision tree representation
The [codebook_codeword_lengths] array and [codebook_entries] value uniquely define the
Huffman decision tree used for entropy decoding.
Briefly, each used codebook entry (recall that length-unordered codebooks support unused
codeword entries) is assigned, in order, the lowest valued unused binary Huffman codeword
possible. Assume the following codeword length list:

<div class="fancyvrb" id="fancyvrb15">
<a 
 id="x1-52002r1"></a>1  entry 0: length 2
 <a 
 id="x1-52004r2"></a>2  entry 1: length 4
 <a 
 id="x1-52006r3"></a>3  entry 2: length 4
 <a 
 id="x1-52008r4"></a>4  entry 3: length 4
 <a 
 id="x1-52010r5"></a>5  entry 4: length 4
 <a 
 id="x1-52012r6"></a>6  entry 5: length 2
 <a 
 id="x1-52014r7"></a>7  entry 6: length 3
 <a 
 id="x1-52016r8"></a>8  entry 7: length 3
</div>
Assigning codewords in order (lowest possible value of the appropriate length to highest) results
in the following codeword list:

<div class="fancyvrb" id="fancyvrb16">
<a 
 id="x1-52018r1"></a>1  entry 0: length 2 codeword 00
 <a 
 id="x1-52020r2"></a>2  entry 1: length 4 codeword 0100
 <a 
 id="x1-52022r3"></a>3  entry 2: length 4 codeword 0101
 <a 
 id="x1-52024r4"></a>4  entry 3: length 4 codeword 0110
 <a 
 id="x1-52026r5"></a>5  entry 4: length 4 codeword 0111
 <a 
 id="x1-52028r6"></a>6  entry 5: length 2 codeword 10
 <a 
 id="x1-52030r7"></a>7  entry 6: length 3 codeword 110
 <a 
 id="x1-52032r8"></a>8  entry 7: length 3 codeword 111
</div>

<a 
 id="x1-530003.2.1"></a>Note: Unlike most binary numerical values in this document, we intend the above codewords to
be read and used bit by bit from left to right, thus the codeword ’001’ is the bit string ’zero, zero,
one’. When determining ’lowest possible value’ in the assignment definition above, the leftmost
bit is the MSb.
It is clear that the codeword length list represents a Huffman decision tree with the entry
numbers equivalent to the leaves numbered left-to-right:
<div class="center" 
>

<img 
src="hufftree.png" alt="PIC" 
>
 <div class="caption" 
>Figure 4: huffman tree illustration</div>
</div>
As we assign codewords in order, we see that each choice constructs a new leaf in the leftmost
possible position.
Note that it’s possible to underspecify or overspecify a Huffman tree via the length list.
In the above example, if codeword seven were eliminated, it’s clear that the tree is
unfinished:
<div class="center" 
>

<img 
src="hufftree-under.png" alt="PIC" 
>
 <div class="caption" 
>Figure 5: underspecified huffman tree illustration</div>
</div>
Similarly, in the original codebook, it’s clear that the tree is fully populated and a ninth
codeword is impossible. Both underspecified and overspecified trees are an error condition
rendering the stream undecodable. Take special care that a codebook with a single used
entry is handled properly; it consists of a single codework of zero bits and ’reading’
a value out of such a codebook always returns the single used value and sinks zero
bits.
Codebook entries marked ’unused’ are simply skipped in the assigning process. They have no
codeword and do not appear in the decision tree, thus it’s impossible for any bit pattern read
from the stream to decode to that entry number.

<a 
 id="x1-540003.2.1"></a>VQ lookup table vector representation
Unpacking the VQ lookup table vectors relies on the following values:
<div class="fancyvrb" id="fancyvrb17">
<a 
 id="x1-54002r1"></a>1  the [codebook_multiplicands] array
 <a 
 id="x1-54004r2"></a>2  [codebook_minimum_value]
 <a 
 id="x1-54006r3"></a>3  [codebook_delta_value]
 <a 
 id="x1-54008r4"></a>4  [codebook_sequence_p]
 <a 
 id="x1-54010r5"></a>5  [codebook_lookup_type]
 <a 
 id="x1-54012r6"></a>6  [codebook_entries]
 <a 
 id="x1-54014r7"></a>7  [codebook_dimensions]
 <a 
 id="x1-54016r8"></a>8  [codebook_lookup_values]
</div>
Decoding (unpacking) a specific vector in the vector lookup table proceeds according to
[codebook_lookup_type]. The unpacked vector values are what a codebook would return
during audio packet decode in a VQ context.
<a 
 id="x1-550003.2.1"></a>Vector value decode: Lookup type 1
Lookup type one specifies a lattice VQ lookup table built algorithmically from a list of
scalar values. Calculate (unpack) the final values of a codebook entry vector from
the entries in [codebook_multiplicands] as follows ([value_vector] is the output
vector representing the vector of values for entry number [lookup_offset] in this
codebook):

<div class="fancyvrb" id="fancyvrb18">
<a 
 id="x1-55002r1"></a>1    1) [last] = 0;
 <a 
 id="x1-55004r2"></a>2    2) [index_divisor] = 1;
 <a 
 id="x1-55006r3"></a>3    3) iterate [i] over the range 0 ... [codebook_dimensions]-1 (once for each scalar value in the value vector) {
 <a 
 id="x1-55008r4"></a>4  
 <a 
 id="x1-55010r5"></a>5         4) [multiplicand_offset] = ( [lookup_offset] divided by [index_divisor] using integer
 <a 
 id="x1-55012r6"></a>6            division ) integer modulo [codebook_lookup_values]
 <a 
 id="x1-55014r7"></a>7  
 <a 
 id="x1-55016r8"></a>8         5) vector [value_vector] element [i] =
 <a 
 id="x1-55018r9"></a>9              ( [codebook_multiplicands] array element number [multiplicand_offset] ) *
 <a 
 id="x1-55020r10"></a>10              [codebook_delta_value] + [codebook_minimum_value] + [last];
 <a 
 id="x1-55022r11"></a>11  
 <a 
 id="x1-55024r12"></a>12         6) if ( [codebook_sequence_p] is set ) then set [last] = vector [value_vector] element [i]
 <a 
 id="x1-55026r13"></a>13  
 <a 
 id="x1-55028r14"></a>14         7) [index_divisor] = [index_divisor] * [codebook_lookup_values]
 <a 
 id="x1-55030r15"></a>15  
 <a 
 id="x1-55032r16"></a>16       }
 <a 
 id="x1-55034r17"></a>17  
 <a 
 id="x1-55036r18"></a>18    8) vector calculation completed.
</div>

<a 
 id="x1-560003.2.1"></a>Vector value decode: Lookup type 2
Lookup type two specifies a VQ lookup table in which each scalar in each vector is explicitly set
by the [codebook_multiplicands] array in a one-to-one mapping. Calculate [unpack] the final
values of a codebook entry vector from the entries in [codebook_multiplicands] as follows
([value_vector] is the output vector representing the vector of values for entry number
[lookup_offset] in this codebook):

<div class="fancyvrb" id="fancyvrb19">
<a 
 id="x1-56002r1"></a>1    1) [last] = 0;
 <a 
 id="x1-56004r2"></a>2    2) [multiplicand_offset] = [lookup_offset] * [codebook_dimensions]
 <a 
 id="x1-56006r3"></a>3    3) iterate [i] over the range 0 ... [codebook_dimensions]-1 (once for each scalar value in the value vector) {
 <a 
 id="x1-56008r4"></a>4  
 <a 
 id="x1-56010r5"></a>5         4) vector [value_vector] element [i] =
 <a 
 id="x1-56012r6"></a>6              ( [codebook_multiplicands] array element number [multiplicand_offset] ) *
 <a 
 id="x1-56014r7"></a>7              [codebook_delta_value] + [codebook_minimum_value] + [last];
 <a 
 id="x1-56016r8"></a>8  
 <a 
 id="x1-56018r9"></a>9         5) if ( [codebook_sequence_p] is set ) then set [last] = vector [value_vector] element [i]
 <a 
 id="x1-56020r10"></a>10  
 <a 
 id="x1-56022r11"></a>11         6) increment [multiplicand_offset]
 <a 
 id="x1-56024r12"></a>12  
 <a 
 id="x1-56026r13"></a>13       }
 <a 
 id="x1-56028r14"></a>14  
 <a 
 id="x1-56030r15"></a>15    7) vector calculation completed.
</div>

<h4 class="subsectionHead">3.3 <a 
 id="x1-570003.3"></a>Use of the codebook abstraction</h4>
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
then returns that entry number to the decoder (when used in a scalar entropy coding context), or
uses that entry number as an offset into the VQ lookup table, returning a vector of values (when
used in a context desiring a VQ value). Scalar or VQ context is always explicit; any
call to the codebook mechanism requests either a scalar entry number or a lookup
vector.
Note that VQ lookup type zero indicates that there is no lookup table; requesting
decode using a codebook of lookup type 0 in any context expecting a vector return
value (even in a case where a vector of dimension one) is forbidden. If decoder setup
or decode requests such an action, that is an error condition rendering the packet

undecodable.
Using a codebook to read from the packet bitstream consists first of reading and decoding the
next codeword in the bitstream. The decoder reads bits until the accumulated bits match a
codeword in the codebook. This process can be though of as logically walking the
Huffman decode tree by reading one bit at a time from the bitstream, and using the
bit as a decision boolean to take the 0 branch (left in the above examples) or the 1
branch (right in the above examples). Walking the tree finishes when the decode process
hits a leaf in the decision tree; the result is the entry number corresponding to that
leaf. Reading past the end of a packet propagates the ’end-of-stream’ condition to the
decoder.
When used in a scalar context, the resulting codeword entry is the desired return
value.
When used in a VQ context, the codeword entry number is used as an offset into the VQ lookup
table. The value returned to the decoder is the vector of scalars corresponding to this
offset.

<h3 class="sectionHead">4 <a 
 id="x1-580004"></a>Codec Setup and Packet Decode</h3>

<h4 class="subsectionHead">4.1 <a 
 id="x1-590004.1"></a>Overview</h4>
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
process, which is provided in <a 
href="#x1-20001">Section 1</a>, “<a 
href="#x1-20001">Introduction and Description</a>”. <a 
href="#x1-360002">Section 2</a>,
“<a 
href="#x1-360002">Bitpacking Convention</a>” covers reading and writing bit fields from and to bitstream
packets.

<h4 class="subsectionHead">4.2 <a 
 id="x1-600004.2"></a>Header decode and decode setup</h4>
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
compliance. An end-of-packet condition during decoding the first or third header packet renders
the stream undecodable. End-of-packet decoding the comment header is a non-fatal error
condition.

<h5 class="subsubsectionHead">4.2.1 <a 
 id="x1-610004.2.1"></a>Common header decode</h5>
Each header packet begins with the same header fields.

<div class="fancyvrb" id="fancyvrb20">
<a 
 id="x1-61002r1"></a>1    1) [packet_type] : 8 bit value
 <a 
 id="x1-61004r2"></a>2    2) 0x76, 0x6f, 0x72, 0x62, 0x69, 0x73: the characters ’v’,’o’,’r’,’b’,’i’,’s’ as six octets
</div>

Decode continues according to packet type; the identification header is type 1, the comment
header type 3 and the setup header type 5 (these types are all odd as a packet with a leading
single bit of ’0’ is an audio packet). The packets must occur in the order of identification,
comment, setup.

<h5 class="subsubsectionHead">4.2.2 <a 
 id="x1-620004.2.2"></a>Identification header</h5>
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
stream. The identification header is coded as follows:

<div class="fancyvrb" id="fancyvrb21">
<a 
 id="x1-62002r1"></a>1   1) [vorbis_version] = read 32 bits as unsigned integer
 <a 
 id="x1-62004r2"></a>2   2) [audio_channels] = read 8 bit integer as unsigned
 <a 
 id="x1-62006r3"></a>3   3) [audio_sample_rate] = read 32 bits as unsigned integer
 <a 
 id="x1-62008r4"></a>4   4) [bitrate_maximum] = read 32 bits as signed integer
 <a 
 id="x1-62010r5"></a>5   5) [bitrate_nominal] = read 32 bits as signed integer
 <a 
 id="x1-62012r6"></a>6   6) [bitrate_minimum] = read 32 bits as signed integer
 <a 
 id="x1-62014r7"></a>7   7) [blocksize_0] = 2 exponent (read 4 bits as unsigned integer)
 <a 
 id="x1-62016r8"></a>8   8) [blocksize_1] = 2 exponent (read 4 bits as unsigned integer)
 <a 
 id="x1-62018r9"></a>9   9) [framing_flag] = read one bit
</div>
[vorbis_version] is to read ’0’ in order to be compatible with this document. Both
[audio_channels] and [audio_sample_rate] must read greater than zero. Allowed final
blocksize values are 64, 128, 256, 512, 1024, 2048, 4096 and 8192 in Vorbis I. [blocksize_0]
must be less than or equal to [blocksize_1]. The framing bit must be nonzero. Failure to meet
any of these conditions renders a stream undecodable.
The bitrate fields above are used only as hints. The nominal bitrate field especially may be
considerably off in purely VBR streams. The fields are meaningful only when greater than
zero.
 <ul class="itemize1">
 <li class="itemize">All three fields set to the same value implies a fixed rate, or tightly bounded, nearly
 fixed-rate bitstream
 </li>
 <li class="itemize">Only nominal set implies a VBR or ABR stream that averages the nominal bitrate

</li>
 <li class="itemize">Maximum and or minimum set implies a VBR bitstream that obeys the bitrate limits
 </li>
 <li class="itemize">None set indicates the encoder does not care to speculate.</li></ul>

<h5 class="subsubsectionHead">4.2.3 <a 
 id="x1-630004.2.3"></a>Comment header</h5>
Comment header decode and data specification is covered in <a 
href="#x1-810005">Section 5</a>, “<a 
href="#x1-810005">comment field and
header specification</a>”.

<h5 class="subsubsectionHead">4.2.4 <a 
 id="x1-640004.2.4"></a>Setup header</h5>
Vorbis codec setup is configurable to an extreme degree:
<div class="center" 
>

<img 
src="components.png" alt="PIC" 
>
 <div class="caption" 
>Figure 6: decoder pipeline configuration</div>
</div>
The setup header contains the bulk of the codec setup information needed for decode. The setup
header contains, in order, the lists of codebook configurations, time-domain transform
configurations (placeholders in Vorbis I), floor configurations, residue configurations, channel
mapping configurations and mode configurations. It finishes with a framing bit of ’1’. Header
decode proceeds in the following order:
<a 
 id="x1-650004.2.4"></a>Codebooks

<ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-65002x1">[vorbis_codebook_count] = read eight bits as unsigned integer and add one
 </li>
 <li 
 class="enumerate" id="x1-65004x2">Decode [vorbis_codebook_count] codebooks in order as defined in <a 
href="#x1-470003">Section 3</a>,
 “<a 
href="#x1-470003">Probability Model and Codebooks</a>”. Save each configuration, in order, in an array
 of codebook configurations [vorbis_codebook_configurations].</li></ol>
<a 
 id="x1-660004.2.4"></a>Time domain transforms
These hooks are placeholders in Vorbis I. Nevertheless, the configuration placeholder values must
be read to maintain bitstream sync.

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-66002x1">[vorbis_time_count] = read 6 bits as unsigned integer and add one
 </li>
 <li 
 class="enumerate" id="x1-66004x2">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.</li></ol>
<a 
 id="x1-670004.2.4"></a>Floors
Vorbis uses two floor types; header decode is handed to the decode abstraction of the appropriate
type.

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-67002x1">[vorbis_floor_count] = read 6 bits as unsigned integer and add one
 </li>
 <li 
 class="enumerate" id="x1-67004x2">For each [i] of [vorbis_floor_count] floor numbers:
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-67006x1">read the floor type: vector [vorbis_floor_types] element [i] = read 16 bits
 as unsigned integer
 </li>
 <li 
 class="enumerate" id="x1-67008x2">If the floor type is zero, decode the floor configuration as defined in <a 
href="#x1-890006">Section 6</a>,
 “<a 
href="#x1-890006">Floor type 0 setup and decode</a>”; save this configuration in slot [i] of the floor
 configuration array [vorbis_floor_configurations].

</li>
 <li 
 class="enumerate" id="x1-67010x3">If the floor type is one, decode the floor configuration as defined in <a 
href="#x1-950007">Section 7</a>,
 “<a 
href="#x1-950007">Floor type 1 setup and decode</a>”; save this configuration in slot [i] of the floor
 configuration array [vorbis_floor_configurations].
 </li>
 <li 
 class="enumerate" id="x1-67012x4">If the the floor type is greater than one, this stream is undecodable; ERROR
 CONDITION</li></ol>
 </li></ol>
<a 
 id="x1-680004.2.4"></a>Residues
Vorbis uses three residue types; header decode of each type is identical.

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-68002x1">[vorbis_residue_count] = read 6 bits as unsigned integer and add one
 </li>
 <li 
 class="enumerate" id="x1-68004x2">For each of [vorbis_residue_count] residue numbers:
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-68006x1">read the residue type; vector [vorbis_residue_types] element [i] = read 16
 bits as unsigned integer
 </li>
 <li 
 class="enumerate" id="x1-68008x2">If the residue type is zero, one or two, decode the residue configuration as defined
 in <a 
href="#x1-1020008">Section 8</a>, “<a 
href="#x1-1020008">Residue setup and decode</a>”; save this configuration in slot [i] of
 the residue configuration array [vorbis_residue_configurations].
 </li>
 <li 
 class="enumerate" id="x1-68010x3">If the the residue type is greater than two, this stream is undecodable; ERROR
 CONDITION</li></ol>
 </li></ol>
<a 
 id="x1-690004.2.4"></a>Mappings
Mappings are used to set up specific pipelines for encoding multichannel audio with varying
channel mapping applications. Vorbis I uses a single mapping type (0), with implicit PCM
channel mappings.

<ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-69002x1">[vorbis_mapping_count] = read 6 bits as unsigned integer and add one
 </li>
 <li 
 class="enumerate" id="x1-69004x2">For each [i] of [vorbis_mapping_count] mapping numbers:
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-69006x1">read the mapping type: 16 bits as unsigned integer. There’s no reason to save
 the mapping type in Vorbis I.
 </li>
 <li 
 class="enumerate" id="x1-69008x2">If the mapping type is nonzero, the stream is undecodable
 </li>
 <li 
 class="enumerate" id="x1-69010x3">If the mapping type is zero:
 <ol class="enumerate3" >
 <li 
 class="enumerate" id="x1-69012x1">read 1 bit as a boolean flag
 <ol class="enumerate4" >
 <li 
 class="enumerate" id="x1-69014x1">if set, [vorbis_mapping_submaps] = read 4 bits as unsigned integer
 and add one
 </li>
 <li 
 class="enumerate" id="x1-69016x2">if unset, [vorbis_mapping_submaps] = 1</li></ol>
 </li>
 <li 
 class="enumerate" id="x1-69018x2">read 1 bit as a boolean flag
 <ol class="enumerate4" >
 <li 
 class="enumerate" id="x1-69020x1">if set, square polar channel mapping is in use:
 <ul class="itemize1">
 <li class="itemize">[vorbis_mapping_coupling_steps] = read 8 bits as unsigned
 integer and add one
 </li>
 <li class="itemize">for [j] each of [vorbis_mapping_coupling_steps] steps:
 <ul class="itemize2">
 <li class="itemize">vector [vorbis_mapping_magnitude] element [j]= read
 <a 
href="#x1-1170009.2.1">ilog</a>([audio_channels] - 1) bits as unsigned integer
 </li>
 <li class="itemize">vector [vorbis_mapping_angle] element [j]= read
 <a 
href="#x1-1170009.2.1">ilog</a>([audio_channels] - 1) bits as unsigned integer
 </li>

<li class="itemize">the numbers read in the above two steps are channel numbers
 representing the channel to treat as magnitude and the channel
 to treat as angle, respectively. If for any coupling step the
 angle channel number equals the magnitude channel number, the
 magnitude channel number is greater than [audio_channels]-1, or
 the angle channel is greater than [audio_channels]-1, the stream
 is undecodable.</li></ul>
 </li></ul>
 </li>
 <li 
 class="enumerate" id="x1-69022x2">if unset, [vorbis_mapping_coupling_steps] = 0</li></ol>
 </li>
 <li 
 class="enumerate" id="x1-69024x3">read 2 bits (reserved field); if the value is nonzero, the stream is undecodable
 </li>
 <li 
 class="enumerate" id="x1-69026x4">if [vorbis_mapping_submaps] is greater than one, we read channel multiplex
 settings. For each [j] of [audio_channels] channels:
 <ol class="enumerate4" >
 <li 
 class="enumerate" id="x1-69028x1">vector [vorbis_mapping_mux] element [j] = read 4 bits as unsigned
 integer
 </li>
 <li 
 class="enumerate" id="x1-69030x2">if the value is greater than the highest numbered submap
 ([vorbis_mapping_submaps] - 1), this in an error condition rendering
 the stream undecodable</li></ol>
 </li>
 <li 
 class="enumerate" id="x1-69032x5">for each submap [j] of [vorbis_mapping_submaps] submaps, read the floor and
 residue numbers for use in decoding that submap:
 <ol class="enumerate4" >
 <li 
 class="enumerate" id="x1-69034x1">read and discard 8 bits (the unused time configuration placeholder)
 </li>
 <li 
 class="enumerate" id="x1-69036x2">read 8 bits as unsigned integer for the floor number; save in vector
 [vorbis_mapping_submap_floor] element [j]
 </li>
 <li 
 class="enumerate" id="x1-69038x3">verify the floor number is not greater than the highest number floor
 configured for the bitstream. If it is, the bitstream is undecodable
 </li>
 <li 
 class="enumerate" id="x1-69040x4">read 8 bits as unsigned integer for the residue number; save in vector
 [vorbis_mapping_submap_residue] element [j]

</li>
 <li 
 class="enumerate" id="x1-69042x5">verify the residue number is not greater than the highest number residue
 configured for the bitstream. If it is, the bitstream is undecodable</li></ol>
 </li>
 <li 
 class="enumerate" id="x1-69044x6">save this mapping configuration in slot [i] of the mapping configuration array
 [vorbis_mapping_configurations].</li></ol>
 </li></ol>
 </li></ol>
<a 
 id="x1-700004.2.4"></a>Modes
 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-70002x1">[vorbis_mode_count] = read 6 bits as unsigned integer and add one
 </li>
 <li 
 class="enumerate" id="x1-70004x2">For each of [vorbis_mode_count] mode numbers:
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-70006x1">[vorbis_mode_blockflag] = read 1 bit
 </li>
 <li 
 class="enumerate" id="x1-70008x2">[vorbis_mode_windowtype] = read 16 bits as unsigned integer
 </li>
 <li 
 class="enumerate" id="x1-70010x3">[vorbis_mode_transformtype] = read 16 bits as unsigned integer
 </li>
 <li 
 class="enumerate" id="x1-70012x4">[vorbis_mode_mapping] = read 8 bits as unsigned integer
 </li>
 <li 
 class="enumerate" id="x1-70014x5">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.
 </li>
 <li 
 class="enumerate" id="x1-70016x6">save this mode configuration in slot [i] of the mode configuration array
 [vorbis_mode_configurations].</li></ol>
 </li>
 <li 
 class="enumerate" id="x1-70018x3">read 1 bit as a framing flag. If unset, a framing error occurred and the stream is not
 decodable.</li></ol>

After reading mode descriptions, setup header decode is complete.

<h4 class="subsectionHead">4.3 <a 
 id="x1-710004.3"></a>Audio packet decode and synthesis</h4>
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. A non-audio packet when audio is
expected indicates stream corruption or a non-compliant stream. The decoder must ignore the
packet and not attempt decoding it to audio.

<h5 class="subsubsectionHead">4.3.1 <a 
 id="x1-720004.3.1"></a>packet type, mode and window decode</h5>

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-72002x1">read 1 bit [packet_type]; check that packet type is 0 (audio)
 </li>
 <li 
 class="enumerate" id="x1-72004x2">read <a 
href="#x1-1170009.2.1">ilog</a>([vorbis˙mode˙count]-1) bits [mode_number]
 </li>
 <li 
 class="enumerate" id="x1-72006x3">decode blocksize [n] is equal to [blocksize_0] if [vorbis_mode_blockflag] is 0,
 else [n] is equal to [blocksize_1].
 </li>
 <li 
 class="enumerate" id="x1-72008x4">perform window selection and setup; this window is used later by the inverse
 MDCT:
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-72010x1">if this is a long window (the [vorbis_mode_blockflag] flag of this mode is
 set):
 <ol class="enumerate3" >
 <li 
 class="enumerate" id="x1-72012x1">read 1 bit for [previous_window_flag]
 </li>
 <li 
 class="enumerate" id="x1-72014x2">read 1 bit for [next_window_flag]

</li>
 <li 
 class="enumerate" id="x1-72016x3">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 <a 
href="#paragraph.1" >paragraph <a 
href="#x1-260001.3.2">1.3.2</a></a>,
 “<a 
href="#x1-260001.3.2">Window shape decode (long windows only)</a>” for an illustration of
 overlapping dissimilar windows. Else, the left half window will have normal
 long shape.
 </li>
 <li 
 class="enumerate" id="x1-72018x4">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 <a 
href="#x1-260001.3.2">paragraph 1.3.2</a>,
 “<a 
href="#x1-260001.3.2">Window shape decode (long windows only)</a>” for an illustration of
 overlapping dissimilar windows. Else, the left right window will have normal
 long shape.</li></ol>
 </li>
 <li 
 class="enumerate" id="x1-72020x2">if this is a short window, the window is always the same short-window
 shape.</li></ol>
 </li></ol>
Vorbis windows all use the slope function y = sin(<img 
src="Vorbis_I_spec1x.png" alt="π2" class="frac" align="middle"> ∗ sin 2((x + 0.5)∕n ∗ π)), where n is window
size and x ranges 0…n− 1, but dissimilar lapping requirements can affect overall shape. Window
generation proceeds as follows:

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-72022x1">[window_center] = [n] / 2
 </li>
 <li 
 class="enumerate" id="x1-72024x2">if ([vorbis_mode_blockflag] is set and [previous_window_flag] is not set)
 then
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-72026x1">[left_window_start] = [n]/4 - [blocksize_0]/4
 </li>
 <li 
 class="enumerate" id="x1-72028x2">[left_window_end] = [n]/4 + [blocksize_0]/4
 </li>
 <li 
 class="enumerate" id="x1-72030x3">[left_n] = [blocksize_0]/2</li></ol>
 else
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-72032x1">[left_window_start] = 0
 </li>
 <li 
 class="enumerate" id="x1-72034x2">[left_window_end] = [window_center]

</li>
 <li 
 class="enumerate" id="x1-72036x3">[left_n] = [n]/2</li></ol>
 </li>
 <li 
 class="enumerate" id="x1-72038x3">if ([vorbis_mode_blockflag] is set and [next_window_flag] is not set) then
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-72040x1">[right_window_start] = [n]*3/4 - [blocksize_0]/4
 </li>
 <li 
 class="enumerate" id="x1-72042x2">[right_window_end] = [n]*3/4 + [blocksize_0]/4
 </li>
 <li 
 class="enumerate" id="x1-72044x3">[right_n] = [blocksize_0]/2</li></ol>
 else
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-72046x1">[right_window_start] = [window_center]
 </li>
 <li 
 class="enumerate" id="x1-72048x2">[right_window_end] = [n]
 </li>
 <li 
 class="enumerate" id="x1-72050x3">[right_n] = [n]/2</li></ol>
 </li>
 <li 
 class="enumerate" id="x1-72052x4">window from range 0 ... [left_window_start]-1 inclusive is zero
 </li>
 <li 
 class="enumerate" id="x1-72054x5">for [i] in range [left_window_start] ... [left_window_end]-1, window([i]) =
 sin(<img 
src="Vorbis_I_spec2x.png" alt="π
2" class="frac" align="middle"> ∗ sin 2( ([i]-[left_window_start]+0.5) / [left_n] ∗<img 
src="Vorbis_I_spec3x.png" alt="π
2" class="frac" align="middle">) )
 </li>
 <li 
 class="enumerate" id="x1-72056x6">window from range [left_window_end] ... [right_window_start]-1 inclusive is
 one
 </li>
 <li 
 class="enumerate" id="x1-72058x7">for [i] in range [right_window_start] ... [right_window_end]-1, window([i]) =
 sin(<img 
src="Vorbis_I_spec4x.png" alt="π
2" class="frac" align="middle"> ∗ sin 2( ([i]-[right_window_start]+0.5) / [right_n] ∗<img 
src="Vorbis_I_spec5x.png" alt="π
2" class="frac" align="middle"> + <img 
src="Vorbis_I_spec6x.png" alt="π
2" class="frac" align="middle">) )
 </li>
 <li 
 class="enumerate" id="x1-72060x8">window from range [right_window_start] ... [n]-1 is zero</li></ol>
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.

<h5 class="subsubsectionHead">4.3.2 <a 
 id="x1-730004.3.2"></a>floor curve decode</h5>
From this point on, we assume out decode context is using mode number [mode_number]
from configuration array [vorbis_mode_configurations] and the map number
[vorbis_mode_mapping] (specified by the current mode) taken from the mapping configuration
array [vorbis_mapping_configurations].
Floor curves are decoded one-by-one in channel order.
For each floor [i] of [audio_channels]
 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-73002x1">[submap_number] = element [i] of vector [vorbis˙mapping˙mux]
 </li>
 <li 
 class="enumerate" id="x1-73004x2">[floor_number] = element [submap_number] of vector [vorbis˙submap˙floor]
 </li>
 <li 
 class="enumerate" id="x1-73006x3">if the floor type of this floor (vector
 [vorbis_floor_types] element [floor_number]) is zero then decode the floor for
 channel [i] according to the <a 
href="#x1-930006.2.2">subsubsection 6.2.2</a>, “<a 
href="#x1-930006.2.2">packet decode</a>”
 </li>
 <li 
 class="enumerate" id="x1-73008x4">if the type of this floor is one then decode the floor for channel [i] according to the
 <a 
href="#x1-1000007.2.2">paragraph 7.2.2</a>, “<a 
href="#x1-1000007.2.2">packet decode</a>”
 </li>
 <li 
 class="enumerate" id="x1-73010x5">save the needed decoded floor information for channel for later synthesis
 </li>
 <li 
 class="enumerate" id="x1-73012x6">if the decoded floor returned ’unused’, set vector [no_residue] element [i] to true,
 else set vector [no_residue] element [i] to false</li></ol>
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.

<h5 class="subsubsectionHead">4.3.3 <a 
 id="x1-740004.3.3"></a>nonzero vector propagate</h5>
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
coded in the stream, save for one complication. If some vectors are used and some are not,

channel coupling could result in mixing a zeroed and nonzeroed vector to produce two nonzeroed
vectors.
for each [i] from 0 ... [vorbis_mapping_coupling_steps]-1

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-74002x1">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.</li></ol>

<h5 class="subsubsectionHead">4.3.4 <a 
 id="x1-750004.3.4"></a>residue decode</h5>
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

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-75002x1">[ch] = 0
 </li>
 <li 
 class="enumerate" id="x1-75004x2">for each channel [j] in order from 0 ... [audio_channels] - 1
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-75006x1">if channel [j] in submap [i] (vector [vorbis_mapping_mux] element [j] is equal to
 [i])
 <ol class="enumerate3" >
 <li 
 class="enumerate" id="x1-75008x1">if vector [no_residue] element [j] is true
 <ol class="enumerate4" >
 <li 
 class="enumerate" id="x1-75010x1">vector [do_not_decode_flag] element [ch] is set</li></ol>
 else
 <ol class="enumerate4" >
 <li 
 class="enumerate" id="x1-75012x1">vector [do_not_decode_flag] element [ch] is unset</li></ol>
 </li>
 <li 
 class="enumerate" id="x1-75014x2">increment [ch]</li></ol>

</li></ol>
 </li>
 <li 
 class="enumerate" id="x1-75016x3">[residue_number] = vector [vorbis_mapping_submap_residue] element [i]
 </li>
 <li 
 class="enumerate" id="x1-75018x4">[residue_type] = vector [vorbis_residue_types] element [residue_number]
 </li>
 <li 
 class="enumerate" id="x1-75020x5">decode [ch] vectors using residue [residue_number], according to type [residue_type],
 also passing vector [do_not_decode_flag] to indicate which vectors in the bundle should
 not be decoded. Correct per-vector decode length is [n]/2.
 </li>
 <li 
 class="enumerate" id="x1-75022x6">[ch] = 0
 </li>
 <li 
 class="enumerate" id="x1-75024x7">for each channel [j] in order from 0 ... [audio_channels]
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-75026x1">if channel [j] is in submap [i] (vector [vorbis_mapping_mux] element [j] is equal
 to [i])
 <ol class="enumerate3" >
 <li 
 class="enumerate" id="x1-75028x1">residue vector for channel [j] is set to decoded residue vector [ch]
 </li>
 <li 
 class="enumerate" id="x1-75030x2">increment [ch]</li></ol>
 </li></ol>
 </li></ol>

<h5 class="subsubsectionHead">4.3.5 <a 
 id="x1-760004.3.5"></a>inverse coupling</h5>
for each [i] from [vorbis_mapping_coupling_steps]-1 descending to 0

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-76002x1">[magnitude_vector] = the residue vector for channel (vector
 [vorbis_mapping_magnitude] element [i])
 </li>
 <li 
 class="enumerate" id="x1-76004x2">[angle_vector] = the residue vector for channel (vector [vorbis_mapping_angle]

element [i])
 </li>
 <li 
 class="enumerate" id="x1-76006x3">for each scalar value [M] in vector [magnitude_vector] and the corresponding scalar value
 [A] in vector [angle_vector]:
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-76008x1">if ([M] is greater than zero)
 <ol class="enumerate3" >
 <li 
 class="enumerate" id="x1-76010x1">if ([A] is greater than zero)
 <ol class="enumerate4" >
 <li 
 class="enumerate" id="x1-76012x1">[new_M] = [M]
 </li>
 <li 
 class="enumerate" id="x1-76014x2">[new_A] = [M]-[A]</li></ol>
 else
 <ol class="enumerate4" >
 <li 
 class="enumerate" id="x1-76016x1">[new_A] = [M]
 </li>
 <li 
 class="enumerate" id="x1-76018x2">[new_M] = [M]+[A]</li></ol>
 </li></ol>
 else
 <ol class="enumerate3" >
 <li 
 class="enumerate" id="x1-76020x1">if ([A] is greater than zero)
 <ol class="enumerate4" >
 <li 
 class="enumerate" id="x1-76022x1">[new_M] = [M]
 </li>
 <li 
 class="enumerate" id="x1-76024x2">[new_A] = [M]+[A]</li></ol>
 else
 <ol class="enumerate4" >
 <li 
 class="enumerate" id="x1-76026x1">[new_A] = [M]
 </li>
 <li 
 class="enumerate" id="x1-76028x2">[new_M] = [M]-[A]</li></ol>
 </li></ol>
 </li>
 <li 
 class="enumerate" id="x1-76030x2">set scalar value [M] in vector [magnitude_vector] to [new_M]

</li>
 <li 
 class="enumerate" id="x1-76032x3">set scalar value [A] in vector [angle_vector] to [new_A]</li></ol>
 </li></ol>

<h5 class="subsubsectionHead">4.3.6 <a 
 id="x1-770004.3.6"></a>dot product</h5>
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 [n]/2.
For each channel, multiply each element of the floor curve by each element of that
channel’s residue vector. The result is the dot product of the floor and residue vectors for
each channel; the produced vectors are the length [n]/2 audio spectrum for each
channel.
One point is worth mentioning about this dot product; a common mistake in a fixed point
implementation might be to assume that a 32 bit fixed-point representation for floor and
residue and direct multiplication of the vectors is sufficient for acceptable spectral depth
in all cases because it happens to mostly work with the current Xiph.Org reference
encoder.
However, floor vector values can span ∼140dB (∼24 bits unsigned), and the audio spectrum
vector should represent a minimum of 120dB (∼21 bits with sign), even when output is to a 16
bit PCM device. For the residue vector to represent full scale if the floor is nailed
to −140dB, it must be able to span 0 to +140dB. For the residue vector to reach
full scale if the floor is nailed at 0dB, it must be able to represent −140dB to +0dB.
Thus, in order to handle full range dynamics, a residue vector may span −140dB to
+140dB entirely within spec. A 280dB range is approximately 48 bits with sign; thus the
residue vector must be able to represent a 48 bit range and the dot product must
be able to handle an effective 48 bit times 24 bit multiplication. This range may be
achieved using large (64 bit or larger) integers, or implementing a movable binary point
representation.

<h5 class="subsubsectionHead">4.3.7 <a 
 id="x1-780004.3.7"></a>inverse MDCT</h5>
Convert the audio spectrum vector of each channel back into time domain PCM audio via an

inverse Modified Discrete Cosine Transform (MDCT). A detailed description of the MDCT is
available in [<a 
href="#XSporer/Brandenburg/Edler">1</a>]. The window function used for the MDCT is the function described
earlier.

<h5 class="subsubsectionHead">4.3.8 <a 
 id="x1-790004.3.8"></a>overlap˙add</h5>
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
current window (as illustrated in <a 
href="#x1-260001.3.2">paragraph 1.3.2</a>, “<a 
href="#x1-260001.3.2">Window shape decode (long windows
only)</a>”). The overlapped portion produced from overlapping the previous and current frame data
is finished data to be returned by the decoder. This data spans from the center of
the previous window to the center of the current window. In the case of same-sized
windows, the amount of data to return is one-half block consisting of and only of the
overlapped portions. When overlapping a short and long window, much of the returned
range does not actually overlap. This does not damage transform orthogonality. Pay
attention however to returning the correct data range; the amount of data to be returned
is:

<div class="fancyvrb" id="fancyvrb22">
<a 
 id="x1-79002r1"></a>1  window_blocksize(previous_window)/4+window_blocksize(current_window)/4
</div>
from the center (element windowsize/2) of the previous window to the center (element
windowsize/2-1, inclusive) of the current window.
Data is not returned from the first frame; it must be used to ’prime’ the decode engine. The
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).

<h5 class="subsubsectionHead">4.3.9 <a 
 id="x1-800004.3.9"></a>output channel order</h5>
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
specification adds defined channel locations for 6.1 and 7.1 surround. Ordering/location for

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.

 <dl class="description"><dt class="description">
one channel </dt><dd 
class="description">the stream is monophonic
 </dd><dt class="description">
two channels </dt><dd 
class="description">the stream is stereo. channel order: left, right
 </dd><dt class="description">
three channels </dt><dd 
class="description">the stream is a 1d-surround encoding. channel order: left, center, right
 </dd><dt class="description">
four channels </dt><dd 
class="description">the stream is quadraphonic surround. channel order: front left, front right,
 rear left, rear right
 </dd><dt class="description">
five channels </dt><dd 
class="description">the stream is five-channel surround. channel order: front left, center, front
 right, rear left, rear right
 </dd><dt class="description">
six channels </dt><dd 
class="description">the stream is 5.1 surround. channel order: front left, center, front right, rear
 left, rear right, LFE
 </dd><dt class="description">
seven channels </dt><dd 
class="description">the stream is 6.1 surround. channel order: front left, center, front right,
 side left, side right, rear center, LFE
 </dd><dt class="description">
eight channels </dt><dd 
class="description">the stream is 7.1 surround. channel order: front left, center, front right,
 side left, side right, rear left, rear right, LFE
 </dd><dt class="description">
greater than eight channels </dt><dd 
class="description">channel use and order is defined by the application
 </dd></dl>
Applications using Vorbis for dedicated purposes may define channel mapping as seen fit. Future
channel mappings (such as three and four channel <a 
href="http://www.ambisonic.net/" >Ambisonics</a>) will make use of channel
mappings other than mapping 0.

<h3 class="sectionHead">5 <a 
 id="x1-810005"></a>comment field and header specification</h3>

<h4 class="subsectionHead">5.1 <a 
 id="x1-820005.1"></a>Overview</h4>
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
belongs in a separate logical bitstream (usually an XML stream type) that provides greater
structure and machine parseability.
The comment field is meant to be used much like someone jotting a quick note on the bottom of
a CDR. It should be a little information to remember the disc by and explain it to others; a
short, to-the-point text note that need not only be a couple words, but isn’t going to be more
than a short paragraph. The essentials, in other words, whatever they turn out to be,
eg:

 <div class="quote">
 Honest Bob and the Factory-to-Dealer-Incentives, “I’m Still Around”, opening
 for Moxy Fr�vous, 1997.</div>

<h4 class="subsectionHead">5.2 <a 
 id="x1-830005.2"></a>Comment encoding</h4>

<h5 class="subsubsectionHead">5.2.1 <a 
 id="x1-840005.2.1"></a>Structure</h5>
The comment header is logically a list of eight-bit-clean vectors; the number of vectors is
bounded to 232 − 1 and the length of each vector is limited to 232 − 1 bytes. The vector length is

encoded; the vector contents themselves are not null terminated. In addition to the vector list,
there is a single vector for vendor name (also 8 bit clean, length encoded in 32 bits). For
example, the 1.0 release of libvorbis set the vendor string to “Xiph.Org libVorbis I
20020717”.
The vector lengths and number of vectors are stored lsb first, according to the bit
packing conventions of the vorbis codec. However, since data in the comment header
is octet-aligned, they can simply be read as unaligned 32 bit little endian unsigned
integers.
The comment header is decoded as follows:

<div class="fancyvrb" id="fancyvrb23">
<a 
 id="x1-84002r1"></a>1    1) [vendor_length] = read an unsigned integer of 32 bits
 <a 
 id="x1-84004r2"></a>2    2) [vendor_string] = read a UTF-8 vector as [vendor_length] octets
 <a 
 id="x1-84006r3"></a>3    3) [user_comment_list_length] = read an unsigned integer of 32 bits
 <a 
 id="x1-84008r4"></a>4    4) iterate [user_comment_list_length] times {
 <a 
 id="x1-84010r5"></a>5         5) [length] = read an unsigned integer of 32 bits
 <a 
 id="x1-84012r6"></a>6         6) this iteration’s user comment = read a UTF-8 vector as [length] octets
 <a 
 id="x1-84014r7"></a>7       }
 <a 
 id="x1-84016r8"></a>8    7) [framing_bit] = read a single bit as boolean
 <a 
 id="x1-84018r9"></a>9    8) if ( [framing_bit] unset or end-of-packet ) then ERROR
 <a 
 id="x1-84020r10"></a>10    9) done.
</div>

<h5 class="subsubsectionHead">5.2.2 <a 
 id="x1-850005.2.2"></a>Content vector format</h5>
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:

 <div class="quote">
 
 <div class="fancyvrb" id="fancyvrb24">
<a 
 id="x1-85002r1"></a>1  comment[0]="ARTIST=me";
 <a 
 id="x1-85004r2"></a>2  comment[1]="TITLE=the sound of Vorbis";
</div>
 </div>

The field name is case-insensitive and may consist of ASCII 0x20 through 0x7D, 0x3D (’=’)
excluded. ASCII 0x41 through 0x5A inclusive (characters A-Z) is to be considered equivalent to
ASCII 0x61 through 0x7A inclusive (characters a-z).
The field name is immediately followed by ASCII 0x3D (’=’); this equals sign is used to
terminate the field name.
0x3D is followed by 8 bit clean UTF-8 encoded value of the field contents to the end of the
field.
<a 
 id="x1-860005.2.2"></a>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.

 <dl class="description"><dt class="description">
TITLE </dt><dd 
class="description">Track/Work name
 </dd><dt class="description">
VERSION </dt><dd 
class="description">The version field may be used to differentiate multiple versions of the same
 track title in a single collection. (e.g. remix info)
 </dd><dt class="description">
ALBUM </dt><dd 
class="description">The collection name to which this track belongs
 </dd><dt class="description">
TRACKNUMBER </dt><dd 
class="description">The track number of this piece if part of a specific larger collection or
 album
 </dd><dt class="description">
ARTIST </dt><dd 
class="description">The artist generally considered responsible for the work. In popular music this is
 usually the performing band or singer. For classical music it would be the composer.
 For an audio book it would be the author of the original text.
 </dd><dt class="description">
PERFORMER </dt><dd 
class="description">The artist(s) who performed the work. In classical music this would be the
 conductor, orchestra, soloists. In an audio book it would be the actor who did the
 reading. In popular music this is typically the same as the ARTIST and is omitted.
 </dd><dt class="description">
COPYRIGHT </dt><dd 
class="description">Copyright attribution, e.g., ’2001 Nobody’s Band’ or ’1999 Jack Moffitt’
 </dd><dt class="description">

LICENSE </dt><dd 
class="description">License information, eg, ’All Rights Reserved’, ’Any Use Permitted’, a URL to
 a license such as a Creative
 Commons license (”www.creativecommons.org/blahblah/license.html”) or the EFF
 Open Audio License (’distributed under the terms of the Open Audio License. see
 http://www.eff.org/IP/Open˙licenses/eff˙oal.html for details’), etc.
 </dd><dt class="description">
ORGANIZATION </dt><dd 
class="description">Name of the organization producing the track (i.e. the ’record label’)
 </dd><dt class="description">
DESCRIPTION </dt><dd 
class="description">A short text description of the contents
 </dd><dt class="description">
GENRE </dt><dd 
class="description">A short text indication of music genre
 </dd><dt class="description">
DATE </dt><dd 
class="description">Date the track was recorded
 </dd><dt class="description">
LOCATION </dt><dd 
class="description">Location where track was recorded
 </dd><dt class="description">
CONTACT </dt><dd 
class="description">Contact information for the creators or distributors of the track. This could
 be a URL, an email address, the physical address of the producing label.
 </dd><dt class="description">
ISRC </dt><dd 
class="description">International Standard Recording Code for the track; see <a 
href="http://www.ifpi.org/isrc/" >the ISRC intro page</a> for
 more information on ISRC numbers.
 </dd></dl>
<a 
 id="x1-870005.2.2"></a>Implications
Field names should not be ’internationalized’; this is a concession to simplicity not
an attempt to exclude the majority of the world that doesn’t speak English. Field
contents, however, use the UTF-8 character encoding to allow easy representation of any
language.
We have the length of the entirety of the field and restrictions on the field name so that
the field name is bounded in a known way. Thus we also have the length of the field
contents.
Individual ’vendors’ may use non-standard field names within reason. The proper
use of comment fields should be clear through context at this point. Abuse will be
discouraged.

There is no vendor-specific prefix to ’nonstandard’ field names. Vendors should make some effort
to avoid arbitrarily polluting the common namespace. We will generally collect the more useful
tags here to help with standardization.
Field names are not required to be unique (occur once) within a comment header. As an
example, assume a track was recorded by three well know artists; the following is permissible,
and encouraged:

 <div class="quote">
 
 <div class="fancyvrb" id="fancyvrb25">
<a 
 id="x1-87002r1"></a>1  ARTIST=Dizzy Gillespie
 <a 
 id="x1-87004r2"></a>2  ARTIST=Sonny Rollins
 <a 
 id="x1-87006r3"></a>3  ARTIST=Sonny Stitt
</div>
 </div>

<h5 class="subsubsectionHead">5.2.3 <a 
 id="x1-880005.2.3"></a>Encoding</h5>
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
be restricted to within the second bitstream page. The length of the comment header packet is
(practically) unbounded. The comment header packet is not optional; it must be present in the
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):

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-88002x1">Vendor string length (32 bit unsigned quantity specifying number of octets)
 </li>
 <li 
 class="enumerate" id="x1-88004x2">Vendor string ([vendor string length] octets coded from beginning of string to end of
 string, not null terminated)

</li>
 <li 
 class="enumerate" id="x1-88006x3">Number of comment fields (32 bit unsigned quantity specifying number of fields)
 </li>
 <li 
 class="enumerate" id="x1-88008x4">Comment field 0 length (if [Number of comment fields] > 0; 32 bit unsigned quantity
 specifying number of octets)
 </li>
 <li 
 class="enumerate" id="x1-88010x5">Comment field 0 ([Comment field 0 length] octets coded from beginning of string to
 end of string, not null terminated)
 </li>
 <li 
 class="enumerate" id="x1-88012x6">Comment field 1 length (if [Number of comment fields] > 1...)...
 </li></ol>
This is actually somewhat easier to describe in code; implementation of the above can be found
in vorbis/lib/info.c, _vorbis_pack_comment() and _vorbis_unpack_comment().

<h3 class="sectionHead">6 <a 
 id="x1-890006"></a>Floor type 0 setup and decode</h3>

<h4 class="subsectionHead">6.1 <a 
 id="x1-900006.1"></a>Overview</h4>
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
response of the LSP filter. This representation is equivalent to a traditional all-pole infinite
impulse response filter as would be used in linear predictive coding; LSP representation may be
converted to LPC representation and vice-versa.

<h4 class="subsectionHead">6.2 <a 
 id="x1-910006.2"></a>Floor 0 format</h4>
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.

<h5 class="subsubsectionHead">6.2.1 <a 
 id="x1-920006.2.1"></a>header decode</h5>
Configuration information for instances of floor zero decodes from the codec setup header (third
packet). configuration decode proceeds as follows:

<div class="fancyvrb" id="fancyvrb26">
<a 
 id="x1-92002r1"></a>1    1) [floor0_order] = read an unsigned integer of 8 bits
 <a 
 id="x1-92004r2"></a>2    2) [floor0_rate] = read an unsigned integer of 16 bits
 <a 
 id="x1-92006r3"></a>3    3) [floor0_bark_map_size] = read an unsigned integer of 16 bits
 <a 
 id="x1-92008r4"></a>4    4) [floor0_amplitude_bits] = read an unsigned integer of six bits
 <a 
 id="x1-92010r5"></a>5    5) [floor0_amplitude_offset] = read an unsigned integer of eight bits
 <a 
 id="x1-92012r6"></a>6    6) [floor0_number_of_books] = read an unsigned integer of four bits and add 1
 <a 
 id="x1-92014r7"></a>7    7) array [floor0_book_list] = read a list of [floor0_number_of_books] unsigned integers of eight bits each;
</div>

An end-of-packet condition during any of these bitstream reads renders this stream undecodable.
In addition, any element of the array [floor0_book_list] that is greater than the maximum
codebook number for this bitstream is an error condition that also renders the stream
undecodable.

<h5 class="subsubsectionHead">6.2.2 <a 
 id="x1-930006.2.2"></a>packet decode</h5>
Extracting a floor0 curve from an audio packet consists of first decoding the curve
amplitude and [floor0_order] LSP coefficient values from the bitstream, and then
computing the floor curve, which is defined as the frequency response of the decoded LSP
filter.
Packet decode proceeds as follows:
<div class="fancyvrb" id="fancyvrb27">
<a 
 id="x1-93002r1"></a>1    1) [amplitude] = read an unsigned integer of [floor0_amplitude_bits] bits
 <a 
 id="x1-93004r2"></a>2    2) if ( [amplitude] is greater than zero ) {
 <a 
 id="x1-93006r3"></a>3         3) [coefficients] is an empty, zero length vector
 <a 
 id="x1-93008r4"></a>4         4) [booknumber] = read an unsigned integer of <a 
href="#x1-1170009.2.1">ilog</a>( [floor0_number_of_books] ) bits
 <a 
 id="x1-93010r5"></a>5         5) if ( [booknumber] is greater than the highest number decode codebook ) then packet is undecodable
 <a 
 id="x1-93012r6"></a>6         6) [last] = zero;
 <a 
 id="x1-93014r7"></a>7         7) vector [temp_vector] = read vector from bitstream using codebook number [floor0_book_list] element [booknumber] in VQ context.
 <a 
 id="x1-93016r8"></a>8         8) add the scalar value [last] to each scalar in vector [temp_vector]
 <a 
 id="x1-93018r9"></a>9         9) [last] = the value of the last scalar in vector [temp_vector]
 <a 
 id="x1-93020r10"></a>10        10) concatenate [temp_vector] onto the end of the [coefficients] vector
 <a 
 id="x1-93022r11"></a>11        11) if (length of vector [coefficients] is less than [floor0_order], continue at step 6
 <a 
 id="x1-93024r12"></a>12  
 <a 
 id="x1-93026r13"></a>13       }
 <a 
 id="x1-93028r14"></a>14  
 <a 
 id="x1-93030r15"></a>15   12) done.
 <a 
 id="x1-93032r16"></a>16  
</div>
Take note of the following properties of decode:
 <ul class="itemize1">
 <li class="itemize">An [amplitude] value of zero must result in a return code that indicates this channel
 is unused in this frame (the output of the channel will be all-zeroes in synthesis).
 Several later stages of decode don’t occur for an unused channel.
 </li>
 <li class="itemize">An end-of-packet condition during decode should be considered a nominal occruence;
 if end-of-packet is reached during any read operation above, floor decode is to return
 ’unused’ status as if the [amplitude] value had read zero at the beginning of decode.
 </li>
 <li class="itemize">The book number used for decode can, in fact, be stored in the bitstream in <a 
href="#x1-1170009.2.1">ilog</a>(

[floor0_number_of_books] - 1 ) bits. Nevertheless, the above specification is correct
 and values greater than the maximum possible book value are reserved.
 </li>
 <li class="itemize">The number of scalars read into the vector [coefficients] may be greater
 than [floor0_order], the number actually required for curve computation. For
 example, if the VQ codebook used for the floor currently being decoded has a
 [codebook_dimensions] value of three and [floor0_order] is ten, the only way to
 fill all the needed scalars in [coefficients] is to to read a total of twelve scalars
 as four vectors of three scalars each. This is not an error condition, and care must
 be taken not to allow a buffer overflow in decode. The extra values are not used and
 may be ignored or discarded.</li></ul>

<h5 class="subsubsectionHead">6.2.3 <a 
 id="x1-940006.2.3"></a>curve computation</h5>
Given an [amplitude] integer and [coefficients] vector from packet decode as well
as the [floor0˙order], [floor0˙rate], [floor0˙bark˙map˙size], [floor0˙amplitude˙bits] and
[floor0˙amplitude˙offset] values from floor setup, and an output vector size [n] specified by the
decode process, we compute a floor output vector.
If the value [amplitude] is zero, the return value is a length [n] vector with all-zero
scalars. Otherwise, begin by assuming the following definitions for the given vector to be
synthesized:
<center class="par-math-display" >
<img 
src="Vorbis_I_spec7x.png" alt=" {
 min (floor0xbarkxmapxsize − 1,foobar ) for i ∈ [0,n − 1 ]
mapi = − 1 for i = n
" class="par-math-display" ></center>

where
<center class="par-math-display" >
<img 
src="Vorbis_I_spec8x.png" alt=" ⌊ ⌋
 (floor0xrate ⋅ i) floor0xbarkxmapxsize
foobar = bark -------2n------- ⋅-bark(.5 ⋅ floor0xrate-)
" class="par-math-display" ></center>

and
<center class="par-math-display" >
<img 
src="Vorbis_I_spec9x.png" alt=" 2
bark(x) = 13.1arctan (.00074x ) + 2.24 arctan(.0000000185x + .0001x )
" class="par-math-display" ></center>

The above is used to synthesize the LSP curve on a Bark-scale frequency axis, then map the
result to a linear-scale frequency axis. Similarly, the below calculation synthesizes the output
LSP curve [output] on a log (dB) amplitude scale, mapping it to linear amplitude in the last
step:

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-94002x1">[i] = 0
 </li>
 <li 
 class="enumerate" id="x1-94004x2">[ω] = π * map element [i] / [floor0_bark_map_size]
 </li>
 <li 
 class="enumerate" id="x1-94006x3">if ( [floor0_order] is odd )
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-94008x1">calculate [p] and [q] according to: <div class="eqnarray">
 <center class="math-display" >
 <img 
src="Vorbis_I_spec10x.png" alt=" floor0xorder−3
 2 ∏2 2
p = (1 − cos ω) 4(cos([coefficients ]2j+1) − cosω )
 j=0
 floor0x∏or2der−1
q = 1- 4(cos([coefficients ]2j) − cosω )2
 4 j=0

" class="math-display" ></center>
 </div>
 </li></ol>
 else [floor0_order] is even
 <ol class="enumerate2" >
 <li 
 class="enumerate" id="x1-94011x1">calculate [p] and [q] according to: <div class="eqnarray">
 <center class="math-display" >
 <img 
src="Vorbis_I_spec11x.png" alt=" floor0xorder−2
 (1 − cos2ω) ∏2 2
p = -----2------ 4(cos([coefficients ]2j+1) − cosω )
 j=0
 2 floor0xor2der−2
q = (1 +-cos-ω)- ∏ 4(cos([coefficients ] ) − cosω )2
 2 j=0 2j
 " class="math-display" ></center>
 </div>
 </li></ol>
 </li>
 <li 
 class="enumerate" id="x1-94014x4">calculate [linear_floor_value] according to:
 <center class="math-display" >
 <img 
src="Vorbis_I_spec12x.png" alt=" ( ( ))
 amplitude---⋅ floor0xamplitutexoffset---
exp .11512925 (2floor0xamplitudexbits − 1)√ p + q − floor0xamplitudexoffset
 " class="math-display" ></center>
 
 </li>
 <li 
 class="enumerate" id="x1-94016x5">[iteration_condition] = map element [i]

</li>
 <li 
 class="enumerate" id="x1-94018x6">[output] element [i] = [linear_floor_value]
 </li>
 <li 
 class="enumerate" id="x1-94020x7">increment [i]
 </li>
 <li 
 class="enumerate" id="x1-94022x8">if ( map element [i] is equal to [iteration_condition] ) continue at step
 5
 </li>
 <li 
 class="enumerate" id="x1-94024x9">if ( [i] is less than [n] ) continue at step 2
 </li>
 <li 
 class="enumerate" id="x1-94026x10">done</li></ol>

<h3 class="sectionHead">7 <a 
 id="x1-950007"></a>Floor type 1 setup and decode</h3>

<h4 class="subsectionHead">7.1 <a 
 id="x1-960007.1"></a>Overview</h4>
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.

<h4 class="subsectionHead">7.2 <a 
 id="x1-970007.2"></a>Floor 1 format</h4>

<h5 class="subsubsectionHead">7.2.1 <a 
 id="x1-980007.2.1"></a>model</h5>
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
description:
 <ul class="itemize1">
 <li class="itemize">the first line segment (base case) is a logical line spanning from x˙0,y˙0 to x˙1,y˙1
 where in the base case x˙0=0 and x˙1=[n], the full range of the spectral floor to be
 computed.
 </li>
 <li class="itemize">the induction step chooses a point x˙new within an existing logical line segment and
 produces a y˙new value at that point computed from the existing line’s y value at
 x˙new (as plotted by the line) and a difference value decoded from the bitstream
 packet.

</li>
 <li class="itemize">floor computation produces two new line segments, one running from x˙0,y˙0 to
 x˙new,y˙new and from x˙new,y˙new to x˙1,y˙1. This step is performed logically even if
 y˙new represents no change to the amplitude value at x˙new so that later refinement
 is additionally bounded at x˙new.
 </li>
 <li class="itemize">the induction step repeats, using a list of x values specified in the codec setup header
 at floor 1 initialization time. Computation is completed at the end of the x value list.
 </li></ul>
Consider the following example, with values chosen for ease of understanding rather than
representing typical configuration:
For the below example, we assume a floor setup with an [n] of 128. The list of selected X values
in increasing order is 0,16,32,48,64,80,96,112 and 128. In list order, the values interleave as 0,
128, 64, 32, 96, 16, 48, 80 and 112. The corresponding list-order Y values as decoded from an
example packet are 110, 20, -5, -45, 0, -25, -10, 30 and -10. We compute the floor in the following
way, beginning with the first line:
<div class="center" 
>

<img 
src="floor1-1.png" alt="PIC" 
>
 <div class="caption" 
>Figure 7: graph of example floor</div>
</div>
We now draw new logical lines to reflect the correction to new˙Y, and iterate for X positions 32
and 96:
<div class="center" 
>

<img 
src="floor1-2.png" alt="PIC" 
>
 <div class="caption" 
>Figure 8: graph of example floor</div>
</div>
Although the new Y value at X position 96 is unchanged, it is still used later as an endpoint for
further refinement. From here on, the pattern should be clear; we complete the floor computation
as follows:

<img 
src="floor1-3.png" alt="PIC" 
>
 <div class="caption" 
>Figure 9: graph of example floor</div>
</div>
<div class="center" 
>

<img 
src="floor1-4.png" alt="PIC" 
>
 <div class="caption" 
>Figure 10: graph of example floor</div>
</div>
A more efficient algorithm with carefully defined integer rounding behavior is used for actual
decode, as described later. The actual algorithm splits Y value computation and line plotting
into two steps with modifications to the above algorithm to eliminate noise accumulation
through integer roundoff/truncation.

<h5 class="subsubsectionHead">7.2.2 <a 
 id="x1-990007.2.2"></a>header decode</h5>
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
assigned to a partition class. X positions 0 and [n] are implicit and do not belong to an explicit
partition or partition class.
A partition class consists of a representation vector width (the number of Y values which
the partition class encodes at once), a ’subclass’ value representing the number of
alternate entropy books the partition class may use in representing Y values, the list of
[subclass] books and a master book used to encode which alternate books were chosen
for representation in a given packet. The master/subclass mechanism is meant to be
used as a flexible representation cascade while still using codebooks only in a scalar
context.

<div class="fancyvrb" id="fancyvrb28">
<a 
 id="x1-99002r1"></a>1  
 <a 
 id="x1-99004r2"></a>2    1) [floor1_partitions] = read 5 bits as unsigned integer
 <a 
 id="x1-99006r3"></a>3    2) [maximum_class] = -1
 <a 
 id="x1-99008r4"></a>4    3) iterate [i] over the range 0 ... [floor1_partitions]-1 {
 <a 
 id="x1-99010r5"></a>5  
 <a 
 id="x1-99012r6"></a>6          4) vector [floor1_partition_class_list] element [i] = read 4 bits as unsigned integer
 <a 
 id="x1-99014r7"></a>7  
 <a 
 id="x1-99016r8"></a>8       }
 <a 
 id="x1-99018r9"></a>9  
 <a 
 id="x1-99020r10"></a>10    5) [maximum_class] = largest integer scalar value in vector [floor1_partition_class_list]
 <a 
 id="x1-99022r11"></a>11    6) iterate [i] over the range 0 ... [maximum_class] {
 <a 
 id="x1-99024r12"></a>12  
 <a 
 id="x1-99026r13"></a>13          7) vector [floor1_class_dimensions] element [i] = read 3 bits as unsigned integer and add 1
 <a 
 id="x1-99028r14"></a>14   8) vector [floor1_class_subclasses] element [i] = read 2 bits as unsigned integer
 <a 
 id="x1-99030r15"></a>15          9) if ( vector [floor1_class_subclasses] element [i] is nonzero ) {
 <a 
 id="x1-99032r16"></a>16  
 <a 
 id="x1-99034r17"></a>17               10) vector [floor1_class_masterbooks] element [i] = read 8 bits as unsigned integer
 <a 
 id="x1-99036r18"></a>18  
 <a 
 id="x1-99038r19"></a>19             }
 <a 
 id="x1-99040r20"></a>20  
 <a 
 id="x1-99042r21"></a>21         11) iterate [j] over the range 0 ... (2 exponent [floor1_class_subclasses] element [i]) - 1 {
 <a 
 id="x1-99044r22"></a>22  
 <a 
 id="x1-99046r23"></a>23               12) array [floor1_subclass_books] element [i],[j] =
 <a 
 id="x1-99048r24"></a>24                   read 8 bits as unsigned integer and subtract one
 <a 
 id="x1-99050r25"></a>25             }
 <a 
 id="x1-99052r26"></a>26        }
 <a 
 id="x1-99054r27"></a>27  
 <a 
 id="x1-99056r28"></a>28   13) [floor1_multiplier] = read 2 bits as unsigned integer and add one
 <a 
 id="x1-99058r29"></a>29   14) [rangebits] = read 4 bits as unsigned integer
 <a 
 id="x1-99060r30"></a>30   15) vector [floor1_X_list] element [0] = 0
 <a 
 id="x1-99062r31"></a>31   16) vector [floor1_X_list] element [1] = 2 exponent [rangebits];
 <a 
 id="x1-99064r32"></a>32   17) [floor1_values] = 2
 <a 
 id="x1-99066r33"></a>33   18) iterate [i] over the range 0 ... [floor1_partitions]-1 {
 <a 
 id="x1-99068r34"></a>34  
 <a 
 id="x1-99070r35"></a>35         19) [current_class_number] = vector [floor1_partition_class_list] element [i]
 <a 
 id="x1-99072r36"></a>36         20) iterate [j] over the range 0 ... ([floor1_class_dimensions] element [current_class_number])-1 {
 <a 
 id="x1-99074r37"></a>37               21) vector [floor1_X_list] element ([floor1_values]) =
 <a 
 id="x1-99076r38"></a>38                   read [rangebits] bits as unsigned integer
 <a 
 id="x1-99078r39"></a>39               22) increment [floor1_values] by one
 <a 
 id="x1-99080r40"></a>40             }
 <a 
 id="x1-99082r41"></a>41       }
 <a 
 id="x1-99084r42"></a>42  
 <a 
 id="x1-99086r43"></a>43   23) done
</div>
An end-of-packet condition while reading any aspect of a floor 1 configuration during
setup renders a stream undecodable. In addition, a [floor1_class_masterbooks] or
[floor1_subclass_books] scalar element greater than the highest numbered codebook
configured in this stream is an error condition that renders the stream undecodable. All vector
[floor1˙x˙list] element values must be unique within the vector; a non-unique value renders the
stream undecodable.
<a 
 id="x1-1000007.2.2"></a>packet decode

Packet decode begins by checking the [nonzero] flag:

<div class="fancyvrb" id="fancyvrb29">
<a 
 id="x1-100002r1"></a>1    1) [nonzero] = read 1 bit as boolean
</div>
If [nonzero] is unset, that indicates this channel contained no audio energy in this frame.
Decode immediately returns a status indicating this floor curve (and thus this channel) is unused
this frame. (A return status of ’unused’ is different from decoding a floor that has all
points set to minimum representation amplitude, which happens to be approximately
-140dB).
Assuming [nonzero] is set, decode proceeds as follows:

<div class="fancyvrb" id="fancyvrb30">
<a 
 id="x1-100004r1"></a>1    1) [range] = vector { 256, 128, 86, 64 } element ([floor1_multiplier]-1)
 <a 
 id="x1-100006r2"></a>2    2) vector [floor1_Y] element [0] = read <a 
href="#x1-1170009.2.1">ilog</a>([range]-1) bits as unsigned integer
 <a 
 id="x1-100008r3"></a>3    3) vector [floor1_Y] element [1] = read <a 
href="#x1-1170009.2.1">ilog</a>([range]-1) bits as unsigned integer
 <a 
 id="x1-100010r4"></a>4    4) [offset] = 2;
 <a 
 id="x1-100012r5"></a>5    5) iterate [i] over the range 0 ... [floor1_partitions]-1 {
 <a 
 id="x1-100014r6"></a>6  
 <a 
 id="x1-100016r7"></a>7         6) [class] = vector [floor1_partition_class]  element [i]
 <a 
 id="x1-100018r8"></a>8         7) [cdim]  = vector [floor1_class_dimensions] element [class]
 <a 
 id="x1-100020r9"></a>9         8) [cbits] = vector [floor1_class_subclasses] element [class]
 <a 
 id="x1-100022r10"></a>10         9) [csub]  = (2 exponent [cbits])-1
 <a 
 id="x1-100024r11"></a>11        10) [cval]  = 0
 <a 
 id="x1-100026r12"></a>12        11) if ( [cbits] is greater than zero ) {
 <a 
 id="x1-100028r13"></a>13  
 <a 
 id="x1-100030r14"></a>14               12) [cval] = read from packet using codebook number
 <a 
 id="x1-100032r15"></a>15                   (vector [floor1_class_masterbooks] element [class]) in scalar context
 <a 
 id="x1-100034r16"></a>16            }
 <a 
 id="x1-100036r17"></a>17  
 <a 
 id="x1-100038r18"></a>18        13) iterate [j] over the range 0 ... [cdim]-1 {
 <a 
 id="x1-100040r19"></a>19  
 <a 
 id="x1-100042r20"></a>20               14) [book] = array [floor1_subclass_books] element [class],([cval] bitwise AND [csub])
 <a 
 id="x1-100044r21"></a>21               15) [cval] = [cval] right shifted [cbits] bits
 <a 
 id="x1-100046r22"></a>22        16) if ( [book] is not less than zero ) {
 <a 
 id="x1-100048r23"></a>23  
 <a 
 id="x1-100050r24"></a>24              17) vector [floor1_Y] element ([j]+[offset]) = read from packet using codebook
 <a 
 id="x1-100052r25"></a>25                         [book] in scalar context
 <a 
 id="x1-100054r26"></a>26  
 <a 
 id="x1-100056r27"></a>27                   } else [book] is less than zero {
 <a 
 id="x1-100058r28"></a>28  
 <a 
 id="x1-100060r29"></a>29              18) vector [floor1_Y] element ([j]+[offset]) = 0
 <a 
 id="x1-100062r30"></a>30  
 <a 
 id="x1-100064r31"></a>31                   }
 <a 
 id="x1-100066r32"></a>32            }
 <a 
 id="x1-100068r33"></a>33  
 <a 
 id="x1-100070r34"></a>34        19) [offset] = [offset] + [cdim]
 <a 
 id="x1-100072r35"></a>35  
 <a 
 id="x1-100074r36"></a>36       }
 <a 
 id="x1-100076r37"></a>37  
 <a 
 id="x1-100078r38"></a>38   20) done
</div>

An end-of-packet condition during curve decode should be considered a nominal occurrence; if
end-of-packet is reached during any read operation above, floor decode is to return ’unused’
status as if the [nonzero] flag had been unset at the beginning of decode.
Vector [floor1_Y] contains the values from packet decode needed for floor 1 synthesis.
<a 
 id="x1-1010007.2.2"></a>curve computation
Curve computation is split into two logical steps; the first step derives final Y amplitude values
from the encoded, wrapped difference values taken from the bitstream. The second step
plots the curve lines. Also, although zero-difference values are used in the iterative
prediction to find final Y values, these points are conditionally skipped during final
line computation in step two. Skipping zero-difference values allows a smoother line
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.

 <dl class="description"><dt class="description">
step 1: amplitude value synthesis </dt><dd 
class="description">
 Unwrap the always-positive-or-zero values read from the packet into +/- difference
 values, then apply to line prediction.
 
 <div class="fancyvrb" id="fancyvrb31">
<a 
 id="x1-101002r1"></a>1    1) [range] = vector { 256, 128, 86, 64 } element ([floor1_multiplier]-1)
 <a 
 id="x1-101004r2"></a>2    2) vector [floor1_step2_flag] element [0] = set
 <a 
 id="x1-101006r3"></a>3    3) vector [floor1_step2_flag] element [1] = set
 <a 
 id="x1-101008r4"></a>4    4) vector [floor1_final_Y] element [0] = vector [floor1_Y] element [0]
 <a 
 id="x1-101010r5"></a>5    5) vector [floor1_final_Y] element [1] = vector [floor1_Y] element [1]
 <a 
 id="x1-101012r6"></a>6    6) iterate [i] over the range 2 ... [floor1_values]-1 {
 <a 
 id="x1-101014r7"></a>7  
 <a 
 id="x1-101016r8"></a>8         7) [low_neighbor_offset] = <a 
href="#x1-1200009.2.4">low_neighbor</a>([floor1_X_list],[i])
 <a 
 id="x1-101018r9"></a>9         8) [high_neighbor_offset] = <a 
href="#x1-1210009.2.5">high_neighbor</a>([floor1_X_list],[i])
 <a 
 id="x1-101020r10"></a>10  
 <a 
 id="x1-101022r11"></a>11         9) [predicted] = <a 
href="#x1-1220009.2.6">render_point</a>( vector [floor1_X_list] element [low_neighbor_offset],
 <a 
 id="x1-101024r12"></a>12         vector [floor1_final_Y] element [low_neighbor_offset],
 <a 
 id="x1-101026r13"></a>13                                        vector [floor1_X_list] element [high_neighbor_offset],
 <a 
 id="x1-101028r14"></a>14         vector [floor1_final_Y] element [high_neighbor_offset],
 <a 
 id="x1-101030r15"></a>15                                        vector [floor1_X_list] element [i] )
 <a 
 id="x1-101032r16"></a>16  
 <a 
 id="x1-101034r17"></a>17        10) [val] = vector [floor1_Y] element [i]
 <a 
 id="x1-101036r18"></a>18        11) [highroom] = [range] - [predicted]
 <a 
 id="x1-101038r19"></a>19        12) [lowroom]  = [predicted]
 <a 
 id="x1-101040r20"></a>20        13) if ( [highroom] is less than [lowroom] ) {
 <a 
 id="x1-101042r21"></a>21  
 <a 
 id="x1-101044r22"></a>22              14) [room] = [highroom] * 2

<a 
 id="x1-101046r23"></a>23  
 <a 
 id="x1-101048r24"></a>24            } else [highroom] is not less than [lowroom] {
 <a 
 id="x1-101050r25"></a>25  
 <a 
 id="x1-101052r26"></a>26              15) [room] = [lowroom] * 2
 <a 
 id="x1-101054r27"></a>27  
 <a 
 id="x1-101056r28"></a>28            }
 <a 
 id="x1-101058r29"></a>29  
 <a 
 id="x1-101060r30"></a>30        16) if ( [val] is nonzero ) {
 <a 
 id="x1-101062r31"></a>31  
 <a 
 id="x1-101064r32"></a>32              17) vector [floor1_step2_flag] element [low_neighbor_offset] = set
 <a 
 id="x1-101066r33"></a>33              18) vector [floor1_step2_flag] element [high_neighbor_offset] = set
 <a 
 id="x1-101068r34"></a>34              19) vector [floor1_step2_flag] element [i] = set
 <a 
 id="x1-101070r35"></a>35              20) if ( [val] is greater than or equal to [room] ) {
 <a 
 id="x1-101072r36"></a>36  
 <a 
 id="x1-101074r37"></a>37                    21) if ( [highroom] is greater than [lowroom] ) {
 <a 
 id="x1-101076r38"></a>38  
 <a 
 id="x1-101078r39"></a>39                          22) vector [floor1_final_Y] element [i] = [val] - [lowroom] + [predicted]
 <a 
 id="x1-101080r40"></a>40  
 <a 
 id="x1-101082r41"></a>41         } else [highroom] is not greater than [lowroom] {
 <a 
 id="x1-101084r42"></a>42  
 <a 
 id="x1-101086r43"></a>43                          23) vector [floor1_final_Y] element [i] = [predicted] - [val] + [highroom] - 1
 <a 
 id="x1-101088r44"></a>44  
 <a 
 id="x1-101090r45"></a>45                        }
 <a 
 id="x1-101092r46"></a>46  
 <a 
 id="x1-101094r47"></a>47                  } else [val] is less than [room] {
 <a 
 id="x1-101096r48"></a>48  
 <a 
 id="x1-101098r49"></a>49     24) if ([val] is odd) {
 <a 
 id="x1-101100r50"></a>50  
 <a 
 id="x1-101102r51"></a>51                          25) vector [floor1_final_Y] element [i] =
 <a 
 id="x1-101104r52"></a>52                              [predicted] - (([val] + 1) divided by  2 using integer division)
 <a 
 id="x1-101106r53"></a>53  
 <a 
 id="x1-101108r54"></a>54                        } else [val] is even {
 <a 
 id="x1-101110r55"></a>55  
 <a 
 id="x1-101112r56"></a>56                          26) vector [floor1_final_Y] element [i] =
 <a 
 id="x1-101114r57"></a>57                              [predicted] + ([val] / 2 using integer division)
 <a 
 id="x1-101116r58"></a>58  
 <a 
 id="x1-101118r59"></a>59                        }
 <a 
 id="x1-101120r60"></a>60  
 <a 
 id="x1-101122r61"></a>61                  }
 <a 
 id="x1-101124r62"></a>62  
 <a 
 id="x1-101126r63"></a>63            } else [val] is zero {
 <a 
 id="x1-101128r64"></a>64  
 <a 
 id="x1-101130r65"></a>65              27) vector [floor1_step2_flag] element [i] = unset
 <a 
 id="x1-101132r66"></a>66              28) vector [floor1_final_Y] element [i] = [predicted]
 <a 
 id="x1-101134r67"></a>67  
 <a 
 id="x1-101136r68"></a>68            }
 <a 
 id="x1-101138r69"></a>69  
 <a 
 id="x1-101140r70"></a>70       }
 <a 
 id="x1-101142r71"></a>71  
 <a 
 id="x1-101144r72"></a>72   29) done
 <a 
 id="x1-101146r73"></a>73  
</div>
 </dd><dt class="description">
step 2: curve synthesis </dt><dd 
class="description">
 Curve synthesis generates a return vector [floor] of length [n] (where [n] is provided by
 the decode process calling to floor decode). Floor 1 curve synthesis makes use of the
 [floor1_X_list], [floor1_final_Y] and [floor1_step2_flag] vectors, as well as
 [floor1˙multiplier] and [floor1˙values] values.

Decode begins by sorting the scalars from vectors [floor1_X_list], [floor1_final_Y] and
 [floor1_step2_flag] together into new vectors [floor1_X_list]’, [floor1_final_Y]’
 and [floor1_step2_flag]’ according to ascending sort order of the values in
 [floor1_X_list]. That is, sort the values of [floor1_X_list] and then apply the same
 permutation to elements of the other two vectors so that the X, Y and step2˙flag values still
 match.
 Then compute the final curve in one pass:
 
 <div class="fancyvrb" id="fancyvrb32">
<a 
 id="x1-101148r1"></a>1    1) [hx] = 0
 <a 
 id="x1-101150r2"></a>2    2) [lx] = 0
 <a 
 id="x1-101152r3"></a>3    3) [ly] = vector [floor1_final_Y]’ element [0] * [floor1_multiplier]
 <a 
 id="x1-101154r4"></a>4    4) iterate [i] over the range 1 ... [floor1_values]-1 {
 <a 
 id="x1-101156r5"></a>5  
 <a 
 id="x1-101158r6"></a>6         5) if ( [floor1_step2_flag]’ element [i] is set ) {
 <a 
 id="x1-101160r7"></a>7  
 <a 
 id="x1-101162r8"></a>8               6) [hy] = [floor1_final_Y]’ element [i] * [floor1_multiplier]
 <a 
 id="x1-101164r9"></a>9         7) [hx] = [floor1_X_list]’ element [i]
 <a 
 id="x1-101166r10"></a>10               8) <a 
href="#x1-1230009.2.7">render_line</a>( [lx], [ly], [hx], [hy], [floor] )
 <a 
 id="x1-101168r11"></a>11               9) [lx] = [hx]
 <a 
 id="x1-101170r12"></a>12       10) [ly] = [hy]
 <a 
 id="x1-101172r13"></a>13            }
 <a 
 id="x1-101174r14"></a>14       }
 <a 
 id="x1-101176r15"></a>15  
 <a 
 id="x1-101178r16"></a>16   11) if ( [hx] is less than [n] ) {
 <a 
 id="x1-101180r17"></a>17  
 <a 
 id="x1-101182r18"></a>18          12) <a 
href="#x1-1230009.2.7">render_line</a>( [hx], [hy], [n], [hy], [floor] )
 <a 
 id="x1-101184r19"></a>19  
 <a 
 id="x1-101186r20"></a>20       }
 <a 
 id="x1-101188r21"></a>21  
 <a 
 id="x1-101190r22"></a>22   13) if ( [hx] is greater than [n] ) {
 <a 
 id="x1-101192r23"></a>23  
 <a 
 id="x1-101194r24"></a>24              14) truncate vector [floor] to [n] elements
 <a 
 id="x1-101196r25"></a>25  
 <a 
 id="x1-101198r26"></a>26       }
 <a 
 id="x1-101200r27"></a>27  
 <a 
 id="x1-101202r28"></a>28   15) for each scalar in vector [floor], perform a lookup substitution using
 <a 
 id="x1-101204r29"></a>29       the scalar value from [floor] as an offset into the vector <a 
href="#x1-12500010.1">[floor1_inverse_dB_static_table]</a>
 <a 
 id="x1-101206r30"></a>30  
 <a 
 id="x1-101208r31"></a>31   16) done
 <a 
 id="x1-101210r32"></a>32  
</div>
 </dd></dl>

<h3 class="sectionHead">8 <a 
 id="x1-1020008"></a>Residue setup and decode</h3>

<h4 class="subsectionHead">8.1 <a 
 id="x1-1030008.1"></a>Overview</h4>
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
may represent spectral lines, spectral magnitude, spectral phase or hybrids as mixed by channel
coupling. The exact semantic content of the vector does not matter to the residue
abstraction.
Whatever the exact qualities, the Vorbis residue abstraction codes the residue vectors into the
bitstream packet, and then reconstructs the vectors during decode. Vorbis makes use of three
different encoding variants (numbered 0, 1 and 2) of the same basic vector encoding
abstraction.

<h4 class="subsectionHead">8.2 <a 
 id="x1-1040008.2"></a>Residue format</h4>
Residue format partitions each vector in the vector bundle into chunks, classifies each
chunk, encodes the chunk classifications and finally encodes the chunks themselves
using the the specific VQ arrangement defined for each selected classification. The
exact interleaving and partitioning vary by residue encoding number, however the
high-level process used to classify and encode the residue vector is the same in all three
variants.
A set of coded residue vectors are all of the same length. High level coding structure, ignoring for
the moment exactly how a partition is encoded and simply trusting that it is, is as
follows:
 <ul class="itemize1">
 <li class="itemize">Each vector is partitioned into multiple equal sized chunks according to configuration
 specified. If we have a vector size of n, a partition size residue˙partition˙size, and
 a total of ch residue vectors, the total number of partitioned chunks coded is

n/residue˙partition˙size*ch. It is important to note that the integer division truncates.
 In the below example, we assume an example residue˙partition˙size of 8.
 </li>
 <li class="itemize">Each partition in each vector has a classification number that specifies which of
 multiple configured VQ codebook setups are used to decode that partition. The
 classification numbers of each partition can be thought of as forming a vector in
 their own right, as in the illustration below. Just as the residue vectors are coded
 in grouped partitions to increase encoding efficiency, the classification vector is also
 partitioned into chunks. The integer elements of each scalar in a classification chunk
 are built into a single scalar that represents the classification numbers in that chunk.
 In the below example, the classification codeword encodes two classification numbers.
 </li>
 <li class="itemize">The values in a residue vector may be encoded monolithically in a single pass through
 the residue vector, but more often efficient codebook design dictates that each vector
 is encoded as the additive sum of several passes through the residue vector using
 more than one VQ codebook. Thus, each residue value potentially accumulates values
 from multiple decode passes. The classification value associated with a partition is
 the same in each pass, thus the classification codeword is coded only in the first pass.
 </li></ul>
<div class="center" 
>

<img 
src="residue-pack.png" alt="PIC" 
>
 <div class="caption" 
>Figure 11: illustration of residue vector format</div>
</div>

<h4 class="subsectionHead">8.3 <a 
 id="x1-1050008.3"></a>residue 0</h4>
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
figure).
Residue encoding 0 interleaves VQ encoding according to the dimension of the codebook used to

encode a partition in a specific pass. The dimension of the codebook need not be the same in
multiple passes, however the partition size must be an even multiple of the codebook
dimension.
As an example, assume a partition vector of size eight, to be encoded by residue 0 using
codebook sizes of 8, 4, 2 and 1:

<div class="fancyvrb" id="fancyvrb33">
<a 
 id="x1-105002r1"></a>1  
 <a 
 id="x1-105004r2"></a>2              original residue vector: [ 0 1 2 3 4 5 6 7 ]
 <a 
 id="x1-105006r3"></a>3  
 <a 
 id="x1-105008r4"></a>4  codebook dimensions = 8  encoded as: [ 0 1 2 3 4 5 6 7 ]
 <a 
 id="x1-105010r5"></a>5  
 <a 
 id="x1-105012r6"></a>6  codebook dimensions = 4  encoded as: [ 0 2 4 6 ], [ 1 3 5 7 ]
 <a 
 id="x1-105014r7"></a>7  
 <a 
 id="x1-105016r8"></a>8  codebook dimensions = 2  encoded as: [ 0 4 ], [ 1 5 ], [ 2 6 ], [ 3 7 ]
 <a 
 id="x1-105018r9"></a>9  
 <a 
 id="x1-105020r10"></a>10  codebook dimensions = 1  encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ]
 <a 
 id="x1-105022r11"></a>11  
</div>
It is worth mentioning at this point that no configurable value in the residue coding setup is
restricted to a power of two.

<h4 class="subsectionHead">8.4 <a 
 id="x1-1060008.4"></a>residue 1</h4>
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,
although dimension may vary from pass to pass.
As an example, assume a partition vector of size eight, to be encoded by residue 0 using
codebook sizes of 8, 4, 2 and 1:

<div class="fancyvrb" id="fancyvrb34">
<a 
 id="x1-106002r1"></a>1  
 <a 
 id="x1-106004r2"></a>2              original residue vector: [ 0 1 2 3 4 5 6 7 ]
 <a 
 id="x1-106006r3"></a>3  
 <a 
 id="x1-106008r4"></a>4  codebook dimensions = 8  encoded as: [ 0 1 2 3 4 5 6 7 ]
 <a 
 id="x1-106010r5"></a>5  
 <a 
 id="x1-106012r6"></a>6  codebook dimensions = 4  encoded as: [ 0 1 2 3 ], [ 4 5 6 7 ]
 <a 
 id="x1-106014r7"></a>7  
 <a 
 id="x1-106016r8"></a>8  codebook dimensions = 2  encoded as: [ 0 1 ], [ 2 3 ], [ 4 5 ], [ 6 7 ]
 <a 
 id="x1-106018r9"></a>9  
 <a 
 id="x1-106020r10"></a>10  codebook dimensions = 1  encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ]
 <a 
 id="x1-106022r11"></a>11

</div>

<h4 class="subsectionHead">8.5 <a 
 id="x1-1070008.5"></a>residue 2</h4>
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 ch passed in vectors of length n are first interleaved
and flattened into a single vector of length ch*n. Encoding then proceeds as in type 1. Decoding
is as in type 1 with decode interleave reversed. If operating on a single vector to begin with,
residue type 1 and type 2 are equivalent.
<div class="center" 
>

<img 
src="residue2.png" alt="PIC" 
>
 <div class="caption" 
>Figure 12: illustration of residue type 2</div>
</div>

<h4 class="subsectionHead">8.6 <a 
 id="x1-1080008.6"></a>Residue decode</h4>

<h5 class="subsubsectionHead">8.6.1 <a 
 id="x1-1090008.6.1"></a>header decode</h5>
Header decode for all three residue types is identical.
<div class="fancyvrb" id="fancyvrb35">
<a 
 id="x1-109002r1"></a>1    1) [residue_begin] = read 24 bits as unsigned integer
 <a 
 id="x1-109004r2"></a>2    2) [residue_end] = read 24 bits as unsigned integer
 <a 
 id="x1-109006r3"></a>3    3) [residue_partition_size] = read 24 bits as unsigned integer and add one
 <a 
 id="x1-109008r4"></a>4    4) [residue_classifications] = read 6 bits as unsigned integer and add one

<a 
 id="x1-109010r5"></a>5    5) [residue_classbook] = read 8 bits as unsigned integer
</div>
[residue_begin] and [residue_end] select the specific sub-portion of each vector that is
actually coded; it implements akin to a bandpass where, for coding purposes, the vector
effectively begins at element [residue_begin] and ends at [residue_end]. Preceding and
following values in the unpacked vectors are zeroed. Note that for residue type 2, these
values as well as [residue_partition_size]apply to the interleaved vector, not the
individual vectors before interleave. [residue_partition_size] is as explained above,
[residue_classifications] is the number of possible classification to which a partition can
belong and [residue_classbook] is the codebook number used to code classification
codewords. The number of dimensions in book [residue_classbook] determines how
many classification values are grouped into a single classification codeword. Note that
the number of entries and dimensions in book [residue_classbook], along with
[residue_classifications], overdetermines to possible number of classification
codewords. If [residue_classifications]ˆ[residue_classbook].dimensions exceeds
[residue_classbook].entries, the bitstream should be regarded to be undecodable.
Next we read a bitmap pattern that specifies which partition classes code values in which
passes.

<div class="fancyvrb" id="fancyvrb36">
<a 
 id="x1-109012r1"></a>1    1) iterate [i] over the range 0 ... [residue_classifications]-1 {
 <a 
 id="x1-109014r2"></a>2  
 <a 
 id="x1-109016r3"></a>3         2) [high_bits] = 0
 <a 
 id="x1-109018r4"></a>4         3) [low_bits] = read 3 bits as unsigned integer
 <a 
 id="x1-109020r5"></a>5         4) [bitflag] = read one bit as boolean
 <a 
 id="x1-109022r6"></a>6         5) if ( [bitflag] is set ) then [high_bits] = read five bits as unsigned integer
 <a 
 id="x1-109024r7"></a>7         6) vector [residue_cascade] element [i] = [high_bits] * 8 + [low_bits]
 <a 
 id="x1-109026r8"></a>8       }
 <a 
 id="x1-109028r9"></a>9    7) done
</div>
Finally, we read in a list of book numbers, each corresponding to specific bit set in the cascade
bitmap. We loop over the possible codebook classifications and the maximum possible number of
encoding stages (8 in Vorbis I, as constrained by the elements of the cascade bitmap being eight
bits):

<div class="fancyvrb" id="fancyvrb37">
<a 
 id="x1-109030r1"></a>1    1) iterate [i] over the range 0 ... [residue_classifications]-1 {
 <a 
 id="x1-109032r2"></a>2  
 <a 
 id="x1-109034r3"></a>3         2) iterate [j] over the range 0 ... 7 {
 <a 
 id="x1-109036r4"></a>4  
 <a 
 id="x1-109038r5"></a>5              3) if ( vector [residue_cascade] element [i] bit [j] is set ) {
 <a 
 id="x1-109040r6"></a>6  
 <a 
 id="x1-109042r7"></a>7                   4) array [residue_books] element [i][j] = read 8 bits as unsigned integer
 <a 
 id="x1-109044r8"></a>8  
 <a 
 id="x1-109046r9"></a>9                 } else {

<a 
 id="x1-109048r10"></a>10  
 <a 
 id="x1-109050r11"></a>11                   5) array [residue_books] element [i][j] = unused
 <a 
 id="x1-109052r12"></a>12  
 <a 
 id="x1-109054r13"></a>13                 }
 <a 
 id="x1-109056r14"></a>14            }
 <a 
 id="x1-109058r15"></a>15        }
 <a 
 id="x1-109060r16"></a>16  
 <a 
 id="x1-109062r17"></a>17    6) done
</div>
An end-of-packet condition at any point in header decode renders the stream undecodable.
In addition, any codebook number greater than the maximum numbered codebook
set up in this stream also renders the stream undecodable. All codebooks in array
[residue˙books] are required to have a value mapping. The presence of codebook in array
[residue˙books] without a value mapping (maptype equals zero) renders the stream
undecodable.

<h5 class="subsubsectionHead">8.6.2 <a 
 id="x1-1100008.6.2"></a>packet decode</h5>
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
infrastructure identical to all three formats.
In addition to configuration information, the residue decode process is passed the number of
vectors in the submap bundle and a vector of flags indicating if any of the vectors are not to be
decoded. If the passed in number of vectors is 3 and vector number 1 is marked ’do not decode’,
decode skips vector 1 during the decode loop. However, even ’do not decode’ vectors are
allocated and zeroed.
Depending on the values of [residue_begin] and [residue_end], it is obvious that the
encoded portion of a residue vector may be the entire possible residue vector or some other strict
subset of the actual residue vector size with zero padding at either uncoded end. However, it is
also possible to set [residue_begin] and [residue_end] to specify a range partially or wholly
beyond the maximum vector size. Before beginning residue decode, limit [residue_begin]
and [residue_end] to the maximum possible vector size as follows. We assume that
the number of vectors being encoded, [ch] is provided by the higher level decoding
process.

<div class="fancyvrb" id="fancyvrb38">
<a 
 id="x1-110002r1"></a>1    1) [actual_size] = current blocksize/2;
 <a 
 id="x1-110004r2"></a>2    2) if residue encoding is format 2
 <a 
 id="x1-110006r3"></a>3         3) [actual_size] = [actual_size] * [ch];

<a 
 id="x1-110008r4"></a>4    4) [limit_residue_begin] = maximum of ([residue_begin],[actual_size]);
 <a 
 id="x1-110010r5"></a>5    5) [limit_residue_end] = maximum of ([residue_end],[actual_size]);
</div>
The following convenience values are conceptually useful to clarifying the decode process:

<div class="fancyvrb" id="fancyvrb39">
<a 
 id="x1-110012r1"></a>1    1) [classwords_per_codeword] = [codebook_dimensions] value of codebook [residue_classbook]
 <a 
 id="x1-110014r2"></a>2    2) [n_to_read] = [limit_residue_end] - [limit_residue_begin]
 <a 
 id="x1-110016r3"></a>3    3) [partitions_to_read] = [n_to_read] / [residue_partition_size]
</div>
Packet decode proceeds as follows, matching the description offered earlier in the document.
<div class="fancyvrb" id="fancyvrb40">
<a 
 id="x1-110018r1"></a>1    1) allocate and zero all vectors that will be returned.
 <a 
 id="x1-110020r2"></a>2    2) if ([n_to_read] is zero), stop; there is no residue to decode.
 <a 
 id="x1-110022r3"></a>3    3) iterate [pass] over the range 0 ... 7 {
 <a 
 id="x1-110024r4"></a>4  
 <a 
 id="x1-110026r5"></a>5         4) [partition_count] = 0
 <a 
 id="x1-110028r6"></a>6  
 <a 
 id="x1-110030r7"></a>7         5) while [partition_count] is less than [partitions_to_read]
 <a 
 id="x1-110032r8"></a>8  
 <a 
 id="x1-110034r9"></a>9              6) if ([pass] is zero) {
 <a 
 id="x1-110036r10"></a>10  
 <a 
 id="x1-110038r11"></a>11                   7) iterate [j] over the range 0 .. [ch]-1 {
 <a 
 id="x1-110040r12"></a>12  
 <a 
 id="x1-110042r13"></a>13                        8) if vector [j] is not marked ’do not decode’ {
 <a 
 id="x1-110044r14"></a>14  
 <a 
 id="x1-110046r15"></a>15                             9) [temp] = read from packet using codebook [residue_classbook] in scalar context
 <a 
 id="x1-110048r16"></a>16                            10) iterate [i] descending over the range [classwords_per_codeword]-1 ... 0 {
 <a 
 id="x1-110050r17"></a>17  
 <a 
 id="x1-110052r18"></a>18                                 11) array [classifications] element [j],([i]+[partition_count]) =
 <a 
 id="x1-110054r19"></a>19                                     [temp] integer modulo [residue_classifications]
 <a 
 id="x1-110056r20"></a>20                                 12) [temp] = [temp] / [residue_classifications] using integer division
 <a 
 id="x1-110058r21"></a>21  
 <a 
 id="x1-110060r22"></a>22                                }
 <a 
 id="x1-110062r23"></a>23  
 <a 
 id="x1-110064r24"></a>24                           }
 <a 
 id="x1-110066r25"></a>25  
 <a 
 id="x1-110068r26"></a>26                      }
 <a 
 id="x1-110070r27"></a>27  
 <a 
 id="x1-110072r28"></a>28                 }
 <a 
 id="x1-110074r29"></a>29  
 <a 
 id="x1-110076r30"></a>30             13) iterate [i] over the range 0 .. ([classwords_per_codeword] - 1) while [partition_count]
 <a 
 id="x1-110078r31"></a>31                 is also less than [partitions_to_read] {
 <a 
 id="x1-110080r32"></a>32  
 <a 
 id="x1-110082r33"></a>33                   14) iterate [j] over the range 0 .. [ch]-1 {
 <a 
 id="x1-110084r34"></a>34  
 <a 
 id="x1-110086r35"></a>35                        15) if vector [j] is not marked ’do not decode’ {
 <a 
 id="x1-110088r36"></a>36  
 <a 
 id="x1-110090r37"></a>37                             16) [vqclass] = array [classifications] element [j],[partition_count]
 <a 
 id="x1-110092r38"></a>38                             17) [vqbook] = array [residue_books] element [vqclass],[pass]
 <a 
 id="x1-110094r39"></a>39                             18) if ([vqbook] is not ’unused’) {
 <a 
 id="x1-110096r40"></a>40  
 <a 
 id="x1-110098r41"></a>41                                  19) decode partition into output vector number [j], starting at scalar
 <a 
 id="x1-110100r42"></a>42                                      offset [limit_residue_begin]+[partition_count]*[residue_partition_size] using
 <a 
 id="x1-110102r43"></a>43                                      codebook number [vqbook] in VQ context
 <a 
 id="x1-110104r44"></a>44                            }

<a 
 id="x1-110106r45"></a>45                       }
 <a 
 id="x1-110108r46"></a>46  
 <a 
 id="x1-110110r47"></a>47                   20) increment [partition_count] by one
 <a 
 id="x1-110112r48"></a>48  
 <a 
 id="x1-110114r49"></a>49                 }
 <a 
 id="x1-110116r50"></a>50            }
 <a 
 id="x1-110118r51"></a>51       }
 <a 
 id="x1-110120r52"></a>52  
 <a 
 id="x1-110122r53"></a>53   21) done
 <a 
 id="x1-110124r54"></a>54  
</div>
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.

<h5 class="subsubsectionHead">8.6.3 <a 
 id="x1-1110008.6.3"></a>format 0 specifics</h5>
Format zero decodes partitions exactly as described earlier in the ’Residue Format: residue 0’
section. The following pseudocode presents the same algorithm. Assume:
 <ul class="itemize1">
 <li class="itemize">[n] is the value in [residue_partition_size]
 </li>
 <li class="itemize">[v] is the residue vector
 </li>
 <li class="itemize">[offset] is the beginning read offset in [v]</li></ul>

<div class="fancyvrb" id="fancyvrb41">
<a 
 id="x1-111002r1"></a>1   1) [step] = [n] / [codebook_dimensions]
 <a 
 id="x1-111004r2"></a>2   2) iterate [i] over the range 0 ... [step]-1 {
 <a 
 id="x1-111006r3"></a>3  
 <a 
 id="x1-111008r4"></a>4        3) vector [entry_temp] = read vector from packet using current codebook in VQ context
 <a 
 id="x1-111010r5"></a>5        4) iterate [j] over the range 0 ... [codebook_dimensions]-1 {
 <a 
 id="x1-111012r6"></a>6  
 <a 
 id="x1-111014r7"></a>7             5) vector [v] element ([offset]+[i]+[j]*[step]) =
 <a 
 id="x1-111016r8"></a>8           vector [v] element ([offset]+[i]+[j]*[step]) +
 <a 
 id="x1-111018r9"></a>9                  vector [entry_temp] element [j]
 <a 
 id="x1-111020r10"></a>10  
 <a 
 id="x1-111022r11"></a>11           }
 <a 
 id="x1-111024r12"></a>12  
 <a 
 id="x1-111026r13"></a>13      }
 <a 
 id="x1-111028r14"></a>14  
 <a 
 id="x1-111030r15"></a>15    6) done
 <a 
 id="x1-111032r16"></a>16

</div>

<h5 class="subsubsectionHead">8.6.4 <a 
 id="x1-1120008.6.4"></a>format 1 specifics</h5>
Format 1 decodes partitions exactly as described earlier in the ’Residue Format: residue 1’
section. The following pseudocode presents the same algorithm. Assume:
 <ul class="itemize1">
 <li class="itemize">[n] is the value in [residue_partition_size]
 </li>
 <li class="itemize">[v] is the residue vector
 </li>
 <li class="itemize">[offset] is the beginning read offset in [v]</li></ul>

<div class="fancyvrb" id="fancyvrb42">
<a 
 id="x1-112002r1"></a>1   1) [i] = 0
 <a 
 id="x1-112004r2"></a>2   2) vector [entry_temp] = read vector from packet using current codebook in VQ context
 <a 
 id="x1-112006r3"></a>3   3) iterate [j] over the range 0 ... [codebook_dimensions]-1 {
 <a 
 id="x1-112008r4"></a>4  
 <a 
 id="x1-112010r5"></a>5        4) vector [v] element ([offset]+[i]) =
 <a 
 id="x1-112012r6"></a>6     vector [v] element ([offset]+[i]) +
 <a 
 id="x1-112014r7"></a>7            vector [entry_temp] element [j]
 <a 
 id="x1-112016r8"></a>8        5) increment [i]
 <a 
 id="x1-112018r9"></a>9  
 <a 
 id="x1-112020r10"></a>10      }
 <a 
 id="x1-112022r11"></a>11  
 <a 
 id="x1-112024r12"></a>12    6) if ( [i] is less than [n] ) continue at step 2
 <a 
 id="x1-112026r13"></a>13    7) done
</div>

<h5 class="subsubsectionHead">8.6.5 <a 
 id="x1-1130008.6.5"></a>format 2 specifics</h5>
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.

Format 2 handles ’do not decode’ vectors differently than residue 0 or 1; if all vectors are marked
’do not decode’, no decode occurrs. However, if at least one vector is to be decoded, all
the vectors are decoded. We then request normal format 1 to decode a single vector
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:

 <ol class="enumerate1" >
 <li 
 class="enumerate" id="x1-113002x1">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.
 </li>
 <li 
 class="enumerate" id="x1-113004x2">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.
 </li>
 <li 
 class="enumerate" id="x1-113006x3">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:
 <div class="fancyvrb" id="fancyvrb43">
<a 
 id="x1-113008r1"></a>1    1) iterate [i] over the range 0 ... [n]-1 {
 <a 
 id="x1-113010r2"></a>2  
 <a 
 id="x1-113012r3"></a>3         2) iterate [j] over the range 0 ... [ch]-1 {
 <a 
 id="x1-113014r4"></a>4  
 <a 
 id="x1-113016r5"></a>5              3) output vector number [j] element [i] = vector [v] element ([i] * [ch] + [j])
 <a 
 id="x1-113018r6"></a>6  
 <a 
 id="x1-113020r7"></a>7            }
 <a 
 id="x1-113022r8"></a>8       }
 <a 
 id="x1-113024r9"></a>9  
 <a 
 id="x1-113026r10"></a>10    4) done
</div>
 </li></ol>

<h3 class="sectionHead">9 <a 
 id="x1-1140009"></a>Helper equations</h3>

<h4 class="subsectionHead">9.1 <a 
 id="x1-1150009.1"></a>Overview</h4>
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.

<h4 class="subsectionHead">9.2 <a 
 id="x1-1160009.2"></a>Functions</h4>

<h5 class="subsubsectionHead">9.2.1 <a 
 id="x1-1170009.2.1"></a>ilog</h5>
The ”ilog(x)” function returns the position number (1 through n) of the highest set bit in the
two’s complement integer value [x]. Values of [x] less than zero are defined to return
zero.

<div class="fancyvrb" id="fancyvrb44">
<a 
 id="x1-117002r1"></a>1    1) [return_value] = 0;
 <a 
 id="x1-117004r2"></a>2    2) if ( [x] is greater than zero ) {
 <a 
 id="x1-117006r3"></a>3  
 <a 
 id="x1-117008r4"></a>4         3) increment [return_value];
 <a 
 id="x1-117010r5"></a>5         4) logical shift [x] one bit to the right, padding the MSb with zero
 <a 
 id="x1-117012r6"></a>6         5) repeat at step 2)
 <a 
 id="x1-117014r7"></a>7  
 <a 
 id="x1-117016r8"></a>8       }
 <a 
 id="x1-117018r9"></a>9  
 <a 
 id="x1-117020r10"></a>10     6) done
</div>

Examples:
 <ul class="itemize1">
 <li class="itemize">ilog(0) = 0;
 </li>
 <li class="itemize">ilog(1) = 1;
 </li>
 <li class="itemize">ilog(2) = 2;
 </li>
 <li class="itemize">ilog(3) = 2;
 </li>
 <li class="itemize">ilog(4) = 3;
 </li>
 <li class="itemize">ilog(7) = 3;
 </li>
 <li class="itemize">ilog(negative number) = 0;</li></ul>

<h5 class="subsubsectionHead">9.2.2 <a 
 id="x1-1180009.2.2"></a>float32˙unpack</h5>
”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
purposes of this example, we will unpack a Vorbis float32 into a host-native floating point
number.

<div class="fancyvrb" id="fancyvrb45">
<a 
 id="x1-118002r1"></a>1    1) [mantissa] = [x] bitwise AND 0x1fffff (unsigned result)
 <a 
 id="x1-118004r2"></a>2    2) [sign] = [x] bitwise AND 0x80000000 (unsigned result)
 <a 
 id="x1-118006r3"></a>3    3) [exponent] = ( [x] bitwise AND 0x7fe00000) shifted right 21 bits (unsigned result)
 <a 
 id="x1-118008r4"></a>4    4) if ( [sign] is nonzero ) then negate [mantissa]
 <a 
 id="x1-118010r5"></a>5    5) return [mantissa] * ( 2 ^ ( [exponent] - 788 ) )
</div>

<h5 class="subsubsectionHead">9.2.3 <a 
 id="x1-1190009.2.3"></a>lookup1˙values</h5>
”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. The values on this list are
permuted to construct the VQ vector lookup table of size [codebook_entries].
The return value for this function is defined to be ’the greatest integer value for which
[return_value] to the power of [codebook_dimensions] is less than or equal to
[codebook_entries]’.

<h5 class="subsubsectionHead">9.2.4 <a 
 id="x1-1200009.2.4"></a>low˙neighbor</h5>
”low˙neighbor(v,x)” finds the position n in vector [v] of the greatest value scalar element for
which n is less than [x] and vector [v] element n is less than vector [v] element
[x].

<h5 class="subsubsectionHead">9.2.5 <a 
 id="x1-1210009.2.5"></a>high˙neighbor</h5>
”high˙neighbor(v,x)” finds the position n in vector [v] of the lowest value scalar element for
which n is less than [x] and vector [v] element n is greater than vector [v] element
[x].

<h5 class="subsubsectionHead">9.2.6 <a 
 id="x1-1220009.2.6"></a>render˙point</h5>
”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
calculating intervening values along the line.

<div class="fancyvrb" id="fancyvrb46">
<a 
 id="x1-122002r1"></a>1    1)  [dy] = [y1] - [y0]
 <a 
 id="x1-122004r2"></a>2    2) [adx] = [x1] - [x0]
 <a 
 id="x1-122006r3"></a>3    3) [ady] = absolute value of [dy]
 <a 
 id="x1-122008r4"></a>4    4) [err] = [ady] * ([X] - [x0])
 <a 
 id="x1-122010r5"></a>5    5) [off] = [err] / [adx] using integer division
 <a 
 id="x1-122012r6"></a>6    6) if ( [dy] is less than zero ) {
 <a 
 id="x1-122014r7"></a>7  
 <a 
 id="x1-122016r8"></a>8         7) [Y] = [y0] - [off]
 <a 
 id="x1-122018r9"></a>9  
 <a 
 id="x1-122020r10"></a>10       } else {
 <a 
 id="x1-122022r11"></a>11  
 <a 
 id="x1-122024r12"></a>12         8) [Y] = [y0] + [off]
 <a 
 id="x1-122026r13"></a>13  
 <a 
 id="x1-122028r14"></a>14       }
 <a 
 id="x1-122030r15"></a>15  
 <a 
 id="x1-122032r16"></a>16    9) done
</div>

<h5 class="subsubsectionHead">9.2.7 <a 
 id="x1-1230009.2.7"></a>render˙line</h5>
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
been relevant elsewhere, but here we must define integer division as rounding division of both
positive and negative numbers toward zero.

<div class="fancyvrb" id="fancyvrb47">
<a 
 id="x1-123002r1"></a>1    1)   [dy] = [y1] - [y0]
 <a 
 id="x1-123004r2"></a>2    2)  [adx] = [x1] - [x0]
 <a 
 id="x1-123006r3"></a>3    3)  [ady] = absolute value of [dy]
 <a 
 id="x1-123008r4"></a>4    4) [base] = [dy] / [adx] using integer division
 <a 
 id="x1-123010r5"></a>5    5)    [x] = [x0]
 <a 
 id="x1-123012r6"></a>6    6)    [y] = [y0]
 <a 
 id="x1-123014r7"></a>7    7)  [err] = 0
 <a 
 id="x1-123016r8"></a>8  
 <a 
 id="x1-123018r9"></a>9    8) if ( [dy] is less than 0 ) {
 <a 
 id="x1-123020r10"></a>10  
 <a 
 id="x1-123022r11"></a>11          9) [sy] = [base] - 1
 <a 
 id="x1-123024r12"></a>12  
 <a 
 id="x1-123026r13"></a>13       } else {
 <a 
 id="x1-123028r14"></a>14  
 <a 
 id="x1-123030r15"></a>15         10) [sy] = [base] + 1
 <a 
 id="x1-123032r16"></a>16  
 <a 
 id="x1-123034r17"></a>17       }
 <a 
 id="x1-123036r18"></a>18  
 <a 
 id="x1-123038r19"></a>19   11) [ady] = [ady] - (absolute value of [base]) * [adx]
 <a 
 id="x1-123040r20"></a>20   12) vector [v] element [x] = [y]
 <a 
 id="x1-123042r21"></a>21  
 <a 
 id="x1-123044r22"></a>22   13) iterate [x] over the range [x0]+1 ... [x1]-1 {
 <a 
 id="x1-123046r23"></a>23  
 <a 
 id="x1-123048r24"></a>24         14) [err] = [err] + [ady];

<a 
 id="x1-123050r25"></a>25         15) if ( [err] >= [adx] ) {
 <a 
 id="x1-123052r26"></a>26  
 <a 
 id="x1-123054r27"></a>27               16) [err] = [err] - [adx]
 <a 
 id="x1-123056r28"></a>28               17)   [y] = [y] + [sy]
 <a 
 id="x1-123058r29"></a>29  
 <a 
 id="x1-123060r30"></a>30             } else {
 <a 
 id="x1-123062r31"></a>31  
 <a 
 id="x1-123064r32"></a>32               18) [y] = [y] + [base]
 <a 
 id="x1-123066r33"></a>33  
 <a 
 id="x1-123068r34"></a>34             }
 <a 
 id="x1-123070r35"></a>35  
 <a 
 id="x1-123072r36"></a>36         19) vector [v] element [x] = [y]
 <a 
 id="x1-123074r37"></a>37  
 <a 
 id="x1-123076r38"></a>38       }
</div>

<h3 class="sectionHead">10 <a 
 id="x1-12400010"></a>Tables</h3>

<h4 class="subsectionHead">10.1 <a 
 id="x1-12500010.1"></a>floor1_inverse_dB_table</h4>
The vector [floor1_inverse_dB_table] is a 256 element static lookup table consiting of the
following values (read left to right then top to bottom):

<div class="fancyvrb" id="fancyvrb48">
<a 
 id="x1-125002r1"></a>1    1.0649863e-07, 1.1341951e-07, 1.2079015e-07, 1.2863978e-07,
 <a 
 id="x1-125004r2"></a>2    1.3699951e-07, 1.4590251e-07, 1.5538408e-07, 1.6548181e-07,
 <a 
 id="x1-125006r3"></a>3    1.7623575e-07, 1.8768855e-07, 1.9988561e-07, 2.1287530e-07,
 <a 
 id="x1-125008r4"></a>4    2.2670913e-07, 2.4144197e-07, 2.5713223e-07, 2.7384213e-07,
 <a 
 id="x1-125010r5"></a>5    2.9163793e-07, 3.1059021e-07, 3.3077411e-07, 3.5226968e-07,
 <a 
 id="x1-125012r6"></a>6    3.7516214e-07, 3.9954229e-07, 4.2550680e-07, 4.5315863e-07,
 <a 
 id="x1-125014r7"></a>7    4.8260743e-07, 5.1396998e-07, 5.4737065e-07, 5.8294187e-07,
 <a 
 id="x1-125016r8"></a>8    6.2082472e-07, 6.6116941e-07, 7.0413592e-07, 7.4989464e-07,
 <a 
 id="x1-125018r9"></a>9    7.9862701e-07, 8.5052630e-07, 9.0579828e-07, 9.6466216e-07,
 <a 
 id="x1-125020r10"></a>10    1.0273513e-06, 1.0941144e-06, 1.1652161e-06, 1.2409384e-06,
 <a 
 id="x1-125022r11"></a>11    1.3215816e-06, 1.4074654e-06, 1.4989305e-06, 1.5963394e-06,
 <a 
 id="x1-125024r12"></a>12    1.7000785e-06, 1.8105592e-06, 1.9282195e-06, 2.0535261e-06,
 <a 
 id="x1-125026r13"></a>13    2.1869758e-06, 2.3290978e-06, 2.4804557e-06, 2.6416497e-06,
 <a 
 id="x1-125028r14"></a>14    2.8133190e-06, 2.9961443e-06, 3.1908506e-06, 3.3982101e-06,
 <a 
 id="x1-125030r15"></a>15    3.6190449e-06, 3.8542308e-06, 4.1047004e-06, 4.3714470e-06,
 <a 
 id="x1-125032r16"></a>16    4.6555282e-06, 4.9580707e-06, 5.2802740e-06, 5.6234160e-06,
 <a 
 id="x1-125034r17"></a>17    5.9888572e-06, 6.3780469e-06, 6.7925283e-06, 7.2339451e-06,
 <a 
 id="x1-125036r18"></a>18    7.7040476e-06, 8.2047000e-06, 8.7378876e-06, 9.3057248e-06,
 <a 
 id="x1-125038r19"></a>19    9.9104632e-06, 1.0554501e-05, 1.1240392e-05, 1.1970856e-05,
 <a 
 id="x1-125040r20"></a>20    1.2748789e-05, 1.3577278e-05, 1.4459606e-05, 1.5399272e-05,
 <a 
 id="x1-125042r21"></a>21    1.6400004e-05, 1.7465768e-05, 1.8600792e-05, 1.9809576e-05,
 <a 
 id="x1-125044r22"></a>22    2.1096914e-05, 2.2467911e-05, 2.3928002e-05, 2.5482978e-05,
 <a 
 id="x1-125046r23"></a>23    2.7139006e-05, 2.8902651e-05, 3.0780908e-05, 3.2781225e-05,
 <a 
 id="x1-125048r24"></a>24    3.4911534e-05, 3.7180282e-05, 3.9596466e-05, 4.2169667e-05,
 <a 
 id="x1-125050r25"></a>25    4.4910090e-05, 4.7828601e-05, 5.0936773e-05, 5.4246931e-05,
 <a 
 id="x1-125052r26"></a>26    5.7772202e-05, 6.1526565e-05, 6.5524908e-05, 6.9783085e-05,
 <a 
 id="x1-125054r27"></a>27    7.4317983e-05, 7.9147585e-05, 8.4291040e-05, 8.9768747e-05,
 <a 
 id="x1-125056r28"></a>28    9.5602426e-05, 0.00010181521, 0.00010843174, 0.00011547824,
 <a 
 id="x1-125058r29"></a>29    0.00012298267, 0.00013097477, 0.00013948625, 0.00014855085,
 <a 
 id="x1-125060r30"></a>30    0.00015820453, 0.00016848555, 0.00017943469, 0.00019109536,
 <a 
 id="x1-125062r31"></a>31    0.00020351382, 0.00021673929, 0.00023082423, 0.00024582449,
 <a 
 id="x1-125064r32"></a>32    0.00026179955, 0.00027881276, 0.00029693158, 0.00031622787,
 <a 
 id="x1-125066r33"></a>33    0.00033677814, 0.00035866388, 0.00038197188, 0.00040679456,
 <a 
 id="x1-125068r34"></a>34    0.00043323036, 0.00046138411, 0.00049136745, 0.00052329927,
 <a 
 id="x1-125070r35"></a>35    0.00055730621, 0.00059352311, 0.00063209358, 0.00067317058,
 <a 
 id="x1-125072r36"></a>36    0.00071691700, 0.00076350630, 0.00081312324, 0.00086596457,
 <a 
 id="x1-125074r37"></a>37    0.00092223983, 0.00098217216, 0.0010459992,  0.0011139742,
 <a 
 id="x1-125076r38"></a>38    0.0011863665,  0.0012634633,  0.0013455702,  0.0014330129,
 <a 
 id="x1-125078r39"></a>39    0.0015261382,  0.0016253153,  0.0017309374,  0.0018434235,
 <a 
 id="x1-125080r40"></a>40    0.0019632195,  0.0020908006,  0.0022266726,  0.0023713743,
 <a 
 id="x1-125082r41"></a>41    0.0025254795,  0.0026895994,  0.0028643847,  0.0030505286,
 <a 
 id="x1-125084r42"></a>42    0.0032487691,  0.0034598925,  0.0036847358,  0.0039241906,

<h3 class="sectionHead">A <a 
 id="x1-126000A"></a>Embedding Vorbis into an Ogg stream</h3>

<h4 class="subsectionHead">A.1 <a 
 id="x1-127000A.1"></a>Overview</h4>
This document describes using Ogg logical and physical transport streams to encapsulate Vorbis
compressed audio packet data into file form.
The <a 
href="#x1-20001">Section 1</a>, “<a 
href="#x1-20001">Introduction and Description</a>” provides an overview of the construction of
Vorbis audio packets.
The <a 
href="oggstream.html" >Ogg bitstream overview</a> and <a 
href="framing.html" >Ogg logical bitstream and framing spec</a> provide detailed
descriptions of Ogg transport streams. This specification document assumes a working
knowledge of the concepts covered in these named backround documents. Please read them
first.

<h5 class="subsubsectionHead">A.1.1 <a 
 id="x1-128000A.1.1"></a>Restrictions</h5>
The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis streams use Ogg transport
streams in degenerate, unmultiplexed form only. That is:
 <ul class="itemize1">
 <li class="itemize">A meta-headerless Ogg file encapsulates the Vorbis I packets
 </li>
 <li class="itemize">The Ogg stream may be chained, i.e., contain multiple, contigous logical streams
 (links).
 </li>
 <li class="itemize">The Ogg stream must be unmultiplexed (only one stream, a Vorbis audio stream,
 per link)
 </li></ul>

This is not to say that it is not currently possible to multiplex Vorbis with other media
types into a multi-stream Ogg file. At the time this document was written, Ogg was
becoming a popular container for low-bitrate movies consisting of DivX video and Vorbis
audio. However, a ’Vorbis I audio file’ is taken to imply Vorbis audio existing alone
within a degenerate Ogg stream. A compliant ’Vorbis audio player’ is not required to
implement Ogg support beyond the specific support of Vorbis within a degenrate Ogg
stream (naturally, application authors are encouraged to support full multiplexed Ogg
handling).

<h5 class="subsubsectionHead">A.1.2 <a 
 id="x1-129000A.1.2"></a>MIME type</h5>
The MIME type of Ogg files depend on the context. Specifically, complex multimedia and
applications should use application/ogg, while visual media should use video/ogg, and audio
audio/ogg. Vorbis data encapsulated in Ogg may appear in any of those types. RTP
encapsulated Vorbis should use audio/vorbis + audio/vorbis-config.

<h4 class="subsectionHead">A.2 <a 
 id="x1-130000A.2"></a>Encapsulation</h4>
Ogg encapsulation of a Vorbis packet stream is straightforward.
 <ul class="itemize1">
 <li class="itemize">The first Vorbis packet (the identification header), which uniquely identifies a stream
 as Vorbis audio, is placed alone in the first page of the logical Ogg stream. This
 results in a first Ogg page of exactly 58 bytes at the very beginning of the logical
 stream.
 </li>
 <li class="itemize">This first page is marked ’beginning of stream’ in the page flags.
 </li>
 <li class="itemize">The second and third vorbis packets (comment and setup headers) may span one or
 more pages beginning on the second page of the logical stream. However many pages
 they span, the third header packet finishes the page on which it ends. The next (first
 audio) packet must begin on a fresh page.

</li>
 <li class="itemize">The granule position of these first pages containing only headers is zero.
 </li>
 <li class="itemize">The first audio packet of the logical stream begins a fresh Ogg page.
 </li>
 <li class="itemize">Packets are placed into ogg pages in order until the end of stream.
 </li>
 <li class="itemize">The last page is marked ’end of stream’ in the page flags.
 </li>
 <li class="itemize">Vorbis packets may span page boundaries.
 </li>
 <li class="itemize">The granule position of pages containing Vorbis audio is in units of PCM audio
 samples (per channel; a stereo stream’s granule position does not increment at twice
 the speed of a mono stream).
 </li>
 <li class="itemize">The granule position of a page represents the end PCM sample position of the last
 packet completed on that page. The ’last PCM sample’ is the last complete sample
 returned by decode, not an internal sample awaiting lapping with a subsequent block.
 A page that is entirely spanned by a single packet (that completes on a subsequent
 page) has no granule position, and the granule position is set to ’-1’.
 Note that the last decoded (fully lapped) PCM sample from a packet is not
 necessarily the middle sample from that block. If, eg, the current Vorbis packet
 encodes a ”long block” and the next Vorbis packet encodes a ”short block”, the last
 decodable sample from the current packet be at position (3*long_block_length/4) -
 (short_block_length/4).
 </li>
 <li class="itemize">The granule (PCM) position of the first page need not indicate that the stream
 started at position zero. Although the granule position belongs to the last completed
 packet on the page and a valid granule position must be positive, by inference it may
 indicate that the PCM position of the beginning of audio is positive or negative.
 <ul class="itemize2">
 <li class="itemize">A positive starting value simply indicates that this stream begins at some
 positive time offset, potentially within a larger program. This is a common case
 when connecting to the middle of broadcast stream.
 </li>
 <li class="itemize">A negative value indicates that output samples preceeding time zero should be

discarded during decoding; this technique is used to allow sample-granularity
 editing of the stream start time of already-encoded Vorbis streams. The number
 of samples to be discarded must not exceed the overlap-add span of the first two
 audio packets.
 </li></ul>
 In both of these cases in which the initial audio PCM starting offset is nonzero, the
 second finished audio packet must flush the page on which it appears and the
 third packet begin a fresh page. This allows the decoder to always be able to
 perform PCM position adjustments before needing to return any PCM data from
 synthesis, resulting in correct positioning information without any aditional seeking
 logic.
 <a 
 id="x1-131000A.2"></a>Note: Failure to do so should, at worst, cause a decoder implementation to return
 incorrect positioning information for seeking operations at the very beginning of the
 stream.
 </li>
 <li class="itemize">A granule position on the final page in a stream that indicates less audio data than the
 final packet would normally return is used to end the stream on other than even frame
 boundaries. The difference between the actual available data returned and the
 declared amount indicates how many trailing samples to discard from the decoding
 process.
 </li></ul>

<h3 class="sectionHead">B <a 
 id="x1-132000B"></a>Vorbis encapsulation in RTP</h3>
Please consult RFC 5215 “RTP Payload Format for Vorbis Encoded Audio” for description of
how to embed Vorbis audio in an RTP stream.

<h3 class="likesectionHead"><a 
 id="x1-133000B"></a>Colophon</h3>
<img 
src="Vorbis_I_spec13x.png" alt="PIC" class="graphics">
Ogg is a <a 
href="http://www.xiph.org/" >Xiph.org Foundation</a> effort to protect essential tenets of Internet multimedia from
corporate hostage-taking; Open Source is the net’s greatest tool to keep everyone honest. See
<a 
href="http://www.xiph.org/about.html" >About the Xiph.org Foundation</a> for details.
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and distribute the Ogg and
Vorbis specification, whether in a private, public or corporate capacity. However, the Xiph.org
Foundation and the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis specification
and certify specification compliance.
Xiph.org’s Vorbis software CODEC implementation is distributed under a BSD-like license. This
does not restrict third parties from distributing independent implementations of Vorbis software
under other licenses.
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm) of the <a 
href="http://www.xiph.org/" >Xiph.org
Foundation</a>. These pages are copyright (C) 1994-2007 Xiph.org Foundation. All rights
reserved.
This document is set using LATEX.

<h3 class="likesectionHead"><a 
 id="x1-134000B"></a>References</h3>

 <div class="thebibliography">
 
 [1]   <a 
 id="XSporer/Brandenburg/Edler"></a>T. Sporer, K. Brandenburg and
 B. Edler, The use of multirate filter banks for coding of high quality digital audio,
 <a 
href="http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps" class="url" >http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps</a>.

 </div>
 
</body></html>

Html程序 | 13723行 | 557.83 KB

登录后可以享受更多权益