From: Monty Date: Thu, 26 Feb 2015 22:06:54 +0000 (+0000) Subject: This commit has two 'functional changes': X-Git-Tag: v1.3.5~11 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=b942206d64f01a598599e48f6d34ae6f824e6c67;p=platform%2Fupstream%2Flibvorbis.git This commit has two 'functional changes': Update the footer to use a modern logo and not kick out a formatting error handle errata discussed in Trac #2139 regarding single-entry codebooks svn path=/trunk/vorbis/; revision=19445 --- diff --git a/doc/03-codebook.tex b/doc/03-codebook.tex index 2da74af..4ba5e31 100644 --- a/doc/03-codebook.tex +++ b/doc/03-codebook.tex @@ -266,17 +266,68 @@ eliminated, it's clear that the tree is unfinished: 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. +undecodable. 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. - +\paragraph{Errata 20150226: Single entry codebooks} + +A 'single-entry codebook' is a codebook with one active codeword +entry. A single-entry codebook may be either a fully populated +codebook with only one declared entry, or a sparse codebook with only +one entry marked used. The Vorbis I spec provides no means to specify +a codeword length of zero, and as a result, a single-entry codebook is +inherently malformed because it is underpopulated. The original +specification did not address directly the matter of single-entry +codebooks; they were implicitly illegal as it was not possible to +write such a codebook with a valid tree structure. + +In r14811 of the libvorbis reference implementation, Xiph added an +additional check to the codebook implementation to reject +underpopulated Huffman trees. This change led to the discovery of +single-entry books used 'in the wild' when the new, stricter checks +rejected a number of apparently working streams. + +In order to minimize breakage of deployed (if technically erroneous) +streams, r16073 of the reference implementation explicitly +special-cased single-entry codebooks to tolerate the single-entry +case. Commit r16073 also added the following to the specification: + +\blockquote{\sout{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. +}} + +The intent was to clarify the spec and codify current practice. +However, this addition is erroneously at odds with the intent of preserving +usability of existing streams using single-entry codebooks, disagrees +with the code changes that reinstated decoding, and does not address how +single-entry codebooks should be encoded. + +As such, the above addition made in r16037 is struck from the +specification and replaced by the following: + +\blockquote{It is possible to declare a Vorbis codebook containing a + single codework entry. A single-entry codebook may be either a + fully populated codebook with \varname{[codebook\_entries]} set to + 1, or a sparse codebook marking only one entry used. Note that it + is not possible to also encode a \varname{[codeword\_length]} of + zero for the single used codeword, as the unsigned value written to + the stream is \varname{[codeword\_length]-1}. Instead, encoder + implementations should indicate a \varname{[codeword\_length]} of 1 + and 'write' the codeword to a stream during audio encoding by + writing a single zero bit. + + Decoder implementations shall reject a codebook if it contains only + one used entry and the encoded \varname{[codeword\_length]} of that + entry is not 1. 'Reading' a value from single-entry codebook always + returns the single used codeword value and sinks one bit. Decoders + should tolerate that the bit read from the stream be '1' instead of + '0'; both values shall return the single used codeword.} \paragraph{VQ lookup table vector representation} diff --git a/doc/Makefile.am b/doc/Makefile.am index 3adf6b3..1ce842f 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -36,6 +36,7 @@ static_docs = \ # bits needed by the spec SPEC_PNG = \ components.png \ + fish_xiph_org.png \ floor1-1.png \ floor1-2.png \ floor1-3.png \ @@ -46,10 +47,6 @@ SPEC_PNG = \ residue2.png \ window1.png \ window2.png -SPEC_PDF = xifish.pdf - -# FIXME: also needed here -# white-xifish.png SPEC_TEX = \ Vorbis_I_spec.tex \ diff --git a/doc/Vorbis_I_spec.css b/doc/Vorbis_I_spec.css index 2324982..5331f18 100644 --- a/doc/Vorbis_I_spec.css +++ b/doc/Vorbis_I_spec.css @@ -135,5 +135,10 @@ span.footnote-mark sup.textsuperscript, span.footnote-mark a sup.textsuperscript .figure img.graphics {margin-left:10%;} P.fancyvrb {white-space: nowrap; margin:0em;} dt.enumerate-enumitem{float:left; clear:left; margin-left:1em; margin-right:1em;} +.uline{ text-decoration:underline; } +.uuline{ text-decoration:underline; } +span.sout {text-decoration: line-through } +span.xout {text-decoration: line-through } +span.uwave {text-decoration:underline } /* end css.sty */ diff --git a/doc/Vorbis_I_spec.html b/doc/Vorbis_I_spec.html index 2f9de8c..31c546a 100644 --- a/doc/Vorbis_I_spec.html +++ b/doc/Vorbis_I_spec.html @@ -3,11 +3,11 @@ Vorbis I specification - - + + - + @@ -23,7 +23,7 @@
Xiph.Org Foundation

February 3, 2012
+class="cmr-17">February 26, 2015

Contents

@@ -100,148 +100,148 @@ href="#x1-500003.2" id="QQ2-1-53">Packed codebook format
   3.2.1 codebook decode
  3.3 Use of the codebook abstraction +href="#x1-580003.3" id="QQ2-1-63">Use of the codebook abstraction
 4 Codec Setup and Packet Decode +href="#x1-590004" id="QQ2-1-64">Codec Setup and Packet Decode
  4.1 Overview +href="#x1-600004.1" id="QQ2-1-65">Overview
  4.2 Header decode and decode setup +href="#x1-610004.2" id="QQ2-1-66">Header decode and decode setup
   4.2.1 Common header decode +href="#x1-620004.2.1" id="QQ2-1-67">Common header decode
   4.2.2 Identification header +href="#x1-630004.2.2" id="QQ2-1-68">Identification header
   4.2.3 Comment header +href="#x1-640004.2.3" id="QQ2-1-69">Comment header
   4.2.4 Setup header +href="#x1-650004.2.4" id="QQ2-1-70">Setup header
  4.3 Audio packet decode and synthesis +href="#x1-720004.3" id="QQ2-1-78">Audio packet decode and synthesis
   4.3.1 packet type, mode and window decode +href="#x1-730004.3.1" id="QQ2-1-79">packet type, mode and window decode
   4.3.2 floor curve decode +href="#x1-740004.3.2" id="QQ2-1-80">floor curve decode
   4.3.3 nonzero vector propagate +href="#x1-750004.3.3" id="QQ2-1-81">nonzero vector propagate
   4.3.4 residue decode +href="#x1-760004.3.4" id="QQ2-1-82">residue decode
   4.3.5 inverse coupling +href="#x1-770004.3.5" id="QQ2-1-83">inverse coupling
   4.3.6 dot product +href="#x1-780004.3.6" id="QQ2-1-84">dot product
   4.3.7 inverse MDCT +href="#x1-790004.3.7" id="QQ2-1-85">inverse MDCT
   4.3.8 overlap_add +href="#x1-800004.3.8" id="QQ2-1-86">overlap_add
   4.3.9 output channel order +href="#x1-810004.3.9" id="QQ2-1-87">output channel order
 5 comment field and header specification +href="#x1-820005" id="QQ2-1-88">comment field and header specification
  5.1 Overview +href="#x1-830005.1" id="QQ2-1-89">Overview
  5.2 Comment encoding +href="#x1-840005.2" id="QQ2-1-90">Comment encoding
   5.2.1 Structure +href="#x1-850005.2.1" id="QQ2-1-91">Structure
   5.2.2 Content vector format +href="#x1-860005.2.2" id="QQ2-1-92">Content vector format
   5.2.3 Encoding +href="#x1-890005.2.3" id="QQ2-1-95">Encoding
 6 Floor type 0 setup and decode +href="#x1-900006" id="QQ2-1-96">Floor type 0 setup and decode
  6.1 Overview +href="#x1-910006.1" id="QQ2-1-97">Overview
  6.2 Floor 0 format +href="#x1-920006.2" id="QQ2-1-98">Floor 0 format
   6.2.1 header decode +href="#x1-930006.2.1" id="QQ2-1-99">header decode
   6.2.2 packet decode +href="#x1-940006.2.2" id="QQ2-1-100">packet decode
   6.2.3 curve computation +href="#x1-950006.2.3" id="QQ2-1-101">curve computation
 7 Floor type 1 setup and decode +href="#x1-960007" id="QQ2-1-102">Floor type 1 setup and decode
  7.1 Overview +href="#x1-970007.1" id="QQ2-1-103">Overview
  7.2 Floor 1 format +href="#x1-980007.2" id="QQ2-1-104">Floor 1 format
   7.2.1 model +href="#x1-990007.2.1" id="QQ2-1-105">model
   7.2.2 header decode +href="#x1-1000007.2.2" id="QQ2-1-110">header decode
   7.2.3 packet decode +href="#x1-1010007.2.3" id="QQ2-1-111">packet decode
   7.2.4 curve computation +href="#x1-1020007.2.4" id="QQ2-1-112">curve computation
 8 Residue setup and decode +href="#x1-1030008" id="QQ2-1-113">Residue setup and decode
  8.1 Overview +href="#x1-1040008.1" id="QQ2-1-114">Overview
  8.2 Residue format +href="#x1-1050008.2" id="QQ2-1-115">Residue format
  8.3 residue 0 +href="#x1-1060008.3" id="QQ2-1-117">residue 0
  8.4 residue 1 +href="#x1-1070008.4" id="QQ2-1-118">residue 1
  8.5 residue 2 +href="#x1-1080008.5" id="QQ2-1-119">residue 2
  8.6 Residue decode +href="#x1-1090008.6" id="QQ2-1-121">Residue decode
   8.6.1 header decode +href="#x1-1100008.6.1" id="QQ2-1-122">header decode
   8.6.2 packet decode +href="#x1-1110008.6.2" id="QQ2-1-123">packet decode
   8.6.3 format 0 specifics +href="#x1-1120008.6.3" id="QQ2-1-124">format 0 specifics
   8.6.4 format 1 specifics +href="#x1-1130008.6.4" id="QQ2-1-125">format 1 specifics
   8.6.5 format 2 specifics +href="#x1-1140008.6.5" id="QQ2-1-126">format 2 specifics
 9 Helper equations +href="#x1-1150009" id="QQ2-1-127">Helper equations
  9.1 Overview +href="#x1-1160009.1" id="QQ2-1-128">Overview
  9.2 Functions +href="#x1-1170009.2" id="QQ2-1-129">Functions
   9.2.1 ilog +href="#x1-1180009.2.1" id="QQ2-1-130">ilog
   9.2.2 float32_unpack +href="#x1-1190009.2.2" id="QQ2-1-131">float32_unpack
   9.2.3 lookup1_values +href="#x1-1200009.2.3" id="QQ2-1-132">lookup1_values
   9.2.4 low_neighbor +href="#x1-1210009.2.4" id="QQ2-1-133">low_neighbor
   9.2.5 high_neighbor +href="#x1-1220009.2.5" id="QQ2-1-134">high_neighbor
   9.2.6 render_point +href="#x1-1230009.2.6" id="QQ2-1-135">render_point
   9.2.7 render_line +href="#x1-1240009.2.7" id="QQ2-1-136">render_line
 10 Tables +href="#x1-12500010" id="QQ2-1-137">Tables
  10.1 floor1_inverse_dB_table +href="#x1-12600010.1" id="QQ2-1-138">floor1_inverse_dB_table
 A Embedding Vorbis into an Ogg stream +href="#x1-127000A" id="QQ2-1-139">Embedding Vorbis into an Ogg stream
  A.1 Overview +href="#x1-128000A.1" id="QQ2-1-140">Overview
   A.1.1 Restrictions +href="#x1-129000A.1.1" id="QQ2-1-141">Restrictions
   A.1.2 MIME type +href="#x1-130000A.1.2" id="QQ2-1-142">MIME type
  A.2 Encapsulation +href="#x1-131000A.2" id="QQ2-1-143">Encapsulation
 B Vorbis encapsulation in RTP +href="#x1-133000B" id="QQ2-1-145">Vorbis encapsulation in RTP @@ -253,8 +253,8 @@ href="#x1-132000B" id="QQ2-1-144">Vorbis encapsulation in RTP id="x1-30001.1">Overview

This document provides a high level description of the Vorbis codec’s construction. A bit-by-bit specification appears beginning in Section 4, “Codec Setup and Packet Decode”. The later +href="#x1-590004">section 4, “Codec Setup and Packet Decode”. The later sections assume a high-level understanding of the Vorbis decode process, which is provided here.

@@ -306,9 +306,9 @@ document, we will assume that Vorbis is to be embedded in an Ogg stream specific 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 Section A, +href="#x1-127000A">section A, “Embedding Vorbis into an Ogg stream”. +href="#x1-127000A">Embedding Vorbis into an Ogg stream”.

1.1.4. Codec Setup and Probability Model
@@ -496,8 +496,8 @@ class="cmbx-12">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 Section 5, “comment field and header specification”. +href="#x1-820005">section 5, “comment field and header specification”.

Setup Header @@ -625,7 +625,7 @@ href="#XSporer/Brandenburg/Edler">1]. Vorbis windows all use the slope function

y = sin (.5 ∗ π sin2((x + .5)∕n ∗ π)). +src=However, floor vector values can span ∼140dB (∼24 bits unsigned), and the audio spectrum +class="cmsy-10x-x-120">~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 +class="cmsy-10x-x-120">~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 +class="cmsy-10x-x-120">-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. +class="cmsy-10x-x-120">-140dB to +0dB. Thus, in order to handle full range dynamics, a residue vector may span −140dB to +class="cmsy-10x-x-120">-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 @@ -742,13 +742,11 @@ 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:

-

-1  window_blocksize(previous_window)/4+window_blocksize(current_window)/4 -
+class="cmtt-8"> window_blocksize(previous_window)/4+window_blocksize(current_window)/4

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 @@ -846,8 +844,7 @@ unsigned. id="x1-430002.1.6">coding example

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

-

-1      | -
 |
2      V -
 V
3   -
 
4  4 3 2 1 0 -
 0
5  1 0 0]  <- -
 <-
6      ] -
 ]
8      ] -
 ]
9      ... -
 ...
10  bytestream length == 1 byte -
 byte
11   -
+class="cmtt-8"> 

Continue by coding the 3 bit integer value ’-1’ [b111]:

-

-1      | -
 |
2      V -
 V
3   -
 
4  4 3 2 1 0 -
 0
5  1 0 0]  <- -
 <-
6     ] - - -
7     ] -
 ]
8      ] -
 ]
9      ... -
 ...
10  bytestream length == 1 byte -
+class="cmtt-8"> byte

Continue by coding the 7 bit integer value ’17’ [b0010001]:

-

-1      | -
 |
2      V -
 V
3   -
 
4  4 3 2 1 0 -
 0
5  1 1 1 0 0] -
 0]
6  0 0 0]  <- -
 <-
7      ] -
 ]
9      ... -
 ...
10  bytestream length == 2 bytes -
 bytes
11   bit cursor == 6 -
+class="cmtt-8"> 6

Continue by coding the 13 bit integer value ’6969’ [b110 11001110 01]:

-

-1      | -
 |
2      V -
 V
3   -
 
4  4 3 2 1 0 -
 0
5  1 1 1 0 0] -
 0]
6  0 1 1 1 0] -
 0]
8  1 1 0]  <- -
 <-
9      ... -
 ...
10  bytestream length == 4 bytes -
 bytes
11   -
+class="cmtt-8">  + + +

2.1.7. decoding example

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

-

- - - -1      | -
 |
2      V -
 V
3   -
 
4  4 3 2 1 0 -
 0
5  0 1 0 0 0] -
 0]
7  0 1 1 1 0] -
 0]
8  bytestream length == 4 bytes -
 bytes
9   -
+class="cmtt-8"> 

We read two, two-bit integer fields, resulting in the returned numbers ’b00’ and ’b11’. Two things are worth noting here:

After all codeword lengths have been decoded, the decoder reads the vector lookup table. Vorbis I supports three lookup types: @@ -2593,8 +2489,7 @@ class="enumerate-enumitem">Implicitly populated value mapping (lattice VQ) 3.

Explicitly populated value mapping (tessellated or ’foam’ VQ)

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

-1  bits as an unsigned integer -
+class="cmtt-8"> integer

Codebook decode precedes according to [codebook_lookup_type]:

+ + +

4.2.3. Comment header
+ id="x1-640004.2.3">Comment header

Comment header decode and data specification is covered in Section 5, “comment field and +href="#x1-820005">section 5, “comment field and header specification”.

4.2.4. Setup header
+ id="x1-650004.2.4">Setup header

Vorbis codec setup is configurable to an extreme degree:

@@ -3861,7 +3729,7 @@ src="components.png" alt="PIC" >
Figure 6: decoder pipeline configuration
+class="content">decoder pipeline configuration

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 @@ -3869,11 +3737,8 @@ configurations (placeholders in Vorbis I), floor configurations, residue configu mapping configurations and mode configurations. It finishes with a framing bit of ’1’. Header decode proceeds in the following order:

Codebooks - - -

1.
[vorbis_codebook_count] = read eight bits as unsigned int 2.
Decode [vorbis_codebook_count] codebooks in order as defined in Section 3, +href="#x1-470003">section 3, “Probability Model and Codebooks”. Save each configuration, in order, in an array of codebook configurations [vorbis_codebook_configurations].
+ + +

Time domain transforms These hooks are placeholders in Vorbis I. Nevertheless, the configuration placeholder values must be read to maintain bitstream sync. @@ -3903,7 +3771,7 @@ class="enumerate-enumitem">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.

Floors Vorbis uses two floor types; header decode is handed to the decode abstraction of the appropriate type. @@ -3926,21 +3794,18 @@ class="cmtt-12">[i] = read 16 bits

b)
If the floor type is zero, decode the floor configuration as defined in Section 6, +href="#x1-900006">section 6, “Floor type 0 setup and decode”; save this configuration in slot Floor type 0 setup and decode”; save this configuration in slot [i] of the floor configuration array [vorbis_floor_configurations]. - - -
c)
If the floor type is one, decode the floor configuration as defined in Section 7, +href="#x1-960007">section 7, “Floor type 1 setup and decode”; save this configuration in slot Floor type 1 setup and decode”; save this configuration in slot [i] of the floor configuration array [vorbis_floor_configurations]. @@ -3948,9 +3813,12 @@ class="cmtt-12">[vorbis_floor_configurations]. d)
If the the floor type is greater than one, this stream is undecodable; ERROR CONDITION
+ + +

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

@@ -3972,8 +3840,8 @@ class="cmtt-12">[i] = read 16 b)

If the residue type is zero, one or two, decode the residue configuration as defined in Section 8, “Residue setup and decode”; save this configuration in slot section 8, “Residue setup and decode”; save this configuration in slot [i] of the residue configuration array [vorbis_residue_configurations]. @@ -3983,14 +3851,11 @@ class="enumerate-enumitem">If the the residue type is greater than two, this str CONDITION

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

1.
[vorbis_mapping_count] = read 6 bits as unsigned integer class="enumerate-enumitem">For each [i] of [vorbis_mapping_count] mapping numbers: + + +
a)
read the mapping type: 16 bits as unsigned integer. There’s no reason to save @@ -4042,19 +3910,16 @@ class="cmtt-12">[vorbis_mapping_coupling_steps] steps: class="cmtt-12">[vorbis_mapping_magnitude] element [j]= read ilog(ilog([audio_channels] - 1) bits as unsigned integer
  • vector [vorbis_mapping_angle] element [j]= read ilog(ilog([audio_channels] - 1) bits as unsigned integer
    • - - -
  • 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 @@ -4064,6 +3929,9 @@ class="cmtt-12">[audio_channels]-1, or the angle channel is greater than [audio_channels]-1, the stream is undecodable.
    • + + +
    B.
    read 8 bits as unsigned integer for the residue numbe [vorbis_mapping_submap_residue] element [j] - - -
    E.
    verify the residue number is not greater than the highest number residue @@ -4130,9 +3995,12 @@ class="cmtt-12">[i] of the mapping configuration array [vorbis_mapping_configurations].
    + + +

    Modes

    1.
    [vorbis_mode_configurations].
    3.
    read 1 bit as a framing flag. If unset, a framing error occurred and the stream is not decodable.
    - - -

    After reading mode descriptions, setup header decode is complete.

    4.3. Audio packet decode and synthesis

    + id="x1-720004.3">Audio packet decode and synthesis + + +

    Following the three header packets, all packets in a Vorbis I stream are audio. The first step of audio packet decode is to read and verify the packet type. A non-audio packet when audio is @@ -4193,7 +4061,7 @@ class="cmti-12">expected indicates stream corruption or a non-compliant stream. class="cmti-12">packet and not attempt decoding it to audio.

    4.3.1. packet type, mode and window decode
    + id="x1-730004.3.1">packet type, mode and window decode

    1.
    [packet_type]; check that packet type is 0 (audio)
    2.
    read ilog([vorbis_mode_count]-1) bits ilog([vorbis_mode_count]-1) bits [mode_number]
    3.
    [previous_window_flag] ii.
    read 1 bit for [next_window_flag] - - -
    iii.
    if if [next_window_flag] is not set, the right half of the window will be a hybrid window for lapping with a short block. See paragraph 1.3.2, + + + “Window shape decode (long windows only)” for an illustration of overlapping dissimilar windows. Else, the left right window will have normal @@ -4261,20 +4129,21 @@ class="enumerate-enumitem">if this is a short window, the window is always the s

    Vorbis windows all use the slope function y = sin(π2 ∗ sin * sin 2((x + 0.5)∕n ∗ π)), where * π)), where n is window size and x ranges 0……n− 1, but dissimilar lapping requirements can affect overall shape. Window +class="cmsy-10x-x-120">- 1, but dissimilar lapping requirements can affect overall shape. Window generation proceeds as follows:

    @@ -4315,9 +4184,6 @@ class="cmtt-12">[left_window_start] = 0 class="enumerate-enumitem">[left_window_end] = [window_center] - - -
    c)
    [right_window_end] = [n]*3/4 + [blocksize_0]/4 + + +
    c)
    [left_window_start] ... [left_window_end]-1, window([i]) = sin(π +src= ∗ sin * sin 2( ([i]-[left_window_start]+0.5) / [left_n] ∗π +class=*π 2) )
    6.
    [right_window_start] ... [right_window_end]-1, window([i]) = sin(π -2 ∗ sin * sin 2( ([i]-[right_window_start]+0.5) / [right_n] ∗π -2 + π -2) ) +class="cmsy-10x-x-120">*π2 + π2) )
    8.
    window from range [n]-1 is zero

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

    4.3.2. floor curve decode
    + id="x1-740004.3.2">floor curve decode

    From this point on, we assume out decode context is using mode number [mode_number] from configuration array [vorbis_mode_mapping] (specified by the current mode) tak array [vorbis_mapping_configurations].

    Floor curves are decoded one-by-one in channel order. + + +

    For each floor [i] of [audio_channels] @@ -4453,15 +4319,15 @@ class="cmtt-12">[vorbis_floor_types] element [floor_number]) is zero then decode the floor for channel [i] according to the subsubsection 6.2.2, “packet decode” +href="#x1-940006.2.2">subsubsection 6.2.2, “packet decode”

    4.
    if the type of this floor is one then decode the floor for channel [i] according to the subsubsection 7.2.3, “packet decode” +href="#x1-1010007.2.3">subsubsection 7.2.3, “packet decode”
    5.
    save the needed decoded floor information for channel for later synthesis @@ -4477,13 +4343,10 @@ class="cmtt-12">[i] to false
    output vectors and skipping to the add/overlap output stage.

    4.3.3. nonzero vector propagate
    + id="x1-750004.3.3">nonzero vector propagate

    A possible result of floor decode is that a specific vector is marked ’unused’ which indicates that that final output vector is all-zero values (and the floor is zero). The residue for that vector is not 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]) 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.

    4.3.4. residue decode
    + id="x1-760004.3.4">residue decode

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

    for each submap [ch] is unset ii.

    increment [ch]
    - - -
    3.
    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 [ch]

    4.3.5. inverse coupling
    + id="x1-770004.3.5">inverse coupling

    for each [i] from [vorbis_mapping_coupling_steps]-1 descending to 0 @@ -4622,9 +4488,6 @@ class="cmtt-12">[i]) class="enumerate-enumitem">[angle_vector] = the residue vector for channel (vector [vorbis_mapping_angle] - - - element [i])

    @@ -4639,6 +4502,9 @@ class="cmtt-12">[angle_vector]: a)
    if ([M] is greater than zero) + + +
    i.
    if (set scalar value [M] in vector [magnitude_vector] to [new_M] - - -
    c)
    set scalar value [A] in vector [angle_vector] to [new_A]
    + + +

    4.3.6. dot product
    + id="x1-780004.3.6">dot product

    For each channel, synthesize the floor curve from the decoded floor information, according to packet type. Note that the vector synthesis length for floor computation is [n]/2. @@ -4729,17 +4595,17 @@ residue and direct multiplication of the vectors is sufficient for acceptable sp 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 +class="cmsy-10x-x-120">~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 +class="cmsy-10x-x-120">~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 +class="cmsy-10x-x-120">-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. +class="cmsy-10x-x-120">-140dB to +0dB. Thus, in order to handle full range dynamics, a residue vector may span −140dB to +class="cmsy-10x-x-120">-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 @@ -4747,18 +4613,18 @@ achieved using large (64 bit or larger) integers, or implementing a movable bina representation.

    4.3.7. inverse MDCT
    + id="x1-790004.3.7">inverse MDCT

    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 [1]. The window function used for the MDCT is the function described earlier. + + +

    4.3.8. overlap_add
    + id="x1-800004.3.8">overlap_add

    Windowed MDCT output is overlapped and added with the right hand data of the previous window such that the 3/4 point of the previous window is aligned with the 1/4 point of the current window (as illustrated in

    -

    -1  window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4 -
    +class="cmtt-8"> window_blocksize(previous_window)/4+window_blocksize(current_window)/4

    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 @@ -4787,13 +4651,10 @@ encoder accounts for this priming when calculating PCM offsets; after the first PCM output offset is ’0’ (as no data has been returned yet).

    4.3.9. output channel order
    + id="x1-810004.3.9">output channel order

    Vorbis I specifies only a channel mapping type 0. In mapping type 0, channel mapping is implicitly defined as follows for standard audio applications. As of revision 16781 (20100113), the 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 @@ -4803,6 +4664,9 @@ document channel reordering behavior. one channel

    the stream is monophonic + + +
    two channels
    5. comment field and header specification + id="x1-820005">comment field and header specification

    5.1. Overview

    + id="x1-830005.1">Overview

    The Vorbis text comment header is the second (of three) header packets that begin a Vorbis bitstream. It is meant for short text comments, not arbitrary metadata; arbitrary metadata belongs in a separate logical bitstream (usually an XML stream type) that provides greater @@ -4872,16 +4736,16 @@ class="cmti-12">“I’m Still Around”, opening for Moxy Früvous, 1997.

    5.2. Comment encoding

    + id="x1-840005.2">Comment encoding

    5.2.1. Structure
    + id="x1-850005.2.1">Structure

    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 2- 1 and the length of each vector is limited to 232 − 1 bytes. The vector length is +class="cmsy-10x-x-120">- 1 bytes. The vector length is @@ -4895,9 +4759,8 @@ is octet-aligned, they can simply be read as unaligned 32 bit little endian unsi integers.

    The comment header is decoded as follows:

    -

    -1   unsigned integer of 32 bits -
     bits
    2   as [vendor\_length] octets
    3   unsigned integer of 32 bits -
     bits
    4   [user\_comment\_list\_length] times {
    5   unsigned integer of 32 bits -
     bits
    6   as [length] octets
    7       } -
     }
    8   a single bit as boolean -
     boolean
    9   or end-of-packet ) then ERROR -
     ERROR
    10    9) done. -
    +class="cmtt-8"> done.

    5.2.2. Content vector format
    + id="x1-860005.2.2">Content vector format

    The comment vectors are structured similarly to a UNIX environment variable. That is, comment fields consist of a field name and a corresponding value and look like:

    -

    -1  comment[0]="ARTIST=me"; -
     comment[0]="ARTIST=me";
    2  comment[1]="TITLE=the sound of Vorbis"; -
    +class="cmtt-8"> Vorbis";
    - - -

    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). @@ -5084,8 +4934,11 @@ ASCII 0x61 through 0x7A inclusive (characters a-z). 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. + + +

    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 @@ -5126,9 +4979,6 @@ class="description">The artist(s) who performed the work. In classical music thi class="cmssbx-10x-x-120">COPYRIGHT

    Copyright attribution, e.g., ’2001 Nobody’s Band’ or ’1999 Jack Moffitt’
    - - - LICENSE
    License information, eg, ’All Rights Reserved’, ’Any Use Permitted’, a URL to @@ -5145,6 +4995,9 @@ class="description">Name of the organization producing the track (i.e. the ̵ class="cmssbx-10x-x-120">DESCRIPTION
    A short text description of the contents
    + + + GENRE
    A short text indication of music genre @@ -5169,7 +5022,7 @@ href="http://www.ifpi.org/isrc/" >the ISRC intro page for more information on ISRC numbers.

    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 @@ -5182,9 +5035,6 @@ 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. @@ -5194,30 +5044,29 @@ and encouraged:

    -

    -1  ARTIST=Dizzy Gillespie -
     Gillespie
    2  ARTIST=Sonny Rollins -
     Rollins
    3  ARTIST=Sonny Stitt -
    +class="cmtt-8"> Stitt

    5.2.3. Encoding
    + id="x1-890005.2.3">Encoding

    The comment header comprises the entirety of the second bitstream header packet. Unlike the first bitstream header packet, it is not generally the only packet on the second page and may not be restricted to within the second bitstream page. The length of the comment header packet is @@ -5234,9 +5083,6 @@ class="enumerate-enumitem">Vendor string length (32 bit unsigned quantity specif 2.

    Vendor string ([vendor string length] octets coded from beginning of string to end of string, not null terminated) - - -
    3.
    Number of comment fields (32 bit unsigned quantity specifying number of fields) @@ -5265,11 +5111,14 @@ class="cmtt-12">_vorbis_unpack_comment(). + + +

    6. Floor type 0 setup and decode

    + id="x1-900006">Floor type 0 setup and decode

    6.1. Overview

    + id="x1-910006.1">Overview

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

    6.2. Floor 0 format

    + id="x1-920006.2">Floor 0 format

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

    6.2.1. header decode
    + id="x1-930006.2.1">header decode

    Configuration information for instances of floor zero decodes from the codec setup header (third packet). configuration decode proceeds as follows:

    -

    -1   unsigned integer of 8 bits -
     bits
    2   of 16 bits
    3   unsigned integer of 16 bits -
     bits
    4   of six bits
    5   of eight bits
    6   and add 1
    7   integers of eight bits each; -
    +class="cmtt-8"> each; @@ -5418,16 +5263,15 @@ codebook number for this bitstream is an error condition that also renders the s undecodable.

    6.2.2. packet decode
    + id="x1-940006.2.2">packet decode

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

    -1   unsigned integer of [floor0_amplitude_bits] bits -
     bits
    2   ) {
    3   an empty, zero length vector -
     vector
    4   unsigned integer of ilog( [floor0_number_of_books] ) bits
    5   ) then packet is undecodable -
     undecodable
    6   [last] = zero;
    7   in VQ context.
    8   each scalar in vector [temp_vector] -
     [temp_vector]
    9   in vector [temp_vector]
    10   the [coefficients] vector
    11   [floor0_order], continue at step 6 -
     6
    12   -
     
    13      } -
    }
    14   -
     
    15   12) done. -
     done.
    16   -
    +class="cmtt-8"> 

    Take note of the following properties of decode:

    • An [amplitude] value of zero must result in a return code th class="cmtt-12">[amplitude] value had read zero at the beginning of decode.
    • The book number used for decode can, in fact, be stored in the bitstream in ilog( - - - +href="#x1-1180009.2.1">ilog( [floor0_number_of_books] - 1 ) bits. Nevertheless, the above specification is correct and values greater than the maximum possible book value are reserved. @@ -5728,6 +5559,9 @@ class="cmtt-12">[floor0_order], the number actually required for cu [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 @@ -5735,7 +5569,7 @@ class="cmtt-12">[coefficients] is to to read a total of twelve scalars may be ignored or discarded.

    6.2.3. curve computation
    + id="x1-950006.2.3">curve computation

    Given an [amplitude] integer and [coefficients] vector from packet decode as well as @@ -5751,20 +5585,17 @@ synthesized:

    { - min (floor0_bark_map_size − 1,foobar ) for i ∈ [0,n − 1 ] -mapi = − 1 for i = n +map = min (floor0_bark_map_size - 1,f oobar) for i ∈ [0, n - 1] + i - 1 for i = n

    where

    ⌊ ⌋ - (floor0_rate ⋅ i) floor0_bark_map_size -foobar = bark -------2n------- ⋅-bark(.5 ⋅ floor0_rate-) +src=
    - - -

    and

    @@ -5787,9 +5618,9 @@ class="cmtt-12">[i] = 0 2.
    [ωω] = π * map element π * map element [i] / [floor0_bark_map_size]
    @@ -5803,35 +5634,36 @@ class="cmtt-12">[p] and [q] according to:
    floor0_order−3 - 2 ∏2 2 -p = (1 − cos ω) 4(cos([coefficients ]2j+1) − cosω ) - floor0_order−1 j=0 - 1 ----∏2---- -q = -- 4(cos([coefficients ]2j) − cosω )2 - 4 j=0 - - - +src=

    else [floor0_order] is even + + +

    - b)
    calculate [p] and [q] according to:
    floor0_order−2 - (1-−-cosω-) ∏2 2 -p = 2 4(cos([coefficients ]2j+1) − cosω) - j=0 - floor0_∏o2rder−-2 -q = (1-+-cosω-) 4(cos([coefficients ]2j) − cos ω)2 +src=
    @@ -5842,8 +5674,8 @@ class="cmtt-12">[linear_floor_value] according to:
    ( ( )) -exp .11512925 amplitude---⋅ floor0_amplitute_√offset---− floor0_amplitude_offset - (2floor0_amplitude_bits − 1) p + q + amplitude---⋅ floor0_amplitute_offset--- +exp .11512925 (2floor0_amplitude_bits - 1)√p--+-q - floor0_amplitude_offset

    @@ -5851,9 +5683,6 @@ exp .11512925 amplitude---⋅ floor0_amplitute_√offset---− f class="enumerate-enumitem">[iteration_condition] = map element [i] - - -
    6.
    [i] class="enumerate-enumitem">if ( map element [i] is equal to [iteration_condition] ) continue at step + + + 5
    9.
    done

    7. Floor type 1 setup and decode

    + id="x1-960007">Floor type 1 setup and decode

    7.1. Overview

    + id="x1-970007.1">Overview

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

    7.2. Floor 1 format

    + id="x1-980007.2">Floor 1 format

    7.2.1. model
    + id="x1-990007.2.1">model

    Floor type one represents a spectral curve as a series of line segments. Synthesis constructs a floor curve using iterative prediction in a process roughly equivalent to the following simplified description: @@ -5939,7 +5771,7 @@ src="floor1-1.png" alt="PIC" >

    Figure 7: graph of example floor
    +class="content">graph of example floor

    We now draw new logical lines to reflect the correction to new˙Y, and iterate for X positions 32 and 96: @@ -5952,7 +5784,7 @@ src="floor1-2.png" alt="PIC" >

    Figure 8: graph of example floor
    +class="content">graph of example floor

    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 @@ -5969,7 +5801,7 @@ src="floor1-3.png" alt="PIC" >

    Figure 9: graph of example floor
    +class="content">graph of example floor
    @@ -5980,7 +5812,7 @@ src="floor1-4.png" alt="PIC" >
    Figure 10: graph of example floor
    +class="content">graph of example floor

    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 @@ -5988,7 +5820,7 @@ into two steps with modifications to the above algorithm to eliminate noise accu through integer roundoff/truncation.

    7.2.2. header decode
    + id="x1-1000007.2.2">header decode

    A list of floor X values is stored in the packet header in interleaved format (used in list order during packet decode and synthesis). This list is split into partitions, and each partition is assigned to a partition class. X positions 0 and [n] are implicit and do not belong to an explicit @@ -6004,14 +5836,12 @@ context.

    -

    -1   -
     
    2   5 bits as unsigned integer -
     integer
    3    2) [maximum_class] = -1 -
     -1
    4   [floor1_partitions]-1 {
    5   -
     
    6   4 bits as unsigned integer -
     integer
    7   -
     
    8      } -
    }
    9  
    10   scalar value in vector [floor1_partition_class_list] -
     [floor1_partition_class_list]
    11   [maximum_class] {
    12   -
     
    13   and add 1
    14   8) as unsigned integer
    15   is nonzero ) { -
    {
    16  
    17   8 bits as unsigned integer -
     integer
    18   -
     
    19      } -
    }
    20  
    21   [i]) - 1 { -
    {
    22  
    23   array [floor1_subclass_books] element [i],[j] = -
     =
    24   unsigned integer and subtract one -
     one
    25    }
    26      } -
    }
    27   -
     
    28   unsigned integer and add one -
     one
    29   as unsigned integer
    30   [floor1_X_list] element [0] = 0 -
     0
    31   2 exponent [rangebits];
    32   17) [floor1_values] = 2 -
     2
    33   [floor1_partitions]-1 {
    34   -
     
    35   [floor1_partition_class_list] element [i]
    36   [current_class_number])-1 {
    37   vector [floor1_X_list] element ([floor1_values]) = -
     =
    38   as unsigned integer
    39   22) increment [floor1_values] by one -
     one
    40      } -
    }
    41      } -
    }
    42   -
     
    43   23) done -
    +class="cmtt-8"> done

    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 @@ -6640,18 +6443,14 @@ configured in this stream is an error condition that renders the stream undecoda total elements (including elements 0 and 1 set prior to the read loop) 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. - - -

    7.2.3. packet decode
    + id="x1-1010007.2.3">packet decode

    Packet decode begins by checking the [nonzero] flag:

    -

    -1   read 1 bit as boolean -
    +class="cmtt-8"> boolean

    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 @@ -6674,9 +6472,8 @@ points set to minimum representation amplitude, which happens to be approximatel

    Assuming [nonzero] is set, decode proceeds as follows:

    -

    -1   } element ([floor1_multiplier]-1) + + +
    2   [0] = read ilog([range]-1) bits as unsigned integer
    3   [1] = read ilog([range]-1) bits as unsigned integer
    4    4) [offset] = 2; -
     2;
    5   0 ... [floor1_partitions]-1 { -
    {
    6  
    7   vector [floor1_partition_class]  element [i] -
     [i]
    8   [floor1_class_dimensions] element [class]
    9   = vector [floor1_class_subclasses] element [class] -
     [class]
    10    = (2 exponent [cbits])-1 -
     [cbits])-1
    11    = 0
    12   than zero ) { -
    {
    13   -
     
    14   using codebook number
    15   in scalar context
    16      } -
    }
    17   -
     
    18   0 ... [cdim]-1 { -
    {
    19  
    20   bitwise AND [csub])
    21   [cval] right shifted [cbits] bits -
     bits
    22    than zero ) { -
    {
    23  
    24    read from packet using codebook -
     codebook
    25   in scalar context
    26   -
     
    27   less than zero { -
    {
    28   -
     
    29    ([j]+[offset]) = 0
    30   -
     
    31      } -
    }
    32      } -
    }
    33   -
     
    34   [offset] = [offset] + [cdim] - - - -
     [cdim]
    35   -
     
    36      } -
    }
    37   -
     
    38   20) done -
    +class="cmtt-8"> done

    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. class="cmtt-12">[floor1_Y] contains the values from packet decode needed for floor 1 synthesis.

    7.2.4. curve computation
    + id="x1-1020007.2.4">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 @@ -7315,14 +7087,13 @@ setups cannot produce out of range values. class="cmssbx-10x-x-120">step 1: amplitude value synthesis

    Unwrap the always-positive-or-zero values read from the packet into +/- difference - values, then apply to line prediction. -

    -

    -

    +

    1   64 } element ([floor1_multiplier]-1) -
     ([floor1_multiplier]-1)
    2   element [0] = set -
    3   [floor1_step2_flag] element [1] = set -
     set
    4   vector [floor1_Y] element [0] -
    5   = vector [floor1_Y] element [1] -
     [1]
    6   2 ... [floor1_values]-1 { -
    {
    7   -
    8   7) [low_neighbor_offset] = low_neighbor([floor1_X_list],[i]) -
    ([floor1_X_list],[i])
    9   8) [high_neighbor_offset] = high_neighbor([floor1_X_list],[i]) -
    10   -
     
    11   9) [predicted] = render_point( vector [floor1_X_list] element [low_neighbor_offset], -
    12    vector [floor1_final_Y] element [low_neighbor_offset], -
    13   vector [floor1_X_list] element [high_neighbor_offset], -
    14    vector [floor1_final_Y] element [high_neighbor_offset], -
    15   vector [floor1_X_list] element [i] ) -
     )
    16   -
     
    17   vector [floor1_Y] element [i] -
    18   [highroom] = [range] - [predicted] -
     [predicted]
    19   [lowroom]  = [predicted] -
    20   than [lowroom] ) { -
    {
    21   -
     
    22   [room] = [highroom] * 2 -
     2
    23   -
    24   less than [lowroom] { -
    {
    25   -
     
    26   [room] = [lowroom] * 2 -
     2
    27   -
     
    28      } -
    }
    29   -
    30   is nonzero ) { -
    {
    31   -
     
    32   element [low_neighbor_offset] = set -
    33   element [high_neighbor_offset] = set -
    34   [floor1_step2_flag] element [i] = set -
     set
    35   [room] ) { -
    36   -
     
    37   than [lowroom] ) { -
    {
    38   -
    39   - [lowroom] + [predicted] -
    40   -
     
    41    greater than [lowroom] { -
    {
    42   -
    43   + [highroom] - 1 -
    44   -
     
    45      } -
    }
    46   -
     
    47   less than [room] { -
    {
    48   -
    49   ([val] is odd) { -
    {
    50   -
     
    51   [floor1_final_Y] element [i] = -
    52    2 using integer division) -
     division)
    53   -
    54   [val] is even { -
    {
    55   -
     
    56   [floor1_final_Y] element [i] = -
    57   / 2 using integer division) -
     division)
    58   -
     
    59      } -
    }
    60   -
    61      } -
    }
    62   -
     
    63   [val] is zero { -
    {
    64   -
     
    65   element [i] = unset - - - -
    66   [floor1_final_Y] element [i] = [predicted] -
     [predicted]
    67   -
     
    68      } -
    }
    69   -
     
    70      } -
    }
    71   -
     
    72   29) done -
     done
    73   -
    +class="cmtt-8"> 
    step 2: curve synthesis
    [floor1_X_list] and then apply the same still match.

    Then compute the final curve in one pass:

    -

    -1    1) [hx] = 0 -
     0
    2    2) [lx] = 0 -
     0
    3   element [0] * [floor1_multiplier] -
    4   1 ... [floor1_values]-1 { -
    {
    5   -
     
    6   is set ) { -
    {
    7   -
    8   [floor1_final_Y]’ element [i] * [floor1_multiplier] -
     [floor1_multiplier]
    9   = [floor1_X_list]’ element [i] -
    10     8) render_line( [lx], [ly], [hx], [hy], [floor] ) -
     )
    11    9) [lx] = [hx] -
     [hx]
    12    10) [ly] = [hy] -
    13      } -
    }
    14      } -
    }
    15   -
     
    16   than [n] ) { -
    {
    17   -
     
    18     12) render_line( [hx], [n], [hy], [floor] ) -
    19   -
     
    20      } -
    }
    21   -
     
    22   than [n] ) { -
    {
    23   -
     
    24   [floor] to [n] elements -
    25   -
     
    26      } -
    }
    27   - - - -
     
    28   a lookup substitution using -
    29   into the vector [floor1_inverse_dB_static_table] -
    [floor1_inverse_dB_static_table]
    30   -
     
    31   16) done -
     done
    32   -
    +class="cmtt-8"> 

    8. Residue setup and decode

    + id="x1-1030008">Residue setup and decode

    8.1. Overview

    + id="x1-1040008.1">Overview

    A residue vector represents the fine detail of the audio spectrum of one channel in an audio frame after the encoder subtracts the floor curve and performs any channel coupling. A residue vector may represent spectral lines, spectral magnitude, spectral phase or hybrids as mixed by channel @@ -9027,7 +8721,7 @@ different encoding variants (numbered 0, 1 and 2) of the same basic vector encod abstraction.

    8.2. Residue format

    + id="x1-1050008.2">Residue format

    Residue format partitions each vector in the vector bundle into chunks, classifies each chunk, encodes the chunk classifications and finally encodes the chunks themselves using the the specific VQ arrangement defined for each selected classification. The @@ -9085,11 +8779,11 @@ src="residue-pack.png" alt="PIC" >

    Figure 11: illustration of residue vector format
    +class="content">illustration of residue vector format

    8.3. residue 0

    + id="x1-1060008.3">residue 0

    Residue 0 and 1 differ only in the way the values within a residue partition are interleaved during partition encoding (visually treated as a black box–or cyan box or brown box–in the above figure). @@ -9103,14 +8797,12 @@ 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:

    -

    -1   -
     
    2   4 5 6 7 ] -
     ]
    3   -
     
    4  codebook 4 5 6 7 ] -
     ]
    5  
    6  codebook 1 3 5 7 ] -
     ]
    7   -
     
    8  codebook 3 7 ]
    9   -
     
    10  codebook 6 ], [ 7 ] -
     ]
    11   -
    +class="cmtt-8"> 

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

    8.4. residue 1

    + id="x1-1070008.4">residue 1

    Residue 1 does not interleave VQ encoding. It represents partition vector scalars in order. As with residue 0, however, partition length must be an integer multiple of the codebook dimension, 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:

    -

    -1   -
     
    2   4 5 6 7 ] -
     ]
    3   -
     
    4  codebook 4 5 6 7 ] -
     ]
    5  
    6  codebook 4 5 6 7 ] -
     ]
    7   -
     
    8  codebook 6 7 ]
    9   -
     
    10  codebook 6 ], [ 7 ] -
     ]
    11   - - - -
    +class="cmtt-8"> 

    8.5. residue 2

    + id="x1-1080008.5">residue 2

    Residue type two can be thought of as a variant of residue type 1. Rather than encoding multiple passed-in vectors as in residue type 1, the ch passed in vectors 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. + + +

    @@ -9472,18 +9146,17 @@ src="residue2.png" alt="PIC" >

    Figure 12: illustration of residue type 2
    +class="content">illustration of residue type 2

    8.6. Residue decode

    + id="x1-1090008.6">Residue decode

    8.6.1. header decode
    + id="x1-1100008.6.1">header decode

    Header decode for all three residue types is identical. -

    -1   24 bits as unsigned integer -
     integer
    2   as unsigned integer
    3   and add one
    4   unsigned integer and add one - - - -
     one
    5   8 bits as unsigned integer -
    +class="cmtt-8"> integer

    [residue_begin] and [residue_end] select the specific sub-portion of each vector that is @@ -9595,12 +9262,14 @@ class="cmtt-12">[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.

    -

    -1   range 0 ... [residue\_classifications]-1 { -
     {
    2   -
     
    3   [high\_bits] = 0
    4   3 bits as unsigned integer -
     integer
    5   bit as boolean
    6   as unsigned integer
    7   [high\_bits] * 8 + [low\_bits] -
     [low\_bits]
    8       } -
     }
    9    7) done -
    +class="cmtt-8"> done

    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):

    -

    -1   range 0 ... [residue\_classifications]-1 { -
     {
    2   -
     
    3   ... 7 {
    4   -
     
    5   [j] is set ) { -
     {
    6  
    7   8 bits as unsigned integer -
     integer
    8   -
     
    9     } else { - - - -
     {
    10  
    11   [residue\_books] element [i][j] = unused -
     unused
    12   -
     
    13       } -
     }
    14       } -
     }
    15       } -
     }
    16   -
     
    17    6) done -
    +class="cmtt-8"> done

    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 @@ -9998,7 +9643,7 @@ set up in this stream also renders the stream undecodable. All codebooks in arra undecodable.

    8.6.2. packet decode
    + id="x1-1110008.6.2">packet decode

    Format 0 and 1 packet decode is identical except for specific partition interleave. Format 2 packet decode can be built out of the format 1 decode process. Thus we describe first the decode infrastructure identical to all three formats. @@ -10012,6 +9657,9 @@ class="cmtt-12">[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 @@ -10023,9 +9671,8 @@ the number of vectors being encoded, [ch] is provided by the higher level decoding process.

    -

    -1   1) [actual\_size] = current blocksize/2; -
     blocksize/2;
    2   is format 2
    3   [actual\_size] = [actual\_size] * [ch]; - - - -
     [ch];
    4   maximum of ([residue\_begin],[actual\_size]);
    5   [limit\_residue\_end] = maximum of ([residue\_end],[actual\_size]); -
    +class="cmtt-8"> ([residue\_end],[actual\_size]);

    The following convenience values are conceptually useful to clarifying the decode process:

    -

    -1   of codebook [residue\_classbook]
    2   [n\_to\_read] = [limit\_residue\_end] - [limit\_residue\_begin] -
     [limit\_residue\_begin]
    3   [partitions\_to\_read] = [n\_to\_read] / [residue\_partition\_size] -
    +class="cmtt-8"> [residue\_partition\_size]

    Packet decode proceeds as follows, matching the description offered earlier in the document. -

    -1   vectors that will be returned. -
     returned.
    2   residue to decode.
    3   range 0 ... 7 { -
     {
    4   -
     
    5    4) [partition\_count] = 0 -
     0
    6  
    7   [partition\_count] is less than [partitions\_to\_read] -
     [partitions\_to\_read]
    8   -
     
    9   if ([pass] is zero) { -
     {
    10  
    11   range 0 .. [ch]-1 { -
     {
    12   -
     
    13   not decode’ {
    14   -
     
    15   in scalar context
    16   ... 0 {
    17   -
     
    18   element [j],([i]+[partition\_count]) =
    19   integer modulo [residue\_classifications]
    20   / [residue\_classifications] using integer division -
     division
    21  
    22       } -
     }
    23   -
     
    24       } -
     }
    25   -
     
    26       } -
     }
    27   -
     
    28       } -
     }
    29  
    30   1) while [partition\_count]
    31   also less than [partitions\_to\_read] { -
     {
    32   -
     
    33   .. [ch]-1 {
    34   -
     
    35   marked ’do not decode’ { -
     {
    36  
    37   [classifications] element [j],[partition\_count]
    38   = array [residue\_books] element [vqclass],[pass] -
     [vqclass],[pass]
    39   not ’unused’) {
    40   -
     
    41   starting at scalar
    42   offset [limit\_residue\_begin]+[partition\_count]*[residue\_partition\_size] using
    43   number [vqbook] in VQ context -
     context
    44       } - - - -
     }
    45     }
    46   -
     
    47   20) increment [partition\_count] by one -
     one
    48   -
     
    49       } -
     }
    50       } -
     }
    51       } -
     }
    52   -
     
    53   21) done -
     done
    54   -
    +class="cmtt-8"> 

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

    8.6.3. format 0 specifics
    + id="x1-1120008.6.3">format 0 specifics

    Format zero decodes partitions exactly as described earlier in the ’Residue Format: residue 0’ section. The following pseudocode presents the same algorithm. Assume: + + +

    -

    -1   [step] = [n] / [codebook\_dimensions] -
     [codebook\_dimensions]
    2   range 0 ... [step]-1 { -
     {
    3  
    4   in VQ context
    5   range 0 ... [codebook\_dimensions]-1 { -
     {
    6   -
     
    7   element ([offset]+[i]+[j]*[step]) =
    8    vector [v] element ([offset]+[i]+[j]*[step]) + -
     +
    9    vector [entry\_temp] element [j] -
     [j]
    10   -
     
    11       } -
     }
    12   -
     
    13      } -
     }
    14   -
     
    15    6) done -
     done
    16   - - - -
    +class="cmtt-8"> 

    8.6.4. format 1 specifics
    + id="x1-1130008.6.4">format 1 specifics

    Format 1 decodes partitions exactly as described earlier in the ’Residue Format: residue 1’ section. The following pseudocode presents the same algorithm. Assume:

    -

    -1   1) [i] = 0 -
     [i] = 0
    2   in VQ context
    3   range 0 ... [codebook\_dimensions]-1 { -
     {
    4   -
     
    5   element ([offset]+[i]) =
    6    vector [v] element ([offset]+[i]) + -
     +
    7    vector [entry\_temp] element [j] -
     [j]
    8     5) increment [i] -
     [i]
    9  
    10      } -
     }
    11   -
     
    12   ) continue at step 2 -
     2
    13    7) done -
    +class="cmtt-8"> done

    8.6.5. format 2 specifics
    -

    Format 2 is reducible to format 1. It may be implemented as an additional step prior to and an -additional post-decode step after a normal format 1 decode. + id="x1-1140008.6.5">format 2 specifics +

    Format 2 is reducible to format 1. It may be implemented as an additional step prior to and an +additional post-decode step after a normal format 1 decode.

    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 @@ -11666,9 +11239,8 @@ class="cmtt-12">[v] returned by format 1 decode as described above into ch independent vectors, one for each outputchannel, according to: -

    -1   range 0 ... [n]-1 { -
     {
    2   -
     
    3   range 0 ... [ch]-1 { -
     {
    4   -
    5   ([i] * [ch] + [j]) -
     [j])
    6   -
     
    7       } -
     }
    8       } -
     }
    9   -
     
    10    4) done -
    +class="cmtt-8"> done @@ -11798,28 +11361,27 @@ class="cmtt-8"> done

    9. Helper equations

    + id="x1-1150009">Helper equations

    9.1. Overview

    + id="x1-1160009.1">Overview

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

    9.2. Functions

    + id="x1-1170009.2">Functions

    9.2.1. ilog
    + id="x1-1180009.2.1">ilog

    The ”ilog(x)” function returns the position number (1 through n) of the highest set bit in the two’s complement integer value [x]. Values of [x] less than zero are defined to return zero.

    -

    -1    1) [return\_value] = 0; -
     0;
    2   greater than zero ) { -
     {
    3   -
     
    4   3) increment [return\_value];
    5   padding the MSb with zero -
     zero
    6   5) repeat at step 2) -
     2)
    7   -
     
    8       } -
     }
    9   -
     
    10     6) done -
    - - - +class="cmtt-8"> done

    Examples:

    9.2.2. float32_unpack
    + id="x1-1190009.2.2">float32_unpack

    ”float32_unpack(x)” is intended to translate the packed binary representation of a Vorbis codebook float value into the representation used by the decoder for floating point numbers. For purposes of this example, we will unpack a Vorbis float32 into a host-native floating point number.

    -

    -1   bitwise AND 0x1fffff (unsigned result) -
     result)
    2   0x80000000 (unsigned result)
    3   bits (unsigned result)
    4   nonzero ) then negate [mantissa] -
     [mantissa]
    5   [exponent] - 788 ) ) -
    - - - +class="cmtt-8"> )

    9.2.3. lookup1_values
    + id="x1-1200009.2.3">lookup1_values

    ”lookup1_values(codebook_entries,codebook_dimensions)” is used to compute the correct length of the value index for a codebook VQ lookup table of lookup type 1. The values on this list are permuted to construct the VQ vector lookup table of size @@ -12064,9 +11610,12 @@ class="cmtt-12">[return_value] to the power of [codebook_dimensions] is less than or equal to [codebook_entries]’. + + +

    9.2.4. low_neighbor
    + id="x1-1210009.2.4">low_neighbor

    ”low_neighbor(v,x)” finds the position n in vector [v] of the greatest value scalar element for @@ -12080,7 +11629,7 @@ class="cmtt-12">[v] element class="cmtt-12">[x].

    9.2.5. high_neighbor
    + id="x1-1220009.2.5">high_neighbor

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

    9.2.6. render_point
    + id="x1-1230009.2.6">render_point

    ”render_point(x0,y0,x1,y1,X)” is used to find the Y value at point X along the line specified by x0, x1, y0 and y1. This function uses an integer algorithm to solve for the point directly without calculating intervening values along the line. - - -

    -

    -1   [dy] = [y1] - [y0] -
     [y0]
    2   [adx] = [x1] - [x0] -
     [x0]
    3   = absolute value of [dy] -
     [dy]
    4   ([X] - [x0])
    5   / [adx] using integer division -
     division
    6   less than zero ) { -
     {
    7   -
     
    8   [y0] - [off]
    9   -
     
    10     } else { -
     {
    11   -
     
    12   [Y] = [y0] + [off] -
     [off]
    13   -
     
    14       } -
     }
    15   -
     
    16    9) done -
    +class="cmtt-8"> done

    9.2.7. render_line
    + id="x1-1240009.2.7">render_line + + +

    Floor decode type one uses the integer line drawing algorithm of ”render_line(x0, y0, x1, y1, v)” to construct an integer floor curve for contiguous piecewise line segments. Note that it has not been relevant elsewhere, but here we must define integer division as rounding division of both positive and negative numbers toward zero.

    -

    -1   [dy] = [y1] - [y0] -
     [y0]
    2   [adx] = [x1] - [x0] -
     [x0]
    3   = absolute value of [dy] -
     [dy]
    4   using integer division
    5     [x] = [x0] -
     [x0]
    6     [y] = [y0] -
     [y0]
    7   7)  [err] = 0 -
     0
    8   -
     
    9   less than 0 ) { -
     {
    10   -
     
    11   [base] - 1
    12   -
     
    13     } else { -
     {
    14   -
     
    15   [sy] = [base] + 1 -
     1
    16   -
     
    17       } -
     }
    18   -
     
    19   [base]) * [adx]
    20   [v] element [x] = [y] -
     [y]
    21   -
     
    22   range [x0]+1 ... [x1]-1 { - - - -
     {
    23   -
     
    24   [err] + [ady];
    25   [err] >= [adx] ) { -
     {
    26   -
     
    27   [err] = [err] - [adx] -
     [adx]
    28   [y] = [y] + [sy] -
     [sy]
    29  
    30     } else { -
     {
    31   -
     
    32   [y] = [y] + [base] -
     [base]
    33   -
     
    34       } -
     }
    35   -
     
    36   [v] element [x] = [y] -
     [y]
    37   -
     
    38       } -
    +class="cmtt-8"> } @@ -12743,17 +12240,16 @@ class="cmtt-8"> }

    10. Tables

    + id="x1-12500010">Tables

    10.1. floor1_inverse_dB_table

    + id="x1-12600010.1">floor1_inverse_dB_table

    The vector [floor1_inverse_dB_table] is a 256 element static lookup table consiting of the +class="cmtt-12">[floor1_inverse_dB_table] is a 256 element static lookup table consisting of the following values (read left to right then top to bottom):

    -

    -1    1.0649863e-07, 1.1341951e-07, 1.2079015e-07, 1.2863978e-07, -
     1.2863978e-07,
    2   1.4590251e-07, 1.5538408e-07, 1.6548181e-07,
    3    1.7623575e-07, 1.8768855e-07, 1.9988561e-07, 2.1287530e-07, -
     2.1287530e-07,
    4   2.4144197e-07, 2.5713223e-07, 2.7384213e-07,
    5    2.9163793e-07, 3.1059021e-07, 3.3077411e-07, 3.5226968e-07, -
     3.5226968e-07,
    6   3.9954229e-07, 4.2550680e-07, 4.5315863e-07,
    7    4.8260743e-07, 5.1396998e-07, 5.4737065e-07, 5.8294187e-07, -
     5.8294187e-07,
    8   6.6116941e-07, 7.0413592e-07, 7.4989464e-07,
    9    7.9862701e-07, 8.5052630e-07, 9.0579828e-07, 9.6466216e-07, -
     9.6466216e-07,
    10   1.0941144e-06, 1.1652161e-06, 1.2409384e-06,
    11    1.3215816e-06, 1.4074654e-06, 1.4989305e-06, 1.5963394e-06, -
     1.5963394e-06,
    12   1.8105592e-06, 1.9282195e-06, 2.0535261e-06,
    13    2.1869758e-06, 2.3290978e-06, 2.4804557e-06, 2.6416497e-06, -
     2.6416497e-06,
    14   2.9961443e-06, 3.1908506e-06, 3.3982101e-06,
    15    3.6190449e-06, 3.8542308e-06, 4.1047004e-06, 4.3714470e-06, -
     4.3714470e-06,
    16   4.9580707e-06, 5.2802740e-06, 5.6234160e-06,
    17    5.9888572e-06, 6.3780469e-06, 6.7925283e-06, 7.2339451e-06, -
     7.2339451e-06,
    18   8.2047000e-06, 8.7378876e-06, 9.3057248e-06,
    19    9.9104632e-06, 1.0554501e-05, 1.1240392e-05, 1.1970856e-05, -
     1.1970856e-05,
    20   1.3577278e-05, 1.4459606e-05, 1.5399272e-05,
    21    1.6400004e-05, 1.7465768e-05, 1.8600792e-05, 1.9809576e-05, -
     1.9809576e-05,
    22   2.2467911e-05, 2.3928002e-05, 2.5482978e-05,
    23    2.7139006e-05, 2.8902651e-05, 3.0780908e-05, 3.2781225e-05, -
     3.2781225e-05,
    24   3.7180282e-05, 3.9596466e-05, 4.2169667e-05,
    25    4.4910090e-05, 4.7828601e-05, 5.0936773e-05, 5.4246931e-05, -
     5.4246931e-05,
    26   6.1526565e-05, 6.5524908e-05, 6.9783085e-05,
    27    7.4317983e-05, 7.9147585e-05, 8.4291040e-05, 8.9768747e-05, -
     8.9768747e-05,
    28   0.00010181521, 0.00010843174, 0.00011547824,
    29    0.00012298267, 0.00013097477, 0.00013948625, 0.00014855085, -
     0.00014855085,
    30   0.00016848555, 0.00017943469, 0.00019109536,
    31    0.00020351382, 0.00021673929, 0.00023082423, 0.00024582449, -
     0.00024582449,
    32   0.00027881276, 0.00029693158, 0.00031622787,
    33    0.00033677814, 0.00035866388, 0.00038197188, 0.00040679456, -
     0.00040679456,
    34   0.00046138411, 0.00049136745, 0.00052329927,
    35    0.00055730621, 0.00059352311, 0.00063209358, 0.00067317058, -
     0.00067317058,
    36   0.00076350630, 0.00081312324, 0.00086596457,
    37   0.00092223983, 0.00098217216, 0.0010459992,  0.0011139742, -
     0.0011139742,
    38   0.0013455702,  0.0014330129,
    39   0.0016253153,  0.0017309374,  0.0018434235, -
     0.0018434235,
    40   0.0022266726,  0.0023713743,
    41   0.0026895994,  0.0028643847,  0.0030505286, -
     0.0030505286,
    42    0.0036847358,  0.0039241906, - - -
    43   0.0044507950,  0.0047400328,  0.0050480668, -
     0.0050480668,
    44   0.0060975636,  0.0064938176,
    45   0.0073652516,  0.0078438871,  0.0083536271, -
     0.0083536271,
    46     0.010746080,
    47    0.012980198,   0.013823725, -
     0.013823725,
    48     0.017782797,
    49    0.021479854,   0.022875735, -
     0.022875735,
    50     0.029427276,
    51    0.035545228,   0.037855157, -
     0.037855157,
    52     0.048696758,
    53    0.058820850,   0.062643361, -
     0.062643361,
    54     0.080584227,
    55    0.097337747,   0.10366330, -
     0.10366330,
    56     0.13335215,
    57   0.16107617,    0.17154380, -
     0.17154380,
    58     0.22067342,
    59   0.26655159,    0.28387361, -
     0.28387361,
    60     0.36517414,
    61   0.44109412,    0.46975890, -
     0.46975890,
    62     0.60429640,
    63   0.72993007,    0.77736504, -
     0.77736504,
    64       1. -
    +class="cmtt-8"> 1. @@ -13569,16 +13029,16 @@ class="cmtt-8"> 1.

    A. Embedding Vorbis into an Ogg stream

    + id="x1-127000A">Embedding Vorbis into an Ogg stream

    A.1. Overview

    + id="x1-128000A.1">Overview

    This document describes using Ogg logical and physical transport streams to encapsulate Vorbis compressed audio packet data into file form.

    The Section 1, “Introduction and Description” provides an overview of the construction of -Vorbis audio packets. +href="#x1-20001">section 1, “Introduction and Description” provides an overview of the construction of Vorbis +audio packets.

    The Ogg bitstream overview and Ogg logical bitstream and framing spec provide detailed @@ -13587,7 +13047,7 @@ knowledge of the concepts covered in these named backround documents. Please rea first.

    A.1.1. Restrictions
    + id="x1-129000A.1.1">Restrictions

    The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis streams use Ogg transport streams in degenerate, unmultiplexed form only. That is: