Re: [codec] Opus comparision test plan

Paul Coverdale <coverdale@sympatico.ca> Tue, 16 April 2013 23:27 UTC

Return-Path: <coverdale@sympatico.ca>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2522D21F97A2 for <codec@ietfa.amsl.com>; Tue, 16 Apr 2013 16:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqKTw3XsHq6g for <codec@ietfa.amsl.com>; Tue, 16 Apr 2013 16:27:45 -0700 (PDT)
Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by ietfa.amsl.com (Postfix) with ESMTP id 0920521F9793 for <codec@ietf.org>; Tue, 16 Apr 2013 16:27:44 -0700 (PDT)
Received: from BLU0-SMTP80 ([65.55.111.72]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Apr 2013 16:27:43 -0700
X-EIP: [Wb6Shj2H98VY7xqKTxtXHe8ZHOduzUBx]
X-Originating-Email: [coverdale@sympatico.ca]
Message-ID: <BLU0-SMTP8054D9BBD9A419B8716D06D0CD0@phx.gbl>
Received: from PaulNewPC ([74.15.60.88]) by BLU0-SMTP80.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Apr 2013 16:27:41 -0700
From: Paul Coverdale <coverdale@sympatico.ca>
To: 'Jean-Marc Valin' <jmvalin@jmvalin.ca>, 'Christian Hoene' <hoene@uni-tuebingen.de>
References: <016f01ce3a76$14577170$3d065450$@uni-tuebingen.de> <516D9A20.6060508@jmvalin.ca>
In-Reply-To: <516D9A20.6060508@jmvalin.ca>
Date: Tue, 16 Apr 2013 19:27:37 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac460VBLKjT3JEQ8Ra6Ml/u/14JGjwAEnixg
Content-Language: en-us
X-OriginalArrivalTime: 16 Apr 2013 23:27:41.0577 (UTC) FILETIME=[FD919F90:01CE3AF9]
Cc: alfons.martin@symonics.com, codec@ietf.org, patrick.schreiner@symonics.com
Subject: Re: [codec] Opus comparision test plan
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 23:27:46 -0000

Hi Christian,

Yes, I think there is still some work to be done on the plan, I noticed for
example that input level and listening level still need to be defined. And
why are you using MUSHRA? It may be quite time-consuming with a large number
of conditions.

But just to comment on some of the points raised by Jean-Marc:
- we need to be consistent about the input filtering. We can't use different
bandwidths for Opus and AMR-WB.
- I don't understand the point about making sure to tell the Opus encoder
what the percentage of loss is so it can optimize the encoding for it. What
happens in practice when the loss percentage isn't known?


Cheers,

...Paul


>-----Original Message-----
>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf
>Of Jean-Marc Valin
>Sent: Tuesday, April 16, 2013 2:36 PM
>To: Christian Hoene
>Cc: alfons.martin@symonics.com; codec@ietf.org;
>patrick.schreiner@symonics.com
>Subject: Re: [codec] Opus comparision test plan
>
>Christian,
>
>I was only able to look at your plan quickly but still found many issues
>with it. I think you should take your time to fix those and also all the
>ones I'm sure I missed. So far...
>
>== AMR-WB test ==
>
>- You should use 8 kHz bandwidth for Opus. Opus it not restricted to 7
>kHz and low-pass filtering will hurt quality.
>- For AMR-WB the 8.85 mode is "intended to be used only temporarily
>during severe radio channel conditions or during network congestion", so
>you should probably test the 18.25 kbps mode instead.
>- It's not clear from your document, but Opus should use VBR
>- If you're going to test packet loss, there should be at least one test
>with FEC -- probably the 23.85 one
>- Make sure to tell the Opus encoder what the percentage of loss is so
>it can optimize the encoding for it.
>
>== AAC-ELD test ==
>
>- Some of the rates in the test are in the bitrates where both codecs
>are expected to be "falling apart", so we will not learn much there
>(really bad quality vs absolutely terrible doesn't help because people
>don't want either).
>- Some of the rates are way too high for listeners to be able to
>reliably judge. These are guaranteed to end up with everything tied
>unless there's a problem with the test.
>- Using SBR at 128 kb/s for ELD is useless and probably harming quality
>- There is no reason to test music at 24/32 kHz because music is almost
>always available at 48 kHz, so it would hurt to artificially limit the
>signal.
>- When considering CBR vs VBR you have to consider the delay, but also
>the different meanings these have between codecs. I'm not familiar with
>the details, but what most codecs like AAC-LC and MP3 call "CBR"
>actually uses a bit reservoir and is equivalent to Opus "Constrained
>VBR".
>- The choice of music samples is critical. Just that choice can
>sometimes determine the outcome of a music test. You need a wide variety
>of samples to get something statistically significant. It's also
>probably a good idea to use "normal" samples at low rates and "hard"
>samples at high rate.
>- I'd need to recheck the MUSHRA spec, but I'm pretty sure mixing mono
>and stereo in the same session is highly discouraged.
>- Not sure in what form, but it might be worth testing the pre-1.1
>encoder of Opus.
>
>In general, for mono music, I'd recommend restricting yourself to rates
>between 40 and 64 kb/s. For stereo music, I'd stay within 56-96 kb/s.
>Outside of this you're either in the falling apart region or in the
>"nearly transparent for most listeners".
>
>Also, I hope you will fix your methodology from the previous test to
>actually tell the listeners about the hidden reference.
>
>In any case, this is only what I've been able to find with a quick look.
>It's probably good to have wider review once you fix everything.
>
>	Jean-Marc
>
>On 04/16/2013 03:43 AM, Christian Hoene wrote:
>> Hello,
>>
>> as for next week, we place to compare Opus against AMR-WB (with noisy
>> signals) and AAC-eLD. Attached our preliminary test plan. Feel free to
>> criticize it.
>>
>> In addition to the comparison, we will do some Opus characterization
>> (Opus vs. Opus). More to about this test later.
>>
>> With best regards,
>>
>> Christian Hoene
>>
>>
>>
>>
>> Symonics GmbH
>> Sand 13
>> 72076 Tübingen
>> Tel +49 7071 5681302
>> Fax +49 7071 5681309
>> Email: christian.hoene@symonics.com
>>
>> Geschäftsführer/Presidents: Michael Haun, Dr. Christian Hoene, Patrick
>> Schreiner Sitz der Gesellschaft/Place of Business: Tübingen
>> Registereintrag/Commercial Register: Amtsgericht Stuttgart, HRB 739918
>>
>>
>>
>>
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>>
>
>_______________________________________________
>codec mailing list
>codec@ietf.org
>https://www.ietf.org/mailman/listinfo/codec