<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" symrefs="yes" ?>
<rfc category="info" docName="draft-ietf-codec-results-00" ipr="trust200902">
  <front>
    <title abbrev="Codec Quality">Summary of Opus listening test
    results</title>

    <author fullname="Christian Hoene" initials="C." role="editor"
            surname="Hoene">
      <organization>Universitaet Tuebingen</organization>

      <address>
        <postal>
          <street>Sand 13</street>

          <city>Tuebingen</city>

          <region></region>

          <code>72076</code>

          <country>Germany</country>
        </postal>

        <email>hoene@uni-tuebingen.de</email>
      </address>
    </author>

    <author fullname="Jean-Marc Valin" initials="JM" surname="Valin">
      <organization>Mozilla Corporation</organization>

      <address>
        <postal>
          <street>650 Castro Street</street>

          <city>Mountain View</city>

          <region>CA</region>

          <code>94041</code>

          <country>USA</country>
        </postal>

        <phone>+1 650 903-0800</phone>

        <email>jmvalin@jmvalin.ca</email>
      </address>
    </author>

    <author fullname="Koen Vos" initials="K." surname="Vos">
      <organization>Skype Technologies S.A.</organization>

      <address>
        <postal>
          <street>Stadsgarden 6</street>

          <city>Stockholm</city>

          <region></region>

          <code>11645</code>

          <country>Sweden</country>
        </postal>

        <email>koen.vos@skype.net</email>
      </address>
    </author>

    <author fullname="Jan Skoglund" initials="J." surname="Skoglund">
      <organization>Google</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <email>jks@google.com</email>
      </address>
    </author>

    <date day="24" month="October" year="2011" />

    <area>General</area>

    <workgroup>codec</workgroup>

    <keyword>audio codec</keyword>

    <keyword>Opus</keyword>

    <abstract>
      <t>This document describes and examines listening test results obtained
      for the Opus codec and how they relate to the requirements.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>This document describes and examines listening test results obtained
      for the Opus codec. Some of the test results presented are based on
      older versions of the codec or on older versions of the SILK or CELT
      components. While they do not necessarily represent the exact quality of
      the current version, they are nonetheless useful for validating the
      technology used and as an indication of a lower bound on quality (based
      on the assumption that the codec has been improved since they were
      performed).</t>

      <t>Throughout this document, all statements about one codec being better
      than or worse than another codec are based on 95% confidence. When no
      statistically significant difference can be shown with 95% confidence,
      then two codecs are said to be "tied".</t>

      <t>In addition to the results summarized in this draft, Opus has been
      subjected to many informal subjective listening tests, as well as
      objective testing.</t>
    </section>

    <section anchor="opus" title="Opus listening tests on final bit-stream">
      <t>The following tests were performed on the Opus codec <spanx
      style="emph">after</spanx> the bit-stream was finalized.</t>

      <section anchor="opus-google" title="Google listening tests">
        <t>The tests followed the MUSHRA test methodology. Two anchors were
        used, one lowpass-filtered at 3.5 kHz and one lowpass-filtered at 7.0
        kHz. Both trained and untrained listeners participated in the tests.
        The reference signals were manually normalized to the same subjective
        levels according to the experimenters' opinion. Experiments with
        automatic normalization with respect to both level and loudness (in
        Adobe Audition) did not result in signals having equal subjective
        loudness. The sample magnitude levels were kept lower than 2^14 to
        provide headroom for possible amplification through the codecs.
        However, the normalization exercise was not repeated with the
        processed sequences as neither the experimenters nor any of the
        subjects (which included expert listeners) noticed any significant
        level differences between the conditions in the tests. The only
        post-processing performed was to remove noticeable delays in the MP3
        files, as one could identify the MP3 samples when switching between
        conditions when the MP3 had the longer delay. The testing tool Step
        from ARL was used for tests and all listeners were instructed to to
        carefully listen through the conditions before starting the grading.
        The results of the tests are a available on the testing slides <xref
        target="Prague-80"> presented at the Prague meeting</xref>.</t>

        <section anchor="opus-google-narrowband"
                 title="Google narrowband listening test">
          <t>The test sequences in Test 1 were mono recordings (between 2 and
          6 seconds long) of 4 different male and 4 different female speakers
          sampled at 48 kHz in low background noise. 17 listeners were
          presented with 6 stimuli according to <xref
          target="narrowband-conditions"></xref> for each test sequence. The
          corresponding bit rate for the reference is 48000 (sampling
          frequency in Hz) x 16 (bits/sample) = 768 kbps. Since the anchors
          are low-pass filtered they can also be downsampled for transmission
          which corresponds to lower bit rates. Three narrowband codecs were
          compared in this test: Opus NB, the royalty-free iLBC, and the
          royalty-free Speex. The codecs all have an encoder frame length of
          20 ms. Both Opus and Speex had variable rate whereas iLBC operated
          at a fixed bit rate.</t>

          <texttable anchor="narrowband-conditions"
                     title="Narrowband mono voice: test conditions">
            <ttcol align="center">Type</ttcol>

            <ttcol align="center">Signal bandwidth</ttcol>

            <ttcol align="center">Bitrate</ttcol>

            <c>Reference</c>

            <c>24 kHz (Fullband)</c>

            <c></c>

            <c>Anchor 1</c>

            <c>3.5 kHz (Narrowband)</c>

            <c></c>

            <c>Anchor 2</c>

            <c>7 kHz (Wideband)</c>

            <c></c>

            <c>iLBC</c>

            <c>4 kHz (Narrowband)</c>

            <c>15.2 kbps, CBR</c>

            <c>Opus NB</c>

            <c>4 kHz (Narrowband)</c>

            <c>11 kbps, VBR</c>

            <c>Speex NB</c>

            <c>3.5 kHz (Narrowband)</c>

            <c>11 kbps, VBR</c>
          </texttable>

          <t>The overall results of the narrowband test, i.e., averaged over
          all listeners for all sequences, are presented in <xref
          target="Prague-80"> the Prague meeting slides</xref>. The results
          suggest that Opus at 11 kbps is superior to both iLBC at 15 kpbs and
          Speex at 11 kbps. T-tests performed by Greg Maxwell confirm that
          there is indeed a statistically significant difference. Note also
          that Opus has a slightly higher average score than the 3.5 kHz
          anchor, likely due to the higher bandwidth of Opus.</t>
        </section>

        <section anchor="opus-google-wideband"
                 title="Google wideband and fullband listening test">
          <t>The eight test sequences for the previous test were also used in
          this Test. 16 listeners rated the stimuli listed in Table 2. In this
          test comparisons were made between four wideband codecs: Opus WB,
          the royalty-free Speex, the royalty-free ITU-T G.722.1, AMR-WB
          (ITU-T G.722.2), and two fullband codecs: Opus FB and the
          royalty-free ITU-T G.719. All six codecs utilize 20 ms encoding
          frames. Opus used variable bitrate, while other codecs used constant
          bit rate.</t>

          <texttable anchor="wideband-conditions"
                     title="Wideband and fullband mono voice: test conditions">
            <ttcol align="center">Type</ttcol>

            <ttcol align="center">Signal bandwidth</ttcol>

            <ttcol align="center">Bitrate</ttcol>

            <c>Reference</c>

            <c>24 kHz (Fullband)</c>

            <c></c>

            <c>Anchor 1</c>

            <c>3.5 kHz (Narrowband)</c>

            <c></c>

            <c>Anchor 2</c>

            <c>7 kHz (Wideband)</c>

            <c></c>

            <c>G.722.1</c>

            <c>7 kHz (Wideband)</c>

            <c>24 kbps, CBR</c>

            <c>Speex WB</c>

            <c>7 kHz (Wideband)</c>

            <c>23.8 kbps, CBR</c>

            <c>AMR-WB</c>

            <c>7 kHz (Wideband)</c>

            <c>19.85 kbps, CBR</c>

            <c>Opus WB</c>

            <c>8 kHz (Wideband)</c>

            <c>19.85 kbps, VBR</c>

            <c>G.719</c>

            <c>~20 kHz (Fullband)</c>

            <c>32 kbps, CBR</c>

            <c>Opus FB</c>

            <c>~20 kHz (Fullband)</c>

            <c>32 kbps, CBR</c>
          </texttable>

          <t>The results from this test are depicted in the Prague meeting
          slides<xref target="Prague-80"></xref>. Opus at 32 kbps is almost
          transparent, although there is a small, but statistically
          significant, difference from the fullband reference material. Opus
          at 20 kbps is significantly better than all the other codecs,
          including AMR-WB and the fullband G.719, and both low-pass
          anchors.</t>
        </section>

        <section anchor="opus-google-music"
                 title="Google stereo music listening test">
          <t>The sequences in this test were excerpts from 10 different stereo
          music files: <list style="symbols">
              <t>Rock/RnB (Boz Scaggs)</t>

              <t>Soft Rock (Steely Dan)</t>

              <t>Rock (Queen)</t>

              <t>Jazz (Harry James)</t>

              <t>Classical (Purcell)</t>

              <t>Electronica (Matmos)</t>

              <t>Piano (Moonlight Sonata)</t>

              <t>Vocals (Suzanne Vega)</t>

              <t>Glockenspiel</t>

              <t>Castanets</t>
            </list></t>

          <t>These sequences were originally recorded at a sampling frequency
          of 44.1 kHz and were upsampled to 48 kHz prior to processing. Test 3
          included comparisons between six codecs (c.f., Table 3): Opus at
          three rates, G.719, AAC-LC (Nero 1.5.1), and MP3 (Lame 3.98.4).
          G.719 is a mono codec, so the two channels were each coded
          independently at 32 kbps. 9 listeners participated in Test 3, and
          the results are depicted in the Prague meeting slides<xref
          target="Prague-80"></xref>. The codecs operated at constant (or
          comparable) bit rate.</t>

          <texttable anchor="google-music-conditions"
                     title="Stereo music: Test conditions">
            <ttcol align="center">Type</ttcol>

            <ttcol align="center">Signal bandwidth</ttcol>

            <ttcol align="center">Frame size (ms)</ttcol>

            <ttcol align="center">Bitrate</ttcol>

            <c>Reference</c>

            <c>22 kHz (Fullband)</c>

            <c>-</c>

            <c>(1536 kbps)</c>

            <c>Anchor 1</c>

            <c>3.5 kHz (Narrowband)</c>

            <c>-</c>

            <c>(256 kbps)</c>

            <c>Anchor 2</c>

            <c>7 kHz (Wideband)</c>

            <c>-</c>

            <c>(512 kbps)</c>

            <c>MP3</c>

            <c>16 kHz (Super wideband)</c>

            <c>&gt;100</c>

            <c>96 kbps, CBR</c>

            <c>AAC-LC</c>

            <c>~20 kHz (Fullband)</c>

            <c>21</c>

            <c>64 kbps, CBR (bit reservoir)</c>

            <c>G.719</c>

            <c>~20 kHz (Fullband)</c>

            <c>20</c>

            <c>64 kbps (2x32), CBR</c>

            <c>Opus FB</c>

            <c>~20 kHz (Fullband)</c>

            <c>20</c>

            <c>64 kbps, constrained VBR</c>

            <c>Opus FB</c>

            <c>~20 kHz (Fullband)</c>

            <c>10</c>

            <c>80 kbps, constrained VBR</c>

            <c>Opus FB</c>

            <c>~20 kHz (Fullband)</c>

            <c>5</c>

            <c>128 kbps, constrained VBR</c>
          </texttable>

          <t>The results indicate that all codecs had comparable performance,
          except for G.719, which had a considerably lower score. T-tests by
          Greg Maxwell verified that the low-delay Opus at 128 kbps had a
          significantly higher performance and that G.719 had a significantly
          lower performance than the other four.</t>
        </section>

        <section anchor="opus-google-transcoding"
                 title="Google transcoding test">
          <t>If two telephone networks of different technology are coupled,
          frequently speech has to be transcoded: It must be decoded and
          encoded before it can be forward to the next network. Then, two
          codecs are cooperating in a row, which is called tandem coding.</t>

          <t>In the following tests, Jan Skoglund studied the impact of
          transcoding if Opus call is forwarded to a cellular phone system.
          <xref target="Skoglund2011" />. Two tests were conducted for both
          narrowband and wideband speech items. The test conditions of the
          narrow-band tests are given in Table
          <ref>google-tandem-nb-conditions</ref> and the respective results in
          <ref>google-tandem-nb-results</ref>. For the wide-band conditions
          and results refer to Table <ref>google-tandem-wb-conditions</ref>and
          <ref>google-tandem-wb-results</ref>.</t>

          <texttable anchor="google-tandem-nb-conditions"
                     title="Narrowband tandem coding: test conditions">
            <ttcol align="left">Condition</ttcol>

            <ttcol align="left">Value</ttcol>

            <c>Laboratory</c>

            <c>Google</c>

            <c>Examiner</c>

            <c>Jan Skoglund</c>

            <c>Date</c>

            <c>August and September 2011</c>

            <c>Methodology</c>

            <c>ITU-R BS.1534-1 (MUSHRA)</c>

            <c>Reference items</c>

            <c>Two male and two female speakers from ITU-T P.501. Two male and
            two female speakers from McGill database. All recorded at 48kHz in
            a room with low background noise.</c>

            <c>Listeners</c>

            <c>19 listeners no listeners rejected / trained and untrained
            English-speaking listeners</c>

            <c>Anchor 1</c>

            <c>Reference file lowpass-filtered at 3.5 kHz</c>

            <c>Anchor 2</c>

            <c>Reference file resampled at 8 kHz, with MNRU at 15 dB SNR</c>

            <c>Test Condition 1</c>

            <c>G.711 at 64 kbps -&gt; Opus NB at 12.2 kbps, variable bit
            rate</c>

            <c>Test Condition 2</c>

            <c>G.711 at 64 kbps -&gt; AMR NB at 12.2 kbps, constant bit
            rate</c>

            <c>Test Condition 3</c>

            <c>AMR NB at 12.2 kbps -&gt; G.711 at 64 kbps -&gt; Opus NB at
            12.2 kbps</c>

            <c>Test Condition 4</c>

            <c>Opus NB at 12.2 kbps &gt; G.711 at 64 kbps &gt; AMR NB at 12.2
            kbps</c>

            <c>Test Condition 5</c>

            <c>AMR NB at 12.2 kbps -&gt; G.711 at 64 kbps -&gt; AMR NB at 12.2
            kbps</c>
          </texttable>

          <texttable anchor="google-tandem-nb-results"
                     title="Tandem narrowband coding: test results">
            <ttcol align="left">Test Item</ttcol>

            <ttcol align="right">Subjective MUSHRA score</ttcol>

            <ttcol align="right">95% CI</ttcol>

            <c>Reference</c>

            <c>99.47</c>

            <c>0.36</c>

            <c>LP3.5</c>

            <c>63.49</c>

            <c>3.01</c>

            <c>G.711-&gt;Opus</c>

            <c>54.51</c>

            <c>2.85</c>

            <c>G.711-&gt;AMR</c>

            <c>54.13</c>

            <c>2.67</c>

            <c>AMR-&gt;G.711-&gt;Opus</c>

            <c>51.11</c>

            <c>2.74</c>

            <c>Opus-&gt;G.711-&gt;AMR</c>

            <c>50.95</c>

            <c>2.76</c>

            <c>AMR-&gt;G.711-&gt;AMR</c>

            <c>47.81</c>

            <c>2.95</c>

            <c>MNRU</c>

            <c>14.94</c>

            <c>2.21</c>
          </texttable>

          <texttable anchor="google-tandem-wb-conditions"
                     title="Tandem wideband coding: test conditions">
            <ttcol align="left">Condition</ttcol>

            <ttcol align="left">Value</ttcol>

            <c>Laboratory</c>

            <c>Google</c>

            <c>Examiner</c>

            <c>Jan Skoglund</c>

            <c>Date</c>

            <c>August and September 2011</c>

            <c>Methodology</c>

            <c>MUSHRA</c>

            <c>Reference items</c>

            <c>Two male and two female speakers from ITU-T P.501. Two male and
            two female speakers recorded at Google at 48kHz in a room with low
            background noise</c>

            <c>Listeners</c>

            <c>18 listeners after post-screening / no listener rejects /
            untrained and trained English speaking listeners</c>

            <c>Anchor 1</c>

            <c>Reference file lowpass-filtered at 3.5 kHz (LP 3.5)</c>

            <c>Anchor 2</c>

            <c>Reference file lowpass-filtered at 7 kHz (LP 7)</c>

            <c>Test Condition 1</c>

            <c>Opus WB at 19.85 kbps, variable bit rate (Opus)</c>

            <c>Test Condition 2</c>

            <c>AMR WB at 19.85 kbps, constant bit rate (AMR WB)</c>

            <c>Test Condition 3</c>

            <c>AMR WB at 19.85 kbps &gt; Opus WB at 19.85 kbps</c>

            <c>Test Condition 4</c>

            <c>Opus WB at 19.85 kbps -&gt; AMR WB at 19.85 kbps</c>
          </texttable>

          <texttable anchor="google-tandem-wb-results"
                     title="Tandem wideband coding: test results">
            <ttcol align="center">Test Item</ttcol>

            <ttcol align="center">Subjective BS.1587 Score</ttcol>

            <ttcol align="center">95% CI</ttcol>

            <c>Reference</c>

            <c>99.44</c>

            <c>0.38</c>

            <c>Opus</c>

            <c>78.38</c>

            <c>2.16</c>

            <c>LP7</c>

            <c>74.24</c>

            <c>2.24</c>

            <c>AMR WB</c>

            <c>65.26</c>

            <c>2.85</c>

            <c>AMR WB-&gt;Opus</c>

            <c>63.97</c>

            <c>2.95</c>

            <c>Opus-&gt;AMR WB</c>

            <c>62.83</c>

            <c>2.94</c>

            <c>LP3.5</c>

            <c>37.01</c>

            <c>2.95</c>
          </texttable>

          <t>Under the given statistical confidence, narrowband tandem coding
          condition using AMR and/or Opus are of similar quality. However, the
          results have indications that Opus outperforms AMR NB slightly. In
          any case, narrow band transcoding is worse than a low pass filtering
          at 3.5kbps.</t>

          <t>Opus at 20kbps outperforms AMR WB at a similar coding rate and
          matches the quality of a 7kHz lowpass filtered signal. Tandem coding
          with Opus does not reduce the quality of AMR WB encoded speech in
          the studied conditions.</t>
        </section>

        <section anchor="opus-google-mandarin" title="Google mandarin tests">
          <t>Modern Standard Chinese - also called Mandarin - is a tonal
          language that is spoken by about 845 million persons. In past,
          codecs have been developed without consideration of the unique
          properties of tonal languages. For the testing of Opus, Jan Skoglund
          has conducted subjective listening-only tests to verify <xref
          target="Skoglund2011">whether Opus can cope well for
          Mandarin</xref>. Two tests were conducted for both narrow- and
          wide-band speech items. The test conditions of the narrow-band tests
          are given in Table <ref>google-mandarin-nb-conditions</ref> and the
          respective results in <ref>google-mandarin-nb-results</ref>. For the
          wide-band conditions and results refer to Table
          <ref>google-mandarin-wb-conditions</ref>and Table
          <ref>google-mandarin-wb-results</ref></t>

          <texttable anchor="google-mandarin-nb-conditions"
                     title="Narrowband mandarin: test conditions">
            <ttcol align="left">Condition</ttcol>

            <ttcol align="left">Value</ttcol>

            <c>Laboratory</c>

            <c>Google</c>

            <c>Examiner</c>

            <c>Jan Skoglund</c>

            <c>Date</c>

            <c>August and September 2011</c>

            <c>Methodology</c>

            <c>ITU-R BS.1534-1 (MUSHRA)</c>

            <c>Reference items</c>

            <c>Two male and two female speakers from ITU-T P.501. Two male and
            two female speakers recorded at Google at 48kHz in a room with low
            background noise.</c>

            <c>Listeners</c>

            <c>21 listeners after post-screening / no listeners rejected /
            untrained Mandarin-speaking listeners</c>

            <c>Anchor 1</c>

            <c>Reference file lowpass-filtered at 3.5 kHz (LP 3.5)</c>

            <c>Anchor 2</c>

            <c>Reference file resampled at 8 kHz, with MNRU at 15 dB SNR
            (MNRU)</c>

            <c>Test Condition 1</c>

            <c>Opus NB at 11 kbps, variable bit rate (Opus 11)</c>

            <c>Test Condition 2</c>

            <c>Speex NB at 11 kbps, variable bit rate (Speex 11)</c>

            <c>Test Condition 3</c>

            <c>iLBC at 15.2 kbps, constant bit rate (iBLC 15)</c>
          </texttable>

          <texttable anchor="google-mandarin-nb-results"
                     title="Mandarin narrowband speech: test results">
            <ttcol align="left">Test Item</ttcol>

            <ttcol align="right">Subjective BS.1534-1 Score</ttcol>

            <ttcol align="right">95% CI</ttcol>

            <c>Reference</c>

            <c>99.79</c>

            <c>0.19</c>

            <c>Opus 11</c>

            <c>77.90</c>

            <c>2.15</c>

            <c>iLBC 15</c>

            <c>76.76</c>

            <c>2.08</c>

            <c>LP 3.5</c>

            <c>76.25</c>

            <c>2.34</c>

            <c>Speex 11</c>

            <c>63.60</c>

            <c>3.30</c>

            <c>MNRU</c>

            <c>22.83</c>

            <c>2.50</c>
          </texttable>

          <texttable anchor="google-mandarin-wb-conditions"
                     title="Mandarin wideband speech: test conditions">
            <ttcol align="left">Condition</ttcol>

            <ttcol align="left">Value</ttcol>

            <c>Laboratory</c>

            <c>Google</c>

            <c>Examiner</c>

            <c>Jan Skoglund</c>

            <c>Date</c>

            <c>August and September 2011</c>

            <c>Methodology</c>

            <c>MUSHRA</c>

            <c>Reference items</c>

            <c>Two male and two female speakers from ITU-T P.501. Two male and
            two female speakers recorded at Google at 48kHz in a room with low
            background noise</c>

            <c>Listeners</c>

            <c>19 listeners after post-screening / Rejected 3 listeners having
            score correlation with the total average lower than R=0.8.</c>

            <c>Anchor 1</c>

            <c>Reference file lowpass-filtered at 3.5 kHz (LP 3.5)</c>

            <c>Anchor 2</c>

            <c>Reference file lowpass-filtered at 7 kHz (LP 7)</c>

            <c>Test Condition 1</c>

            <c>Opus WB at 19.85 kbps, variable bit rate (Opus 20)</c>

            <c>Test Condition 2</c>

            <c>Speex WB at 23.8 kbps, constant bit rate (Speex 24)</c>

            <c>Test Condition 3</c>

            <c>G.722.1 at 24 kbps, constant bit rate (G.722.1 24)</c>

            <c>Test Condition 4</c>

            <c>Opus FB at 32 kbps, constant bit rate (Opus 32)</c>

            <c>Test Condition 5</c>

            <c>G.719 at 32 kbps, constant bit rate (G.719 32)</c>
          </texttable>

          <texttable anchor="google-mandarin-wb-results"
                     title="Mandarin wideband speech: test results">
            <ttcol align="center">Test Item</ttcol>

            <ttcol align="center">Subjective BS.1587 Score</ttcol>

            <ttcol align="center">95% CI</ttcol>

            <c>Reference</c>

            <c>98.95</c>

            <c>0.59</c>

            <c>Opus 32</c>

            <c>98.13</c>

            <c>0.72</c>

            <c>G.719 32</c>

            <c>93.43</c>

            <c>1.51</c>

            <c>Opus 20</c>

            <c>81.59</c>

            <c>2.48</c>

            <c>LP 7</c>

            <c>79.51</c>

            <c>2.53</c>

            <c>G.722.1 24</c>

            <c>72.55</c>

            <c>3.06</c>

            <c>LP 3.5</c>

            <c>54.57</c>

            <c>3.44</c>

            <c>Speex 24</c>

            <c>53.63</c>

            <c>4.23</c>
          </texttable>

          <t>Under the given confidence intervals, the quality of Opus at 11
          kbps equals the quality of iLBC at 15 kbps and the quality
          aferlowpass filtering at 3.5 kHz. Speex at 11 kbps does not perform
          as well. According to the listening-only tests, Opus at 32 kbps is
          better than G.719 at 32 kbps. Opus at 20 kbps outperforms G.722.1
          and Speex at 24 kbps. If one compares the Mandarin results with
          those for English (<xref target="opus-google-narrowband"></xref> and
          <xref target="opus-google-wideband"></xref>), one can see that are
          pretty consistent. The only difference is that using English stimuli
          Opus at 20 kbps outperforms G.719 at 32 kbps. Probabily, this is due
          to the fact that Mandarin speech does not contain as many high
          frequency-rich consonants such as [s] as English.</t>
        </section>
      </section>

      <section anchor="opus-ha"
               title="HydrogenAudio stereo music listening test">
        <t>In March 2011, the HydrogenAudio community conducted a listening
        test comparing codec performance on <xref target="ha-test">stereo
        audio at 64 kb/s</xref>. The Opus codec was compared to the Apple and
        Nero implementations of HE-AAC, as well as to the Vorbis codec. The
        test included 30 audio samples, including known "hard to code" samples
        from previous HydrogenAudio listening tests.</t>

        <t>A total of 33 listeners participated in the test, 10 of which
        provided results for all the audio samples. The results of test showed
        that Opus out-performed both HE-AAC implementations as well as
        Vorbis.</t>
      </section>

      <section anchor="nokia-2011"
               title="Nokia Interspeech 2011 listening test">
        <t>In 2011, Anssi Ramo from Nokia <xref
        target="Ramo2011">submitted</xref> the results of a second listening
        test, focusing specifically on the Opus codec, to Interspeech 2011. As
        in the previous test, the methodology used was a 9-scale ACR MOS test
        with clean and noisy speech samples.</t>

        <t>The results show Opus clearly out-performing both G.722.1C and
        G.719 on clean speech at 24 kb/s and above, while on noisy speech all
        codecs and bit-rates above 24 kb/s are very close. It is also found
        that the Opus hybrid mode at 28 kb/s has quality that is very close to
        the recent G.718B standard at the same rate. At 20 kb/s, the Opus
        wideband mode also out-performs AMR-WB, while the situation is
        reversed for 12 kb/s and below. The only narrowband rate tested is 6
        kb/s, which is below what Opus targets and unsurprisingly shows poorer
        quality than AMR-NB at 5.9 kb/s.M</t>
      </section>

      <section anchor="hoene-2011"
               title="Universitaet Tuebingen stereo and binaural tests">
        <t>Modern teleconferencing system use stereo or spatialy rendered
        speech to enhance the conversation quality. Then, talkers can be
        identified according to their acoustic locations. Opus allows to
        encode speech in a stereo mode. In the tests conducted by Christian
        Hoene<xref target="Hoene2011"></xref>, the performance of Opus coding
        stereo and binaural speech was studied.</t>

        <texttable anchor="tuebingen-binaural-conditions"
                   title="Stereo and binaural speech coding: test conditions">
          <ttcol align="left">Condition</ttcol>

          <ttcol align="left">Value</ttcol>

          <c>Laboratory</c>

          <c>Univesitaet Tuebingen</c>

          <c>Examiner</c>

          <c>Christian Hoene and Mansoor Hyder</c>

          <c>Date</c>

          <c>August 2011</c>

          <c>Methodology</c>

          <c>ITU-R BS.1534-1 (MUSHRA) using a modified "rateit v0.1" software
          with German translations.</c>

          <c>Reference items</c>

          <c>One German female voice recorded in stereo (8s). Two female
          voices (stereo recording) mixed together (9 s). One moving talker
          binaural rendered with HTRF and an artificial room impulse response
          (13 s). Two voices binaural render at two different stationary
          positions. Acappella Song "Mein Fahrrad" by "Die Prinzen" (10.5s,
          mono)</c>

          <c>Listeners</c>

          <c>20 German native speakers. Age between 20 and 59 (avg. 30.55). 9
          male and 11 female. All have academic background. Three listeners
          were rejected because their rating showed a low correlation
          (R&lt;0.8) to the average ratings.</c>

          <c>Anchor</c>

          <c>Reference file lowpass-filtered at 3.5 kHz calling "sox in.wav
          -r48000 -c1 out.wav lowpass 3500"</c>

          <c>Test Condition 1</c>

          <c>Opus in the SILK mode, 12kbps, stereo, 60ms calling
          "draft-ietf-codec-opus-07/test_opus 0 48000 2 12000 -cbr -framesize
          60 -bandwidth NB"</c>

          <c>Test Condition 2</c>

          <c>Opus in the SILK mode, 16kbps, stereo, 20ms calling
          "draft-ietf-codec-opus-07/test_opus 0 48000 2 16000 -cbr -framesize
          20 -bandwidth WB"</c>

          <c>Test Condition 3</c>

          <c>Opus in the HYBRID mode, 32kbps, stereo, 20ms calling
          "draft-ietf-codec-opus-07/test_opus 0 48000 2 32000 -cbr -framesize
          20 -bandwidth FB"</c>

          <c>Test Condition 4</c>

          <c>Opus in the CELT mode, 64kbps, stereo, 20ms calling
          "draft-ietf-codec-opus-07/test_opus 1 48000 2 64000 -cbr -framesize
          20 -bandwidth FB"</c>

          <c>Test Condition 5</c>

          <c>AMR-WB+ at 12kbps, 80ms using 26304_ANSI-C_source_code_v6_6_0:
          Arguments: -rate 12</c>

          <c>Test Condition 6</c>

          <c>AMR-WB+ at 15.2kbps, 80ms using 26304_ANSI-C_source_code_v6_6_0:
          Arguments: -rate 16</c>

          <c>Test Condition 7</c>

          <c>AMR-WB+ at 32kbps, 60ms using 26304_ANSI-C_source_code_v6_6_0:
          Arguments: -rate 32</c>
        </texttable>

        <texttable anchor="tuebingen-binaural-results"
                   title="Binaural Speech: Test Results">
          <ttcol align="left">Test Item</ttcol>

          <ttcol align="right">Subjective BS.1534-1 Score</ttcol>

          <ttcol align="right">95% CI</ttcol>

          <c>Reference</c>

          <c>97.36</c>

          <c>1.31</c>

          <c>Opus 64</c>

          <c>95.58</c>

          <c>1.76</c>

          <c>AMR-WB+ 32</c>

          <c>80.11</c>

          <c>4.79</c>

          <c>Opus 32</c>

          <c>55.42</c>

          <c>5.96</c>

          <c>AMR-WB+ 16</c>

          <c>49.69</c>

          <c>6.05</c>

          <c>LP 3.5</c>

          <c>48.35</c>

          <c>4.50</c>

          <c>Opus 16</c>

          <c>39.31</c>

          <c>4.80</c>

          <c>AMR-WP+ 12</c>

          <c>35.40</c>

          <c>5.79</c>

          <c>Opus 12</c>

          <c>16.99</c>

          <c>3.49</c>
        </texttable>

        <t>According to the test results, Opus transmits binaural content well
        at 64kbps. The other Opus results are not valid anymore as the codec
        implementation have been updated.</t>
      </section>
    </section>

    <section title="Conclusion on the requirements">
      <t>The requirements call for the Opus codec to be better than Speex and
      iLBC in narrowband mode, better than Speex and G.722.1 in wideband mode,
      and better than G.722.1C in super-wideband/fullband mode.</t>

      <section title="Comparison to Speex (narrowband)">
        <t>The Opus codec was compared to Speex in narrowband mode in the
        <xref target="opus-google-narrowband">Google narrowband test</xref>.
        This test showed that Opus at 11 kb/s was significantly better than
        Speex at the same rate. In fact, Opus at 11 kb/s was tied with the 3.5
        low-pass of the original. Considering the results, we conclude that
        the Opus codec is better than the Speex codec.</t>
      </section>

      <section title="Comparison to iLBC">
        <t>The Opus codec was compared to iLBC in the <xref
        target="opus-google-narrowband">Google narrowband test</xref>. This
        test showed that Opus at 11 kb/s was significantly better than iLBC
        running at 15 kb/s. Considering the results, we conclude that the Opus
        codec is better than the iLBC codec.</t>
      </section>

      <section title="Comparison to Speex (wideband)">
        <t>The Opus codec was compared to Speex in wideband mode in the <xref
        target="opus-google-wideband">Google wideband and fullband
        test</xref>. This test showed that Opus at 20 kb/s was significantly
        better than Speex at at 24 kb/s. In fact, Opus at 20 kb/s was better
        than the 7 kHz low-pass of the original. These results are consistent
        with an earlier <xref target="silk-dynastat">Dynastat test</xref> that
        also concluded that SILK had significantly higher quality than Speex
        in wideband mode at the same bit-rate. Considering the results, we
        conclude that the Opus codec is better than the Speex codec for
        wideband.</t>
      </section>

      <section title="Comparison to G.722.1">
        <t>In the <xref target="opus-google-wideband">Google wideband and
        fullband test</xref>, Opus at 20 kb/s was shown to significantly
        out-perform G.722.1 operating at 24 kb/s. An indirect comparison point
        also comes from the <xref target="nokia-2011">Nokia Interspeech 2011
        listening test</xref> that shows Opus out-performing AMR-WB at 20
        kb/s, while AMR-WB is known to out-perform G.722.1. Considering these
        results, we conclude that the Opus codec is better than the G.722.1
        codec for wideband.</t>
      </section>

      <section title="Comparison to G.722.1C">
        <t>Opus has been compared to G.722.1C in multiple listening tests. As
        early as 2008, an <xref target="celt-aslp">old version of the CELT
        codec</xref> using very short frames was found to have higher quality
        than G.722.1C at 48 kb/s. More recently, the <xref
        target="nokia-2011">Nokia Interspeech 2011 listening test</xref>
        showed that Opus out-performed G.722.1C at 24 kb/s, 32 kb/s, and 48
        kb/s. We thus conclude that the Opus codec is better than the G.722.1C
        codec for superwideband/fullband audio.</t>
      </section>

      <section title="Comparison to AMR-NB">
        <t>In the <xref target="opus-google-narrowband">Google narrowband
        test</xref>, Opus was shown to out-perform AMR-NB at 12 kb/s. On the
        other hand, in the <xref target="nokia-2011">Nokia Interspeech 2011
        listening test</xref>, AMB-NB was found to have better quality than
        Opus at 6 kb/s. This indicates that Opus is better than AMR-NB at
        higher rates and worse at lower rates, which is to be expected given
        Opus' emphasis on higher quality and higher rates.</t>
      </section>

      <section title="Comparison to AMR-WB">
        <t>In the <xref target="opus-google-wideband">Google wideband and
        fullband test</xref>, Opus at 20 kb/s was shown to out-perform AMR-WB
        at the same rate. This was also confirmed by the <xref
        target="nokia-2011">Nokia Interspeech 2011 listening test</xref>, with
        also found AMR-WB to out-perform Opus at 12 kb/s and below. As with
        AMR-NB, we conclude that Opus is better than AMR-WB at higher rates
        and worse at lower rates.</t>
      </section>
    </section>

    <section anchor="Security Considerations" title="Security Considerations">
      <t>No security considerations.</t>
    </section>

    <section title="IANA Considerations ">
      <t>This document has no actions for IANA.</t>
    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>The authors would like to thank Anssi Ramo and the HydrogenAudio
      community, who conducted some of the Opus listening test cited in this
      draft.</t>
    </section>
  </middle>

  <back>
    <section anchor="pre-opus" title="Pre-Opus listening tests">
      <t>Several listening tests have been performed on the SILK and CELT
      codecs prior to them being merged as part of the Opus codec.</t>

      <section anchor="silk-dynastat" title="SILK Dynastat listening test">
        <t>The original (pre-Opus) SILK codec was characterized in a <xref
        target="SILK-Dynastat">Dynastat listening test</xref>. The test
        included 32 conditions with 4 male and 4 female talkers. The test
        signals were wideband speech with and without office background noise
        at 15 dB SNR. Packet loss was tested at 2, 5, and 10% loss rates. The
        bitrates ranged from 8.85 kb/s to 64 kb/s. The codecs included in the
        test were SILK-WB, AMR-WB, Speex-WB and G.722 (which ran at 64
        kb/s).</t>

        <t>The results showed that for clean speech (1) SILK out-performs
        AMR-WB at all bit-rates except 8.85 kb/s (which was a tie); (2) SILK
        out-performs Speex at all bit-rates; and (3) SILK running at 18.25
        kb/s and above out-performs G.722 at 64 kbps. For noisy speech, tested
        at 18.25 kb/s, SILK is tied with AMR-WB, and out-performs Speex. For
        2, 5 and 10% packet loss, tested at 18.25 kb/s, SILK out-performs both
        AMR-WB and Speex in all conditions.</t>
      </section>

      <section anchor="silk-deutsche-telekom"
               title="SILK Deutsche Telekom test">
        <t>In 2010 Deutsche Telekom published <xref
        target="Wustenhagen2010">results</xref> of their evaulation of
        super-wideband speech and audio codecs. The test included the version
        of SILK submitted to the IETF. The results showed that for clean
        speech (item "speechsample") SILK was tied with AMR-WB and G.718, and
        out-performed Speex. For noisy speech (item "arbeit") SILK
        out-performed AMR-WB and G.718 at 12 and 24 kb/s, and Speex at all
        bitrates. At bitrates above 24 kb/s SILK and G.718 were tied.</t>
      </section>

      <section anchor="silk-nokia" title="SILK Nokia test">
        <t>In 2010, Anssi Ramo from Nokia <xref
        target="Ramo2010">presented</xref> the results of a listening test
        focusing on open-source codecs at Interspeech 2010. The methodology
        used was a 9-scale ACR MOS test with clean and noisy speech
        samples.</t>

        <t>It was noted in the test that:</t>

        <t>"Especially at around 16 kbit/s or above Silk is better than AMR-WB
        at comparable bitrates. This is due to the fact that Silk wideband is
        critically sampled up to 8 kHz instead of ITU- T or 3GPP defined 7
        kHz. This added bandwidth (from 7 to 8 kHz) shows up in the results
        favourable to Silk. It seems that Silk provides quite artifact free
        voice quality for the whole 16- 24 kbit/s range with WB signals. At 32
        and 40 kbit/s Silk is SWB and competes quite equally against G.718B or
        G.722.1C although having a slightly narrower bandwidth than the ITU-T
        standardized codecs."</t>
      </section>

      <section anchor="celt-aslp" title="CELT 0.3.2 listening test">
        <t>The first listening tests conducted on CELT version 0.3.2 in 2009
        and <xref target="valin2010">published in 2010</xref> included AAC-LD
        (Apple), G.722.1C and MP3 (Lame). Two MUSHRA tests were conducted: a
        48 kb/s test and a 64 kb/s test, both at a 44.1 kHz sampling rate.
        CELT was used with 256-sample frames (5.8 ms). All codecs used
        constant bit-rate (CBR). The algorithmic delay was 8.7 ms for CELT,
        34.8 ms for AAC-LD, 40 ms for G.722.1C and more than 100 ms for
        MP3.</t>

        <t>The 48 kb/s test included two clean speech samples (one male, one
        female) from the EBU SQAM database, four clean speech files (two male,
        two female) from the NTT multi-lingual speech database for
        telephonometry, and two music samples. In this test, CELT
        out-performed AAC-LD, G.722.1C and MP3.</t>

        <t>The 64 kb/s test included two clean speech samples (one male, one
        female) from the EBU SQAM database, and six music files. In this test,
        AAC-LD out-performed CELT, but CELT out-performed both MP3 and
        G.722.1C (running at its highest rate of 48 kb/s).</t>
      </section>

      <section anchor="celt-eusipco" title="CELT 0.5.0 listening test">
        <t>Another CELT listening test was conducted in 2009 on version 0.5.0
        and <xref target="valin2009">presented at EUSIPCO 2009</xref>. In that
        test, CELT was compared to G.722.1C and to the Fraunhofer Ultra
        Low-Delay (ULD) codec on 9 audio samples: 2 clean speech samples and 7
        music samples. At 64 kb/s with 5.3 ms frames, CELT clearly
        out-performed G.722.1C running at 48 kb/s with 20 ms frames. Also, at
        96 kb/s and equal frame size (2.7 ms), CELT clearly out-performed the
        ULD codec.</t>
      </section>
    </section>

    <section anchor="opus-nonfinal"
             title="Opus listening tests on non-final bit-stream">
      <t>The following listening tests were conducted on the Opus codec on
      versions prior to the bit-stream freeze. While Opus has evolved since
      these tests were conducted, the results should be considered as a <spanx
      style="emph">lower bound</spanx> on the quality of the final codec.</t>

      <section anchor="opus-maastricht" title="First hybrid mode test">
        <t>In July 2010, the Opus codec authors conducted a preliminary MUSHRA
        listening test to evaluate the quality of the recently created
        "hybrid" mode combining the SILK and CELT codecs. That test was
        conducted at 32 kb/s and compared the following codecs: <list
            style="symbols">
            <t>Opus hybrid mode (fullband)</t>

            <t>G.719 (fullband)</t>

            <t>CELT (fullband)</t>

            <t>SILK (wideband)</t>

            <t>BroadVoice32 (wideband)</t>
          </list></t>

        <t>The test material consisted of two English speech samples from the
        EBU SQAM (one male, one female) database and six speech samples (three
        male, three female) from the NTT multi-lingual speech database for
        telephonometry. Although only eight listeners participated to the
        test, the difference between the Opus hybrid mode and all other codecs
        was large enough to obtain 95% confidence that the Opus hybrid mode
        provided better quality than all other codecs tested. This test is of
        interest because it shows that the hybrid clearly out-performs the
        codecs that it combines (SILK and CELT). It also out-performs G.719,
        which is the only fullband interactive codec standardized by the
        ITU-T. These results were <xref target="Maastricht-78">
        presented</xref> at the 78th IETF meeting Maastricht.</t>
      </section>

      <section anchor="opus-broadcom" title="Broadcom stereo music test">
        <t>In December 2010, Broadcom conducted an ITU-R BS.1116-style
        subjective listening test comparing different configurations of the
        CELT-only mode of the IETF Opus codec along with MP3 and AAC-LC. The
        test included stereo 10 audio samples sampled at 44.1 kHz and
        distributed as follows: <list style="symbols">
            <t>2 pure speech</t>

            <t>2 vocal</t>

            <t>2 solo instruments</t>

            <t>1 rock-and-roll</t>

            <t>1 pop</t>

            <t>1 classical orchestra</t>

            <t>1 jazz</t>
          </list></t>

        <t>A total of 17 listeners participated to the test. The results of
        the test are a available on the testing slides <xref
        target="Prague-80"> presented at the Prague meeting</xref>. Although
        at the time, Opus was not properly optimised for 44.1 kHz audio, the
        quality of the Opus codec at 96 kb/s with 22 ms frame was
        significantly better than MP3 and only slightly worse than AAC-LC.
        Even in ultra low-delay mode (5.4 ms), Opus still outperformed MP3.
        The test also confirmed the usefulness of the prefilter/postfilter
        contribution by Raymond Chen, showing that this contribution
        significantly improves quality for small frames (long frames were not
        tested with the prefilter/postfilter disabled).</t>
      </section>
    </section>

    <section anchor="field" title="In-the-field testing">
      <t>Various versions of Opus (or SILK/CELT components) are currently in
      use in production in the following applications: <list style="symbols">
          <t>Skype: VoIP client used by hundreds of millions of people</t>

          <t>Steam: Gaming distribution and communications platform with over
          30 million users</t>

          <t>Mumble: Gaming VoIP client with more than 200 thousand users</t>

          <t>Soundjack: Client for live network music performances</t>

          <t>Freeswitch: Open-source telephony platform</t>

          <t>Ekiga: Open-source VoIP client</t>

          <t>CHNC: Radio station using CELT for its studio-transmitter
          link</t>
        </list></t>
    </section>

    <references title="Informative References">
      <reference anchor="valin2010">
        <front>
          <title>A High-Quality Speech and Audio Codec With Less Than 10 ms
          delay</title>

          <author fullname="Jean-Marc Valin" initials="J.M." surname="Valin">
            <organization />
          </author>

          <author fullname="Timothy Terriberry" initials="T."
                  surname="Terriberry">
            <organization />
          </author>

          <author fullname="Christopher Montgonery" initials="C."
                  surname="Montgomery">
            <organization />
          </author>

          <author fullname="Gregory Maxwell" initials="G." surname="Maxwell">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="2010" />

        <format target="http://jmvalin.ca/papers/celt_tasl.pdf" type="PDF" />
      </reference>

      <reference anchor="valin2009">
        <front>
          <title>A High-Quality Speech and Audio Codec With Less Than 10 ms
          delay</title>

          <author fullname="Jean-Marc Valin" initials="J.M." surname="Valin">
            <organization />
          </author>

          <author fullname="Timothy Terriberry" initials="T."
                  surname="Terriberry">
            <organization />
          </author>

          <author fullname="Gregory Maxwell" initials="G." surname="Maxwell">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="2010" />

        <format target="http://jmvalin.ca/papers/celt_eusipco2009.pdf"
                type="PDF" />
      </reference>

      <reference anchor="Wustenhagen2010">
        <front>
          <title>Evaluation of Super-Wideband Speech and Audio Codecs</title>

          <author fullname="Ulf Wüstenhagen" initials="U."
                  surname="Wüstenhagen">
            <organization />
          </author>

          <author fullname="Bernhard Feiten" initials="B." surname="Feiten">
            <organization />
          </author>

          <author fullname="Jens Kroll" initials="J." surname="Kroll">
            <organization />
          </author>

          <author fullname="Alexander Raake" initials="A." surname="Raake">
            <organization />
          </author>

          <author fullname="Marcel Wältermann" initials="M."
                  surname="Wältermann">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="2010" />
      </reference>

      <reference anchor="Ramo2010">
        <front>
          <title>Voice Quality Evaluation of Recent Open Source Codecs</title>

          <author fullname="Anssi Ramo" initials="A." surname="Ramo">
            <organization />
          </author>

          <author fullname="Henri Toukomaa" initials="H." surname="Toukomaa">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="2010" />

        <format target="http://research.nokia.com/files/public/%5B12%5D_Interspeech%202010_Voice%20Quality%20Evaluation%20of%20Recent%20Open%20Source%20Codecs.pdf"
                type="PDF" />
      </reference>

      <reference anchor="Ramo2011">
        <front>
          <title>Voice Quality Characterization of IETF Opus Codec</title>

          <author fullname="Anssi Ramo" initials="A." surname="Ramo">
            <organization />
          </author>

          <author fullname="Henri Toukomaa" initials="H." surname="Toukomaa">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="2011" />
      </reference>

      <reference anchor="Maastricht-78">
        <front>
          <title>Codec Prototype</title>

          <author fullname="Jean-Marc Valin" initials="J.M." surname="Valin">
            <organization />
          </author>

          <author fullname="Koen Vos" initials="K." surname="Vos">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="2010" />

        <format target="http://www.ietf.org/proceedings/78/slides/codec-0.pdf"
                type="PDF" />
      </reference>

      <reference anchor="Prague-80">
        <front>
          <title>Testing results</title>

          <author fullname="Raymond Chen" initials="R." surname="Chen">
            <organization />
          </author>

          <author fullname="Timothy Terriberry" initials="T."
                  surname="Terriberry">
            <organization />
          </author>

          <author fullname="Gregory Maxwell" initials="G." surname="Maxwell">
            <organization />
          </author>

          <author fullname="Jan Skoglund" initials="J." surname="Skoglund">
            <organization />
          </author>

          <author fullname="Hoang Thi Minh Nguyet" initials="H."
                  surname="Nguyet">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="2011" />

        <format target="http://www.ietf.org/proceedings/80/slides/codec-4.pdf"
                type="PDF" />
      </reference>

      <reference anchor="SILK-Dynastat">
        <front>
          <title>SILK Datasheet</title>

          <author fullname="Skype" surname="Skype">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="2009" />

        <format target="http://developer.skype.com/resources/SILKDataSheet.pdf"
                type="PDF" />
      </reference>

      <reference anchor="ha-test">
        <front>
          <title>Results of the public multiformat listening test @ 64
          kbps</title>

          <author fullname="Igor Dyakonov" surname="Dyakonov">
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="2011" />

        <format target="http://listening-tests.hydrogenaudio.org/igorc/results.html"
                type="PDF" />
      </reference>

      <reference anchor="Skoglund2011">
        <front>
          <title>Listening tests of Opus at Google</title>

          <author fullname="Jan Skoglund" surname="Skoglund">
            <organization>Google</organization>
          </author>

          <date day="13" month="September" year="2011" />
        </front>

        <format target="http://www.ietf.org/mail-archive/web/codec/current/pdf1TrCfaNJE6.pdf"
                type="PDF" />
      </reference>

      <reference anchor="Hoene2011">
        <front>
          <title>MUSHRA Listening Tests - Focusing on Stereo Voice
          Coding</title>

          <author fullname="Christian Hoene" surname="Hoene">
            <organization>Universitaet Tuebingen</organization>
          </author>

          <author fullname="Mansoor Hyder" surname="Hyder">
            <organization>Universitaet Tuebingen</organization>
          </author>

          <date day="28" month="August" year="2011" />
        </front>

        <format target="http://www.ietf.org/mail-archive/web/codec/current/pdfocFkgWnGqi.pdf"
                type="PDF" />
      </reference>
    </references>
  </back>
</rfc>

