[vorbis] RE: Hlp in finding a native Ogg trim, fade & nomalisetool

[Segher Boessenkool]

Beni Cherniavksy wrote:
> I think this:
> 
> http://www.xiph.org/archives/vorbis-dev/200105/0139.html
> 
> comes from the thread which you refer to but it's the part which was
> crossposted to vorbis-dev where some more detailed answers were given.
> Look for the following messages by Monty and Segher...  To sum up, there
> actually is a per-frame volume in Vorbis (but twiddling it might be a bit
> complicated and no tools were ever written for this) and the volume of the

With floor1, I think it's a very tiny little bit harder to change the
per-packet volume than it was with floor0, but it's still very easy.

> whole stream can be changed by very easy codebook manipualtion (it might
> have become less easy with the introduction of channel couplig).  The

No, it's still the same.

> later (amplifying the whole stream) is now implemented in ReplayGain by
> most self-respecting vorbis players so there is no need for the codebook
> manipulation anyway...

Sure there is.  ReplayGain only specifies a recommended playback gain
value, while changing the actual stream gain, erm, changes the actual gain.
Different concepts.

> I don't quite see the reason for compressing the vorbis file itself (even
> if it was lossless) since compression generally lowers audio fidelity.
> Store the vorbis file as is and compress before playing through media
> requiring it (like FM).

Sound advice.  (pun intended, sorry 'bout that).

> However (read above thread), there is a theretical possibility to
> losslessly manipulate volume locally in Vorbis.  The only problem is that
> the envelope is defined with packet granularity (somewhat smoothed by the
> window function).  This will make the envelope sort of "wavy" which might
> distort the frequency domain (any modulation does but this adds
> higher-frequency componenets to the envelope than usually).

It's a bigger problem for low frequencies.  Changing adjacent blocks by
different gains violates the MDCT overlap-add property -> bad artifacts.

> Another trick once suggested for fade in/out at ends of the pieces (or
> even cross-fading) is to reencode only the ends and copy the middle as-is.
> This should leave the degradation almost unnoticable.

It might still be noticable at those beginnings and ends.  A better solution
would be to have a meta-stream that describes how different tracks should
be played back (only one track in this case, of course).  Something like this
will be needed anyway, for example, for subtitle tracks on video streams.

<p>Cheers,

Segher

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.