--- /dev/null
+<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
+<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
+<nobr><a href="http://www.xiph.org/ogg/index.html"><img src="white-ogg.png" border=0><img
+src="vorbisword2.png" border=0></a></nobr><p>
+
+<h1><font color=#000070>
+Ogg logical bitstream framing
+</font></h1>
+
+<em>Last update to this document: July 14, 2002</em><br>
+
+<h2>Ogg bitstreams</h2>
+
+The Ogg transport bitstream is designed to provide framing, error
+protection and seeking structure for higher-level codec streams that
+consist of raw, unencapsulated data packets, such as the Vorbis audio
+codec or Tarkin video codec.
+
+<h2>Application example: Vorbis</h2>
+Vorbis encodes short-time blocks of PCM data into raw packets of
+bit-packed data. These raw packets may be used directly by transport
+mechanisms that provide their own framing and packet-separation
+mechanisms (such as UDP datagrams). For stream based storage (such as
+files) and transport (such as TCP streams or pipes), Vorbis uses the
+Ogg bitstream format to provide framing/sync, sync recapture
+after error, landmarks during seeking, and enough information to
+properly separate data back into packets at the original packet
+boundaries without relying on decoding to find packet boundaries.<p>
+
+<h2>Design constraints for Ogg bitstreams</h2>
+
+<ol><li>True streaming; we must not need to seek to build a 100%
+ complete bitstream.
+
+<li> Use no more than approximately 1-2% of bitstream bandwidth for
+ packet boundary marking, high-level framing, sync and seeking.
+
+<li> Specification of absolute position within the original sample
+ stream.
+
+<li> Simple mechanism to ease limited editing, such as a simplified
+ concatenation mechanism.
+
+<li> Detection of corruption, recapture after error and direct, random
+ access to data at arbitrary positions in the bitstream.
+</ol>
+
+<h2>Logical and Physical Bitstreams</h2>
+
+A <em>logical</em> Ogg bitstream is a contiguous stream of
+sequential pages belonging only to the logical bitstream. A
+<em>physical</em> Ogg bitstream is constructed from one or more
+than one logical Ogg bitstream (the simplest physical bitstream
+is simply a single logical bitstream). We describe below the exact
+formatting of an Ogg logical bitstream. Combining logical
+bitstreams into more complex physical bitstreams is described in the
+<a href="oggstream.html">Ogg bitstream overview</a>. The exact
+mapping of raw Vorbis packets into a valid Ogg Vorbis physical
+bitstream is described in <a href="vorbis-stream.html">Vorbis
+bitstream mapping</a>.
+
+<h2>Bitstream structure</h2>
+
+An Ogg stream is structured by dividing incoming packets into
+segments of up to 255 bytes and then wrapping a group of contiguous
+packet segments into a variable length page preceded by a page
+header. Both the header size and page size are variable; the page
+header contains sizing information and checksum data to determine
+header/page size and data integrity.<p>
+
+The bitstream is captured (or recaptured) by looking for the beginning
+of a page, specifically the capture pattern. Once the capture pattern
+is found, the decoder verifies page sync and integrity by computing
+and comparing the checksum. At that point, the decoder can extract the
+packets themselves.<p>
+
+<h3>Packet segmentation</h3>
+
+Packets are logically divided into multiple segments before encoding
+into a page. Note that the segmentation and fragmentation process is a
+logical one; it's used to compute page header values and the original
+page data need not be disturbed, even when a packet spans page
+boundaries.<p>
+
+The raw packet is logically divided into [n] 255 byte segments and a
+last fractional segment of < 255 bytes. A packet size may well
+consist only of the trailing fractional segment, and a fractional
+segment may be zero length. These values, called "lacing values" are
+then saved and placed into the header segment table.<p>
+
+An example should make the basic concept clear:<p>
+
+<pre>
+<tt>
+raw packet:
+ ___________________________________________
+ |______________packet data__________________| 753 bytes
+
+lacing values for page header segment table: 255,255,243
+</tt>
+</pre>
+
+We simply add the lacing values for the total size; the last lacing
+value for a packet is always the value that is less than 255. Note
+that this encoding both avoids imposing a maximum packet size as well
+as imposing minimum overhead on small packets (as opposed to, eg,
+simply using two bytes at the head of every packet and having a max
+packet size of 32k. Small packets (<255, the typical case) are
+penalized with twice the segmentation overhead). Using the lacing
+values as suggested, small packets see the minimum possible
+byte-aligned overheade (1 byte) and large packets, over 512 bytes or
+so, see a fairly constant ~.5% overhead on encoding space.<p>
+
+Note that a lacing value of 255 implies that a second lacing value
+follows in the packet, and a value of < 255 marks the end of the
+packet after that many additional bytes. A packet of 255 bytes (or a
+multiple of 255 bytes) is terminated by a lacing value of 0:<p>
+
+<pre><tt>
+raw packet:
+ _______________________________
+ |________packet data____________| 255 bytes
+
+lacing values: 255, 0
+</tt></pre>
+
+Note also that a 'nil' (zero length) packet is not an error; it
+consists of nothing more than a lacing value of zero in the header.<p>
+
+<h3>Packets spanning pages</h3>
+
+Packets are not restricted to beginning and ending within a page,
+although individual segments are, by definition, required to do so.
+Packets are not restricted to a maximum size, although excessively
+large packets in the data stream are discouraged; the Ogg
+bitstream specification strongly recommends nominal page size of
+approximately 4-8kB (large packets are foreseen as being useful for
+initialization data at the beginning of a logical bitstream).<p>
+
+After segmenting a packet, the encoder may decide not to place all the
+resulting segments into the current page; to do so, the encoder places
+the lacing values of the segments it wishes to belong to the current
+page into the current segment table, then finishes the page. The next
+page is begun with the first value in the segment table belonging to
+the next packet segment, thus continuing the packet (data in the
+packet body must also correspond properly to the lacing values in the
+spanned pages. The segment data in the first packet corresponding to
+the lacing values of the first page belong in that page; packet
+segments listed in the segment table of the following page must begin
+the page body of the subsequent page).<p>
+
+The last mechanic to spanning a page boundary is to set the header
+flag in the new page to indicate that the first lacing value in the
+segment table continues rather than begins a packet; a header flag of
+0x01 is set to indicate a continued packet. Although mandatory, it
+is not actually algorithmically necessary; one could inspect the
+preceding segment table to determine if the packet is new or
+continued. Adding the information to the packet_header flag allows a
+simpler design (with no overhead) that needs only inspect the current
+page header after frame capture. This also allows faster error
+recovery in the event that the packet originates in a corrupt
+preceding page, implying that the previous page's segment table
+cannot be trusted.<p>
+
+Note that a packet can span an arbitrary number of pages; the above
+spanning process is repeated for each spanned page boundary. Also a
+'zero termination' on a packet size that is an even multiple of 255
+must appear even if the lacing value appears in the next page as a
+zero-length continuation of the current packet. The header flag
+should be set to 0x01 to indicate that the packet spanned, even though
+the span is a nil case as far as data is concerned.<p>
+
+The encoding looks odd, but is properly optimized for speed and the
+expected case of the majority of packets being between 50 and 200
+bytes (note that it is designed such that packets of wildly different
+sizes can be handled within the model; placing packet size
+restrictions on the encoder would have only slightly simplified design
+in page generation and increased overall encoder complexity).<p>
+
+The main point behind tracking individual packets (and packet
+segments) is to allow more flexible encoding tricks that requiring
+explicit knowledge of packet size. An example is simple bandwidth
+limiting, implemented by simply truncating packets in the nominal case
+if the packet is arranged so that the least sensitive portion of the
+data comes last.<p>
+
+<h3>Page header</h3>
+
+The headering mechanism is designed to avoid copying and re-assembly
+of the packet data (ie, making the packet segmentation process a
+logical one); the header can be generated directly from incoming
+packet data. The encoder buffers packet data until it finishes a
+complete page at which point it writes the header followed by the
+buffered packet segments.<p>
+
+<h4>capture_pattern</h4>
+
+ A header begins with a capture pattern that simplifies identifying
+ pages; once the decoder has found the capture pattern it can do a more
+ intensive job of verifying that it has in fact found a page boundary
+ (as opposed to an inadvertent coincidence in the byte stream).<p>
+
+<pre><tt>
+ byte value
+
+ 0 0x4f 'O'
+ 1 0x67 'g'
+ 2 0x67 'g'
+ 3 0x53 'S'
+</tt></pre>
+
+<h4>stream_structure_version</h4>
+
+ The capture pattern is followed by the stream structure revision:
+
+<pre><tt>
+ byte value
+
+ 4 0x00
+</tt></pre>
+
+<h4>header_type_flag</h4>
+
+ The header type flag identifies this page's context in the bitstream:
+
+<pre><tt>
+ byte value
+
+ 5 bitflags: 0x01: unset = fresh packet
+ set = continued packet
+ 0x02: unset = not first page of logical bitstream
+ set = first page of logical bitstream (bos)
+ 0x04: unset = not last page of logical bitstream
+ set = last page of logical bitstream (eos)
+</tt></pre>
+
+<h4>absolute granule position</h4>
+
+ (This is packed in the same way the rest of Ogg data is packed; LSb
+ of LSB first. Note that the 'position' data specifies a 'sample'
+ number (eg, in a CD quality sample is four octets, 16 bits for left
+ and 16 bits for right; in video it would likely be the frame number.
+ It is up to the specific codec in use to define the semantic meaning
+ of the granule position value). The position specified is the total
+ samples encoded after including all packets finished on this page
+ (packets begun on this page but continuing on to the next page do not
+ count). The rationale here is that the position specified in the
+ frame header of the last page tells how long the data coded by the
+ bitstream is. A truncated stream will still return the proper number
+ of samples that can be decoded fully.
+<p>
+ A special value of '-1' (in two's complement) indicates that no packets
+ finish on this page.
+
+<pre><tt>
+ byte value
+
+ 6 0xXX LSB
+ 7 0xXX
+ 8 0xXX
+ 9 0xXX
+ 10 0xXX
+ 11 0xXX
+ 12 0xXX
+ 13 0xXX MSB
+</tt></pre>
+
+<h4>stream serial number</h4>
+
+ Ogg allows for separate logical bitstreams to be mixed at page
+ granularity in a physical bitstream. The most common case would be
+ sequential arrangement, but it is possible to interleave pages for
+ two separate bitstreams to be decoded concurrently. The serial
+ number is the means by which pages physical pages are associated with
+ a particular logical stream. Each logical stream must have a unique
+ serial number within a physical stream:
+
+<pre><tt>
+ byte value
+
+ 14 0xXX LSB
+ 15 0xXX
+ 16 0xXX
+ 17 0xXX MSB
+</tt></pre>
+
+<h4>page sequence no</h4>
+
+ Page counter; lets us know if a page is lost (useful where packets
+ span page boundaries).
+
+<pre><tt>
+ byte value
+
+ 18 0xXX LSB
+ 19 0xXX
+ 20 0xXX
+ 21 0xXX MSB
+</tt></pre>
+
+<h4>page checksum</h4>
+
+ 32 bit CRC value (direct algorithm, initial val and final XOR = 0,
+ generator polynomial=0x04c11db7). The value is computed over the
+ entire header (with the CRC field in the header set to zero) and then
+ continued over the page. The CRC field is then filled with the
+ computed value.<p>
+
+ (A thorough discussion of CRC algorithms can be found in <a
+ href="ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt">"A
+ Painless Guide to CRC Error Detection Algorithms"</a> by Ross
+ Williams <a
+ href="mailto:ross@guest.adelaide.edu.au">ross@guest.adelaide.edu.au</a>.)
+
+<pre><tt>
+ byte value
+
+ 22 0xXX LSB
+ 23 0xXX
+ 24 0xXX
+ 25 0xXX MSB
+</tt></pre>
+
+<h4>page_segments</h4>
+
+ The number of segment entries to appear in the segment table. The
+ maximum number of 255 segments (255 bytes each) sets the maximum
+ possible physical page size at 65307 bytes or just under 64kB (thus
+ we know that a header corrupted so as destroy sizing/alignment
+ information will not cause a runaway bitstream. We'll read in the
+ page according to the corrupted size information that's guaranteed to
+ be a reasonable size regardless, notice the checksum mismatch, drop
+ sync and then look for recapture).<p>
+
+<pre><tt>
+ byte value
+
+ 26 0x00-0xff (0-255)
+</tt></pre>
+
+<h4>segment_table (containing packet lacing values)</h4>
+
+ The lacing values for each packet segment physically appearing in
+ this page are listed in contiguous order.
+
+<pre><tt>
+ byte value
+
+ 27 0x00-0xff (0-255)
+ [...]
+ n 0x00-0xff (0-255, n=page_segments+26)
+</tt></pre>
+
+Total page size is calculated directly from the known header size and
+lacing values in the segment table. Packet data segments follow
+immediately after the header.<p>
+
+Page headers typically impose a flat .25-.5% space overhead assuming
+nominal ~8k page sizes. The segmentation table needed for exact
+packet recovery in the streaming layer adds approximately .5-1%
+nominal assuming expected encoder behavior in the 44.1kHz, 128kbps
+stereo encodings.<p>
+
+<hr>
+<a href="http://www.xiph.org/">
+<img src="white-xifish.png" align=left border=0>
+</a>
+<font size=-2 color=#505050>
+
+Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
+to protect essential tenets of Internet multimedia from corporate
+hostage-taking; Open Source is the net's greatest tool to keep
+everyone honest. See <a href="http://www.xiph.org/about.html">About
+the Xiph.org Foundation</a> for details.
+<p>
+
+Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
+distribute the Ogg and Vorbis specification, whether in a private,
+public or corporate capacity. However, the Xiph.org Foundation and
+the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
+specification and certify specification compliance.<p>
+
+Xiph.org's Vorbis software CODEC implementation is distributed under a
+BSD-like license. This does not restrict third parties from
+distributing independent implementations of Vorbis software under
+other licenses.<p>
+
+Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
+of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
+pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
+reserved.<p>
+
+</body>
+
+
--- /dev/null
+<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
+<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
+<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
+
+<h1><font color=#000070>
+Ogg Vorbis I format specification: helper equations
+</font></h1>
+
+<em>Last update to this document: July 15, 2002</em><br>
+
+<h1>Overview</h1>
+
+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 linked int he main documents
+where appropriate.<p>
+
+<a name=log><h2>ilog</h2></a>
+
+
+The "ilog(x)" function returns the highest set bit in the two's complement integer value
+<tt>[x]</tt>. Values of <tt>[x]</tt> less than zero are defined to return zero.
+
+<pre>
+ 1) [return_value] = 0;
+ 2) if ( [x] is greater than nonzero ){
+
+ 3) increment [return_value];
+ 4) logical shift [x] one bit to the right, padding the MSb with zero
+ 5) repeat at step 2)
+
+ }
+
+ 6) done
+</pre>
+
+Examples:
+
+<ul><li> ilog(0) = 0;
+ <li> ilog(1) = 1;
+ <li> ilog(2) = 2;
+ <li> ilog(3) = 2;
+ <li> ilog(4) = 3;
+ <li> ilog(7) = 3;
+ <li> ilog(negative number) = 0;
+</uL>
+
+<a name=float32_unpack><h2>float32_unpack</h2></a>
+
+"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.<p>
+
+<pre>
+ 1) [mantissa] = [x] bitwise AND 0x1fffff (unsigned result)
+ 2) [sign] = [x] bitwise AND 0x80000000 (unsigned result)
+ 3) [exponent] = ( [x] bitwise AND 0x7fe00000) shifted left 21 bits (unsigned result)
+ 4) if ( [mantissa] is nonzero ) then negate [mantissa]
+ 5) return [mantissa] * ( 2 ^ ( [exponent] - 788 ) )
+</pre>
+
+<a name=lookup1_values><h2>lookup1_values</h2></a>
+
+"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
+<tt>[codebook_entries]</tt>.<p>
+
+The return value for this function is defined to be 'the greatest
+integer value for which <tt>[return_value] to the power of
+[codebook_dimensions] is less than or equal to
+[codebook_entries]</tt>'.
+
+
+<hr>
+<a href="http://www.xiph.org/">
+<img src="white-xifish.png" align=left border=0>
+</a>
+<font size=-2 color=#505050>
+
+Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
+to protect essential tenets of Internet multimedia from corporate
+hostage-taking; Open Source is the net's greatest tool to keep
+everyone honest. See <a href="http://www.xiph.org/about.html">About
+the Xiph.org Foundation</a> for details.
+<p>
+
+Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
+distribute the Ogg and Vorbis specification, whether in a private,
+public or corporate capacity. However, the Xiph.org Foundation and
+the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
+specification and certify specification compliance.<p>
+
+Xiph.org's Vorbis software CODEC implementation is distributed under a
+BSD-like license. This does not restrict third parties from
+distributing independent implementations of Vorbis software under
+other licenses.<p>
+
+Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
+of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
+pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
+reserved.<p>
+
+</body>
+
--- /dev/null
+<title> xiph.org: Ogg Vorbis documentation </title>
+
+<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
+<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
+<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
+
+<h1><font color=#000070>
+Ogg Vorbis Documentation
+</font></h1>
+
+<em>Last documentation revision: July 16, 2002</em><p>
+
+<h2>Vorbis technical discussion documents</h2>
+<ul>
+<li><a href="vorbis-fidelity.html">Fidelity measurement terminology</a>
+<li><a href="stereo.html">Vorbis channel coupling and stereo-specific application</a>
+</ul>
+
+<h2>Ogg Vorbis I specification documents</h2>
+<ul>
+<li><a href="vorbis-spec-intro.html">Vorbis specification introduction and description</a>
+<li><a href="vorbis-spec-bitpack.html">Vorbis bitpacking convention</a>
+<li><a href="vorbis-spec-codebook.html">Vorbis probability model and codebooks</a>
+<li><a href="vorbis-spec-ref.html">Vorbis codec setup and packet decode</a>
+<li><a href="v-comment.html">Vorbis comment header specification</a>
+<li><a href="vorbis-spec-floor0.html">Vorbis floor type 0 setup and decode</a>
+<li><a href="vorbis-spec-floor1.html">Vorbis floor type 1 setup and decode</a>
+<li><a href="vorbis-spec-res.html">Vorbis residue types 0, 1 and 2 setup and decode</a>
+<li><a href="vorbis-ogg.html">Embedding Vorbis encoded audio in an Ogg bitstream</a>
+<li><a href="draft-moffitt-vorbis-rtp-00.txt">Embedding Vorbis encoded audio in an RTP payload format</a>
+</ul>
+
+
+<h2>Ogg Vorbis programming documents</h2>
+<ul>
+<li>Programming with libvorbis
+<li><a href="vorbisfile/index.html">Programming with vorbisfile</a>
+<li><a href="vorbisenc/index.html">Programming with vorbisenc</a><P>
+
+
+</ul>
+
+<h2>Ogg bitstream documentation</h2>
+<ul>
+<li><a href="oggstream.html">Ogg bitstream overview</a>
+<li><a href="framing.html">Ogg logical bitstream and framing spec</a>
+</ul>
+
+<hr>
+<a href="http://www.xiph.org/">
+<img src="white-xifish.png" align=left border=0>
+</a>
+<font size=-2 color=#505050>
+
+Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
+to protect essential tenets of Internet multimedia from corporate
+hostage-taking; Open Source is the net's greatest tool to keep
+everyone honest. See <a href="http://www.xiph.org/about.html">About
+the Xiph.org Foundation</a> for details.
+<p>
+
+Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
+distribute the Ogg and Vorbis specification, whether in a private,
+public or corporate capacity. However, the Xiph.org Foundation and
+the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
+specification and certify specification compliance.<p>
+
+Xiph.org's Vorbis software CODEC implementation is distributed under a
+BSD-like license. This does not restrict third parties from
+distributing independent implementations of Vorbis software under
+other licenses.<p>
+
+Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
+of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
+pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
+reserved.<p>
+
+</body>
+
--- /dev/null
+<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
+<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
+<nobr><a href="http://www.xiph.org/ogg/index.html"><img src="white-ogg.png" border=0><img
+src="vorbisword2.png" border=0></a></nobr><p>
+
+
+<h1><font color=#000070>
+Ogg logical and physical bitstream overview
+</font></h1>
+
+<em>Last update to this document: July 14, 2002</em><br>
+
+<h2>Ogg bitstreams</h2>
+
+Ogg codecs use octet vectors of raw, compressed data
+(<em>packets</em>). These compressed packets do not have any
+high-level structure or boundary information; strung together, they
+appear to be streams of random bytes with no landmarks.<p>
+
+Raw packets may be used directly by transport mechanisms that provide
+their own framing and packet-separation mechanisms (such as UDP
+datagrams). For stream based storage (such as files) and transport
+(such as TCP streams or pipes), Vorbis and other future Ogg codecs use
+the Ogg bitstream format to provide framing/sync, sync recapture
+after error, landmarks during seeking, and enough information to
+properly separate data back into packets at the original packet
+boundaries without relying on decoding to find packet boundaries.<p>
+
+<h2>Logical and physical bitstreams</h2>
+
+Raw packets are grouped and encoded into contiguous pages of
+structured bitstream data called <em>logical bitstreams</em>. A
+logical bitstream consists of pages, in order, belonging to a single
+codec instance. Each page is a self contained entity (although it is
+possible that a packet may be split and encoded across one or more
+pages); that is, the page decode mechanism is designed to recognize,
+verify and handle single pages at a time from the overall bitstream.<p>
+
+Multiple logical bitstreams can be combined (with restrictions) into a
+single <em>physical bitstream</em>. A physical bitstream consists of
+multiple logical bitstreams multiplexed at the page level and may
+include a 'meta-header' at the beginning of the multiplexed logical
+stream that serves as identification magic. Whole pages are taken in
+order from multiple logical bitstreams and combined into a single
+physical stream of pages. The decoder reconstructs the original
+logical bitstreams from the physical bitstream by taking the pages in
+order from the physical bitstream and redirecting them into the
+appropriate logical decoding entity. The simplest physical bitstream
+is a single, unmultiplexed logical bitstream with no meta-header; this
+is referred to as a 'degenerate stream'. <p>
+
+<a href=framing.html>Ogg Logical Bitstream Framing</a> discusses
+the page format of an Ogg bitstream, the packet coding process
+and logical bitstreams in detail. The remainder of this document
+specifies requirements for constructing finished, physical Ogg
+bitstreams.<p>
+
+<h2>Mapping Restrictions</h2>
+
+Logical bitstreams may not be mapped/multiplexed into physical
+bitstreams without restriction. Here we discuss design restrictions
+on Ogg physical bitstreams in general, mostly to introduce
+design rationale. Each 'media' format defines its own (generally more
+restrictive) mapping. An '<a href="vorbis-ogg.html">Ogg Vorbis
+Audio Bitstream</a>', for example, has a <a
+href="vorbis-ogg.html">specific physical bitstream structure</a>.
+An 'Ogg A/V' bitstream (not currently specified) will also mandate a
+specific, restricted physical bitstream format.<p>
+
+<h3>additional end-to-end structure</h3>
+
+The <a href="framing.html">framing specification</a> defines
+'beginning of stream' and 'end of stream' page markers via a header
+flag (it is possible for a stream to consist of a single page). A
+stream always consists of an integer number of pages, an easy
+requirement given the variable size nature of pages.<p>
+
+In addition to the header flag marking the first and last pages of a
+logical bitstream, the first page of an Ogg bitstream obeys
+additional restrictions. Each individual media mapping specifies its
+own implementation details regarding these restrictions.<p>
+
+The first page of a logical Ogg bitstream consists of a single,
+small 'initial header' packet that includes sufficient information to
+identify the exact CODEC type and media requirements of the logical
+bitstream. The intent of this restriction is to simplify identifying
+the bitstream type and content; for a given media type (or across all
+Ogg media types) we can know that we only need a small, fixed
+amount of data to uniquely identify the bitstream type.<p>
+
+As an example, Ogg Vorbis places the name and revision of the Vorbis
+CODEC, the audio rate and the audio quality into this initial header,
+thus simplifying vastly the certain identification of an Ogg Vorbis
+audio bitstream.<p>
+
+<h3>sequential multiplexing (chaining)</h3>
+
+The simplest form of logical bitstream multiplexing is concatenation
+(<em>chaining</em>). Complete logical bitstreams are strung
+one-after-another in order. The bitstreams do not overlap; the final
+page of a given logical bitstream is immediately followed by the
+initial page of the next. Chaining is the only logical->physical
+mapping allowed by Ogg Vorbis.<p>
+
+Each chained logical bitstream must have a unique serial number within
+the scope of the physical bitstream.<p>
+
+<h3>concurrent multiplexing (grouping)</h3>
+
+Logical bitstreams may also be multiplexed 'in parallel'
+(<em>grouped</em>). An example of grouping would be to allow
+streaming of separate audio and video streams, using different codecs
+and different logical bitstreams, in the same physical bitstream.
+Whole pages from multiple logical bitstreams are mixed together.<p>
+
+The initial pages of each logical bitstream must appear first; the
+media mapping specifies the order of the initial pages. For example,
+Ogg A/V will eventually specify an Ogg video bitstream with
+audio. The mapping may specify that the physical bitstream must begin
+with the initial page of a logical video bitstream, followed by the
+initial page of an audio stream. Unlike initial pages, terminal pages
+for the logical bitstreams need not all occur contiguously (although a
+specific media mapping may require this; it is not mandated by the
+generic Ogg stream spec). Terminal pages may be 'nil' pages,
+that is, pages containing no content but simply a page header with
+position information and the 'last page of bitstream' flag set in the
+page header.<p>
+
+Each grouped bitstream must have a unique serial number within the
+scope of the physical bitstream.<p>
+
+<h3>sequential and concurrent multiplexing</h3>
+
+Groups of concurrently multiplexed bitstreams may be chained
+consecutively. Such a physical bitstream obeys all the rules of both
+grouped and chained multiplexed streams; the groups, when unchained ,
+must stand on their own as a valid concurrently multiplexed
+bitstream.<p>
+
+<h3>multiplexing example</h3>
+
+Below, we present an example of a grouped and chained bitstream:<p>
+
+<img src=stream.png><p>
+
+In this example, we see pages from five total logical bitstreams
+multiplexed into a physical bitstream. Note the following
+characteristics:
+
+<ol><li>Grouped bitstreams begin together; all of the initial pages
+must appear before any data pages. When concurrently multiplexed
+groups are chained, the new group does not begin until all the
+bitstreams in the previous group have terminated.<p>
+
+<li>The pages of concurrently multiplexed bitstreams need not conform
+to a regular order; the only requirement is that page <tt>n</tt> of a
+logical bitstream follow page <tt>n-1</tt> in the physical bitstream.
+There are no restrictions on intervening pages belonging to other
+logical bitstreams. (Tying page appearance to bitrate demands is one
+logical strategy, ie, the page appears at the chronological point
+where decode requires more information).
+
+</ol>
+
+<hr>
+<a href="http://www.xiph.org/">
+<img src="white-xifish.png" align=left border=0>
+</a>
+<font size=-2 color=#505050>
+
+Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
+to protect essential tenets of Internet multimedia from corporate
+hostage-taking; Open Source is the net's greatest tool to keep
+everyone honest. See <a href="http://www.xiph.org/about.html">About
+the Xiph.org Foundation</a> for details.
+<p>
+
+Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
+distribute the Ogg and Vorbis specification, whether in a private,
+public or corporate capacity. However, the Xiph.org Foundation and
+the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
+specification and certify specification compliance.<p>
+
+Xiph.org's Vorbis software CODEC implementation is distributed under a
+BSD-like license. This does not restrict third parties from
+distributing independent implementations of Vorbis software under
+other licenses.<p>
+
+Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
+of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
+pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
+reserved.<p>
+
+</body>
+
+
<h1><font color=#000070>
-Stereo Channel Coupling in the Vorbis CODEC
+Ogg Vorbis stereo-specific channel coupling discussion
</font></h1>
-<em>Last update to this document: July 2, 2002</em><br>
+<em>Last update to this document: July 16, 2002</em><br>
<h2>Abstract</h2> The Vorbis audio CODEC provides a channel coupling
mechanisms designed to reduce effective bitrate by both eliminating
models. This document describes both the mechanical coupling
mechanisms available within the Vorbis specification, as well as the
specific stereo coupling models used by the reference
-<tt>libvorbis</tt> CODEC provided by xiph.org.
-
-<h2>Terminology</h2> Terminology as used in this document is based on
-common terminology associated with contemporary CODECs such as MPEG I
-audio layer 3 (mp3). However, some differences in terminology are
-useful in the context of Vorbis as Vorbis functions somewhat
-differently than most current formats. For clarity, a few terms are
-defined beforehand here, and others will be defined where they first
-appear in context.<p>
-
-<h3>Subjective and Objective</h3>
-
-<em>Objective</em> fidelity is a measure, based on a computable,
-mechanical metric, of how carefully an output matches an input. For
-example, a stereo amplifier may claim to introduce less that .01%
-total harmonic distortion when amplifying an input signal; this claim
-is easy to verify given proper equipment, and any number of testers are
-likely to arrive at the same, exact results. One need not listen to
-the equipment to make this measurement.<p>
-
-However, given two amplifiers with identical, verifiable objective
-specifications, listeners may strongly prefer the sound quality of one
-over the other. This is actually the case in the decades old debate
-[some would say jihad] among audiophiles involving vacuum tube versus
-solid state amplifiers. There are people who can tell the difference,
-and strongly prefer one over the other despite seemingly identical,
-measurable quality. This preference is <em>subjective</em> and
-difficult to measure but nonetheless real.
-
-Individual elements of subjective differences often can be qualified,
-but overall subjective quality generally is not measurable. Different
-observers are likely to disagree on the exact results of a subjective
-test as each observer's perspective differs. When measuring
-subjective qualities, the best one can hope for is average, empirical
-results that show statistical significance across a group.<p>
-
-Perceptual codecs are most concerned with subjective, not objective,
-quality. This is why evaluating a perceptual codec via distortion
-measures and sonograms alone is useless; these objective measures may
-provide insight into the quality or functioning of a codec, but cannot
-answer the much squishier subjective question, "Does it sound
-good?". The tube amplifier example is perhaps not the best as very few
-people can hear, or care to hear, the minute differences between tubes
-and transistors, whereas the subjective differences in perceptual
-codecs tend to be quite large even when objective differences are
-not.<p>
-
-<h3>Fidelity, Artifacts and Differences</h3> Audio <em>artifacts</em>
-and loss of fidelity or more simply put, audio <em>differences</em>
-are not the same thing.<p>
-
-A loss of fidelity implies differences between the perceived input and
-output signal; it does not necessarily imply that the differences in
-output are displeasing or that the output sounds poor (although this
-is often the case). Tube amplifiers are <em>not</em> higher fidelity
-than modern solid state and digital systems. They simply produce a
-form of distortion and coloring that is either unnoticeable or actually
-pleasing to many ears.<p>
-
-As compared to an original signal using hard metrics, all perceptual
-codecs [ASPEC, ATRAC, MP3, WMA, AAC, TwinVQ, AC3 and Vorbis included]
-lose objective fidelity in order to reduce bitrate. This is fact. The
-idea is to lose fidelity in ways that cannot be perceived. However,
-most current streaming applications demand bitrates lower than what
-can be achieved by sacrificing only objective fidelity; this is also
-fact, despite whatever various company press releases might claim.
-Subjective fidelity eventually must suffer in one way or another.<p>
-
-The goal is to choose the best possible tradeoff such that the
-fidelity loss is graceful and not obviously noticeable. Most listeners
-of FM radio do not realize how much lower fidelity that medium is as
-compared to compact discs or DAT. However, when compared directly to
-source material, the difference is obvious. A cassette tape is lower
-fidelity still, and yet the degredation, relatively speaking, is
-graceful and generally easy not to notice. Compare this graceful loss
-of quality to an average 44.1kHz stereo mp3 encoded at 80 or 96kbps.
-The mp3 might actually be higher objective fidelity but subjectively
-sounds much worse.<p>
-
-Thus, when a CODEC <em>must</em> sacrifice subjective quality in order
-to satisfy a user's requirements, the result should be a
-<em>difference</em> that is generally either difficult to notice
-without comparison, or easy to ignore. An <em>artifact</em>, on the
-other hand, is an element introduced into the output that is
-immediately noticeable, obviously foreign, and undesired. The famous
-'underwater' or 'twinkling' effect synonymous with low bitrate (or
-poorly encoded) mp3 is an example of an <em>artifact</em>. This
-working definition differs slightly from common usage, but the coined
-distinction between differences and artifacts is useful for our
-discussion.<p>
-
-The goal, when it is absolutely necessary to sacrifice subjective
-fidelity, is obviously to strive for differences and not artifacts.
-The vast majority of CODECs today fail at this task miserably,
-predictably, and regularly in one way or another. Avoiding such
-failures when it is necessary to sacrifice subjective quality is a
-fundamental design objective of Vorbis and that objective is reflected
-in Vorbis's channel coupling design.<p>
+<tt>libvorbis</tt> codec provided by xiph.org.
<h2>Mechanisms</h2>
with no cross-analysis or redundancy elimination between channels.
This multichannel strategy is very similar to the mp3's <em>dual
stereo</em> mode and Vorbis uses the same name for its analogous
-uncoupled multichannel modes.
+uncoupled multichannel modes.<p>
However, the Vorbis spec provides for, and Vorbis release 1.0 rc1 and
later implement a coupled channel strategy. Vorbis has two specific
mechanisms that may be used alone or in conjunction to implement
channel coupling. The first is <em>channel interleaving</em> via
-residue backend #2, and the second is <em>square polar mapping</em>.
-These two general mechanisms are particularly well suited to coupling
-due to the structure of Vorbis encoding, as we'll explore below, and
-using both we can implement both totally <em>lossless stereo image
-coupling</em> [bit-for-bit decode-identical to uncoupled modes], as
-well as various lossy models that seek to eliminate inaudible or
-unimportant aspects of the stereo image in order to enhance
-bitrate. The exact coupling implementation is generalized to allow the
-encoder a great deal of flexibility in implementation of a stereo
-model without requiring any significant complexity increase over the
-combinatorically simpler mid/side joint stereo of mp3 and other
-current audio codecs.<p>
-
-An encoder may apply channel coupling directly to more than a single
-channel and polar mapping is hierarchical such that polar coupling may be
-extrapolated to an arbitrary number of channels and is not restricted
-to only stereo, quadriphonics, ambisonics or 5.1 surround. However,
-the scope of this document restricts itself to the stereo coupling
-case.<p>
+residue backend type 2, and the second is <em>square polar
+mapping</em>. These two general mechanisms are particularly well
+suited to coupling due to the structure of Vorbis encoding, as we'll
+explore below, and using both we can implement both totally
+<em>lossless stereo image coupling</em> [bit-for-bit decode-identical
+to uncoupled modes], as well as various lossy models that seek to
+eliminate inaudible or unimportant aspects of the stereo image in
+order to enhance bitrate. The exact coupling implementation is
+generalized to allow the encoder a great deal of flexibility in
+implementation of a stereo or surround model without requiring any
+significant complexity increase over the combinatorially simpler
+
mid/side joint stereo of mp3 and other current audio codecs.<p>
+
+A particular Vorbis bitstream may apply channel coupling directly to
+more than a pair of channels; polar mapping is hierarchical such that
+polar coupling may be extrapolated to an arbitrary number of channels
+and is not restricted to only stereo, quadraphonics, ambisonics or 5.1
+surround. However, the scope of this document restricts itself to the
+
stereo coupling case.<p>
<h3>Square Polar Mapping</h3>
<h4>point and diffuse imaging</h4>
The first advantage of a polar representation is that it effectively
-seperates the spatial audio information into a 'point image'
+separates the spatial audio information into a 'point image'
(magnitude) at a given frequency and located somewhere in the sound
field, and a 'diffuse image' (angle) that fills a large amount of
space simultaneously. Even if we preserve only the magnitude (point)
Entropy coding the results, then, further benefits from the entropy
model being able to compress magnitude and angle simultaneously. For
-this reason, Vorbis implements residuebackend #2 which preinterleaves
+this reason, Vorbis implements residue backend #2 which pre-interleaves
a number of input vectors (in the stereo case, two, A and B) into a
single output vector (with the elements in the order of
A_0, B_0, A_1, B_1, A_2 ... A_n-1, B_n-1) before entropy encoding. Thus
Overall, this stereo mode is overkill; however, it offers a safe
alternative to users concerned about the slightest possible
-degr
edation to the stereo image or archival quality audio.<p>
+degr
adation to the stereo image or archival quality audio.<p>
<h3>Phase Stereo</h3>
can be demonstrated that even an average user can tell the difference
between high frequency in-phase and out-of-phase noise. Obviously
then, the statement is not entirely true. However, it's also the case
-that one must resort to nearly such an extreme demostration before
+that one must resort to nearly such an extreme demonstration before
finding the counterexample.<p>
'Phase stereo' is simply a more aggressive quantization of the polar
to the left). This effect is most noticeable at low and mid
frequencies and using headphones (which grant perfect stereo
separation). Point stereo is is a graceful but generally easy to
-detect degrdation to the sound quality and is thus used in frequency
+detect degradation to the sound quality and is thus used in frequency
ranges where it is least noticeable.<p>
<h3>Mixed Stereo</h3>
Vorbis, as of 1.0, uses lossless stereo and a number of mixed modes
constructed out of lossless and point stereo. Phase stereo was used
in the rc2 encoder, but is not currently used for simplicity's sake. It
-will likely be readded to the stereo model in the future.
+will likely be re-added to the stereo model in the future.
<p>
<hr>
<h1><font color=#000070>
-Ogg Vorbis comment field specification
+Ogg Vorbis I format specification: comment field and header specification
</font></h1>
-<em>Last update to this document: July 1
1, 2002</em><p>
+<em>Last update to this document: July 1
6, 2002</em><p>
-<p>The 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 bitream (usually an XML stream type) that provides greater
-structure and machine parseability.</p>
+<h1>Overview</h1>
-<h2>Comment use rationale</h2>
+<p>The Vorbis text comment header is the second (of three) header
+packets that begin a Vorbis bitstream. It is meant for short, text
+comments, not arbitrary metadata; arbitrary metadata belongs in a
+separate logical bitstream (usually an XML stream type) that provides
+greater structure and machine parseability.
-The comment field is meant to be used much like someone jotting a
+<p>The comment field is meant to be used much like someone jotting a
quick note on the bottom of a CDR. It should be a little information to
remember the disc by and explain it to others; a short, to-the-point
text note that need not only be a couple words, but isn't going to be
opening for Moxy Fruvous, 1997"
</blockquote>
+<h1>Comment encoding</h1>
+
+
<h2>Structure</h2>
The comment header logically is a list of eight-bit-clean vectors; the
number of vectors is bounded to 2^32-1 and the length of each vector
is limited to 2^32-1 bytes. The vector length is encoded; the vector
-is not null terminated. In addition to the vector list, there is a
-single vector for vendor name (also 8 bit clean, length encoded in 32
-bits). Libvorbis currently sets the vendor string to "Xiph.Org
-libVorbis I 20020711".<p>
+contents themselves are not null terminated. In addition to the vector
+list, there is a single vector for vendor name (also 8 bit clean,
+length encoded in 32 bits). Libvorbis currently sets the vendor string
+to "Xiph.Org libVorbis I 20020713".<p>
+
+The comment header is decoded as follows:<p>
+
+<pre>
+ 1) [vendor_length] = read an unsigned integer of 32 bits
+ 2) [vendor_string] = read a UTF-8 vector as [vendor_length] octets
+ 3) [user_comment_list_length] = read an unsigned integer of 32 bits
+ 4) iterate [user_comment_list_length] times {
+
+ 5) [length] = read an unsigned integer of 32 bits
+ 6) this iteration's user comment = read a UTF-8 vector as [length] octets
+
+ }
+
+ 7) [framing_bit] = read a single bit as boolean
+ 8) if ( [framing_bit] unset or end of packet ) then ERROR
+ 9) done.
+</pre>
+
+
+<h2>Content vector format</h2>
The comment vectors are structured similarly to a UNIX environment variable.
That is, comment fields consist of a field name and a field value and
<pre>
comment[0]="ARTIST=me";
-comment[1]="TITLE=the sound of vorbis";
+comment[1]="TITLE=the sound of Vorbis";
</pre>
-<h2>Content vector format</h2>
-
<ul>
<li>A case-insensitive field name that may consist of ASCII 0x20 through
0x7D, 0x3D ('=') excluded. ASCII 0x41 through 0x5A inclusive (A-Z) is
<dt>ARTIST<dd>The artist generally considered responsible for the work. In popular music this is usually the performing band or singer. For classical music it would be the composer. For an audio book it would be the author of the original text.
-<dt>PERFORMER<dd>The artist(s) who performed the work. In classical music this would be the conductor, orchestra, soloists. In an audio book it would be the actor who did the reading. In popular music this is typically the same as the ARTIST and is ommitted.
+<dt>PERFORMER<dd>The artist(s) who performed the work. In classical music this would be the conductor, orchestra, soloists. In an audio book it would be the actor who did the reading. In popular music this is typically the same as the ARTIST and is omitted.
-<dt>COPYRIGHT<dd>Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffit'
+<dt>COPYRIGHT<dd>Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'
<dt>LICENSE<dd>License information, eg, 'All Rights Reserved', 'Any
Use Permitted', a URL to a license such as a Creative Commons license
--- /dev/null
+<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
+<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
+<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
+
+
+<h1><font color=#000070>
+Ogg Vorbis: Fidelity measurement and terminology discussion
+</font></h1>
+
+<em>Last update to this document: July 16, 2002</em><p>
+
+Terminology discussed in this document is based on common terminology
+associated with contemporary codecs such as MPEG I audio layer 3
+(mp3). However, some differences in terminology are useful in the
+context of Vorbis as Vorbis functions somewhat differently than most
+current formats. For clarity, then, we describe a common terminology
+for discussion of Vorbis's and other formats' audio quality.<p>
+
+<h2>Subjective and Objective</h2>
+
+<em>Objective</em> fidelity is a measure, based on a computable,
+mechanical metric, of how carefully an output matches an input. For
+example, a stereo amplifier may claim to introduce less that .01%
+total harmonic distortion when amplifying an input signal; this claim
+is easy to verify given proper equipment, and any number of testers are
+likely to arrive at the same, exact results. One need not listen to
+the equipment to make this measurement.<p>
+
+However, given two amplifiers with identical, verifiable objective
+specifications, listeners may strongly prefer the sound quality of one
+over the other. This is actually the case in the decades old debate
+[some would say jihad] among audiophiles involving vacuum tube versus
+solid state amplifiers. There are people who can tell the difference,
+and strongly prefer one over the other despite seemingly identical,
+measurable quality. This preference is <em>subjective</em> and
+difficult to measure but nonetheless real.
+
+Individual elements of subjective differences often can be qualified,
+but overall subjective quality generally is not measurable. Different
+observers are likely to disagree on the exact results of a subjective
+test as each observer's perspective differs. When measuring
+subjective qualities, the best one can hope for is average, empirical
+results that show statistical significance across a group.<p>
+
+Perceptual codecs are most concerned with subjective, not objective,
+quality. This is why evaluating a perceptual codec via distortion
+measures and sonograms alone is useless; these objective measures may
+provide insight into the quality or functioning of a codec, but cannot
+answer the much squishier subjective question, "Does it sound
+good?". The tube amplifier example is perhaps not the best as very few
+people can hear, or care to hear, the minute differences between tubes
+and transistors, whereas the subjective differences in perceptual
+codecs tend to be quite large even when objective differences are
+not.<p>
+
+<h2>Fidelity, Artifacts and Differences</h2> Audio <em>artifacts</em>
+and loss of fidelity or more simply put, audio <em>differences</em>
+are not the same thing.<p>
+
+A loss of fidelity implies differences between the perceived input and
+output signal; it does not necessarily imply that the differences in
+output are displeasing or that the output sounds poor (although this
+is often the case). Tube amplifiers are <em>not</em> higher fidelity
+than modern solid state and digital systems. They simply produce a
+form of distortion and coloring that is either unnoticeable or actually
+pleasing to many ears.<p>
+
+As compared to an original signal using hard metrics, all perceptual
+codecs [ASPEC, ATRAC, MP3, WMA, AAC, TwinVQ, AC3 and Vorbis included]
+lose objective fidelity in order to reduce bitrate. This is fact. The
+idea is to lose fidelity in ways that cannot be perceived. However,
+most current streaming applications demand bitrates lower than what
+can be achieved by sacrificing only objective fidelity; this is also
+fact, despite whatever various company press releases might claim.
+Subjective fidelity eventually must suffer in one way or another.<p>
+
+The goal is to choose the best possible tradeoff such that the
+fidelity loss is graceful and not obviously noticeable. Most listeners
+of FM radio do not realize how much lower fidelity that medium is as
+compared to compact discs or DAT. However, when compared directly to
+source material, the difference is obvious. A cassette tape is lower
+fidelity still, and yet the degradation, relatively speaking, is
+graceful and generally easy not to notice. Compare this graceful loss
+of quality to an average 44.1kHz stereo mp3 encoded at 80 or 96kbps.
+The mp3 might actually be higher objective fidelity but subjectively
+sounds much worse.<p>
+
+Thus, when a CODEC <em>must</em> sacrifice subjective quality in order
+to satisfy a user's requirements, the result should be a
+<em>difference</em> that is generally either difficult to notice
+without comparison, or easy to ignore. An <em>artifact</em>, on the
+other hand, is an element introduced into the output that is
+immediately noticeable, obviously foreign, and undesired. The famous
+'underwater' or 'twinkling' effect synonymous with low bitrate (or
+poorly encoded) mp3 is an example of an <em>artifact</em>. This
+working definition differs slightly from common usage, but the coined
+distinction between differences and artifacts is useful for our
+discussion.<p>
+
+The goal, when it is absolutely necessary to sacrifice subjective
+fidelity, is obviously to strive for differences and not artifacts.
+The vast majority of codecs today fail at this task miserably,
+predictably, and regularly in one way or another. Avoiding such
+failures when it is necessary to sacrifice subjective quality is a
+fundamental design objective of Vorbis and that objective is reflected
+in Vorbis's design and tuning.<p>
+
+<hr>
+<a href="http://www.xiph.org/">
+<img src="white-xifish.png" align=left border=0>
+</a>
+<font size=-2 color=#505050>
+
+Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
+to protect essential tenets of Internet multimedia from corporate
+hostage-taking; Open Source is the net's greatest tool to keep
+everyone honest. See <a href="http://www.xiph.org/about.html">About
+the Xiph.org Foundation</a> for details.
+<p>
+
+Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
+distribute the Ogg and Vorbis specification, whether in a private,
+public or corporate capacity. However, the Xiph.org Foundation and
+the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
+specification and certify specification compliance.<p>
+
+Xiph.org's Vorbis software CODEC implementation is distributed under a
+BSD-like license. This does not restrict third parties from
+distributing independent implementations of Vorbis software under
+other licenses.<p>
+
+Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
+of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
+pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
+reserved.<p>
+</body>
+
+
+
+
+
+
--- /dev/null
+<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
+<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
+<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
+
+<h1><font color=#000070>
+Ogg Vorbis I format specification: floor type 0 setup and decode
+</font></h1>
+
+<em>Last update to this document: July 16, 2002</em><br>
+
+<h1>Overview</h1>
+
+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 responce of the LSP
+filter. This representation is equivalent to a traditional all-pole
+infinite impulse response filter as would be used in linear predictive
+coding; LSP representation may be converted to LPC representation and
+vice-versa.<p>
+
+<h1>Floor 0 format</h1>
+
+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. <p>
+
+<h2>header decode</h2>
+
+Configuration information for instances of floor zero decodes from the
+codec setup header (third packet). configuration decode proceeds as
+follows:<p>
+
+<pre>
+ 1) [floor0_order] = read an unsigned integer of 8 bits
+ 2) [floor0_rate] = read an unsigned integer of 16 bits
+ 3) [floor0_bark_map_size] = read an unsigned integer of 16 bits
+ 4) [floor0_amplitude_bits] = read an unsigned integer of six bits
+ 5) [floor0_amplitude_offset] = read an unsigned integer of eight bits
+ 6) [floor0_number_of_books] = read an unsigned integer of four bits and add 1
+ 7) if any of [floor0_order], [floor0_rate], [floor0_bark_map_size], [floor0_amplitude_bits],
+ [floor0_amplitude_offset] or [floor0_number_of_books] are less than zero, the stream is not decodable
+ 8) array [floor0_book_list] = read a list of [floor0_number_of_books] unsigned integers of eight bits each;
+</pre>
+
+An end-of-packet condition during any of these bitstream reads renders
+this stream undecodable. In addition, any element of the array
+<tt>[floor0_book_list]</tt> that is greater than the maximum codebook
+number for this bitstream is an error condition that also renders the
+stream undecodable.
+
+<h2>packet decode</h2>
+
+Extracting a floor0 curve from an audio packet consists of first
+decoding the curve amplitude and <tt>[floor0_order]</tt> LSP
+coefficient values from the bitstream, and then comupting the floor
+curve, which is defined as the frequency response of the decoded LSP
+filter.<p>
+
+Packet decode proceeeds as follows:<p>
+<pre>
+ 1) [amplitude] = read an unsigned integer of [floor0_amplitude_bits] bits
+ 2) [coefficients] is an empty, zero length vector
+ 3) if ( [amplitude] is greater than zero ) {
+
+ 4) [booknumber] = read an unsigned integer of <a href="helper.html#ilog">ilog</a>( [floor0_number_of_books] ) bits
+ 5) if ( [booknumber] is greater than the highest number decode codebook ) then packet is undecodable
+ 6) [lastval] = zero;
+ 7) vector [temp_vector] = read vector from bistream using codebook number [booknumber] in VQ context.
+ 8) add the scalar value [last] to each scalar in vector [temp_vector]
+ 9) [last] = the value of the last scalar in vector [temp_vector]
+ 10) concatenate [temp_vector] onto the end of the [coefficients] vector
+ 11) if (length of vector [coefficients] is less than [floor0_order], continue at step 6
+
+ }
+
+ 12) done.
+
+</pre>
+
+Take note of the following properties of decode:
+<ul>
+<li>The book number used for decode
+can, in fact, be stored in the bitstream in <a
+href="helper.html#ilog">ilog</a>( <tt>[floor0_number_of_books]</tt> -
+1 ) bits. Nevertheless, the above specification is correct and values
+greater than the maximum possible book value are reserved. <p>
+
+<li>The number of scalars read into the vector <tt>[coefficients]</tt>
+may be greater than <tt>[floor0_order]</tt>, the number actually
+required for curve computation. For example, if the VQ codebook used
+for the floor currently being decoded has a
+<tt>[codebook_dimensions]</tt> value of three and
+<tt>[floor0_order]</tt> is ten, the only way to fill all the needed
+scalars in <tt>[coefficients]</tt> is to to read a total of twelve
+scalars as four vectors of three scalars each. This is not an error
+condition, and care must be taken not to allow a buffer overflow in
+decode. The extra values are not used and may be ignored or discarded.
+</ul>
+
+<h2>curve computation</h2>
+
+Given an <tt>[amplitude]</tt> integer and <tt>[coefficients]</tt>
+vector from packet decode as well as the [floor0_order],
+[floor0_rate], [floor0_bark_map_size], [floor0_amplitude_bits] and
+[floor0_amplitude_offset] values from floor setup, and an output
+vector size <tt>[n]</tt> specified by the decode process, we compute a
+floor output vector.<p>
+
+If the value <tt>[amplitude]</tt> is zero, the return value is a
+length <tt>[n]</tt> vector with all-zero scalars. Otherwise, begin by
+assuming the following definitions for the given vector to be
+synthesized:<p>
+
+<img src="lspmap.png"><p>
+
+The above is used to synthesize the LSP curve on a Bark-scale fequency
+axis, then map the result to a linear-scale frequency axis.
+Similarly, the below calculation synthesizes the output LSP curve [output] on a log
+(dB) amplitude scale, mapping it to linear amplitude in the last step:<p>
+
+<pre>
+ 1) [i] = 0
+ 2) if ( [floor0_order] is odd ) {
+
+ 3) calculate [p] and [q] according to: <br>
+ <img src="oddlsp.png">
+
+ } else [floor0_order] is even {
+
+ 4) calculate [p] and [q] according to: <br>
+ <img src="evenlsp.png">
+
+ }
+
+ 5) calculate [linear_floor_value] according to:<br>
+ <img src="floorval.png">
+
+ 6) [iteration_condition] = map element [i]
+ 7) [output] element [i] = [linear_floor_value]
+ 8) increment [i]
+ 9) if ( map element [i] is equal to [iteration_condition] ) continue at step 7
+ 10) if ( [i] is less than [n] ) continue at step 2
+ 11) done
+
+</pre>
+
+<hr>
+<a href="http://www.xiph.org/">
+<img src="white-xifish.png" align=left border=0>
+</a>
+<font size=-2 color=#505050>
+
+Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
+to protect essential tenets of Internet multimedia from corporate
+hostage-taking; Open Source is the net's greatest tool to keep
+everyone honest. See <a href="http://www.xiph.org/about.html">About
+the Xiph.org Foundation</a> for details.
+<p>
+
+Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
+distribute the Ogg and Vorbis specification, whether in a private,
+public or corporate capacity. However, the Xiph.org Foundation and
+the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
+specification and certify specification compliance.<p>
+
+Xiph.org's Vorbis software CODEC implementation is distributed under a
+BSD-like license. This does not restrict third parties from
+distributing independent implementations of Vorbis software under
+other licenses.<p>
+
+Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
+of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
+pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
+reserved.<p>
+
+</body>
+
<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
<h1><font color=#000070>
-Ogg Vorbis I format specification: high-level description
+Ogg Vorbis I format specification: introduction and description
</font></h1>
<em>Last update to this document: July 13, 2002</em><br>
projects / platform / upstream / libvorbis.git / commitdiff
