shithub: opus

Info  •  Files  •  Log  •  Branches

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.

--- a/doc/draft-ietf-codec-oggopus.xml

+++ b/doc/draft-ietf-codec-oggopus.xml

@@ -319,10 +319,10 @@

 </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>

@@ -329,7 +329,7 @@

 Matching synthetic TOC byte(s) MAY be packed into packets using any of

  codes 0, 1, 2, or 3.

 If the TOC configuration matches, the muxer MAY further combine the empty

-frames with previous or subsequent non-zero-length frames (using code 2

+ frames with previous or subsequent non-zero-length frames (using code 2

  or VBR code 3).

 </t>

 </section>

@@ -337,7 +337,7 @@

 <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 @@

 The largest packet consisting of entirely useful data is

  (15,326*N - 2) octets, or about 15 kB per stream.

 This corresponds to 120 ms of audio encoded as 10 ms frames in either

- LP or Hybrid mode, but at a data rate of over 1 Mbps, which makes little

+ SILK or Hybrid mode, but at a data rate of over 1 Mbps, which makes little

  sense for the quality achieved.

 A more reasonable limit is (7,664*N - 2) octets, or about 7.5 kB

  per stream.

-This corresponds to 120 ms of audio encoded as 20 ms stereo MDCT mode

+This corresponds to 120 ms of audio encoded as 20 ms stereo CELT mode

  frames, with a total bitrate just under 511 kbps (not counting the Ogg

  encapsulation overhead).

 With N=8, the maximum number of channels currently defined by mapping