eden-emu/opus
17
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Ogg Opus Draft: bump release date, version, and more cleanup.

Browse source
This commit is contained in:
Ralph Giles 2014-08-08 23:07:36 -07:00
parent 64881eca01
commit fd2992aaab
1 changed files with 10 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

20
doc/draft-ietf-codec-oggopus.xml
View file

@ -11,7 +11,7 @@
]>
<?rfc toc="yes" symrefs="yes" ?>
<rfc ipr="trust200902" category="std" docName="draft-ietf-codec-oggopus-03">
<rfc ipr="trust200902" category="std" docName="draft-ietf-codec-oggopus-04">
<front>
<title abbrev="Ogg Opus">Ogg Encapsulation for the Opus Audio Codec</title>
@ -60,7 +60,7 @@
</address>
</author>
<date day="7" month="February" year="2014"/>
<date day="9" month="August" year="2014"/>
<area>RAI</area>
<workgroup>codec</workgroup>
@ -365,7 +365,7 @@ A 'pre-skip' field in the ID header (see <xref target="id_header"/>) signals
the number of samples which SHOULD be skipped (decoded but discarded) at the
beginning of the stream.
This amount MAY not be a multiple of 2.5&nbsp;ms, MAY be smaller than a single
packet, or MAT span the contents of several packets.
packet, or MAY span the contents of several packets.
These samples are not valid audio, and should not be played.
</t>
@ -702,7 +702,7 @@ Although the output gain has enormous range (+/- 128 dB, enough to amplify
inaudible sounds to the threshold of physical pain), most applications can
only reasonably use a small portion of this range around zero.
The large range serves in part to ensure that gain can always be losslessly
transferred between OpusHead and R128_TRACK_GAIN (see below) without
transferred between OpusHead and R128 gain tags (see below) without
saturating.
<vspace blankLines="1"/>
</t>
@ -1173,7 +1173,7 @@ The user comment strings follow the NAME=value format described by
ARTIST, TITLE, DATE, ALBUM, and so on.
</t>
<t>
Two new comment tags are introduced for Ogg Opus:
Two new comment tags are introduced here:
</t>
<figure align="center">
@ -1200,7 +1200,7 @@ R128_ALBUM_GAIN=111
]]></artwork>
<postamble>
representing the volume shift needed to normalize the overall volume when
played as part of a collection of tracks.
played as part of a particular collection of tracks.
The gain is also a Q7.8 fixed point number in dB, as in the ID header's
'output gain' field.
</postamble>
@ -1229,10 +1229,10 @@ If a tool modifies the ID header's 'output gain' field, it MUST also update or
To avoid confusion with multiple normalization schemes, an Opus comment header
SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK,
REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK tags.
The <xref target="EBU-R128"/> normalization is preferred to the earlier
<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 because of variation
in excursion heights due to decoder differences.
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.
</t>
@ -1243,7 +1243,7 @@ In the authors' investigations they were not applied consistently or broadly
<section anchor="packet_size_limits" title="Packet Size Limits">
<t>
Technically valid Opus packets can be arbitrarily large due to the padding
Technically, valid Opus packets can be arbitrarily large due to the padding
format, although the amount of non-padding data they can contain is bounded.
These packets might be spread over a similarly enormous number of Ogg pages.
Encoders SHOULD use no more padding than required to make a variable bitrate