RubyGems - gstreamer - Versions diffs - 1.1.0-x86-mingw32 - Mend

gstreamer 1.1.0-x86-mingw32

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1897) hide show

data/vendor/local/share/doc/libvorbis-1.3.2/squarepolar.png ADDED Viewed

Binary file

data/vendor/local/share/doc/libvorbis-1.3.2/stereo.html ADDED Viewed

@@ -0,0 +1,419 @@
+<!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, h4, h4 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 stereo-specific channel coupling discussion</h1>
+<h2>Abstract</h2>
+<p>The Vorbis audio CODEC provides a channel coupling
+mechanisms designed to reduce effective bitrate by both eliminating
+interchannel redundancy and eliminating stereo image information
+labeled inaudible or undesirable according to spatial psychoacoustic
+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.</p>
+<h2>Mechanisms</h2>
+<p>In encoder release beta 4 and earlier, Vorbis supported multiple
+channel encoding, but the channels were encoded entirely separately
+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.</p>
+<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 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>
+<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>
+<a name="sqpm"></a>
+<h3>Square Polar Mapping</h3>
+<h4>maximal correlation</h4>
+<p>Recall that the basic structure of a a Vorbis I stream first generates
+from input audio a spectral 'floor' function that serves as an
+MDCT-domain whitening filter. This floor is meant to represent the
+rough envelope of the frequency spectrum, using whatever metric the
+encoder cares to define. This floor is subtracted from the log
+frequency spectrum, effectively normalizing the spectrum by frequency.
+Each input channel is associated with a unique floor function.</p>
+<p>The basic idea behind any stereo coupling is that the left and right
+channels usually correlate. This correlation is even stronger if one
+first accounts for energy differences in any given frequency band
+across left and right; think for example of individual instruments
+mixed into different portions of the stereo image, or a stereo
+recording with a dominant feature not perfectly in the center. The
+floor functions, each specific to a channel, provide the perfect means
+of normalizing left and right energies across the spectrum to maximize
+correlation before coupling. This feature of the Vorbis format is not
+a convenient accident.</p>
+<p>Because we strive to maximally correlate the left and right channels
+and generally succeed in doing so, left and right residue is typically
+nearly identical. We could use channel interleaving (discussed below)
+alone to efficiently remove the redundancy between the left and right
+channels as a side effect of entropy encoding, but a polar
+representation gives benefits when left/right correlation is
+strong.</p>
+<h4>point and diffuse imaging</h4>
+<p>The first advantage of a polar representation is that it effectively
+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)
+data, a detailed and carefully chosen floor function in each channel
+provides us with a free, fine-grained, frequency relative intensity
+stereo*. Angle information represents diffuse sound fields, such as
+reverberation that fills the entire space simultaneously.</p>
+<p>*<em>Because the Vorbis model supports a number of different possible
+stereo models and these models may be mixed, we do not use the term
+'intensity stereo' talking about Vorbis; instead we use the terms
+'point stereo', 'phase stereo' and subcategories of each.</em></p>
+<p>The majority of a stereo image is representable by polar magnitude
+alone, as strong sounds tend to be produced at near-point sources;
+even non-diffuse, fast, sharp echoes track very accurately using
+magnitude representation almost alone (for those experimenting with
+Vorbis tuning, this strategy works much better with the precise,
+piecewise control of floor 1; the continuous approximation of floor 0
+results in unstable imaging). Reverberation and diffuse sounds tend
+to contain less energy and be psychoacoustically dominated by the
+point sources embedded in them. Thus, we again tend to concentrate
+more represented energy into a predictably smaller number of numbers.
+Separating representation of point and diffuse imaging also allows us
+to model and manipulate point and diffuse qualities separately.</p>
+<h4>controlling bit leakage and symbol crosstalk</h4>
+<p>Because polar
+representation concentrates represented energy into fewer large
+values, we reduce bit 'leakage' during cascading (multistage VQ
+encoding) as a secondary benefit. A single large, monolithic VQ
+codebook is more efficient than a cascaded book due to entropy
+'crosstalk' among symbols between different stages of a multistage cascade.
+Polar representation is a way of further concentrating entropy into
+predictable locations so that codebook design can take steps to
+improve multistage codebook efficiency. It also allows us to cascade
+various elements of the stereo image independently.</p>
+<h4>eliminating trigonometry and rounding</h4>
+<p>Rounding and computational complexity are potential problems with a
+polar representation. As our encoding process involves quantization,
+mixing a polar representation and quantization makes it potentially
+impossible, depending on implementation, to construct a coupled stereo
+mechanism that results in bit-identical decompressed output compared
+to an uncoupled encoding should the encoder desire it.</p>
+<p>Vorbis uses a mapping that preserves the most useful qualities of
+polar representation, relies only on addition/subtraction (during
+decode; high quality encoding still requires some trig), and makes it
+trivial before or after quantization to represent an angle/magnitude
+through a one-to-one mapping from possible left/right value
+permutations. We do this by basing our polar representation on the
+unit square rather than the unit-circle.</p>
+<p>Given a magnitude and angle, we recover left and right using the
+following function (note that A/B may be left/right or right/left
+depending on the coupling definition used by the encoder):</p>
+<pre>
+      if(magnitude>0)
+        if(angle>0){
+          A=magnitude;
+          B=magnitude-angle;
+        }else{
+          B=magnitude;
+          A=magnitude+angle;
+        }
+      else
+        if(angle>0){
+          A=magnitude;
+          B=magnitude+angle;
+        }else{
+          B=magnitude;
+          A=magnitude-angle;
+        }
+    }
+</pre>
+<p>The function is antisymmetric for positive and negative magnitudes in
+order to eliminate a redundant value when quantizing. For example, if
+we're quantizing to integer values, we can visualize a magnitude of 5
+and an angle of -2 as follows:</p>
+<p><img src="squarepolar.png" alt="square polar"/></p>
+<p>This representation loses or replicates no values; if the range of A
+and B are integral -5 through 5, the number of possible Cartesian
+permutations is 121. Represented in square polar notation, the
+possible values are:</p>
+<pre>
+ 0, 0
+-1,-2  -1,-1  -1, 0  -1, 1
+ 1,-2   1,-1   1, 0   1, 1
+-2,-4  -2,-3  -2,-2  -2,-1  -2, 0  -2, 1  -2, 2  -2, 3
+ 2,-4   2,-3   ... following the pattern ...
+ ...   5, 1   5, 2   5, 3   5, 4   5, 5   5, 6   5, 7   5, 8   5, 9
+</pre>
+<p>...for a grand total of 121 possible values, the same number as in
+Cartesian representation (note that, for example, <tt>5,-10</tt> is
+the same as <tt>-5,10</tt>, so there's no reason to represent
+both. 2,10 cannot happen, and there's no reason to account for it.)
+It's also obvious that this mapping is exactly reversible.</p>
+<h3>Channel interleaving</h3>
+<p>We can remap and A/B vector using polar mapping into a magnitude/angle
+vector, and it's clear that, in general, this concentrates energy in
+the magnitude vector and reduces the amount of information to encode
+in the angle vector. Encoding these vectors independently with
+residue backend #0 or residue backend #1 will result in bitrate
+savings. However, there are still implicit correlations between the
+magnitude and angle vectors. The most obvious is that the amplitude
+of the angle is bounded by its corresponding magnitude value.</p>
+<p>Entropy coding the results, then, further benefits from the entropy
+model being able to compress magnitude and angle simultaneously. For
+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
+each vector to be coded by the vector quantization backend consists of
+matching magnitude and angle values.</p>
+<p>The astute reader, at this point, will notice that in the theoretical
+case in which we can use monolithic codebooks of arbitrarily large
+size, we can directly interleave and encode left and right without
+polar mapping; in fact, the polar mapping does not appear to lend any
+benefit whatsoever to the efficiency of the entropy coding. In fact,
+it is perfectly possible and reasonable to build a Vorbis encoder that
+dispenses with polar mapping entirely and merely interleaves the
+channel. Libvorbis based encoders may configure such an encoding and
+it will work as intended.</p>
+<p>However, when we leave the ideal/theoretical domain, we notice that
+polar mapping does give additional practical benefits, as discussed in
+the above section on polar mapping and summarized again here:</p>
+<ul>
+<li>Polar mapping aids in controlling entropy 'leakage' between stages
+of a cascaded codebook.</li>
+<li>Polar mapping separates the stereo image
+into point and diffuse components which may be analyzed and handled
+differently.</li>
+</ul>
+<h2>Stereo Models</h2>
+<h3>Dual Stereo</h3>
+<p>Dual stereo refers to stereo encoding where the channels are entirely
+separate; they are analyzed and encoded as entirely distinct entities.
+This terminology is familiar from mp3.</p>
+<h3>Lossless Stereo</h3>
+<p>Using polar mapping and/or channel interleaving, it's possible to
+couple Vorbis channels losslessly, that is, construct a stereo
+coupling encoding that both saves space but also decodes
+bit-identically to dual stereo. OggEnc 1.0 and later uses this
+mode in all high-bitrate encoding.</p>
+<p>Overall, this stereo mode is overkill; however, it offers a safe
+alternative to users concerned about the slightest possible
+degradation to the stereo image or archival quality audio.</p>
+<h3>Phase Stereo</h3>
+<p>Phase stereo is the least aggressive means of gracefully dropping
+resolution from the stereo image; it affects only diffuse imaging.</p>
+<p>It's often quoted that the human ear is deaf to signal phase above
+about 4kHz; this is nearly true and a passable rule of thumb, but it
+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 demonstration before
+finding the counterexample.</p>
+<p>'Phase stereo' is simply a more aggressive quantization of the polar
+angle vector; above 4kHz it's generally quite safe to quantize noise
+and noisy elements to only a handful of allowed phases, or to thin the
+phase with respect to the magnitude. The phases of high amplitude
+pure tones may or may not be preserved more carefully (they are
+relatively rare and L/R tend to be in phase, so there is generally
+little reason not to spend a few more bits on them)</p>
+<h4>example: eight phase stereo</h4>
+<p>Vorbis may implement phase stereo coupling by preserving the entirety
+of the magnitude vector (essential to fine amplitude and energy
+resolution overall) and quantizing the angle vector to one of only
+four possible values. Given that the magnitude vector may be positive
+or negative, this results in left and right phase having eight
+possible permutation, thus 'eight phase stereo':</p>
+<p><img src="eightphase.png" alt="eight phase"/></p>
+<p>Left and right may be in phase (positive or negative), the most common
+case by far, or out of phase by 90 or 180 degrees.</p>
+<h4>example: four phase stereo</h4>
+<p>Similarly, four phase stereo takes the quantization one step further;
+it allows only in-phase and 180 degree out-out-phase signals:</p>
+<p><img src="fourphase.png" alt="four phase"/></p>
+<h3>example: point stereo</h3>
+<p>Point stereo eliminates the possibility of out-of-phase signal
+entirely. Any diffuse quality to a sound source tends to collapse
+inward to a point somewhere within the stereo image. A practical
+example would be balanced reverberations within a large, live space;
+normally the sound is diffuse and soft, giving a sonic impression of
+volume. In point-stereo, the reverberations would still exist, but
+sound fairly firmly centered within the image (assuming the
+reverberation was centered overall; if the reverberation is stronger
+to the left, then the point of localization in point stereo would be
+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 degradation to the sound quality and is thus used in frequency
+ranges where it is least noticeable.</p>
+<h3>Mixed Stereo</h3>
+<p>Mixed stereo is the simultaneous use of more than one of the above
+stereo encoding models, generally using more aggressive modes in
+higher frequencies, lower amplitudes or 'nearly' in-phase sound.</p>
+<p>It is also the case that near-DC frequencies should be encoded using
+lossless coupling to avoid frame blocking artifacts.</p>
+<h3>Vorbis Stereo Modes</h3>
+<p>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 re-added to the stereo model in the future.</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/vendor/local/share/doc/libvorbis-1.3.2/stream.png ADDED Viewed

Binary file

data/vendor/local/share/doc/libvorbis-1.3.2/v-comment.html ADDED Viewed

@@ -0,0 +1,285 @@
+<!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 I format specification: comment field and header specification</h1>
+<h1>Overview</h1>
+<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.</p>
+<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
+more than a short paragraph. The essentials, in other words, whatever
+they turn out to be, eg:</p>
+<blockquote><p>
+"Honest Bob and the Factory-to-Dealer-Incentives, _I'm Still Around_,
+opening for Moxy Fr&uuml;vous, 1997"
+</p></blockquote>
+<h1>Comment encoding</h1>
+<h2>Structure</h2>
+<p>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
+contents themselves are not null terminated. In addition to the vector
+list, there is a single vector for vendor name (also 8 bit clean,
+length encoded in 32 bits). For example, the 1.0 release of libvorbis
+set the vendor string to "Xiph.Org libVorbis I 20020717".</p>
+<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>
+<p>The comment vectors are structured similarly to a UNIX environment variable.
+That is, comment fields consist of a field name and a corresponding value and
+look like:</p>
+<pre>
+comment[0]="ARTIST=me";
+comment[1]="TITLE=the sound of Vorbis";
+</pre>
+<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
+to be considered equivalent to ASCII 0x61 through 0x7A inclusive
+(a-z).</li>
+<li>The field name is immediately followed by ASCII 0x3D ('=');
+this equals sign is used to terminate the field name.</li>
+<li>0x3D is followed by the 8 bit clean UTF-8 encoded value of the
+field contents to the end of the field.</li>
+</ul>
+<h3>Field names</h3>
+<p>Below is a proposed, minimal list of standard field names with a
+description of intended use. No single or group of field names is
+mandatory; a comment header may contain one, all or none of the names
+in this list.</p>
+<dl>
+<dt>TITLE</dt>
+<dd>Track/Work name</dd>
+<dt>VERSION</dt>
+<dd>The version field may be used to differentiate multiple
+versions of the same track title in a single collection.
+(e.g. remix info)</dd>
+<dt>ALBUM</dt>
+<dd>The collection name to which this track belongs</dd>
+<dt>TRACKNUMBER</dt>
+<dd>The track number of this piece if part of a specific larger collection or album</dd>
+<dt>ARTIST</dt>
+<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.</dd>
+<dt>PERFORMER</dt>
+<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.</dd>
+<dt>COPYRIGHT</dt>
+<dd>Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'</dd>
+<dt>LICENSE</dt>
+<dd>License information, eg, 'All Rights Reserved', 'Any
+Use Permitted', a URL to a license such as a Creative Commons license
+("www.creativecommons.org/blahblah/license.html") or the EFF Open
+Audio License ('distributed under the terms of the Open Audio
+License. see http://www.eff.org/IP/Open_licenses/eff_oal.html for
+details'), etc.</dd>
+<dt>ORGANIZATION</dt>
+<dd>Name of the organization producing the track (i.e.
+the 'record label')</dd>
+<dt>DESCRIPTION</dt>
+<dd>A short text description of the contents</dd>
+<dt>GENRE</dt>
+<dd>A short text indication of music genre</dd>
+<dt>DATE</dt>
+<dd>Date the track was recorded</dd>
+<dt>LOCATION</dt>
+<dd>Location where track was recorded</dd>
+<dt>CONTACT</dt>
+<dd>Contact information for the creators or distributors of the track.
+This could be a URL, an email address, the physical address of
+the producing label.</dd>
+<dt>ISRC</dt>
+<dd>ISRC number for the track; see <a href="http://www.ifpi.org/isrc/">the
+ISRC intro page</a> for more information on ISRC numbers.</dd>
+</dl>
+<h3>Implications</h3>
+<ul>
+<li>Field names should not be 'internationalized'; this is a
+concession to simplicity not an attempt to exclude the majority of
+the world that doesn't speak English. Field <emph>contents</emph>,
+however, use the UTF-8 character encoding to allow easy representation
+of any language.</li>
+<li>We have the length of the entirety of the field and restrictions on
+the field name so that the field name is bounded in a known way. Thus
+we also have the length of the field contents.</li>
+<li>Individual 'vendors' may use non-standard field names within
+reason. The proper use of comment fields should be clear through
+context at this point. Abuse will be discouraged.</li>
+<li>There is no vendor-specific prefix to 'nonstandard' field names.
+Vendors should make some effort to avoid arbitrarily polluting the
+common namespace. We will generally collect the more useful tags
+here to help with standardization.</li>
+<li>Field names are not required to be unique (occur once) within a
+comment header. As an example, assume a track was recorded by three
+well know artists; the following is permissible, and encouraged:
+<pre>
+              ARTIST=Dizzy Gillespie
+              ARTIST=Sonny Rollins
+              ARTIST=Sonny Stitt
+</pre></li>
+</ul>
+<h2>Encoding</h2>
+<p>The comment header comprises the entirety of the second bitstream
+header packet. Unlike the first bitstream header packet, it is not
+generally the only packet on the second page and may not be restricted
+to within the second bitstream page. The length of the comment header
+packet is (practically) unbounded. The comment header packet is not
+optional; it must be present in the bitstream even if it is
+effectively empty.</p>
+<p>The comment header is encoded as follows (as per Ogg's standard
+bitstream mapping which renders least-significant-bit of the word to be
+coded into the least significant available bit of the current
+bitstream octet first):</p>
+<ol>
+<li>Vendor string length (32 bit unsigned quantity specifying number of octets)</li>
+<li>Vendor string ([vendor string length] octets coded from beginning of string
+to end of string, not null terminated)</li>
+<li>Number of comment fields (32 bit unsigned quantity specifying number of fields)</li>
+<li>Comment field 0 length (if [Number of comment fields]>0; 32 bit unsigned
+quantity specifying number of octets)</li>
+<li>Comment field 0 ([Comment field 0 length] octets coded from beginning of
+string to end of string, not null terminated)</li>
+<li>Comment field 1 length (if [Number of comment fields]>1...)...</li>
+</ol>
+<p>This is actually somewhat easier to describe in code; implementation of the above
+can be found in vorbis/lib/info.c:_vorbis_pack_comment(),_vorbis_unpack_comment()</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>