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

Jean-Marc Valin <jmvalin@jmvalin.ca> Fri, 08 April 2011 01:51 UTC

Return-Path: <jmvalin@jmvalin.ca>
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 A5DDB3A69A0 for <codec@core3.amsl.com>; Thu, 7 Apr 2011 18:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 qDyNqzOc+s8h for <codec@core3.amsl.com>; Thu, 7 Apr 2011 18:51:41 -0700 (PDT)
Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id B54F73A6834 for <codec@ietf.org>; Thu, 7 Apr 2011 18:51:37 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_9wA00ruCi/JWB2e3hh0CKA)"
Received: from [192.168.1.14] ([184.160.206.46]) by vl-mh-mrz21.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LJB00GQG982SV10@vl-mh-mrz21.ip.videotron.ca> for codec@ietf.org; Thu, 07 Apr 2011 21:52:51 -0400 (EDT)
Message-id: <4D9E6A7E.4060204@jmvalin.ca>
Date: Thu, 07 Apr 2011 21:53:02 -0400
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
To: Roman Shpount <roman@telurix.com>
References: <BANLkTimeDEPY8va6_MQVztn3YGyTZ2LmVw@mail.gmail.com> <607546550.2587173.1302222242947.JavaMail.root@lu2-zimbra> <BANLkTinTZUyRBYUQq7igHB74r8cXsUMPCg@mail.gmail.com>
In-reply-to: <BANLkTinTZUyRBYUQq7igHB74r8cXsUMPCg@mail.gmail.com>
Cc: codec@ietf.org, Stephen Botzko <stephen.botzko@gmail.com>
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: Fri, 08 Apr 2011 01:51:43 -0000

On 11-04-07 08:50 PM, Roman Shpount wrote:
> Quoting Nokia's paper: "Codecs done without thorough standardization 
> effort like Speex and iLBC offer significantly reduced efficiency, 
> probably due to much lesser optimization, *listening tests* and IPR 
> free design." Testing is an important part of development and 
> standardization process for a CODEC.

I don't think I'm qualified to comment on iLBC, but when it comes to 
Speex, I think I know better than anyone why it does not perform as well 
as codecs like AMR. Probably the main reason is quite simple: it was 
written by a PhD student (me) with no prior experience in speech coding 
as a side project in during his spare time. Another reason is the fact 
that the original goal was just to get something decent and free out 
there, not to beat (or even equal) the state-of-the-art. Avoiding 
encumbered technology (e.g. ACELP) also had something to do with it, 
along with the fact that I did almost all the code by myself. Lack of 
listening test at the end of the process was totally irrelevant. Even if 
I had all the listening tests in the world at that point, it wouldn't 
have changed anything.

This is the exact opposite of what has happened so far with Opus. I'm 
obviously much more experienced than when I started Speex in 2002, but 
I'm also no longer working by myself. There have been other developers 
(e.g. Tim and Greg) involved right from the start, and since the codec 
WG was created, there's been a lot of collaboration between all the 
companies/developers involved in Opus. This has let to many improvements 
to the components that were originally the SILK and CELT codecs. The 
last difference is testing. But not the type of testing that's been 
discussed in this thread. Spending a lot of time to just get back a 
handful of numbers is mostly useless in terms of improving a codec. The 
kind of testing that has allowed us to make huge progress is of a 
different kind. More along the lines of "I tried playing live with my 
friends and all the instruments sounded great except for my bass guitar" 
(true story) or "I used this on this dong from my collection and at 
exactly this point in the file I hear this funny artefact". This is the 
kind of testing that has lead to *huge* improvements to Opus.

Cheers,

     Jean-Marc