I changed it to "hold for update". Thanks!
Ben. On 15 Jun 2015, at 14:46, Mo Zanaty (mzanaty) wrote: > "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
