<?xml version="1.0" encoding="utf-8"?>
<!--
     draft-rfcxml-general-template-standard-00

     This template includes examples of the most commonly used features of RFCXML with comments
     explaining how to customise them. This template can be quickly turned into an I-D by editing
     the examples provided. Look for [REPLACE], [REPLACE/DELETE], [CHECK] and edit accordingly.
     Note - 'DELETE' means delete the element or attribute, not just the contents.

     Documentation is at https://authors.ietf.org/en/templates-and-schemas
-->
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  consensus="true"
  docName="draft-valin-opus-scalable-quality-extension-00"
  ipr="trust200902"
  obsoletes=""
  updates="6716"
  submissionType="IETF"
  xml:lang="en"
  version="3">
<!-- [REPLACE]
       * docName with name of your draft
     [CHECK]
       * category should be one of std, bcp, info, exp, historic
       * ipr should be one of trust200902, noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
       * updates can be an RFC number as NNNN
       * obsoletes can be an RFC number as NNNN
-->

  <front>
    <title abbrev="Scalable Quality Extension">Scalable Quality Extension for the Opus Codec</title>

    <seriesInfo name="Internet-Draft" value="draft-valin-opus-scalable-quality-extension-00"/>

    <author fullname="Jean-Marc Valin" initials="JM" surname="Valin">
      <organization>Google</organization>
      <address>
        <postal>
          <country>CA</country>
          <!-- Uses two letter country code -->
        </postal>
        <email>jeanmarcv@google.com</email>
      </address>
    </author>

    <date year="2024"/>
    <!-- On draft subbmission:
         * If only the current year is specified, the current day and month will be used.
         * If the month and year are both specified and are the current ones, the current day will
           be used
         * If the year is not the current one, it is necessary to specify at least a month and day="1" will be used.
    -->

    <area>Applications and Real-Time</area>
    <workgroup>mlcodec</workgroup>
    <!-- "Internet Engineering Task Force" is fine for individual submissions.  If this element is
          not present, the default is "Network Working Group", which is used by the RFC Editor as
          a nod to the history of the RFC Series. -->

    <keyword>Opus, RFC6716</keyword>

    <abstract>
      <t>This document updates RFC6716 to add support for a scalable quality layer. </t>
    </abstract>

  </front>

  <middle>

    <section>
      <name>Introduction</name>
      <t>This document updates RFC6716 to add support for a scalable quality extension layer.</t>

      <section>
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
          RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
          interpreted as described in BCP 14 <xref target="RFC2119"/>
          <xref target="RFC8174"/> when, and only when, they appear in
          all capitals, as shown here.</t>
      </section>

    </section>

    <section anchor="format">
      <name>Scalable Quality Extension</name>
      <t>The Opus codec was designed to operate at sampling frequencies up to 48 kHz,
        with an audio bandwidth up to 20 kHz.
        The CELT mode that is used for high bitrate coding uses ector quantization with
        a mostly implicit bit allocation system that is dictated by the bitstream definition.
        Opus can allocate up to 8 bits per MDCT bin in some of the bands.
      </t>

      <t>While Opus capabilities listed above are sufficient to reach achieve
        perceptually transparent audio coding, there is a use for codecs that scale
        beyond those specs. That includes the current market for 24-bit/96 kHz codecs,
        but also any application where the intended receipient is not (only) a human being,
        e.g. ultra-sonic applications.</t>

      <t>This document proposes a scalable quality extension layer that both increases the
        resolution of existing Opus quantizers below 20 kHz, and defines a way of coding audio
        above 20 kHz, with a sampling rate of 96 kHz. The extension is designed to be forward
        and backward compatible with <xref target="RFC6716"/>.
        All extra bits use the Opus extension mechanism defined in <xref target="opus-extension"/>
        and a 96 kHz decoder is designed to be able to decode a regular 48 kHz RFC 6716 stream and vice versa.
        </t>

      <t>
        The code corresponding to this draft (work in progress) is available on the exp_qext17
        branch of the Opus repository at https://gitlab.xiph.org/xiph/opus/ .
      </t>

      <section anchor="existing">
        <name>Extended resolution</name>
        <t>
        To reduce the coding error, we need to increase the resolution for 3 different quantizers:
        the fine energy quantizer (scalar), the band pyramid vector quantizer (PVQ), and the
        band splitting angle quantizer.</t>
        <t>More on extra resolution here</t>
      </section>

      <section anchor="extra">
        <name>Extended frequency range</name>
        <t>
        To extend the audio bandwidth, we need to define more frequency bands.
        Because psychoacoustics is no longer involved past 20 kHz, all new bands are defined
        to have the same width. </t>
        <t>More on band definitions here</t>
      </section>

      <section anchor="time-domain">
        <name>Time-domain processing at 96 kHz</name>
        <t>CELT includes two time-domain filter pairs that require updating for 96 kHz:
          the preemphasis/deempahsis filters, as well as the pitch prefilter/postfilter.
          The CELT deemphasis filter is currently defined as D(z)=1/(1 - a1*z^-1) for a 48 kHz
          signal, where a1=27853/32768.
          To obtain approximately the same response in the 0-20 kHz range using a
          sampling rate of 96 kHz, we instead use D(z)=g*(1 - b1*z^-1)/(1 - a1*z^-1),
          where g=5415/8192, b1=7209/32768, a1=30245/32768.</t>

        <t>For the pitch pre-filter/post-filter, we use zero-insertion upsampling of the 48 kHz
          filters, which results in the same frequency response below 24 kHz and a "folded" image
          above 24 kHz. For example, if for a pitch period T (in 48 kHz units) the postfilter was
          P(z)=1/(1 - a0*z^-T+1 - a1*z^-T - a2*z^-T-1), then for the same pitch, the 96 kHz filter
          becomes P(z)=1/(1 - a0*z^-2T+2 - a1*z^-2T - a2*z^-2T-2).</t>
      </section>

    </section>

    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>[Note: Until the IANA performs the actions described below, implementers should use 124 instead of 33 as the extension number.]</t>
      <t>This document assigns ID 33 to the "Opus Extension IDs" registry created in
        <xref target="opus-extension"/> to implement the proposed scalable quality extension. </t>
    </section>


    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
      <t>This document does not add security considerations beyond those already documented in <xref target="RFC6716"/>.
          </t>
    </section>

  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6716.xml"/>
        <reference anchor="opus-extension">
        <!-- Manually added reference -->
          <front>
            <title>Extension Formatting for the Opus Codec (draft-ietf-mlcodec-opus-extension)</title>
            <author initials="T.B." surname="Terriberry" fullname="Timothy B. Terriberry">
              <organization/>
            </author>
            <author initials="J.-M." surname="Valin" fullname="Jean-Marc Valin">
              <organization/>
            </author>
            <date year="2023" month="October"/>
            <abstract>
              <t>Opus extension format.
              </t>
            </abstract>
          </front>
        </reference>

        <!-- The recommended and simplest way to include a well known reference -->

      </references>

      <!--
      <references>
        <name>Informative References</name>

        <reference anchor="exampleRefMin">
          <front>
            <title>Title [REPLACE]</title>
            <author initials="Initials [REPLACE]" surname="Surname [REPLACE]">
              <organization/>
            </author>
            <date year="2006"/>
          </front>
        </reference>

      </references>
      -->
    </references>

    <!--
    <section>
      <name>Appendix 1 [REPLACE/DELETE]</name>
      <t>This becomes an Appendix [REPLACE]</t>
    </section>

    <section anchor="Acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>We would like to thank...</t>
    </section>

    <section anchor="Contributors" numbered="false">
      <name>Contributors</name>
      <t>Thanks to all of the contributors. [REPLACE]</t>
    </section>
      -->

 </back>
</rfc>
