Re: [codec] ***CAUTION_Invalid_Signature*** Re: Opus comparision test plan

<Bernhard.Feiten@telekom.de> Wed, 17 April 2013 02:45 UTC

Return-Path: <Bernhard.Feiten@telekom.de>
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 F015221F96BA for <codec@ietfa.amsl.com>; Tue, 16 Apr 2013 19:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 K5B9xz-aAGlJ for <codec@ietfa.amsl.com>; Tue, 16 Apr 2013 19:45:26 -0700 (PDT)
Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id E258F21F93FB for <codec@ietf.org>; Tue, 16 Apr 2013 19:45:24 -0700 (PDT)
Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 17 Apr 2013 04:45:22 +0200
Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Wed, 17 Apr 2013 04:45:22 +0200
From: Bernhard.Feiten@telekom.de
To: jmvalin@mozilla.com
Date: Wed, 17 Apr 2013 04:45:21 +0200
Thread-Topic: ***CAUTION_Invalid_Signature*** Re: [codec] Opus comparision test plan
Thread-Index: Ac47EinPw7yhUdHvQ/OGTo0iGJn5VgAAh7oA
Message-ID: <CE8995AB5D178F44A2154F5C9A97CAF402553CFC1861@HE111541.emea1.cds.t-internal.com>
References: <016f01ce3a76$14577170$3d065450$@uni-tuebingen.de> <516D9A20.6060508@jmvalin.ca> <BLU0-SMTP8054D9BBD9A419B8716D06D0CD0@phx.gbl> <CE8995AB5D178F44A2154F5C9A97CAF402553CFC185E@HE111541.emea1.cds.t-internal.com> <516E06F6.3080806@mozilla.com>
In-Reply-To: <516E06F6.3080806@mozilla.com>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: codec@ietf.org, patrick.schreiner@symonics.com, alfons.martin@symonics.com
Subject: Re: [codec] ***CAUTION_Invalid_Signature*** Re: 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: Wed, 17 Apr 2013 02:45:27 -0000

>> Concerning SBR: AFAIK know AAC-ELD standard does not have SBR 
>> specified as a tool.
>Actually SBR is the main improvement that ELD has over LD.
Ok. You are right. Sorry for that.

>> For music testing I would recommend  the bitrates 24, 32, 48 kbit/s 
>> for mono at 32 kHz sample rate.
>This is way too low. You end up in a zone where neither codec will provide acceptable quality music and where the result is highly sensitive on the exact way in which the encoder implementation decided to mitigate the "falling >apart" case.
We are interested in a codec for telephony applications that also provides good audio quality. It has been shown that AAC-ELD might fulfill this in the range  of 24  to 32 kbit/s.  (AES 129, Ulf Wüstenhagen et. 
all, "Evaluation of Super-Wideband Speech and Audio Codecs"). Now it would be of interest how Opus behaves in this range.

>For low-delay applications, it's useless to try saving 8 kb/s when you're spending 32+ kb/s transmitting headers.
Headers might be compressed

Best regards,
Bernhard

-----Original Message-----
From: Jean-Marc Valin [mailto:jmvalin@mozilla.com] 
Sent: Mittwoch, 17. April 2013 04:21
To: Feiten, Bernhard
Cc: coverdale@sympatico.ca; jmvalin@jmvalin.ca; hoene@uni-tuebingen.de; alfons.martin@symonics.com; codec@ietf.org; patrick.schreiner@symonics.com
Subject: ***CAUTION_Invalid_Signature*** Re: [codec] Opus comparision test plan

On 04/16/2013 10:04 PM, Bernhard.Feiten@telekom.de wrote:
> For the test it should be ensured that the used codec implementation 
> fulfills  high quality requirements. I don't know the AAC-ELD fdk-aac 
> library.  The link in your document did not work for me. It does not 
> make sense to test an AAC-ELD encoder that does not provide 
> state-of-the-art encoding quality.

Well, last I heard when Jan Skoglund was organizing a music, there was just no way for him to obtain any LD or ELD implementation (IIRC FhG refused to send him one). That being said, I've no idea what the quality of tdk-aac looks like.

> Concerning SBR: AFAIK know AAC-ELD standard does not have SBR 
> specified as a tool.

Actually SBR is the main improvement that ELD has over LD.

> I think, 20 % Frame erasure rate makes no sense as it is unrealistic. 
> I would prefer frame erase rates like 1%, 3% or  6%.
> These rates should be used both in speech and music experiments.

I tend to agree on that one.

> For music testing I would recommend  the bitrates 24, 32, 48 kbit/s 
> for mono at 32 kHz sample rate.

This is way too low. You end up in a zone where neither codec will provide acceptable quality music and where the result is highly sensitive on the exact way in which the encoder implementation decided to mitigate the "falling apart" case.

> For stereo 32, 48, 64 and 96 kbit/s could be used.

48 kb/s stereo is pushing it. 32 kb/s is just ridiculously low for stereo and requires parametric stereo, which neither AAC-ELD nor Opus has (not that PS sounds particularly good in the first place).

> I think these working points would be used most likely in applications 
> where low delay is a major requirement.

For low-delay applications, it's useless to try saving 8 kb/s when you're spending 32+ kb/s transmitting headers.

> It is more important to test a higher number of contents than to tests 
> the very high bitrates.

Totally agreed.

> What is a MOS 4 anchor in the context of a MUSHRA test?

Not sure what you mean by "MOS 4 anchor", but MUSHRA specifies that you must have a 3.5 kHz low-pass anchor and optionally anchors with a low-pass at 7 or 10 kHz (in this case 7 is more appropriate IMO).

Cheers,

	Jean-Marc