Typo and grammar corrections found in proofing.
authorRalph Giles <giles@xiph.org>
Mon, 21 Oct 2002 23:37:00 +0000 (23:37 +0000)
committerRalph Giles <giles@xiph.org>
Mon, 21 Oct 2002 23:37:00 +0000 (23:37 +0000)
svn path=/trunk/vorbis/; revision=4030

doc/xml/01-introduction.xml
doc/xml/02-bitpacking.xml
doc/xml/03-codebook.xml
doc/xml/04-codec.xml
doc/xml/Vorbis_I_spec.xml

index fd13c512f22079b7c46d04707b84d05c042025b0..c5f94b9d4b4cc62a3359a40bde5b6661213d12e4 100644 (file)
@@ -1,7 +1,7 @@
 <section id="vorbis-spec-intro">
 <sectioninfo>
 <releaseinfo>
- $Id: 01-introduction.xml,v 1.3 2002/10/14 23:47:54 giles Exp $
+ $Id: 01-introduction.xml,v 1.4 2002/10/21 23:36:59 giles Exp $
 <emphasis>Last update to this document: July 18, 2002</emphasis>
 </releaseinfo>
 </sectioninfo>
@@ -13,9 +13,9 @@
 <para>
 This document provides a high level description of the Vorbis codec's
 construction.  A bit-by-bit specification appears beginning in <xref
-linkend="vorbis-spec-codec"/>. The other reference documents assumes
-a high-level understanding of the Vorbis decode process, which is 
-provided in this document.</para>
+linkend="vorbis-spec-codec"/>. The later sections assume a high-level
+understanding of the Vorbis decode process, which is 
+provided here.</para>
 
 <section>
 <title>Application</title>
@@ -23,9 +23,9 @@ provided in this document.</para>
 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),
+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 48kpbs
+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,
@@ -54,7 +54,7 @@ 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 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.
@@ -64,10 +64,10 @@ 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
+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 VBR codec and packets have no
+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
@@ -85,18 +85,20 @@ embedded in an Ogg stream specifically, although this is by no means a
 requirement or fundamental assumption in the Vorbis design.</para>
 
 <para>
-<ulink url="vorbis-ogg.html">The specifications for embedding Vorbis into
-an Ogg transport stream is in a separate document.</ulink></para>
+The specification for embedding Vorbis into
+an Ogg transport stream is in a <xref linkend="vorbis-over-ogg"/>.
+</para>
+
 </section>
 
 <section>
 <title>Codec Setup and Probability Model</title>
 
 <para>
-Vorbis's heritage is as a research CODEC and its current design
+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 codec setup intentionally
+For these reasons, configurable aspects of codec setup intentionally
 lean toward the extreme of forward adaptive.</para>
 
 <para>
@@ -107,10 +109,13 @@ 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. [Note:
-Vorbis *can* initiate decode at any arbitrary packet within a
+without having previously fetched the codec setup header.
+</para>
+
+<note><para>
+Vorbis <emphasis>can</emphasis> initiate decode at any arbitrary packet within a
 bitstream so long as the codec has been initialized/setup with the
-setup headers].</para>
+setup headers.</para></note>
 
 <para>
 Thus, Vorbis headers are both required for decode to begin and
@@ -125,7 +130,7 @@ 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's suitable application space.</para>
+Vorbis' suitable application space.</para>
 
 </section>
 
@@ -338,8 +343,7 @@ sample rate and number of channels.</para>
 <para>
 The comment header includes user text comments ("tags") and a vendor
 string for the application/library that produced the bitstream.  The
-encoding of the comment header is described within this document; the
-proper use of the comment fields is described in 
+encoding and proper use of the comment header is described in 
 <xref linkend="vorbis-spec-comment"/>.</para>
 </section>
 
@@ -368,7 +372,7 @@ fundamentally the same.
 <listitem><simpara>compute dot product of floor and residue, producing audio spectrum vector</simpara></listitem>
 <listitem><simpara>inverse monolithic transform of audio spectrum vector, always an MDCT in Vorbis I</simpara></listitem>
 <listitem><simpara>overlap/add left-hand output of transform with right-hand output of previous frame</simpara></listitem>
-<listitem><simpara>store right hand-data from transform of current frame for future lapping.</simpara></listitem>
+<listitem><simpara>store right hand-data from transform of current frame for future lapping</simpara></listitem>
 <listitem><simpara>if not first frame, return results of overlap/add as audio result of current frame</simpara></listitem>
 </orderedlist>
 </para>
@@ -388,9 +392,9 @@ specification, it need not be a literal semantic implementation.</para>
 
 <para>
 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 others packet types are reserved; packets
-marked with a reserved flag type should be ignored.</para>
+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.</para>
 
 <para>
 Following the three header packets, all packets in a Vorbis I stream
@@ -457,7 +461,7 @@ 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
+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
@@ -475,6 +479,7 @@ The use of multirate filter banks for coding of high quality digital
 audio</ulink></citetitle>, by T. Sporer, K. Brandenburg and B. Edler.  Vorbis windows
 all use the slope function 
   <inlineequation>
+    <!-- this equation is incorrect -->
     <alt>y=sin(2PI*sin^2(x/n))</alt>
     <inlinemediaobject>
      <textobject>
@@ -515,8 +520,8 @@ are coded individually in channel order.</para>
 
 <para>
 A detailed discussion of stereo in the Vorbis codec can be found in
-the document <ulink url="stereo.html">_Stereo Channel Coupling in the
-Vorbis CODEC_</ulink>.  Vorbis is not limited to only stereo coupling, but
+the document <ulink url="stereo.html"><citetitle>Stereo Channel Coupling in the
+Vorbis CODEC</citetitle></ulink>.  Vorbis is not limited to only stereo coupling, but
 the stereo document also gives a good overview of the generic coupling
 mechanism.</para>
 
@@ -529,8 +534,8 @@ polar representation (where one vector is magnitude and the second
 angle) back to Cartesian representation.</para>
 
 <para>
-After decoupling, in order, each pair of vectors on the coupling list
-in, the resulting residue vector represents the fine spectral detail
+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.</para>
 
 </section>
@@ -590,11 +595,9 @@ representation.</para>
 <para>
 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 the paper 
-<citetitle pubwork="article"><ulink
-url="http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps">
-The use of multirate filter banks for coding of high quality digital
-audio</ulink></citetitle>, by T. Sporer, K. Brandenburg and B. Edler.</para>
+description of the MDCT is available in the paper <ulink
+url="http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps"><citetitle pubwork="article">The use of multirate filter banks for coding of high quality digital
+audio</citetitle></ulink>, by T. Sporer, K. Brandenburg and B. Edler.</para>
 
 <para>
 Note that the PCM produced directly from the MDCT is not yet finished
index 249381793579698ff5b1b01098db46fc84c592f0..2a6512804235a74c20527094c4350430bf2053c5 100644 (file)
@@ -1,7 +1,7 @@
 <section id="vorbis-spec-bitpacking">
 <sectioninfo>
 <releaseinfo>
- $Id: 02-bitpacking.xml,v 1.3 2002/10/14 18:20:30 giles Exp $
+ $Id: 02-bitpacking.xml,v 1.4 2002/10/21 23:37:00 giles Exp $
  <emphasis>Last update to this document: July 14, 2002</emphasis>
 </releaseinfo>
 </sectioninfo>
@@ -40,7 +40,7 @@ size that is a grouped multiple of this smallest size.</para>
 <para>
 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
+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.</para>
@@ -83,10 +83,10 @@ through byte <emphasis>n</emphasis>.</para>
 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 that the previous field ends.</para>
+is written at the bit position at which the previous field ends.</para>
 
 <para>
-The encoder logically packs integers by writing the LSb of an binary
+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
index 43b3da0ed7d8c57a8e8359e9201cfdfe6e8b9271..c14e1a00b9aac3a038c94413d8f3c201583eda11 100644 (file)
@@ -1,7 +1,7 @@
 <section id="vorbis-spec-codebook">
 <sectioninfo>
 <releaseinfo>
- $Id: 03-codebook.xml,v 1.2 2002/10/14 23:47:54 giles Exp $
+ $Id: 03-codebook.xml,v 1.3 2002/10/21 23:37:00 giles Exp $
  <emphasis>Last update to this document: August 8, 2002</emphasis>
 </releaseinfo>
 </sectioninfo>
@@ -35,7 +35,7 @@ stream according to <xref linkend="vorbis-spec-bitpacking"/>.</para>
 <title>Packed Codebook Format</title>
 
 <para>
-For purposes of the below examples, we assume that the storage
+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 <xref linkend="vorbis-spec-bitpacking"/> for discussion 
 relating to non-eight-bit bytes.</para>
@@ -98,7 +98,7 @@ byte 8: [             X 1 ] [sparse] flag (1 bit)
 
 <para>
   The decoder now performs for each of the <varname>[codebook_entries]</varname>
-  code book entries:
+  codebook entries:
 
 <screen>
   
@@ -134,15 +134,13 @@ byte 8: [             X 1 ] [sparse] flag (1 bit)
 <screen>
   1) [current_entry] = 0;
   2) [current_length] = read a five bit unsigned integer and add 1;
-  3) [number] = read <link linkend="vorbis-spec-ilog">ilog</link>([codebook_entries] -
-[current_entry])
-bits as an unsigned integer
+  3) [number] = read <link linkend="vorbis-spec-ilog">ilog</link>([codebook_entries] - [current_entry]) bits as an unsigned integer
   4) set the entries [current_entry] through [current_entry]+[number]-1, inclusive, 
-     of the [codebook_codeword_lengths] array to [current_length]
+    of the [codebook_codeword_lengths] array to [current_length]
   5) set [current_entry] to [number] + [current_entry]
   6) increment [current_length] by 1
-  7) if [current_entry] is greater than [codebook_entries] ERROR CONDITION; the decoder will
-     not be able to read this stream.
+  7) if [current_entry] is greater than [codebook_entries] ERROR CONDITION; 
+    the decoder will not be able to read this stream.
   8) if [current_entry] is less than [codebook_entries], repeat process starting at 3)
   9) done.
 </screen></para>
@@ -202,12 +200,10 @@ possible scalar values.  Lookup decode proceeds as follows:
 
   7) read a total of [codebook_lookup_values] unsigned integers of [codebook_value_bits] each; 
      store these in order in the array [codebook_multiplicands]
-
 </screen></para>
 </listitem><listitem>
 <para>A <varname>[codebook_lookup_type]</varname> of greater than two is reserved
-and indicates
-a stream that's not decodable by the specification in this
+and indicates a stream that is not decodable by the specification in this
 document.</para>
 </listitem>
 </itemizedlist>
@@ -340,10 +336,10 @@ decode in a VQ context.</para>
 
 <para>
 Lookup type one specifies a lattice VQ lookup table built
-algorithmically from a list of scalar values.  Calculate [unpack] the
+algorithmically from a list of scalar values.  Calculate (unpack) the
 final values of a codebook entry vector from the entries in
 <varname>[codebook_multiplicands]</varname> as follows (<varname>[value_vector]</varname>
-is the output vector representing the vctor of values for entry number
+is the output vector representing the vector of values for entry number
 <varname>[lookup_offset]</varname> in this codebook):
 
 <screen>
@@ -377,7 +373,7 @@ each vector is explicitly set by the <varname>[codebook_multiplicands]</varname>
 array in a one-to-one mapping.  Calculate [unpack] the
 final values of a codebook entry vector from the entries in
 <varname>[codebook_multiplicands]</varname> as follows (<varname>[value_vector]</varname>
-is the output vector representing the vctor of values for entry number
+is the output vector representing the vector of values for entry number
 <varname>[lookup_offset]</varname> in this codebook):
 
 <screen>
index 5fa0fc4f276d724ea329a02fd4be6afcf100472e..9fc1f5c07794868e84529d1e48d96c4ac2f05c31 100644 (file)
@@ -1,7 +1,7 @@
 <section id="vorbis-spec-codec">
 <sectioninfo>
 <releaseinfo>
- $Id: 04-codec.xml,v 1.3 2002/10/18 00:43:00 giles Exp $
+ $Id: 04-codec.xml,v 1.4 2002/10/21 23:37:00 giles Exp $
  <emphasis>Last update to this document: October 15, 2002</emphasis>
 </releaseinfo>
 </sectioninfo>
@@ -207,20 +207,20 @@ uses a single mapping type (0), with implicit PCM channel mappings.</para>
 
 <orderedlist>
  <listitem><simpara><varname>[vorbis_mapping_count]</varname> = read 6 bits as unsigned integer and add one</simpara></listitem>
- <listitem><simpara>For each <varname>[i]</varname>
-of <varname>[vorbis_mapping_count]</varname> mapping numbers:</simpara>
+ <listitem><para>For each <varname>[i]</varname> of <varname>[vorbis_mapping_count]</varname> mapping numbers:
   <orderedlist>
    <listitem><simpara>read the mapping type: 16 bits as unsigned integer.  There's no reason to save the mapping type in Vorbis I.</simpara></listitem>
    <listitem><simpara>If the mapping type is nonzero, the stream is undecodable</simpara></listitem>
    <listitem><para>If the mapping type is zero:
     <orderedlist>
-     <listitem><simpara>read 1 bit as a boolean flag</simpara>
+     <listitem><para>read 1 bit as a boolean flag
       <orderedlist>
        <listitem><simpara>if set, <varname>[vorbis_mapping_submaps]</varname> = read 4 bits as unsigned integer and add one</simpara></listitem>
        <listitem><simpara>if unset, <varname>[vorbis_mapping_submaps]</varname> = 1</simpara></listitem>
       </orderedlist>
+      </para>
      </listitem>
-     <listitem><simpara>read 1 bit as a boolean flag</simpara>
+     <listitem><para>read 1 bit as a boolean flag
        <orderedlist>
          <listitem><para>if set, square polar channel mapping is in use:
            <orderedlist>
@@ -231,11 +231,14 @@ of <varname>[vorbis_mapping_count]</varname> mapping numbers:</simpara>
                  <listitem><simpara>vector <varname>[vorbis_mapping_angle]</varname> element <varname>[j]</varname>= read <link linkend="vorbis-spec-ilog">ilog</link>(<varname>[audio_channels]</varname> - 1) bits as unsigned integer</simpara></listitem>
                  <listitem><simpara>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 <varname>[audio_channels]</varname>-1, or the angle channel is greater than <varname>[audio_channels]</varname>-1, the stream is undecodable.</simpara></listitem>
                </orderedlist>
-             </para></listitem>
+               </para>
+             </listitem>
            </orderedlist>
-         </para></listitem>
+           </para>
+         </listitem>
          <listitem><simpara>if unset, <varname>[vorbis_mapping_coupling_steps]</varname> = 0</simpara></listitem>
        </orderedlist>
+       </para>
      </listitem>
      <listitem><simpara>read 2 bits (reserved field); if the value is nonzero, the stream is undecodable</simpara></listitem>
      <listitem><simpara>if <varname>[vorbis_mapping_submaps]</varname> is greater than one, we read channel multiplex settings. For each <varname>[j]</varname> of <varname>[audio_channels]</varname> channels:</simpara>
@@ -257,7 +260,7 @@ of <varname>[vorbis_mapping_count]</varname> mapping numbers:</simpara>
     </orderedlist></para>
    </listitem>
   </orderedlist>
- </listitem>
+ </para></listitem>
 </orderedlist>
 
 </section>
@@ -299,7 +302,7 @@ After reading mode descriptions, setup header decode is complete.
 <para>
 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; <emphasis>a non-audio packet when audio is expected
+verify the packet type. <emphasis>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</emphasis>.
 </para>
@@ -341,7 +344,7 @@ illustration of overlapping dissimilar
 </orderedlist>
 
 <para>
-Vorbis windows all use the slope function y=sin(0.5 * &pi; * sin^2((x+.5)/n * &pi;)),
+Vorbis windows all use the slope function y=sin(0.5 * \pi * sin^2((x+.5)/n * \pi)),
 where n is window size and x ranges 0...n-1, but dissimilar
 lapping requirements can affect overall shape.  Window generation
 proceeds as follows:</para>
@@ -382,9 +385,9 @@ set) then
  </listitem>
  <listitem><simpara> window from range 0 ... <varname>[left_window_start]</varname>-1 inclusive is zero</simpara></listitem>
  <listitem><simpara> for <varname>[i]</varname> in range <varname>[left_window_start]</varname> ...
-<varname>[left_window_end]</varname>-1, window(<varname>[i]</varname>) = sin(.5 * &pi; * sin^2( (<varname>[i]</varname>-<varname>[left_window_start]</varname>+.5) / <varname>[left_n]</varname> * .5 * &pi;) )</simpara></listitem>
+<varname>[left_window_end]</varname>-1, window(<varname>[i]</varname>) = sin(.5 * \pi * sin^2( (<varname>[i]</varname>-<varname>[left_window_start]</varname>+.5) / <varname>[left_n]</varname> * .5 * \pi) )</simpara></listitem>
  <listitem><simpara> window from range <varname>[left_window_end]</varname> ... <varname>[right_window_start]</varname>-1
-inclusive is one</simpara></listitem><listitem><simpara> for <varname>[i]</varname> in range <varname>[right_window_start]</varname> ... <varname>[right_window_end]</varname>-1, window(<varname>[i]</varname>) = sin(.5 * &pi; * sin^2( (<varname>[i]</varname>-<varname>[right_window_start]</varname>+.5) / <varname>[right_n]</varname> * .5 * &pi;/2. + .5 * &pi;) )</simpara></listitem>
+inclusive is one</simpara></listitem><listitem><simpara> for <varname>[i]</varname> in range <varname>[right_window_start]</varname> ... <varname>[right_window_end]</varname>-1, window(<varname>[i]</varname>) = sin(.5 * \pi * sin^2( (<varname>[i]</varname>-<varname>[right_window_start]</varname>+.5) / <varname>[right_n]</varname> * .5 * \pi/2. + .5 * \pi) )</simpara></listitem>
 <listitem><simpara> window from range <varname>[rigth_window_start]</varname> ... <varname>[n]</varname>-1 is
 zero</simpara></listitem>
 </orderedlist>
@@ -420,12 +423,10 @@ For each floor <varname>[i]</varname> of <varname>[audio_channels]</varname>
 floor (vector <varname>[vorbis_floor_types]</varname> element
 <varname>[floor_number]</varname>) is zero then decode the floor for
 channel <varname>[i]</varname> according to the
-<xref linkend="vorbis-spec-floor0-decode"/>floor 0 decode
-algorithm</simpara></listitem>
+<xref linkend="vorbis-spec-floor0-decode"/></simpara></listitem>
   <listitem><simpara>if the type of this floor
 is one then decode the floor for channel <varname>[i]</varname> according
-to the <xref linkend="vorbis-spec-floor1-decode"/>floor 1 decode
-algorithm</simpara></listitem>
+to the <xref linkend="vorbis-spec-floor1-decode"/></simpara></listitem>
   <listitem><simpara>save the needed decoded floor information for channel for later synthesis</simpara></listitem>
   <listitem><simpara>if the decoded floor returned 'unused', set vector <varname>[no_residue]</varname> element
 <varname>[i]</varname> to true, else set vector <varname>[no_residue]</varname> element <varname>[i]</varname> to
@@ -571,7 +572,7 @@ length for floor computation is <varname>[n]</varname>/2.</para>
 <para>
 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 the floor and residue vectors for each channel; the produced
+product of the floor and residue vectors for each channel; the produced
 vectors are the length <varname>[n]</varname>/2 audio spectrum for each
 channel.</para>
 
@@ -607,11 +608,10 @@ representation.</para>
 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 the paper
-<citetitle pubwork="article"><ulink
-url="http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps">The
+<ulink url="http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps"><citetitle pubwork="article">The
 use of multirate filter banks for coding of high quality digital
-audio</ulink></citetitle>, by T. Sporer, K. Brandenburg and B. Edler.  The window
-function used for the MDCT is the window determined earlier.</para>
+audio</citetitle></ulink>, by T. Sporer, K. Brandenburg and B. Edler.  The window
+function used for the MDCT is the function described earlier.</para>
 
 </section>
 
@@ -621,18 +621,20 @@ function used for the MDCT is the window determined earlier.</para>
 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
-<xref linkend="vorbis-spec-window"/>.  The overlapped portion
+<xref linkend="vorbis-spec-window"/>).  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
+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:
 
-<programlisting>window_blocksize(previous_window)/4+window_blocksize(current_window)/4</programlisting>
+<programlisting>
+window_blocksize(previous_window)/4+window_blocksize(current_window)/4
+</programlisting>
 
 from the center (element windowsize/2) of the previous window to the
 center (element windowsize/2-1, inclusive) of the current window.</para>
@@ -679,7 +681,7 @@ front center, front right, rear left, rear right</simpara>
   </listitem>
  </varlistentry><varlistentry>
   <term>six channels</term><listitem>
-   <simpara>the stream is 5,1 surround.  channel order: front left, front
+   <simpara>the stream is 5.1 surround.  channel order: front left, front
 center, front right, rear left, rear right, LFE</simpara>
   </listitem>
  </varlistentry><varlistentry>
index 8354c073c994c66df2d9f15b35d03f0928cbf2e8..ff93846dc87ff289e5fc1c2e48961d59491532dc 100644 (file)
@@ -2,6 +2,7 @@
 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
                "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 [
+%isogrk3;
 <!ENTITY intro SYSTEM "01-introduction.xml">
 <!ENTITY bitpacking SYSTEM "02-bitpacking.xml">
 <!ENTITY codebook SYSTEM "03-codebook.xml">
@@ -15,7 +16,8 @@
 <!ENTITY oggvorbis SYSTEM "a1-encapsulation_ogg.xml">
 <!ENTITY rtpvorbis SYSTEM "a2-encapsulation_rtp.xml">
 <!ENTITY footer SYSTEM "footer.xml">
-<!ENTITY draft-rtp SYSTEM "../draft-moffitt-vorbis-rtp-00.txt">
+<!NOTATION TEXT SYSTEM "text/plain">
+<!ENTITY draft-rtp SYSTEM "../draft-moffitt-vorbis-rtp-00.txt" NDATA TEXT>
 ]>
 
 <article>