[xiph-cvs] r6560 - in websites/xiph.org: . SSI ogg ogg/vorbis/doc
giles at xiph.org
giles at xiph.org
Tue May 4 21:23:50 PDT 2004
Author: giles
Date: 2004-04-20 20:09:46 -0400 (Tue, 20 Apr 2004)
New Revision: 6560
Removed:
websites/xiph.org/SSI/plug.inc-
websites/xiph.org/cvs.html-
websites/xiph.org/index.html~
websites/xiph.org/indextop.include~
websites/xiph.org/indextopbar.include~
websites/xiph.org/ogg/index.html-
websites/xiph.org/ogg/vorbis/doc/framing.html-
websites/xiph.org/ogg/vorbis/doc/oggstream.html-
websites/xiph.org/ogg/vorbis/doc/vorbis.html-
websites/xiph.org/press.tgz
Log:
remove some backup files
Deleted: websites/xiph.org/SSI/plug.inc-
===================================================================
--- websites/xiph.org/SSI/plug.inc- 2004-04-21 00:04:55 UTC (rev 6559)
+++ websites/xiph.org/SSI/plug.inc- 2004-04-21 00:09:46 UTC (rev 6560)
@@ -1,5 +0,0 @@
-<p class='visitUs'>
-Also, stay updated by joining #vorbis on irc.xiph.org, and remember to read
-<a href='http://www.vorbis.com/ot'>Ogg Traffic</a> every week on
-vorbis.com!
-</p>
Deleted: websites/xiph.org/cvs.html-
===================================================================
--- websites/xiph.org/cvs.html- 2004-04-21 00:04:55 UTC (rev 6559)
+++ websites/xiph.org/cvs.html- 2004-04-21 00:09:46 UTC (rev 6560)
@@ -1,169 +0,0 @@
-<title> Xiph.Org: naming </title>
-
-<!--#include file="xiphtop.include" -->
-
- Xiph.Org read-only CVS access
-
-<!--#include file="xiphmid.include" -->
-
-Xiph.Org development projects are available to the public at large
-through read-only remote CVS access of the developers' live source
-repositories. This access gives external contributers access to all
-the infomation, code and history available to our own core developers.
-
-<h2>Accessing CVS at Xiph.Org</h2>
-
-These instructions assume that CVS is already installed and generally
-configured on your host. Note that the anonymous CVS access offered
-here is read-only; the repository will not accept anonymous commits.<p>
-
-Access to Xiph.Org can be handled basically two ways:<p>
-
-<h3>Using the CVSROOT environment variable</h3>
-
-Set CVSROOT in your environment to:
-<pre>
-
-:pserver:anoncvs at xiph.org:/usr/local/cvsroot
-
-</pre>
-
-Log into the CVS repository using:
-<pre>
-cvs login
-</pre>
-When prompted for a password, reply <tt>anoncvs</tt>.<p>
-
-Then access modules using the typical:
-<pre>
-cvs -z 1 co <i>module</i>
-</pre>
-...substituting the specific desired module for <tt><i>module</i></tt>.
-
-The undesireable part of this strategy is its global nature
-(personally, I use several seperate CVS servers daily).
-
-<h3>Using <tt> cvs -d</tt></h3>
-
-Alternately, use the -d option to locally configure a specific module
-checkout. For Xiph.Org, the command line (needed only with <tt>cvs
-login</tt> and <tt>cvs checkout</tt> would read:
-
-<pre>
-cvs -d :pserver:anoncvs at xiph.org:/usr/local/cvsroot login
-</pre>
-(as above, when prompted for a password, use <tt>anoncvs</tt>).
-<pre>
-cvs -d :pserver:anoncvs at xiph.org:/usr/local/cvsroot -z 9 co <i>module</i>
-</pre>
-...substituting the specific desired module for <tt><i>module</i></tt>.
-
-In both cases, once you've got the repository checked out, neither -d
-nor the environment variable are required; the repository location is
-stored with the checkout. <tt>cvs update </tt> will sync your local
-copy with the repository. See the CVS manual for additional
-information on how to use CVS. (Besides downloads of recent versions
-of CVS Cyclic Software also has a <a
-href="http://www.cvshome.org/cyclic/cvs/doc-blandy.html">reasonably simple
-introduction to CVS</a>.)<p>
-
-(Thanks to Cygnus for the basis of this page)<p>
-
-<h2>Modules</h2>
-
-<dl>
-<dt>ao<dd>
-The source code to libao, used by some vorbis utilities.
-
-<dt>ao-python<dd>
-Python bindings to libao.
-
-<dt>icecast<dd>
-The icecast2 streaming audio server.
-
-<dt>ices<dd>
-An audio source client to the icecast2 server.
-
-<dt>libshout<dd>
-A library for communicating with an icecast server.
-
-<dt>masktest<dd>
-The source code to a package that collects masking data from a user by running listening experiments.
-
-<dt>mgm<dd>
-The source code to MGM, a status/load meter package written in Perl.
-
-<dt>ogg<dd>
-The source code to libogg.
-
-<dt>ogg-python<dd>
-Python bindings for libogg.
-
-<dt>ogg-tools<dd>
-The source code to various command line utilities for other types of Ogg files.
-
-<dt>paranoia-III<dd>
-The source code to cdparanoia and Paranoia-III.
-
-<dt>speex<dd>
-The source code to the Speex low-bitrate voice-only audio codec.
-
-<dt>tarkin<dd>
-The source code to the original Tarkin video CODEC source experiment.
-
-<dt>theora<dd>
-The source code to the Theora video CODEC project.
-
-<dt>Tremor<dd>
-The source code to the integer-only Ogg Vorbis decode library named 'Tremor'.
-
-<dt>vp32<dd>
-The source code to ON2's VP3.2 video codec.
-
-<dt>vorbis<dd>
-The source code to libvorbis, libvorbisfile, libvorbisenc and example code.
-
-<dt>vorbis-plugins<dd>
-The source code to a few OggVorbis player plugins.
-
-<dt>vorbis-python<dd>
-Python bindings for libvorbis, libvorbisfile and libvorbisenc.
-
-<dt>vorbis-tools<dd>
-The source code to various command line OggVorbis utilities.
-
-<dt>w3d<dd>
-The source code to another Tarkin video CODEC source experiment.
-
-<dt>win32-tools<dd>
-Source code for Windows Ogg tools.
-
-<dt>win32sdk<dd>
-Source code for Windows Ogg development SDK.
-</dl>
-
-<p>The following helper libraries are used by icecast and related programs:</p>
-
-<dl>
-<dt>avl<dd>
-AVL tree library.
-
-<dt>httpp<dd>
-A simple http parser library.
-
-<dt>log<dd>
-A thread-safe logging library.
-
-<dt>net<dd>
-A thread-safe name resolving library.
-
-<dt>thread<dd>
-A cross platform thread and synchronization library
-
-<dt>timing<dd>
-A cross platform timing library.
-
-</dl>
-
-
-<!--#include file="xiphbottom.include" -->
Deleted: websites/xiph.org/index.html~
===================================================================
--- websites/xiph.org/index.html~ 2004-04-21 00:04:55 UTC (rev 6559)
+++ websites/xiph.org/index.html~ 2004-04-21 00:09:46 UTC (rev 6560)
@@ -1,18 +0,0 @@
-<title> Xiph.Org: home </title>
-
-<!--#include file="style.include" -->
-
-<!--#include file="indextop.include" -->
-<!--#include file="indextopbar.include" -->
-
-<h1 style='font-size: 12pt; font-weight: normal;'>Welcome to the Xiph.Org Foundation homepage.</h1>
-
-<p>
-Xiph.Org Foundation is a non-profit corporation dedicated to protecting
-the foundations of Internet multimedia from control by private interests.
-Our purpose is to support and develop free, open protocols and software to
-serve the public, developer and business markets.</p>
-
-
-<!--#include file="indexbottombar.include" -->
-
Deleted: websites/xiph.org/indextop.include~
===================================================================
--- websites/xiph.org/indextop.include~ 2004-04-21 00:04:55 UTC (rev 6559)
+++ websites/xiph.org/indextop.include~ 2004-04-21 00:09:46 UTC (rev 6560)
@@ -1,124 +0,0 @@
-<body bgcolor="#ffffff" link="#208b8b" vlink="#000080" color="#000000" background="inback.jpg">
-
-<!-- open space formatting ************************************* -->
-<!-- tricky: table formatting always is. *********************** -->
-
-<table border=0 cellspacing=0 cellpadding=0 width="100%">
-<tr>
-
- <!-- big fish ************************************************ -->
- <td valign=center align=center width=85%>
- <img src=xifish.gif width=112 height=112 alt=" "><br>
- <img src=xiphword.gif width=300 height=41 alt="Xiph.Org: home"><br>
-
- <font size=+2 face="Verdana, Arial, Helvetica">
- building a new era of Open multimedia
- </td>
-
-
- <!-- spacer ************************************************** -->
- <td><img src=spacer13.gif width=13 height=13 alt=" "></td>
-
- <!-- side menu *********************************************** -->
- <td valign=center align=right>
- <!-- right hand tan blocks ************* -->
- <img src=spacer32.gif width=32 height=32 alt=" "><br>
-
- <table border=0 bgcolor=#46463c cellpadding=1 cellspacing=0 width="100%">
- <tr><td>
-
- <table border=0 bgcolor=#e8e0c0 cellpadding=5 cellspacing=0 width="100%">
-
- <tr><td valign=top>
- <a href="about.html">
- <img src=small-grey-xiph.gif
- border=0 width=42 height=43 alt=" "></a></td>
- <td valign=center align=center width="100%">
- <font face="Verdana, Arial, Helvetica">
- <img src=spacer6.gif width=6 height=6 alt=""><br>
- <a href="about.html">
- About Xiph.Org</a><br>
- Press Releases<br>
-
- <img src=spacer6.gif width=6 height=6 alt=""><br>
- </font>
- </td>
- <td><img src=spacer6.gif width=6 height=6></td>
- </tr>
- </table>
-
- </td></tr>
- </table>
-
- <img src=spacer1.gif width=1 height=1 alt=" ">
-
- <table border=0 bgcolor=#46463c cellpadding=1 cellspacing=0 width="100%">
- <tr><td>
-
- <table border=0 cellpadding=5 cellspacing=0 width="100%"
- bgcolor=#e8e0c0>
-
- <tr><td valign=top align=center>
- <a href="http://www.icecast.org/">
- <img border=0 src=small-grey-icecast.png
- width=37 height=37 alt=" "></a></td>
- <td valign=center align=center width="100%">
- <font face="Verdana, Arial, Helvetica">
- <a href="http://www.icecast.org/">
- Icecast</a><br></td>
- <td><img src=spacer6.gif width=6 height=6></td></tr>
- </font>
-
- <tr><td valign=top align=center>
- <a href="ogg/">
- <img src=small-grey-ogg.png border=0
- width=41 height=57 alt=" "></a></td>
- <td valign=center align=center width="100%">
- <font face="Verdana, Arial, Helvetica">
- <a href="ogg/">
- Ogg project</a><br>
- <a href="ogg/vorbis/">
- Ogg Vorbis</a></td>
- <td><img src=spacer6.gif width=6 height=6></td></tr>
- </font>
-
- <tr><td valign=top align=center>
- <a href="paranoia/">
- <img src=small-grey-eye.png border=0
- width=41 height=39 alt=" "></a></td>
- <td valign=center align=center width="100%">
- <font face="Verdana, Arial, Helvetica">
- <a href="paranoia/">
- Paranoia IV</a><br>
- <a href="paranoia/">
- cdparanoia</a></td>
- <td><img src=spacer6.gif width=6 height=6></td></tr>
- </font>
-
- <tr><td valign=top align=center>
- <a href="mgm/">
- <img src=small-grey-mgm.png border=0
- width=39 height=35 alt=" "></a></td>
- <td valign=center align=center width="100%">
- <font face="Verdana, Arial, Helvetica">
- <a href="mgm/">
- MGM</a></td>
- </font>
- <td><img src=spacer6.gif width=6 height=6></td></tr>
- </table>
- </td></tr>
- </table>
-
- <br><img src=spacer32.gif width=32 height=32 alt=" "><br>
-
- <!-- /right hand tan blocks ************* -->
- </td>
-</tr>
-</table>
-
-
-
-
-
-
-
Deleted: websites/xiph.org/indextopbar.include~
===================================================================
--- websites/xiph.org/indextopbar.include~ 2004-04-21 00:04:55 UTC (rev 6559)
+++ websites/xiph.org/indextopbar.include~ 2004-04-21 00:09:46 UTC (rev 6560)
@@ -1,88 +0,0 @@
-
-<table border=0 cellpadding=0 cellspacing=0>
-<tr>
-<td><img src=spacer1.gif alt=" "></td>
-<td><img src=spacer1.gif alt=" "></td>
-<td><img src=topcurveA.gif alt=" "></td>
-<td bgcolor=#46463c><img src=spacer1.gif alt=" "></td>
-<td bgcolor=#46463c><img src=spacer1.gif alt=" "></td>
-</tr>
-
-<tr>
-<td><img src=spacer1.gif alt=" "></td>
-<td><img src=spacer1.gif alt=" "></td>
-<td><img src=topcurveAA.gif alt=" "></td>
-<td bgcolor=#e8e0c0><img src=spacer1.gif alt=" "></td>
-<td bgcolor=#46463c><img src=spacer1.gif alt=" "></td>
-</tr>
-
-<tr>
-<td><img src=spacer1.gif alt=" "></td>
-<td valign=top rowspan=2 bgcolor=#46463c><img src=topcurveB.gif alt=" "></td>
-<td valign=top rowspan=2 bgcolor=#e8e0c0><img src=topcurveC.gif alt=" "></td>
-<td align=center valign=top bgcolor=#e8e0c0 width=10000>
- <table border=0 cellpadding=0 cellspacing=0 width=100%>
- <tr>
- <td style='font-family: Verdana, sans-serif; text-align: center;'>
- <!-- body *********************************** -->
- <!--#include file="indexdate.include" -->
- [
- about |
- press |
- donate |
- <a href='/contact/' title='Find out who we are'>contact</a> |
- mailing lists/archives |
- cvs |
- vorbis |
- icecast |
- speex |
- <a href='http://flac.sourceforge.net/'>flac</a> |
- <a href='http://www.theora.org/'>theora</a> |
- paranoia |
- MGM |
- bugs |
- <a href='http://wiki.xiph.org/'>wiki</a>
- ]
- <!-- body *********************************** -->
- </td>
- </tr>
- </table>
-</td>
-<td width=1 bgcolor=#46463c><img src=spacer1.gif alt=" "></td>
-</tr>
-
-<tr>
-<td><img src=spacer1.gif alt=" "></td>
-<td bgcolor=#e8e0c0><img src=spacer3.gif alt=" "></td>
-<td bgcolor=#46463c><img src=spacer1.gif alt=" "></td>
-</tr>
-
-<tr>
-<td><img src=spacer1.gif alt=" "></td>
-<td bgcolor=#e8e0c0 colspan=2><img src=topcurveD.gif alt=" "></td>
-<td colspan=2 bgcolor=#46463c valign=top><img src=spacer1.gif alt=" "></td>
-</tr>
-</table>
-
-<table cellspacing=0 cellpadding=0 border=0>
-<tr>
-<td><img src=spacer1.gif alt=" "></td>
-<td bgcolor=#e8e0c0><img src=topcurveE.gif alt=" "></td>
-<td><img src=topcurveEE.gif alt=" "></td>
-</tr>
-</table>
-
-<table cellspacing=0 cellpadding=0 border=0>
-<td><img src=spacer1.gif alt=" "></td>
-<td bgcolor=#46463c><img src=spacer1.gif alt=" "></td>
-<td bgcolor=#e8e0c0><img src=spacer7.gif alt=" "></td>
-<td bgcolor=#46463c><img src=spacer1.gif alt=" "></td>
-<td><img src=spacer32.gif alt=" "></td>
-
-<td>
-
-<font face="Verdana, Ariel, Helvetica">
-<img src=spacer13.gif width=13 height=13 alt=" "><br>
-
-
-
Deleted: websites/xiph.org/ogg/index.html-
===================================================================
--- websites/xiph.org/ogg/index.html- 2004-04-21 00:04:55 UTC (rev 6559)
+++ websites/xiph.org/ogg/index.html- 2004-04-21 00:09:46 UTC (rev 6560)
@@ -1,48 +0,0 @@
-<title> xiph.org: the Ogg project </title>
-
-<!--#include file="oggtop.include" -->
-
- <img src=/ogg/images/oggword2.gif><br>The Ogg project homepage
-
-<!--#include file="xiphmid.include" -->
-
-<font color=#208080><tt><nohype></tt><p></font>
-
-OggSquish is a group of several related multimedia and signal
-processing projects; two are currently in active development for
-planned release. Our goal is 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="/about.html">About Xiphophorus</a> for
-details.<p>
-
-OggSquish is about research, source code and education. Along with our
-code, we offer the development community detailed documentation of our
-research and the resulting software. Our current development focuses
-on the Vorbis audio codec (now nearing
-initial release). Research also includes work on future video and
-lossless audio coding.<p>
-
-<h1>Ogg Vorbis</h1>
-
-Currently, Ogg Vorbis is our primary effort: A patent-clear, fully
-open general purpose audio encoding format standard that rivals or
-surpasses the 'upcoming' generation of proprietary coders (AAC and
-TwinVQ, also known as VQF). <p>
-
-Xiphophorus is currently actively developing libvorbis, an LGPLed source
-implementation of Vorbis as a library and a full featured
-encoder/player based on libvorbis. See the <a href="vorbis/index.html">Ogg
-Vorbis homepage</a> for documentation, downloads and distribution
-terms.<p>
-
-<h1>Ogg Tarkin</h1>
-
-Discussion and tinkering have begun on an Ogg project video codec,
-currently named Tarkin. Developers are encouraged to <a
-href="http://www.xiph.org/archives/tarkin-dev">browse</a> or <a
-href="vmail.html">join</a> the <a
-href="http://www.xiph.org/archives/tarkin-dev">Tarking developers
-mailing list</a>.
-
-<!--#include file="xiphbottom.include" -->
Deleted: websites/xiph.org/ogg/vorbis/doc/framing.html-
===================================================================
--- websites/xiph.org/ogg/vorbis/doc/framing.html- 2004-04-21 00:04:55 UTC (rev 6559)
+++ websites/xiph.org/ogg/vorbis/doc/framing.html- 2004-04-21 00:09:46 UTC (rev 6560)
@@ -1,387 +0,0 @@
-<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
-<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
-<nobr><a href="vorbis.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>
-
-Last update to this document: February 18, 2001</em><br>
-
-<h2>Ogg bitstreams</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-seperation
-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 seperate 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 logical</em> Ogg bitstream is a contiguous stream of
-sequential pages belonging only to the logical bitstream. A
-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
-Ogg bitstream overview. 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 preceeded 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 resticted 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 forseen 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
-preceeding 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
-preceeding 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 inadvertant 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>PCM absolute 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 be the frame number). 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 thenext page do not count). The rationale here is
- that the position specified in the frame header of the last page
- tells how long the PCM 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 seperate 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 seperate 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 at guest.adelaide.edu.au">ross at 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 Xiphophorus 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
-Xiphophorus</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,
-Xiphophorus and the Ogg project (xiph.org) reserve the right to set
-the Ogg/Vorbis specification and certify specification compliance.<p>
-
-Xiphophorus's Vorbis software CODEC implementation is distributed
-under the Lessr/Library GNU Public License. This does not restrict
-third parties from distributing independent implementations of Vorbis
-software under other licenses.<p>
-
-OggSquish, Vorbis, Xiphophorus and their logos are trademarks (tm) of
-Xiphophorus. These pages are
-copyright (C) 1994-2001 Xiphophorus. All rights reserved.<p>
-
-</body>
-
-
Deleted: websites/xiph.org/ogg/vorbis/doc/oggstream.html-
===================================================================
--- websites/xiph.org/ogg/vorbis/doc/oggstream.html- 2004-04-21 00:04:55 UTC (rev 6559)
+++ websites/xiph.org/ogg/vorbis/doc/oggstream.html- 2004-04-21 00:09:46 UTC (rev 6560)
@@ -1,193 +0,0 @@
-<HTML><HEAD><TITLE>xiph.org: OggSquish Vorbis documentation</TITLE>
-<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
-<nobr><a href="vorbis.html"><img src="/white-ogg.gif" border=0><img
-src="/vorbisword2.gif" border=0></a></nobr><p>
-
-
-<h1><font color=#000070>
-OggSquish logical and physical bitstream overview
-</font></h1>
-
-Last update to this document: July 18, 1999</em><br>
-
-<h2>OggSquish bitstreams</h2>
-
-OggSquish codecs use octet vectors of raw, compressed data
-(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-seperation 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 OggSquish bitstream format to provide framing/sync, sync recapture
-after error, landmarks during seeking, and enough information to
-properly seperate 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 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 restricctions) into
-a single physical bitstream</em>. A physical bitstream consists
-of multiple logical bitstreams multiplexed at the page level. 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 fromt he physical bitstream and redirecting them into
-the appropriate logical decoding entitiy. The simplest physical
-bitstream is a single, unmultiplexed logical bitstream. <p>
-
-<a href=framing.html>OggSquish Logical Bitstream Framing</a> discusses
-the page format of an OggSquish bitstream, the packet coding process
-and logical bitstreams in detail. The remainder of this document
-specifies requirements for constructing finished, physical OggSquish
-bitstreams.<p>
-
-<h2>Mapping Restrictions</h2>
-
-Logical bitstreams may not be mapped/multiplexed into physical
-bitstreams without restriction. Here we discuss design restrictions
-on OggSquish physical bitstreams in general, mostly to introduce
-design rationale. Each 'media' format defines its own (generally more
-restrictive) mapping. An '<a href="vorbis-stream.html">Ogg Vorbis
-Audio Bitstream</a>', for example, has a <a
-href="vorbis-stream.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 framing specification 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 OggSquish bitstream obeys
-additional restrictions. Each individual media mapping specifies its
-own implementation details regarding these restrictions.<p>
-
-The first page of a logical OggSquish 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
-OggSquish 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
-(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'
-(grouped</em>). An example of grouping would be to allow
-streaming of seperate audio and video streams, using differnt 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 OggSquish 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 OggSquish 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.gif><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 appearence 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.gif" align=left border=0>
-</a>
-<font size=-2 color=#505050>
-
-OggSquish is a Xiphophorus 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
-Xiphophorus</a> for details.
-<p>
-
-Ogg Vorbis is the first OggSquish audio CODEC. Anyone may
-freely use and distribute the OggSquish and Vorbis specification,
-whether in a private, public or corporate capacity. However,
-Xiphophorus and the Ogg project (xiph.org) reserve the right to set
-the Ogg/Vorbis specification and certify specification compliance.<p>
-
-Xiphophorus's Vorbis software CODEC implementation (libvorbis and the
-vorbis encode/decode/playback utility) are distributed under the GNU
-Public License. This does not restrict third parties from
-distributing independent implementations of Vorbis software under
-other licenses.<p>
-
-OggSquish, Vorbis, Xiphophorus and their logos are trademarks (tm) of
-Xiphophorus. These pages are
-copyright (C) 1994-2000 Xiphophorus. All rights reserved.<p>
-
-</body>
-
-
Deleted: websites/xiph.org/ogg/vorbis/doc/vorbis.html-
===================================================================
--- websites/xiph.org/ogg/vorbis/doc/vorbis.html- 2004-04-21 00:04:55 UTC (rev 6559)
+++ websites/xiph.org/ogg/vorbis/doc/vorbis.html- 2004-04-21 00:09:46 UTC (rev 6560)
@@ -1,197 +0,0 @@
-<HTML><HEAD><TITLE>xiph.org: OggSquish Vorbis documentation</TITLE>
-<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
-<nobr><img src="/white-ogg.gif"><img src="/ogg/images/vorbisword2.gif"></nobr><p>
-
-
-<h1><font color=#000070>
-OggSquish Vorbis encoding format documentation
-</font></h1>
-
-Last update to this document: July 15, 1999</em><br>
-Last update to Vorbis documentation: July 19, 1999</em><p>
-
-<table><tr><td>
-<img src=/ogg/images/wait.gif>
-</td><td valign=center>
-As of writing, not all the below document
-links are live. They will be populated as we complete the
-documents.
-</td></tr></table>
-
-<p>
-<h2>Documents</h2>
-<ul>
-<li>Vorbis packet structure
-<li>Temporal envelope shaping and blocksize
-<li>Time domain segmentation and MDCT transform
-<li>The resolution floor
-<li>MDCT-domain fine structure<p>
-
-<li>The Vorbis probability model
-
-<li>The Vorbis bitpacker<p>
-
-<li>OggSquish bitstream overview
-<li>OggSquish logical bitstream and framing spec
-<li>Vorbis packet->OggSquish bitstream
- mapping<p>
-
-<li>Programming with libvorbis<p>
-</ul>
-
-<h2>Description</h2>
-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>
-
-Vorbis is the first of a planned family of OggSquish multimedia coding
-formats being developed as part of Xiphophorus's OggSquish multimedia
-project. See http://www.xiph.org/
-for more information.
-
-<h2>Vorbis technical documents</h2>
-
-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 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 coding</em>.
-Lastly, in a streaming environment, the raw packets are then
-structured into a continuous stream of octets; this last phase is
-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>
-
-A Vorbis decoder performs a mirror image process of extracting the
-original sequence of raw packets from an Ogg stream (stream
-decomposition</em>), reconstructing the signal representation from the
-raw data in the packet (decoding</em>) and them reconstituting an
-audio signal from the decoded representation (synthesis</em>).<p>
-
-The Programming with libvorbis
-documents discuss use of the reference Vorbis codec library
-(libvorbis) produced by Xiphophorus.<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>
-
-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>
-
-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>Vorbis packet structure: Describes the basic analysis components necessary to produce Vorbis packets and the structure of the packet itself.
-<li>Temporal envelope shaping and blocksize: 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>Time domain segmentation and MDCT transform: Division of time domain data into individual overlapped, windowed short-time vectors and transformation using the MDCT
-<li>The resolution floor: Use of frequency doamin psychoacoustics, and the MDCT-domain noise, masking and resolution floors
-<li>MDCT-domain fine structure: Production, quantization and massaging of MDCT-spectrum fine structure
-</ul>
-
-<h3>Vorbis coding and decoding</h3>
-
-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, back-end coding</em> and <em>bitpacking</em>.<p>
-
-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>
-
-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>The Vorbis probability model
-
-<li>The Vorbis bitpacker: Arrangement of
-variable bit-length words into an octet-aligned packet.
-
-</ul>
-
-<h3>Vorbis streaming and stream decomposition</h3>
-
-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>OggSquish bitstream overview: High-level
-description of OggSquish 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><a href="framing.html">OggSquish logical bitstream and framing
-spec</a>: Low level, complete specification of OggSquish logical
-bitstream pages. Note that this document is not specific only to Ogg
-Vorbis.
-
-<li>Vorbis bitstream mapping:
-Specifically describes mapping Vorbis data into an
-OggSquish physical bitstream.
-
-</ul>
-
-
-<hr>
-<a href="http://www.xiph.org/">
-<img src="/white-xifish.gif" align=left border=0>
-</a>
-<font size=-2 color=#505050>
-
-OggSquish is a Xiphophorus 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
-Xiphophorus</a> for details.
-<p>
-
-Ogg Vorbis is the first OggSquish audio CODEC. Anyone may
-freely use and distribute the OggSquish and Vorbis specification,
-whether in a private, public or corporate capacity. However,
-Xiphophorus and the Ogg project (xiph.org) reserve the right to set
-the Ogg/Vorbis specification and certify specification compliance.<p>
-
-Xiphophorus's Vorbis software CODEC implementation (libvorbis and the
-vorbis encode/decode/playback utility) are distributed under the GNU
-Public License. This does not restrict third parties from
-distributing independent implementations of Vorbis software under
-other licenses.<p>
-
-OggSquish, Vorbis, Xiphophorus and their logos are trademarks (tm) of
-Xiphophorus. These pages are
-copyright (C) 1994-2000 Xiphophorus. All rights reserved.<p>
-
-</body>
-
-
-
-
-
-
Deleted: websites/xiph.org/press.tgz
===================================================================
(Binary files differ)
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'cvs-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the commits
mailing list