Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt

Ralph Giles <> Mon, 16 July 2012 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AD5121F880F for <>; Mon, 16 Jul 2012 11:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.956
X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jn8KqsxlZh23 for <>; Mon, 16 Jul 2012 11:38:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2CAED21F8814 for <>; Mon, 16 Jul 2012 11:38:42 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so5863755ggn.31 for <>; Mon, 16 Jul 2012 11:39:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=QFfA7X/WT/5I5/yOoqecMKMGrsXZfSEAjzeDEFXhCRg=; b=cLTHVOME7NCizuRPxxztUh7uxhwfrY96TK27ujxB+zTg0zoJZ/hRaR138D/06RDmQt HgHu9Zlf4Zjre1jhjtmiHFTE+FqqR5my4zc7xUimjjR9UFF1hGrmwj8QANbtDIHSZfsF Abe55W9KkwyrkHzOA0UTHKbjeaVxXZHND1NTmd1ByRr1tz2nQT9ilrMFCp6NjaEkNvPG f4BZMjkM1BHu34CSHAK+i571NLEdvwV8of/39qGkti/ND4MFT1cNsS2RSosO7v5xtMgg Dv/Ie7NuA05LBHhio1jFvN0AtAfExxTbHtPxqhA6Yc0ezA4TbvQN+Zs5QQ5mjtZdoo4p 6ClA==
Received: by with SMTP id p5mr6013109igl.68.1342463967525; Mon, 16 Jul 2012 11:39:27 -0700 (PDT)
Received: from Glaucomys.local ([]) by with ESMTPS id q1sm19984490igj.15.2012. (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 11:39:26 -0700 (PDT)
Message-ID: <>
Date: Mon, 16 Jul 2012 14:39:25 -0400
From: Ralph Giles <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Timothy B. Terriberry" <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQk5l3XHG3Vb/LntuhL820EynjHSz8dbFugRMeqSk5Vl+O6U6CjhZGreZfef5bQjMoOrYfuk
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jul 2012 18:38:50 -0000

On 12-07-05 4:55 PM, Timothy B. Terriberry wrote:

> Trying to specify what to do in the case of a corrupt file always looked
> like a pretty deep rathole to me 

Fair enough.

> Most of these restrictions are in place to make things easier to
> implement, but "what's easy" depends a good deal on your application.

True, but you go on to list exactly the sort of options I was thinking
it would be helpful to document. What options and tradeoffs are
available isn't necessarily obvious to implementors without previous
experience with the Ogg container, or the details of the Opus codec.

> And of course, most importantly, I don't want to give people the
> impression that, however weakly we suggest it in the spec, what's
> written there is what all implementations will do, and that therefore
> encoders will _rely_ on that behavior. Then it becomes impossible to use
> the decoder flexibility gained by declaring such constructs invalid.


>> Do I
>> understand correctly that, since pre-skip is subtracted from granulepos
>> to obtain timestamps, cropping this way requires rewriting the
>> granulepos field for every page in the logical stream, if
>> synchronization with other logical streams is to be maintained?
> Yes, I believe this is correct. This is still an improvement, in that
> you can get sample-accurate cutting without rewriting the granulepos
> field in every page so long as you _aren't_ trying to synchronize with
> another stream. That's impossible in Vorbis.

I agree. Thanks for clarifying.

>> I was surprised that the R128_TRACK_GAIN field specifies its value is
>> the ascii representation of an integer, which is then interpreted as
>> a fixed point number. Surely including the radix would be more natural
>> for a human-readable field. The draft could still specify the same valid
>> range.
> Care to offer some text to make this more clear?

One new comment tag is introduced for Ogg Opus:


representing the volume shift needed to normalize the track's volume.
The value of this tag is an ASCII signed decimal number representing
the gain in dB with the same scale as the ID header's 'output gain'

An Ogg Opus logical stream MUST NOT have more than one such tag. Players
MAY clamp the the value to the same range and precision of the Q7.8
fixed-point value of the 'output-gain' field.

Decoders MUST ignore any additional characters after the last digit. So
'R128_TRACK_GAIN=-2.238dB' would be equivalent to the above example.