Re: [codec] draft test and processing plan for the IETF Codec

Jean-Marc Valin <jmvalin@jmvalin.ca> Sat, 16 April 2011 13:56 UTC

Return-Path: <jmvalin@jmvalin.ca>
X-Original-To: codec@ietfc.amsl.com
Delivered-To: codec@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 55720E06DD for <codec@ietfc.amsl.com>; Sat, 16 Apr 2011 06:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iL0JkHeJfJSK for <codec@ietfc.amsl.com>; Sat, 16 Apr 2011 06:56:27 -0700 (PDT)
Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by ietfc.amsl.com (Postfix) with ESMTP id 830C8E06B5 for <codec@ietf.org>; Sat, 16 Apr 2011 06:56:27 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Received: from [192.168.1.14] ([184.160.206.46]) by VL-MR-MRZ22.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LJR00B320222I20@VL-MR-MRZ22.ip.videotron.ca> for codec@ietf.org; Sat, 16 Apr 2011 09:56:26 -0400 (EDT)
Message-id: <4DA99FF7.4000406@jmvalin.ca>
Date: Sat, 16 Apr 2011 09:56:07 -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: Paul Coverdale <coverdale@sympatico.ca>
References: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC684E@LHREML503-MBX.china.huawei.com> <1954673134.214770.1302930235411.JavaMail.root@lu2-zimbra> <BLU0-SMTP45D80A749744A85182EC0CD0AF0@phx.gbl>
In-reply-to: <BLU0-SMTP45D80A749744A85182EC0CD0AF0@phx.gbl>
Cc: codec@ietf.org
Subject: Re: [codec] draft test and processing plan for the IETF Codec
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: Sat, 16 Apr 2011 13:56:32 -0000

On 11-04-16 07:42 AM, Paul Coverdale wrote:
> You mean that VoIP applications have no filtering at all, not even
> anti-aliassing?

What Koen means (I assume!) is that there is no deliberate stop band 
starting at 87.5% of the Nyquist rate (e.g. 7 kHz for wideband). These 
days what you will see is either a sharp cutoff with "complete 
attenuation" starting at 8 kHz -- just enough to avoid aliasing -- or 
even using a -3 dB cutoff at 8 kHz and complete attenuation starting 
just above that. While the latter introduces a tiny bit of aliasing, it 
also produces the widest audio bandwidth possible and the aliasing is 
likely to be lower than the coding noise at that frequency anyway. 
Fortunately, I think systems with no anti-aliasing at all are pretty 
rare (and they don't deserve we care about them anyway!).

I have to admit that in Speex I tuned/trained everything assuming these 
3.5/7 kHz cutoff frequencies and I now consider that this was an error 
because very few of my users have such filtering.

Cheers,

	Jean-Marc

> ...Paul
>
>> -----Original Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf
>> Of Koen Vos
>> Sent: Saturday, April 16, 2011 1:04 AM
>> To: Anisse Taleb
>> Cc: codec@ietf.org
>> Subject: Re: [codec] draft test and processing plan for the IETF Codec
>>
>> Hi Anisse,
>>
>> I noticed your plan tests with band-limited signals: Narrowband signals
>> are
>> filtered from 300-4000 Hz, Wideband from 50-7000 Hz, Superwideband from
>> 50-14000 Hz.
>>
>> However, VoIP applications have no such band-pass filters (which degrade
>> quality and add complexity).  So results will be more informative to the
>> WG
>> and potential adopters of the codec if the testing avoids band-pass
>> filtering as well.  We want test conditions to mimic the real world as
>> closely as possible.
>>
>> Instead of band-pass filtering, tests on speech could use a simple high-
>> pass
>> filter with a cutoff around 50 Hz, as many VoIP applications do indeed
>> have
>> such a filter.
>>
>> best,
>> koen.
>>
>>
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>
>