Re: [codec] Some listening test results

"Timothy B. Terriberry" <tterribe@xiph.org> Fri, 26 July 2013 22:51 UTC

Return-Path: <tterribe@xiph.org>
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 56B8321F9B94 for <codec@ietfa.amsl.com>; Fri, 26 Jul 2013 15:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 DR1o+OZOkOaI for <codec@ietfa.amsl.com>; Fri, 26 Jul 2013 15:51:09 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id C3C9321F9B98 for <codec@ietf.org>; Fri, 26 Jul 2013 15:51:09 -0700 (PDT)
Received: from [192.168.15.42] (unknown [213.23.104.157]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BA1D9F22B0; Fri, 26 Jul 2013 15:51:07 -0700 (PDT)
Message-ID: <51F2FD5A.9020900@xiph.org>
Date: Fri, 26 Jul 2013 15:51:06 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16
MIME-Version: 1.0
To: Ron <ron@debian.org>, Christian Hoene <christian.hoene@symonics.com>
References: <006001ce8a0d$89a2aa30$9ce7fe90$@symonics.com> <20130726203652.GM25981@audi.shelbyville.oz>
In-Reply-To: <20130726203652.GM25981@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: codec@ietf.org, opus@xiph.org, Michael Haun <michael.haun@symonics.com>, patrick.schreiner@symonics.com
Subject: Re: [codec] Some listening test results
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: Fri, 26 Jul 2013 22:51:17 -0000

Ron wrote:
> I'm curious about that because you note that the Opus bitstream
> wasn't designed to be inherently robust against a bit error at
> any point in the packet (and some places will obviously effect
> it worse than others) - however it's not quite true that it
> 'cannot tolerate them'.

It's not quite true to say that Opus was not designed to be robust to 
them, either. We use "raw bits" (RFC 6716 Section 4.1.4) where possible 
precisely because a bit error in one of those will not desync the 
bitstream. We also designed things so that the bits most sensitive to 
errors were at the beginning of the packet (see slide 46 of 
<http://www.celt-codec.org/presentations/misc/lca-celt.pdf> for some 
early measurements on the CELT layer from my 2009 LCA talk). This takes 
advantage of the unequal error protection afforded by Trellis Coded 
Modulation (TCM), and in other modulation schemes a SECDED code on the 
first 64 bits or so of the packet should substantially cure the bulk of 
bit-error impairment.

As Ron notes, the choice of modulation scheme or error protection scheme 
is best dealt with at a layer above the codec itself. We just tried to 
make it easy to do so. I guess you can argue whether or not that's 
"inherent".