Updates and spelling corrections

git-svn-id: http://svn.xiph.org/trunk/ogg@3630 0101bb08-14d6-0310-b084-bc0e0c8e3800

2 files changed, 48 insertions, 38 deletions

diff --git a/doc/framing.html b/doc/framing.html
index 50bba5e..9ea9795 100644
--- a/doc/framing.html
+++ b/doc/framing.html
@@ -7,18 +7,24 @@ src="vorbisword2.png" border=0></a></nobr><p>
 Ogg logical bitstream framing
 </font></h1>
 
-<em>Last update to this document: February 18, 2001</em><br> 
+<em>Last update to this document: July 14, 2002</em><br> 
 
 <h2>Ogg bitstreams</h2>
 
+The Ogg transport bitstream is designed to provide framing, error
+protection and seeking structure for higher-level codec streams that
+consist of raw, unencapsulated data packets, such as the Vorbis audio
+codec or Tarkin video codec.
+
+<h2>Application example: Vorbis</h2>
 Vorbis encodes short-time blocks of PCM data into raw packets of
 bit-packed data.  These raw packets may be used directly by transport
-mechanisms that provide their own framing and packet-seperation
+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 seperate data back into packets at the original packet
+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>
@@ -57,7 +63,7 @@ bitstream mapping</a>.
 
 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
+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>
@@ -123,12 +129,12 @@ 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,
+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 forseen as being useful for
+approximately 4-8kB (large packets are foreseen as being useful for
 initialization data at the beginning of a logical bitstream).<p>
 
 After segmenting a packet, the encoder may decide not to place all the
@@ -148,12 +154,12 @@ 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
+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
-preceeding page, implying that the previous page's segment table
+preceding page, implying that the previous page's segment table
 cannot be trusted.<p>
 
 Note that a packet can span an arbitrary number of pages; the above
@@ -192,7 +198,7 @@ buffered packet segments.<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 inadvertant coincidence in the byte stream).<p>
+ (as opposed to an inadvertent coincidence in the byte stream).<p>
 
 <pre><tt>
  byte value
@@ -228,19 +234,20 @@ buffered packet segments.<p>
                        set = last page of logical bitstream (eos)
 </tt></pre>
 
-<h4>PCM absolute position</h4>
+<h4>absolute granule position</h4>
 
- (This is packed in the same way the rest of Ogg data is packed;
- LSb of LSB first.  Note that the 'position' data specifies a 'sample'
+ (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.
+ and 16 bits for right; in video it would likely be the frame number.
+ It is up to the specific codec in use to define the semantic meaning
+ of the granule position value).  The position specified is the total
+ samples encoded after including all packets finished on this page
+ (packets begun on this page but continuing on to the next page do not
+ count).  The rationale here is that the position specified in the
+ frame header of the last page tells how long the data coded by the
+ bitstream is.  A truncated stream will still return the proper number
+ of samples that can be decoded fully.
 <p>
  A special value of '-1' (in two's complement) indicates that no packets
  finish on this page.
@@ -260,10 +267,10 @@ buffered packet segments.<p>
 
 <h4>stream serial number</h4>
  
- Ogg allows for seperate logical bitstreams to be mixed at page
+ 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 seperate bitstreams to be decoded concurrently.  The serial
+ 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:
diff --git a/doc/oggstream.html b/doc/oggstream.html
index 56a50d7..6870f46 100644
--- a/doc/oggstream.html
+++ b/doc/oggstream.html
@@ -8,7 +8,7 @@ src="vorbisword2.png" border=0></a></nobr><p>
 Ogg logical and physical bitstream overview
 </font></h1>
 
-<em>Last update to this document: July 18, 1999</em><br> 
+<em>Last update to this document: July 14, 2002</em><br> 
 
 <h2>Ogg bitstreams</h2>
 
@@ -18,12 +18,12 @@ 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
+their own framing and packet-separation mechanisms (such as UDP
 datagrams).  For stream based storage (such as files) and transport
 (such as TCP streams or pipes), Vorbis and other future Ogg codecs use
 the Ogg bitstream format to provide framing/sync, sync recapture
 after error, landmarks during seeking, and enough information to
-properly seperate data back into packets at the original packet
+properly separate data back into packets at the original packet
 boundaries without relying on decoding to find packet boundaries.<p>
 
 <h2>Logical and physical bitstreams</h2>
@@ -36,15 +36,18 @@ 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 <em>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>
+Multiple logical bitstreams can be combined (with restrictions) into a
+single <em>physical bitstream</em>.  A physical bitstream consists of
+multiple logical bitstreams multiplexed at the page level and may
+include a 'meta-header' at the beginning of the multiplexed logical
+stream that serves as identification magic. Whole pages are taken in
+order from multiple logical bitstreams and combined into a single
+physical stream of pages. The decoder reconstructs the original
+logical bitstreams from the physical bitstream by taking the pages in
+order from the physical bitstream and redirecting them into the
+appropriate logical decoding entity. The simplest physical bitstream
+is a single, unmultiplexed logical bitstream with no meta-header; this
+is referred to as a 'degenerate stream'.  <p>
 
 <a href=framing.html>Ogg Logical Bitstream Framing</a> discusses
 the page format of an Ogg bitstream, the packet coding process
@@ -58,9 +61,9 @@ Logical bitstreams may not be mapped/multiplexed into physical
 bitstreams without restriction.  Here we discuss design restrictions
 on Ogg physical bitstreams in general, mostly to introduce
 design rationale. Each 'media' format defines its own (generally more
-restrictive) mapping.  An '<a href="vorbis-stream.html">Ogg Vorbis
+restrictive) mapping.  An '<a href="vorbis-ogg.html">Ogg Vorbis
 Audio Bitstream</a>', for example, has a <a
-href="vorbis-stream.html">specific physical bitstream structure</a>.
+href="vorbis-ogg.html">specific physical bitstream structure</a>.
 An 'Ogg A/V' bitstream (not currently specified) will also mandate a
 specific, restricted physical bitstream format.<p>
 
@@ -106,7 +109,7 @@ the scope of the physical bitstream.<p>
 
 Logical bitstreams may also be multiplexed 'in parallel'
 (<em>grouped</em>).  An example of grouping would be to allow
-streaming of seperate audio and video streams, using differnt codecs
+streaming of separate audio and video streams, using different codecs
 and different logical bitstreams, in the same physical bitstream.
 Whole pages from multiple logical bitstreams are mixed together.<p>
 
@@ -153,7 +156,7 @@ bitstreams in the previous group have terminated.<p>
 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 bitstreams.  (Tying page appearance to bitrate demands is one
 logical strategy, ie, the page appears at the chronological point
 where decode requires more information).