Commit e26ed59a authored by Ralph Giles's avatar Ralph Giles
Browse files

Use SILK/CELT everywhere describing modes.

There was some attempt to use LP/MDCT instead, to avoid confusion
of the Opus modes with the earlier codecs of the same name, but
Jean-Marc says they gave up on doing that in the Opus RFC, and in
particular the tables a reader would need to reference from RFC 6716
Section 3.2 mentions SILK and CELT, so I think it's important to use
the same terms here.
parent af807b28
......@@ -319,17 +319,17 @@ At 0.6 kbps, this is still a minimal bitrate impact over a naive, low quality
</t>
<t>
Since medium-band audio is only supported in the LP mode, wideband frames SHOULD
be generated if switching from it to the MDCT mode, to ensure that any PLC
implementation that does try to migrate state between the modes will be able to
preserve all of the available audio bandwidth.
Since medium-band audio is only supported in the SILK modes, wideband frames
SHOULD be generated if switching from it to CELT modes, to ensure that
any PLC implementation that does try to migrate state between the modes
will be able to preserve all of the available audio bandwidth.
</t>
<t>
Matching synthetic TOC byte(s) MAY be packed into packets using any of
codes&nbsp;0, 1, 2, or&nbsp;3.
If the TOC configuration matches, the muxer MAY further combine the empty
frames with previous or subsequent non-zero-length frames (using code&nbsp;2
frames with previous or subsequent non-zero-length frames (using code&nbsp;2
or VBR code&nbsp;3).
</t>
</section>
......@@ -337,7 +337,7 @@ frames with previous or subsequent non-zero-length frames (using code&nbsp;2
<section anchor="preskip" title="Pre-skip">
<t>
There is some amount of latency introduced during the decoding process, to
allow for overlap in the MDCT modes, stereo mixing in the LP modes, and
allow for overlap in the CELT modes, stereo mixing in the SILK modes, and
resampling, and the encoder will introduce even more latency (though the exact
amount is not specified).
Therefore, the first few samples produced by the decoder do not correspond to
......@@ -1204,11 +1204,11 @@ Even in such a packet, most of the data will be zeros as 2.5&nbsp;ms frames
The largest packet consisting of entirely useful data is
(15,326*N&nbsp;-&nbsp;2) octets, or about 15&nbsp;kB per stream.
This corresponds to 120&nbsp;ms of audio encoded as 10&nbsp;ms frames in either
LP or Hybrid mode, but at a data rate of over 1&nbsp;Mbps, which makes little
SILK or Hybrid mode, but at a data rate of over 1&nbsp;Mbps, which makes little
sense for the quality achieved.
A more reasonable limit is (7,664*N&nbsp;-&nbsp;2) octets, or about 7.5&nbsp;kB
per stream.
This corresponds to 120&nbsp;ms of audio encoded as 20&nbsp;ms stereo MDCT mode
This corresponds to 120&nbsp;ms of audio encoded as 20&nbsp;ms stereo CELT mode
frames, with a total bitrate just under 511&nbsp;kbps (not counting the Ogg
encapsulation overhead).
With N=8, the maximum number of channels currently defined by mapping
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment