gosu 0.7.16 → 0.7.17

data/dependencies/libvorbis/doc/vorbis-clip.txt

@@ -1,139 +0,0 @@
-Topic:
-
-Sample granularity editing of a Vorbis file; inferred arbitrary sample
-length starting offsets / PCM stream lengths
-
-Overview:
-
-Vorbis, like mp3, is a frame-based* audio compression where audio is
-broken up into discrete short time segments.  These segments are
-'atomic' that is, one must recover the entire short time segment from
-the frame packet; there's no way to recover only a part of the PCM time
-segment from part of the coded packet without expanding the entire
-packet and then discarding a portion of the resulting PCM audio.
-
-* In mp3, the data segment representing a given time period is called
-  a 'frame'; the roughly equivalent Vorbis construct is a 'packet'.
-
-Thus, when we edit a Vorbis stream, the finest physical editing
-granularity is on these packet boundaries (the mp3 case is
-actually somewhat more complex and mp3 editing is more complicated
-than just snipping on a frame boundary because time data can be spread
-backward or forward over frames.  In Vorbis, packets are all
-stand-alone).  Thus, at the physical packet level, Vorbis is still
-limited to streams that contain an integral number of packets.
-
-However, Vorbis streams may still exactly represent and be edited to a
-PCM stream of arbitrary length and starting offset without padding the
-beginning or end of the decoded stream or requiring that the desired
-edit points be packet aligned.  Vorbis makes use of Ogg stream
-framing, and this framing provides time-stamping data, called a
-'granule position'; our starting offset and finished stream length may
-be inferred from correct usage of the granule position data.
-
-Time stamping mechanism:
-
-Vorbis packets are bundled into into Ogg pages (note that pages do not
-necessarily contain integral numbers of packets, but that isn't
-inportant in this discussion.  More about Ogg framing can be found in
-ogg/doc/framing.html).  Each page that contains a packet boundary is
-stamped with the absolute sample-granularity offset of the data, that
-is, 'complete samples-to-date' up to the last completed packet of that
-page. (The same mechanism is used for eg, video, where the number
-represents complete 2-D frames, and so on).
-
-(It's possible but rare for a packet to span more than two pages such
-that page[s] in the middle have no packet boundary; these packets have
-a granule position of '-1'.)
-
-This granule position mechaism in Ogg is used by Vorbis to indicate when the
-PCM data intended to be represented in a Vorbis segment begins a
-number of samples into the data represented by the first packet[s]
-and/or ends before the physical PCM data represented in the last
-packet[s].
-
-File length a non-integral number of frames:
-
-A file to be encoded in Vorbis will probably not encode into an
-integral number of packets; such a file is encoded with the last
-packet containing 'extra'* samples. These samples are not padding; they
-will be discarded in decode. 
-
-*(For best results, the encoder should use extra samples that preserve
-the character of the last frame.  Simply setting them to zero will
-introduce a 'cliff' that's hard to encode, resulting in spread-frame
-noise.  Libvorbis extrapolates the last frame past the end of data to
-produce the extra samples.  Even simply duplicating the last value is
-better than clamping the signal to zero).
-
-The encoder indicates to the decoder that the file is actually shorter
-than all of the samples ('original' + 'extra') by setting the granule
-position in the last page to a short value, that is, the last
-timestamp is the original length of the file discarding extra samples.
-The decoder will see that the number of samples it has decoded in the
-last page is too many; it is 'original' + 'extra', where the
-granulepos says that through the last packet we only have 'original'
-number of samples.  The decoder then ignores the 'extra' samples.
-This behavior is to occur only when the end-of-stream bit is set in
-the page (indicating last page of the logical stream).
- 
-Note that it not legal for the granule position of the last page to
-indicate that there are more samples in the file than actually exist,
-however, implementations should handle such an illegal file gracefully
-in the interests of robust programming.
-
-Beginning point not on integral packet boundary:
-
-It is possible that we will the PCM data represented by a Vorbis
-stream to begin at a position later than where the decoded PCM data
-really begins after an integral packet boundary, a situation analagous
-to the above description where the PCM data does not end at an
-integral packet boundary.  The easiest example is taking a clip out of
-a larger Vorbis stream, and choosing a beginning point of the clip
-that is not on a packet boundary; we need to ignore a few samples to
-get the desired beginning point.
-
-The process of marking the desired beginning point is similar to
-marking an arbitrary ending point. If the encoder wishes sample zero
-to be some location past the actual beginning of data, it associates a
-'short' granule position value with the completion of the second*
-audio packet.  The granule position is associated with the second
-packet simply by making sure the second packet completes its page.
-
-*(We associate the short value with the second packet for two reasons.
- a) The first packet only primes the overlap/add buffer.  No data is
- returned before decoding the second packet; this places the decision
- information at the point of decision.  b) Placing the short value on
- the first packet would make the value negative (as the first packet
- normally represents position zero); a negative value would break the
- requirement that granule positions increase; the headers have
- position values of zero)
-
-The decoder sees that on the first page that will return
-data from the overlap/add queue, we have more samples than the granule
-position accounts for, and discards the 'surplus' from the beginning
-of the queue.
-
-Note that short granule values (indicating less than the actually
-returned about of data) are not legal in the Vorbis spec outside of
-indicating beginning and ending sample positions.  However, decoders
-should, at minimum, tolerate inadvertant short values elsewhere in the
-stream (just as they should tolerate out-of-order/non-increasing
-granulepos values, although this too is illegal).
-
-Beginning point at arbitrary positive timestamp (no 'zero' sample):
-
-It's also possible that the granule position of the first page of an
-audio stream is a 'long value', that is, a value larger than the
-amount of PCM audio decoded.  This implies only that we are starting
-playback at some point into the logical stream, a potentially common
-occurence in streaming applications where the decoder may be
-connecting into a live stream.  The decoder should not treat the long
-value specially.
-
-A long value elsewhere in the stream would normally occur only when a
-page is lost or out of sequence, as indicated by the page's sequence
-number.  A long value under any other situation is not legal, however
-a decoder should tolerate both possibilities.
-
-

data/dependencies/libvorbis/doc/vorbis-errors.txt

@@ -1,103 +0,0 @@
-Error return codes possible from libvorbis and libvorbisfile:
-
-All 'failure' style returns are <0; this either indicates a generic
-'false' value (eg, ready?  T or F) or an error condition.  Code can
-safely just test for < 0, or look at the specific return code for more
-detail.
-
-*** Return codes:
-
-OV_FALSE        The call returned a 'false' status (eg, ov_bitrate_instant 
-		can return OV_FALSE if playback is not in progress, and thus 
-		there is no instantaneous bitrate information to report.
-
-OV_HOLE		libvorbis/libvorbisfile is alerting the application that 
-		there was an interruption in the data (one of: garbage 
-		between pages, loss of sync followed by recapture, or a 
-		corrupt page)
-
-OV_EREAD        A read from media returned an error.
-
-OV_EFAULT       Internal logic fault; indicates a bug or heap/stack 
-		corruption.
-
-OV_EIMPL        The bitstream makes use of a feature not implemented in this 
-		library version.
-
-OV_EINVAL       Invalid argument value.
-
-OV_ENOTVORBIS	Bitstream/page/packet is not Vorbis data.
-
-OV_EBADHEADER   Invalid Vorbis bitstream header.
-
-OV_EVERSION	Vorbis version mismatch.
-
-OV_ENOTAUDIO	Packet data submitted to vorbis_synthesis is not audio data.
-
-OV_EBADPACKET	Invalid packet submitted to vorbis_synthesis.
-
-OV_EBADLINK	Invalid stream section supplied to libvorbis/libvorbisfile, 
-		or the requested link is corrupt. 
-
-OV_ENOSEEK	Bitstream is not seekable.
-
-
-****************************************************************
-*** Libvorbis functions that can return failure/error codes:
-
-int vorbis_analysis_headerout()
-    OV_EIMPL
-
-int vorbis_analysis_wrote()
-    OV_EINVAL
-
-int vorbis_synthesis_headerin()
-    OV_ENOTVORBIS, OV_EVERSION, OV_EBADHEADER
-
-int vorbis_synthesis()
-    OV_ENOTAUDIO, OV_EBADPACKET
-
-int vorbis_synthesis_read()
-    OV_EINVAL
-
-****************************************************************
-*** Libvorbisfile functions that can return failure/error codes:
-
-int ov_open_callbacks()   
-    OV_EREAD, OV_ENOTVORBIS, OV_EVERSION, OV_EBADHEADER, OV_FAULT
-
-int ov_open()
-    OV_EREAD, OV_ENOTVORBIS, OV_EVERSION, OV_EBADHEADER, OV_FAULT
-
-long ov_bitrate()
-    OV_EINVAL, OV_FALSE
-
-long ov_bitrate_instant()
-    OV_FALSE
-
-ogg_int64_t ov_raw_total()
-    OV_EINVAL
-
-ogg_int64_t ov_pcm_total()
-    OV_EINVAL
-
-double ov_time_total()
-    OV_EINVAL
-
-int ov_raw_seek()
-    OV_ENOSEEK, OV_EINVAL, OV_BADLINK
-
-int ov_pcm_seek_page()
-    OV_ENOSEEK, OV_EINVAL, OV_EREAD, OV_BADLINK, OV_FAULT
-
-int ov_pcm_seek()
-    OV_ENOSEEK, OV_EINVAL, OV_EREAD, OV_BADLINK, OV_FAULT
-
-int ov_time_seek()
-    OV_ENOSEEK, OV_EINVAL, OV_EREAD, OV_BADLINK, OV_FAULT
-
-int ov_time_seek_page()
-    OV_ENOSEEK, OV_EINVAL, OV_EREAD, OV_BADLINK, OV_FAULT
-
-long ov_read()
-    OV_HOLE, OV_EBADLINK

data/dependencies/libvorbis/doc/vorbis-fidelity.html

@@ -1,180 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html>
-<head>
-
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
-<title>Ogg Vorbis Documentation</title>
-
-<style type="text/css">
-body {
-  margin: 0 18px 0 18px;
-  padding-bottom: 30px;
-  font-family: Verdana, Arial, Helvetica, sans-serif;
-  color: #333333;
-  font-size: .8em;
-}
-
-a {
-  color: #3366cc;
-}
-
-img {
-  border: 0;
-}
-
-#xiphlogo {
-  margin: 30px 0 16px 0;
-}
-
-#content p {
-  line-height: 1.4;
-}
-
-h1, h1 a, h2, h2 a, h3, h3 a {
-  font-weight: bold;
-  color: #ff9900;
-  margin: 1.3em 0 8px 0;
-}
-
-h1 {
-  font-size: 1.3em;
-}
-
-h2 {
-  font-size: 1.2em;
-}
-
-h3 {
-  font-size: 1.1em;
-}
-
-li {
-  line-height: 1.4;
-}
-
-#copyright {
-  margin-top: 30px;
-  line-height: 1.5em;
-  text-align: center;
-  font-size: .8em;
-  color: #888888;
-  clear: both;
-}
-</style>
-
-</head>
-
-<body>
-
-<div id="xiphlogo">
-  <a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
-</div>
-
-<h1>Ogg Vorbis: Fidelity measurement and terminology discussion</h1>
-
-<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>
-
-<p><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>
-
-<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.</p>
-
-<p>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>
-
-<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>
-
-<p>Audio <em>artifacts</em> and loss of fidelity or more simply
-put, audio <em>differences</em> are not the same thing.</p>
-
-<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>
-
-<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>
-
-<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>
-
-<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>
-
-<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>
-
-<div id="copyright">
-  The Xiph Fish Logo is a
-  trademark (&trade;) of Xiph.Org.<br/>
-
-  These pages &copy; 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>

data/dependencies/libvorbis/doc/vorbis.html

@@ -1,234 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html>
-<head>
-
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
-<title>Ogg Vorbis Documentation</title>
-
-<style type="text/css">
-body {
-  margin: 0 18px 0 18px;
-  padding-bottom: 30px;
-  font-family: Verdana, Arial, Helvetica, sans-serif;
-  color: #333333;
-  font-size: .8em;
-}
-
-a {
-  color: #3366cc;
-}
-
-img {
-  border: 0;
-}
-
-#xiphlogo {
-  margin: 30px 0 16px 0;
-}
-
-#content p {
-  line-height: 1.4;
-}
-
-h1, h1 a, h2, h2 a, h3, h3 a {
-  font-weight: bold;
-  color: #ff9900;
-  margin: 1.3em 0 8px 0;
-}
-
-h1 {
-  font-size: 1.3em;
-}
-
-h2 {
-  font-size: 1.2em;
-}
-
-h3 {
-  font-size: 1.1em;
-}
-
-li {
-  line-height: 1.4;
-}
-
-#copyright {
-  margin-top: 30px;
-  line-height: 1.5em;
-  text-align: center;
-  font-size: .8em;
-  color: #888888;
-  clear: both;
-}
-</style>
-
-</head>
-
-<body>
-
-<div id="xiphlogo">
-  <a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
-</div>
-
-<h1>Ogg Vorbis encoding format documentation</h1>
-
-<p><img src="wait.png" alt="wait"/>As of writing, not all the below document
-links are live. They will be populated as we complete the documents.</p>
-
-<h2>Documents</h2>
-
-<ul>
-<li><a href="packet.html">Vorbis packet structure</a></li>
-<li><a href="envelope.html">Temporal envelope shaping and blocksize</a></li>
-<li><a href="mdct.html">Time domain segmentation and MDCT transform</a></li>
-<li><a href="resolution.html">The resolution floor</a></li>
-<li><a href="residuals.html">MDCT-domain fine structure</a></li>
-</ul>
-
-<ul>
-<li><a href="probmodel.html">The Vorbis probability model</a></li>
-<li><a href="bitpack.html">The Vorbis bitpacker</a></li>
-</ul>
-
-<ul>
-<li><a href="oggstream.html">Ogg bitstream overview</a></li>
-<li><a href="framing.html">Ogg logical bitstream and framing spec</a></li>
-<li><a href="vorbis-stream.html">Vorbis packet->Ogg bitstream mapping</a></li>
-</ul>
-
-<ul>
-<li><a href="programming.html">Programming with libvorbis</a></li>
-</ul>
-
-<h2>Description</h2>
-
-<p>Ogg Vorbis is a general purpose compressed audio format
-for high quality (44.1-48.0kHz, 16+ bit, polyphonic) audio and music
-at moderate fixed and variable bitrates (40-80 kb/s/channel). This
-places Vorbis in the same class as audio representations including
-MPEG-1 audio layer 3, MPEG-4 audio (AAC and TwinVQ), and PAC.</p>
-
-<p>Vorbis is the first of a planned family of Ogg multimedia coding
-formats being developed as part of the Xiph.org Foundation's Ogg multimedia
-project. See <a href="http://www.xiph.org/">http://www.xiph.org/</a>
-for more information.</p>
-
-<h2>Vorbis technical documents</h2>
-
-<p>A Vorbis encoder takes in overlapping (but contiguous) short-time
-segments of audio data. The encoder analyzes the content of the audio
-to determine an optimal compact representation; this phase of encoding
-is known as <em>analysis</em>. For each short-time block of sound,
-the encoder then packs an efficient representation of the signal, as
-determined by analysis, into a raw packet much smaller than the size
-required by the original signal; this phase is <em>coding</em>.
-Lastly, in a streaming environment, the raw packets are then
-structured into a continuous stream of octets; this last phase is
-<em>streaming</em>. Note that the stream of octets is referred to both
-as a 'byte-' and 'bit-'stream; the latter usage is acceptible as the
-stream of octets is a physical representation of a true logical
-bit-by-bit stream.</p>
-
-<p>A Vorbis decoder performs a mirror image process of extracting the
-original sequence of raw packets from an Ogg stream (<em>stream
-decomposition</em>), reconstructing the signal representation from the
-raw data in the packet (<em>decoding</em>) and them reconstituting an
-audio signal from the decoded representation (<em>synthesis</em>).</p>
-
-<p>The <a href="programming.html">Programming with libvorbis</a>
-documents discuss use of the reference Vorbis codec library
-(libvorbis) produced by the Xiph.org Foundation.</p>
-
-<p>The data representations and algorithms necessary at each step to
-encode and decode Ogg Vorbis bitstreams are described by the below
-documents in sufficient detail to construct a complete Vorbis codec.
-Note that at the time of writing, Vorbis is still in a 'Request For
-Comments' stage of development; despite being in advanced stages of
-development, input from the multimedia community is welcome.</p>
-
-<h3>Vorbis analysis and synthesis</h3>
-
-<p>Analysis begins by seperating an input audio stream into individual,
-overlapping short-time segments of audio data. These segments are
-then transformed into an alternate representation, seeking to
-represent the original signal in a more efficient form that codes into
-a smaller number of bytes. The analysis and transformation stage is
-the most complex element of producing a Vorbis bitstream.</p>
-
-<p>The corresponding synthesis step in the decoder is simpler; there is
-no analysis to perform, merely a mechanical, deterministic
-reconstruction of the original audio data from the transform-domain
-representation.</p>
-
-<ul>
-<li><a href="packet.html">Vorbis packet structure</a>:
-Describes the basic analysis components necessary to produce Vorbis
-packets and the structure of the packet itself.</li>
-<li><a href="envelope.html">Temporal envelope shaping and blocksize</a>:
-Use of temporal envelope shaping and variable blocksize to minimize
-time-domain energy leakage during wide dynamic range and spectral energy
-swings. Also discusses time-related principles of psychoacoustics.</li>
-<li><a href="mdct.html">Time domain segmentation and MDCT transform</a>:
-Division of time domain data into individual overlapped, windowed
-short-time vectors and transformation using the MDCT</li>
-<li><a href="resolution.html">The resolution floor</a>: Use of frequency
-doamin psychoacoustics, and the MDCT-domain noise, masking and resolution
-floors</li>
-<li><a href="residuals.html">MDCT-domain fine structure</a>: Production,
-quantization and massaging of MDCT-spectrum fine structure</li>
-</ul>
-
-<h3>Vorbis coding and decoding</h3>
-
-<p>Coding and decoding converts the transform-domain representation of
-the original audio produced by analysis to and from a bitwise packed
-raw data packet. Coding and decoding consist of two logically
-orthogonal concepts, <em>back-end coding</em> and <em>bitpacking</em>.</p>
-
-<p><em>Back-end coding</em> uses a probability model to represent the raw numbers
-of the audio representation in as few physical bits as possible;
-familiar examples of back-end coding include Huffman coding and Vector
-Quantization.</p>
-
-<p><em>Bitpacking</em> arranges the variable sized words of the back-end
-coding into a vector of octets without wasting space. The octets
-produced by coding a single short-time audio segment is one raw Vorbis
-packet.</p>
-
-<ul>
-<li><a href="probmodel.html">The Vorbis probability model</a></li>
-<li><a href="bitpack.html">The Vorbis bitpacker</a>: Arrangement of 
-variable bit-length words into an octet-aligned packet.</li>
-</ul>
-
-<h3>Vorbis streaming and stream decomposition</h3>
-
-<p>Vorbis packets contain the raw, bitwise-compressed representation of a
-snippet of audio. These packets contain no structure and cannot be
-strung together directly into a stream; for streamed transmission and
-storage, Vorbis packets are encoded into an Ogg bitstream.</p>
-
-<ul>
-<li><a href="oggstream.html">Ogg bitstream overview</a>: High-level
-description of Ogg logical bitstreams, how logical bitstreams
-(of mixed media types) can be combined into physical bitstreams, and
-restrictions on logical-to-physical mapping. Note that this document is
-not specific only to Ogg Vorbis.</li>
-<li><a href="framing.html">Ogg logical bitstream and framing
-spec</a>: Low level, complete specification of Ogg logical
-bitstream pages. Note that this document is not specific only to Ogg
-Vorbis.</li>
-<li><a href="vorbis-stream.html">Vorbis bitstream mapping</a>:
-Specifically describes mapping Vorbis data into an
-Ogg physical bitstream.</li>
-</ul>
-
-<div id="copyright">
-  The Xiph Fish Logo is a
-  trademark (&trade;) of Xiph.Org.<br/>
-
-  These pages &copy; 1994 - 2005 Xiph.Org. All rights reserved.
-</div>
-
-</body>
-</html>