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

[Ralph Giles <[e-mail]>]

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.

Ok.

>> 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:

  R128_TRACK_GAIN=-2.238

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'
field.

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.

 -r