Re: [codec] A concrete proposal for requirements and testing

Anisse Taleb <anisse.taleb@huawei.com> Thu, 07 April 2011 06:31 UTC

Return-Path: <anisse.taleb@huawei.com>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9577F28C0D9 for <codec@core3.amsl.com>; Wed, 6 Apr 2011 23:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.348
X-Spam-Level:
X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEDx4YrCMgy4 for <codec@core3.amsl.com>; Wed, 6 Apr 2011 23:31:45 -0700 (PDT)
Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by core3.amsl.com (Postfix) with ESMTP id 886DB3A6876 for <codec@ietf.org>; Wed, 6 Apr 2011 23:31:45 -0700 (PDT)
Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ900EZHRJPB3@lhrga02-in.huawei.com> for codec@ietf.org; Thu, 07 Apr 2011 07:33:26 +0100 (BST)
Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LJ9005KKRJPUT@lhrga02-in.huawei.com> for codec@ietf.org; Thu, 07 Apr 2011 07:33:25 +0100 (BST)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML201-EDG.china.huawei.com (172.18.7.188) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Apr 2011 07:33:15 +0100
Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 07 Apr 2011 07:33:24 +0100
Date: Thu, 07 Apr 2011 06:33:23 +0000
From: Anisse Taleb <anisse.taleb@huawei.com>
In-reply-to: <4D9CB1AA.3050101@octasic.com>
X-Originating-IP: [10.200.218.220]
To: Jean-Marc Valin <jean-marc.valin@octasic.com>
Message-id: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC4CB2@LHREML503-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-US
Content-transfer-encoding: 7bit
Accept-Language: en-GB, en-US
Thread-topic: [codec] A concrete proposal for requirements and testing
Thread-index: Acvvs3HtzlEZPvSGSjK6pDMAnYZZngEfHGZwABQq1QAAGjGb0A==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <64212FE1AE068044AD567CCB214073F123A10234@MAIL2.octasic.com> <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC47FA@LHREML503-MBX.china.huawei.com> <4D9CB1AA.3050101@octasic.com>
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] A concrete proposal for requirements and testing
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 07 Apr 2011 06:31:46 -0000

Dear JM,
> >>1) The narrowband test showed that Opus had higher quality than Speex at
> > 11 kb/s. Does anyone disagree that this is sufficient to meet the Sec
> > 4.2 requirement of out-performing Speex in narrowband mode?
> >
> >>2) The narrowband test showed that Opus had higher quality at 11 kb/s
> > than iLBC at 15 kb/s. Does anyone disagree that this is sufficient to
> > meet the Sec 4.2 requirement of out-performing iLBC.
> >
> > The tests conducted by Jan were performed with clean speech only (to the
> > best of my knowledge), in addition the methodology used (MUSHRA) is
> > admittedly limited when it comes to testing narrowband signals and
> > especially speech. Moreover, I am not sure as to the use of different
> > native language listeners. The test is useful in itself, however, more
> > is needed in order to reach the conclusion you claim.
> 
> Thank you for answering my questions. So I understand that what you
> would like to see is a MOS-type listening test with 40-60 listeners
> (from memory, number quoted by Paul Coverdale at the codec dinner) in
> both English and (I assume) Chinese. Is that correct? Other things that
> should be included for narrowband in your opinion?

The languages used for testing will depend on the labs participating in the testing,
I would not explicitly suggest English and Chinese at this point. 

For the number of listeners, we need to balance the cost of testing and the required accuracy of the test and the methodology used. I would not venture in setting the exact number of listeners, but requiring a minimum of say 24 listeners could be reasonable.
 
> 
> >>3) There have been no formal comparison with AMR-NB yet. What do you
> > think would be sufficient to assess the quality of Opus compared to AMR-
> NB?
> >
> > Not sure what the question means, as was discussed during the meeting, I
> > think the inclusion and comparison to state of the art codecs, including
> > AMR-NB, is a must in order to fully assess the quality of Opus.
> 
> In the original email, Koen and I were proposing to include "no worse
> than AMB-NB" as a desirable *objective* (rather than a hard
> requirement), as proposed by Paul Coverdale during the meeting.

My understanding of the concept of "objectives" is similar to that of a "Bonus", i.e. we require the codec to have certain "requirements" and would like, as a "bonus", to have more than just fulfilling the requirements.
As you phrased it, what would be the requirement on Opus wrt. AMR if NWT is the objective?

> 
> >>4) The wideband test showed that Opus at 19.85 kb/s had higher quality
> > than Speex-WB at 24 kb/s. Does anyone disagree that this is sufficient
> > to meet the Sec 4.2 requirement of out-performing Speex in wideband mode?
> >
> >>5) The wideband test showed that Opus at 19.85 kb/s had higher quality
> > than G.722.1 at 24 kb/s. Does anyone disagree that this is sufficient to
> > meet the Sec 4.2 requirement of out-performing G.722.1?
> >>6) The wideband test showed that Opus at 19.85 kb/s had higher quality
> > than AMR-WB at 19.85 kb/s. Does anyone disagree that this is sufficient
> > to concluded that the proposed "nice to have" objective of "no worse
> > than AMR-WB" is met?
> >
> > Same comment as for 1) and 2), higher quality cannot be concluded on a
> > such a restrictive test set.
> 
> So for wideband, my understanding is that you'd also like to see a
> MOS-type listening test with 40-60 listeners in both English and
> Chinese. Is that correct? Anything else on your list?
> 

Correct, also all item types should be considered, i.e.  clean, noisy, reverberant speech with and without interfering talker, music, speech and music mixed.


> >>7) The fullband test showed that Opus at 32 kb/s had higher quality than
> > G.719 at 32 kb/s. Does anyone disagree that this is sufficient to meet
> > the Sec 4.2 requirement of out-performing G.722.1C, considering that
> > G.719 has already been shown to out-perform G.722.1C
> >
> > Not strongly against taking such shortcuts, however, please consider
> > that G.719 has been tested with many signals including reverberant
> > speech, background noise conditions etc...
> 
> OK. So I understand that the main issues you have are with narrowband
> and wideband, right?

Some of the issues apply equally on all bandwidths, so the issues are not only for wideband and narrowband.


Kind regards,
/Anisse