"Hold for update² seems most appropriate, given the pending update draft. (Which is now expired, so authors please update the update. ;)
Thanks, Mo On 6/15/15, 2:45 PM, Ben Campbell <[email protected]> wrote: Am I correct that this is in descriptive overview text that isn't likely to affect interoperability, especially if it gets corrected in an update? If so, My thoughts would be to mark this as "hold for update", and fix in the update. Do people agree? Thanks! Ben. On 15 Jun 2015, at 12:33, Jean-Marc Valin wrote: > The suggested text is indeed correct. The question is whether that > should go in an errata or in this draft that is already meant to > update > RFC6716: > https://tools.ietf.org/html/draft-ietf-codec-opus-update-01 > > Cheers, > > Jean-Marc > > On 15/06/15 11:01 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC6716, >> "Definition of the Opus Audio Codec". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6716&eid=4392 >> >> -------------------------------------- >> Type: Technical >> Reported by: Peter Budny <[email protected]> >> >> Section: 2 >> >> Original Text >> ------------- >> The Opus codec scales from 6 kbit/s narrowband mono speech to >> 510 kbit/s fullband stereo music, with algorithmic delays ranging >> from 5 ms to 65.2 ms. >> >> (further in the same section) >> >> To >> compensate for the different look-ahead required by each layer, the >> CELT encoder input is delayed by an additional 2.7 ms. >> >> Corrected Text >> -------------- >> The Opus codec scales from 6 kbit/s narrowband mono speech to >> 510 kbit/s fullband stereo music, with algorithmic delays ranging >> from 5 ms to 66.5 ms. >> >> (further in the same section) >> >> To >> compensate for the different look-ahead required by each layer, the >> CELT encoder input is delayed by an additional 4 ms. >> >> Notes >> ----- >> For the latter text, the delays for the CELT and SILK layers must >> match. SILK has a "5 ms look-ahead for noise shaping estimation", >> and "1.5 ms delay for sampling rate conversion", totaling 6.5 ms. >> CELT has a "2.5 ms look-ahead due to the overlapping MDCT windows". >> Thus, the amount of delay needed to align CELT with SILK is 6.5ms - >> 2.5ms = 4ms. >> >> The text at the beginning of the section must reflect this as well. >> The "algorithmic delays" reported apparently include framing (minimum >> frame size 2.5ms + look-ahead delay in CELT-only mode 2.5ms = 5ms). >> In that case, the maximum delay is the maximum frame size (60ms) + >> the maximum delay for look-ahead and resampling (6.5ms) = 66.5ms. >> >> Confirmed by author ("Jmvalin") at >> >>https://en.wikipedia.org/wiki/Talk:Opus_(audio_format)/Archive_1#Codec_de >>lay_values >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6716 (draft-ietf-codec-opus-16) >> -------------------------------------- >> Title : Definition of the Opus Audio Codec >> Publication Date : September 2012 >> Author(s) : JM. Valin, K. Vos, T. Terriberry >> Category : PROPOSED STANDARD >> Source : Internet Wideband Audio Codec RAI >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
