RubyGems - gosu - Versions diffs - 0.7.16 → 0.7.17 - Mend

@@ -1,154 +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 I format specification: floor1_inverse_dB_table</h1>
-<p>The vector <tt>[floor1_inverse_dB_table]</tt> is a 256 element static
-lookup table consiting of the following values (read left to right
-then top to bottom):</p>
-<pre>
-  1.0649863e-07, 1.1341951e-07, 1.2079015e-07, 1.2863978e-07,
-  1.3699951e-07, 1.4590251e-07, 1.5538408e-07, 1.6548181e-07,
-  1.7623575e-07, 1.8768855e-07, 1.9988561e-07, 2.1287530e-07,
-  2.2670913e-07, 2.4144197e-07, 2.5713223e-07, 2.7384213e-07,
-  2.9163793e-07, 3.1059021e-07, 3.3077411e-07, 3.5226968e-07,
-  3.7516214e-07, 3.9954229e-07, 4.2550680e-07, 4.5315863e-07,
-  4.8260743e-07, 5.1396998e-07, 5.4737065e-07, 5.8294187e-07,
-  6.2082472e-07, 6.6116941e-07, 7.0413592e-07, 7.4989464e-07,
-  7.9862701e-07, 8.5052630e-07, 9.0579828e-07, 9.6466216e-07,
-  1.0273513e-06, 1.0941144e-06, 1.1652161e-06, 1.2409384e-06,
-  1.3215816e-06, 1.4074654e-06, 1.4989305e-06, 1.5963394e-06,
-  1.7000785e-06, 1.8105592e-06, 1.9282195e-06, 2.0535261e-06,
-  2.1869758e-06, 2.3290978e-06, 2.4804557e-06, 2.6416497e-06,
-  2.8133190e-06, 2.9961443e-06, 3.1908506e-06, 3.3982101e-06,
-  3.6190449e-06, 3.8542308e-06, 4.1047004e-06, 4.3714470e-06,
-  4.6555282e-06, 4.9580707e-06, 5.2802740e-06, 5.6234160e-06,
-  5.9888572e-06, 6.3780469e-06, 6.7925283e-06, 7.2339451e-06,
-  7.7040476e-06, 8.2047000e-06, 8.7378876e-06, 9.3057248e-06,
-  9.9104632e-06, 1.0554501e-05, 1.1240392e-05, 1.1970856e-05,
-  1.2748789e-05, 1.3577278e-05, 1.4459606e-05, 1.5399272e-05,
-  1.6400004e-05, 1.7465768e-05, 1.8600792e-05, 1.9809576e-05,
-  2.1096914e-05, 2.2467911e-05, 2.3928002e-05, 2.5482978e-05,
-  2.7139006e-05, 2.8902651e-05, 3.0780908e-05, 3.2781225e-05,
-  3.4911534e-05, 3.7180282e-05, 3.9596466e-05, 4.2169667e-05,
-  4.4910090e-05, 4.7828601e-05, 5.0936773e-05, 5.4246931e-05,
-  5.7772202e-05, 6.1526565e-05, 6.5524908e-05, 6.9783085e-05,
-  7.4317983e-05, 7.9147585e-05, 8.4291040e-05, 8.9768747e-05,
-  9.5602426e-05, 0.00010181521, 0.00010843174, 0.00011547824,
-  0.00012298267, 0.00013097477, 0.00013948625, 0.00014855085,
-  0.00015820453, 0.00016848555, 0.00017943469, 0.00019109536,
-  0.00020351382, 0.00021673929, 0.00023082423, 0.00024582449,
-  0.00026179955, 0.00027881276, 0.00029693158, 0.00031622787,
-  0.00033677814, 0.00035866388, 0.00038197188, 0.00040679456,
-  0.00043323036, 0.00046138411, 0.00049136745, 0.00052329927,
-  0.00055730621, 0.00059352311, 0.00063209358, 0.00067317058,
-  0.00071691700, 0.00076350630, 0.00081312324, 0.00086596457,
-  0.00092223983, 0.00098217216, 0.0010459992,  0.0011139742,
-  0.0011863665,  0.0012634633,  0.0013455702,  0.0014330129,
-  0.0015261382,  0.0016253153,  0.0017309374,  0.0018434235,
-  0.0019632195,  0.0020908006,  0.0022266726,  0.0023713743,
-  0.0025254795,  0.0026895994,  0.0028643847,  0.0030505286,
-  0.0032487691,  0.0034598925,  0.0036847358,  0.0039241906,
-  0.0041792066,  0.0044507950,  0.0047400328,  0.0050480668,
-  0.0053761186,  0.0057254891,  0.0060975636,  0.0064938176,
-  0.0069158225,  0.0073652516,  0.0078438871,  0.0083536271,
-  0.0088964928,  0.009474637,   0.010090352,   0.010746080,
-  0.011444421,   0.012188144,   0.012980198,   0.013823725,
-  0.014722068,   0.015678791,   0.016697687,   0.017782797,
-  0.018938423,   0.020169149,   0.021479854,   0.022875735,
-  0.024362330,   0.025945531,   0.027631618,   0.029427276,
-  0.031339626,   0.033376252,   0.035545228,   0.037855157,
-  0.040315199,   0.042935108,   0.045725273,   0.048696758,
-  0.051861348,   0.055231591,   0.058820850,   0.062643361,
-  0.066714279,   0.071049749,   0.075666962,   0.080584227,
-  0.085821044,   0.091398179,   0.097337747,   0.10366330,
-  0.11039993,    0.11757434,    0.12521498,    0.13335215,
-  0.14201813,    0.15124727,    0.16107617,    0.17154380,
-  0.18269168,    0.19456402,    0.20720788,    0.22067342,
-  0.23501402,    0.25028656,    0.26655159,    0.28387361,
-  0.30232132,    0.32196786,    0.34289114,    0.36517414,
-  0.38890521,    0.41417847,    0.44109412,    0.46975890,
-  0.50028648,    0.53279791,    0.56742212,    0.60429640,
-  0.64356699,    0.68538959,    0.72993007,    0.77736504,
-  0.82788260,    0.88168307,    0.9389798,     1.
-</pre>
-<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/floorval.png DELETED

Binary file

data/dependencies/libvorbis/doc/fourphase.png DELETED

Binary file

data/dependencies/libvorbis/doc/framing.html DELETED

@@ -1,431 +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 logical bitstream framing</h1>
-<h2>Ogg bitstreams</h2>
-<p>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 Theora video codec.</p>
-<h2>Application example: Vorbis</h2>
-<p>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>
-<li>Use no more than approximately 1-2% of bitstream bandwidth for
-  packet boundary marking, high-level framing, sync and seeking.</li>
-<li>Specification of absolute position within the original sample
-  stream.</li>
-<li>Simple mechanism to ease limited editing, such as a simplified
-  concatenation mechanism.</li>
-<li>Detection of corruption, recapture after error and direct, random
-  access to data at arbitrary positions in the bitstream.</li>
-</ol>
-<h2>Logical and Physical Bitstreams</h2>
-<p>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 the Vorbis I Specification.</p>
-<h2>Bitstream structure</h2>
-<p>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>
-<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>
-<p>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>
-<p>The raw packet is logically divided into [n] 255 byte segments and a
-last fractional segment of &lt; 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>
-<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>
-<p>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 (&lt;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>
-<p>Note that a lacing value of 255 implies that a second lacing value
-follows in the packet, and a value of &lt; 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>
-<p>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>
-<p>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>
-<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>
-<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>
-<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>
-<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>
-<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>
-<p>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>
-<p>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>
-<p>The capture pattern is followed by the stream structure revision:</p>
-<pre><tt>
- byte value
-  4  0x00
-</tt></pre>
-<h4>header_type_flag</h4>
-<p>The header type flag identifies this page's context in the bitstream:</p>
-<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>
-<p>(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>
-<p>A special value of '-1' (in two's complement) indicates that no packets
-finish on this page.</p>
-<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>
-<p>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:</p>
-<pre><tt>
- byte value
- 14  0xXX LSB
- 15  0xXX
- 16  0xXX
- 17  0xXX MSB
-</tt></pre>
-<h4>page sequence no</h4>
-<p>Page counter; lets us know if a page is lost (useful where packets
-span page boundaries).</p>
-<pre><tt>
- byte value
- 18  0xXX LSB
- 19  0xXX
- 20  0xXX
- 21  0xXX MSB
-</tt></pre>
-<h4>page checksum</h4>
-<p>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>
-<p>(A thorough discussion of CRC algorithms can be found in <a
-href="http://www.ross.net/crc/download/crc_v3.txt">"A
-Painless Guide to CRC Error Detection Algorithms"</a> by Ross
-Williams <a href="mailto:ross@ross.net">ross@ross.net</a>.)</p>
-<pre><tt>
- byte value
- 22  0xXX LSB
- 23  0xXX
- 24  0xXX
- 25  0xXX MSB
-</tt></pre>
-<h4>page_segments</h4>
-<p>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>
-<p>The lacing values for each packet segment physically appearing in
-this page are listed in contiguous order.</p>
-<pre><tt>
- byte value
- 27 0x00-0xff (0-255)
- [...]
- n  0x00-0xff (0-255, n=page_segments+26)
-</tt></pre>
-<p>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>
-<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>
-<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>