oggopus: Refer to 'TOC sequence' instead of byte.
[opus.git] / doc / draft-ietf-codec-oggopus.xml
index 128c343..d319bfb 100644 (file)
@@ -11,7 +11,7 @@
 ]>
 <?rfc toc="yes" symrefs="yes" ?>
 
-<rfc ipr="trust200902" category="std" docName="draft-ietf-codec-oggopus-04">
+<rfc ipr="trust200902" category="std" docName="draft-ietf-codec-oggopus-05">
 
 <front>
 <title abbrev="Ogg Opus">Ogg Encapsulation for the Opus Audio Codec</title>
@@ -60,7 +60,7 @@
 </address>
 </author>
 
-<date day="9" month="August" year="2014"/>
+<date day="15" month="October" year="2014"/>
 <area>RAI</area>
 <workgroup>codec</workgroup>
 
@@ -187,8 +187,8 @@ A decoder SHOULD treat any Opus packet whose duration is different from that of
 <t>
 The coding mode (SILK, Hybrid, or CELT), audio bandwidth, channel count,
  duration (frame size), and number of frames per packet, are indicated in the
- TOC (table of contents) in the first byte of each Opus packet, as described
- in Section&nbsp;3.1 of&nbsp;<xref target="RFC6716"/>.
+ TOC (table of contents) sequence at the beginning of each Opus packet, as
described in Section&nbsp;3.1 of&nbsp;<xref target="RFC6716"/>.
 The combination of mode, audio bandwidth, and frame size is referred to as
  the configuration of an Opus packet.
 </t>
@@ -1219,7 +1219,7 @@ An Ogg Opus stream MUST NOT have more than one of each tag, and if present
  their values MUST be an integer from -32768 to 32767, inclusive,
  represented in ASCII as a base 10 number with no whitespace.
 A leading '+' or '-' character is valid.
-Leading zeros are also permitted, but the value MUST be represented in
+Leading zeros are also permitted, but the value MUST be represented by
  no more than 6 characters.
 Other non-digit characters MUST NOT be present.
 </t>
@@ -1241,7 +1241,7 @@ To avoid confusion with multiple normalization schemes, an Opus comment header
  REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK tags.
 <xref target="EBU-R128"/> normalization is preferred to the earlier
  REPLAYGAIN schemes because of its clear definition and adoption by industry.
-PEAK normalizations are difficult to calculate reliably for lossy codecs
+Peak normalizations are difficult to calculate reliably for lossy codecs
  because of variation in excursion heights due to decoder differences.
 In the authors' investigations they were not applied consistently or broadly
  enough to merit inclusion here.
@@ -1309,7 +1309,7 @@ In encoders derived from the reference implementation, the number of
  samples can be queried with:
 </preamble>
 <artwork align="center"><![CDATA[
- opus_encoder_ctl(encoder_state, OPUS_GET_LOOKAHEAD, &delay_samples);
+ opus_encoder_ctl(encoder_state, OPUS_GET_LOOKAHEAD(&delay_samples));
 ]]></artwork>
 </figure>
 <t>
@@ -1391,7 +1391,7 @@ In encoders derived from the reference implementation, inter-frame prediction
  can be turned off by calling:
 </preamble>
 <artwork align="center"><![CDATA[
- opus_encoder_ctl(encoder_state, OPUS_SET_PREDICTION_DISABLED, 1);
+ opus_encoder_ctl(encoder_state, OPUS_SET_PREDICTION_DISABLED(1));
 ]]></artwork>
 <postamble>
 For best results, this implementation requires that prediction be explicitly