Re: [codec] draft-ietf-codec-oggopus and "album" gain

Ian Nartowicz <flac@nartowicz.co.uk> Wed, 27 August 2014 22:54 UTC

Return-Path: <flac@nartowicz.co.uk>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9F61A01D2 for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 15:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-S1ecMbwTJ2 for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 15:54:41 -0700 (PDT)
Received: from know-smtprelay-omc-2.server.virginmedia.net (know-smtprelay-omc-2.server.virginmedia.net [80.0.253.66]) by ietfa.amsl.com (Postfix) with ESMTP id 44C101A0151 for <codec@ietf.org>; Wed, 27 Aug 2014 15:54:40 -0700 (PDT)
Received: from crunchbang ([81.103.170.84]) by know-smtprelay-2-imp with bizsmtp id jyue1o01y1pcAUZ01yufSc; Wed, 27 Aug 2014 23:54:39 +0100
X-Originating-IP: [81.103.170.84]
X-Spam: 0
X-Authority: v=2.1 cv=MI/umapl c=1 sm=1 tr=0 a=bYNBYWS+Sj0o/bRbN9Xjqw==:117 a=bYNBYWS+Sj0o/bRbN9Xjqw==:17 a=KEKbkQfv9EEA:10 a=ud0LK1MCnV8A:10 a=RoPK8JaNmp0A:10 a=kj9zAlcOel0A:10 a=hU221NPEAAAA:8 a=tkKQBNAWq-XDekDwCj0A:9 a=3SwqxaF5wcGUcyXn:21 a=p07tGZv5LudfkD6d:21 a=CjuIK1q_8ugA:10
Date: Wed, 27 Aug 2014 23:54:38 +0100
From: Ian Nartowicz <flac@nartowicz.co.uk>
To: codec@ietf.org
Message-ID: <20140827235438.1eb21a89@crunchbang>
In-Reply-To: <20140827212114.GV326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang> <20140827212114.GV326@hex.shelbyville.oz>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.10; i486-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/wYRUk1LuGjYBn_oVT_WDwVCiqjs
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
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, 27 Aug 2014 22:54:44 -0000

<snip>

>I thought the only confusion there was "how do I turn off album gain
>if there isn't an explicit album gain tag?" - given that you MUST NOT
>disable the output_gain, which may or may not have been calibrated to
>R128 album gain levels.
>
>You still MUST NOT turn off output gain, even if R128_ALBUM_GAIN=0
>is explicitly specified, since the raw file still could be at "I'm
>50 meters from ground zero of an atomic test" levels.  That still
>doesn't imply *anything* about what the output_gain is or means.
>
>But we've given you an explicit album gain tag now that you can
>switch on or off if it's not zero.  I'm not sure what the remaining
>confusion really is, but indeed, let's find it and clear it up.
>
>  Cheers,
>  Ron
>
And so we're back to square one.

There's no confusion here.  I have pointed up a perfectly reasonable and
widespread requirement to sometimes, at the user's choice, play back music *as
encoded* (and sometimes normalised to R128).  You don't accept that this
is a legitimate requirement, even making up bizarre examples to somehow refute
real things that are happening in real software.

I do understand the desire for "just works" level adjustment in the majority of
software, but I ask for recognition that some specialist software requires more
stringent control of the playback parameters.  I even offered what I believe is
a better all-round solution of the output gain setting the desired playback
level and the two tags each containing the *entire* R128 normalisation
adjustment, to be subtracted out if desired while still leaving the rest of the
output gain in place.

Whenever we get close to a form of words that accepts this requirement as a
possibility, albeit far short of properly supporting it, it slips away again.
I'm out of ideas.

--ian