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

Stephen Botzko <stephen.botzko@gmail.com> Mon, 18 April 2011 13:32 UTC

Return-Path: <stephen.botzko@gmail.com>
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 42D8FE06F6 for <codec@ietfc.amsl.com>; Mon, 18 Apr 2011 06:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.287
X-Spam-Level:
X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 9BqEi9y-MBeC for <codec@ietfc.amsl.com>; Mon, 18 Apr 2011 06:32:23 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id BC7F0E0664 for <codec@ietf.org>; Mon, 18 Apr 2011 06:32:23 -0700 (PDT)
Received: by vws12 with SMTP id 12so4405802vws.31 for <codec@ietf.org>; Mon, 18 Apr 2011 06:32:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8kVWvjzInjz2e8wcd0Z2QIOBScvsiUfyV8NbSbe36ww=; b=PhhLucaSM1p9phUWvKSoCsuZrx2Im7ngtSh93VCGH0F00iQPRLkX/I5IXW/ixvq6/y RWfU5MQhzwwhGbsR3t0qyOi8P4GzlQFfqlJ2dUr3mHefwzRgy54Gb+ltQn3bO0R5HN94 Wly/Vhio5NNlKmZguglLcswsyyXcndwjZhCYE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hyu0TO/ciWAzHDU74EDugOHvPUk9JlojdenWE/n9vedNJq9vobVEQKmXejsKA6+KEn sHpRR2BEUfjwFX17dHu4BqJpmbPNWXfG0G5dpVUVHIw3fGnEmnTX0ESqNU2hEC/d9aFi /0fDvPi5e6q/e1FEhOh30LvZRFHpRrKLI93JE=
MIME-Version: 1.0
Received: by 10.52.69.2 with SMTP id a2mr7596986vdu.5.1303133543487; Mon, 18 Apr 2011 06:32:23 -0700 (PDT)
Received: by 10.52.168.6 with HTTP; Mon, 18 Apr 2011 06:32:23 -0700 (PDT)
In-Reply-To: <20110418114716.GC31013@audi.shelbyville.oz>
References: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC684E@LHREML503-MBX.china.huawei.com> <4DA5A748.2050401@fas.harvard.edu> <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC870C@LHREML503-MBX.china.huawei.com> <20110418114716.GC31013@audi.shelbyville.oz>
Date: Mon, 18 Apr 2011 09:32:23 -0400
Message-ID: <BANLkTi=K4nWp3UX7TFtbPJd_iDsy-n3L+w@mail.gmail.com>
From: Stephen Botzko <stephen.botzko@gmail.com>
To: Ron <ron@debian.org>
Content-Type: multipart/alternative; boundary="20cf30780e6ef4595c04a1316b63"
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: Mon, 18 Apr 2011 13:32:25 -0000

in-line

On Mon, Apr 18, 2011 at 7:47 AM, Ron <ron@debian.org> wrote:

>
> Hi Anisse,
>
> On Mon, Apr 18, 2011 at 09:52:42AM +0000, Anisse Taleb wrote:
> > Hi Ben,
> >
> > > On 04/13/2011 03:32 AM, Anisse Taleb wrote:
> > > > Please find attached a first draft of a test plan of the IETF codec
> > > (Opus).
> > >
> > > Thank you for drawing up this test plan, which clearly required a great
> > > deal of thought.  The results of such testing would certainly be very
> > > interesting to many.
> > >
> > > However, I think the execution of such a test is clearly _not_ an
> > > appropriate prerequisite for publishing a Proposed Standard.  By my
> > > calculations, the draft plan presently calls for over 1300 hours of
> > > listening tests, counting only audio being played, estimating 10-second
> > > samples and the minimum number of listeners.  Even if many listeners
> are
> > > listening in parallel, and overheads (such as delays between samples)
> are
> > > low, conducting such a test would still take many months.
> >
> > It is always a good practice to first have a target on what would be
> tested
> > and then find ways how to make the test realistic and reasonable. When it
> > comes to the proposal itself, I think that shortcuts have been taken
> already.
> > I am not against discussing the size of the test, the draft proposal was
> > exactly made to initiate such discussion...
> > >
> > > Such an extensive, expensive battery of tests can hardly be justified
> on
> > > some arbitrary codec version still under development.
> >
> > I cannot agree more. Freeze a version of Opus, and let's check the
> quality of
> > the codec. If it passes the quality expectations, it will become a
> standard.
> >
> > -- But before that, clean up the code and the specification and fix the
> IPR
> > issues. Right now the codec does not pass the "admin" part of
> requirements.
>
> I thought it was already agreed that the people acting in good faith would
> endeavour to conduct as much of this in parallel as possible.
>
> I'm sure we have plenty of time to file off the rough edges while you
> gather
> enough people to run the two hundred and something nonillion iterations of
> your test that Gregory showed would be necessary for it to approach an even
> remotely significant result that wasn't entirely a function of chance.
>
> It saddens me to see you play a cheap shot like this at Ben, when so many
> people are eagerly awaiting your explanation as to whether that was simply
> an error in your math, or a factor you had not considered.  Or possibly an
> essential ingredient in your insistence of a single do-or-die test?  That
> nobody could possibly afford to repeat independently ...
>
> Maybe I am missing something, but I am not seeing any cheap shots at Ben or
anyone else in Anisse's post.  The "nonillion iterations" and "heat death of
the universe" stuff in your reply are perhaps pejorative, though as we all
know it is hard to judge intentions from emails.  I agree with Cullen that
we should assume good faith - that the proponents of systematic testing are
not trying to kill standardization of Opus, but instead simply believe that
such testing is important part of codec standardization, no matter what SDO
is doing the work.  As far as I know, that is the truth of it.

The answer to the statistical argument is quite simple - people run
cross-checks and follow up as needed to verify failed results.  This allows
fairly efficient weeding out of false negatives and the occasional false
positive), and is one reason why the test procedures need to be
well-documented (so they can be verified/reproduced). The math exercise
presumed that the test procedure could only be run once, and that failure to
pass a requirement or two could not be followed up on.  That is not the
case, if we see a result that concerns us, we can follow up.  Perhaps the
test plan should say this explicitly, or perhaps we can just agree to
discuss needed follow-ups when we see the results.


>
> So please, we've mapped both extremes of what a non-test might look like
> now,
> and we've clearly shown, with absolute certainty, that this entire group
> will
> never, not before the heat death of the universe, agree upon and perform
> one
> single tell-all test which satisfies them all.  And that's before we
> consider
> the users who aren't represented in this testing yet.
>
> I think Cullen very accurately plotted where the middle ground may lay.
> Let's all gravitate a little closer to that now, can we please?
>
> Thanks Much!
> Ron
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>