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

[Cherniavsky Beni]

Quoting Segher Boessenkool <segher at koffie.nl>: 
 
> 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. 
>  
Great!  What's the granularity?  Is it a float or something coarse? 
 
> > 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. 
>  
True - but who is going to write tools for the later when the former 
acomplishes almost the same result ?-) 
 
> > 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. 
>  
How bad?  Is it worth trying or will it be surely worse than re-encoding? 
 
> > 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. 
>  
That'd be ideal, of course but requires player support.  And these are 
different concepts ;-). 
 
I think Audacity does some nice lossless multi-channel envelope editing - 
maybe we can steal their format? 
 
--  
Beni Cherniavsky <cben at tx.technion.ac.il> 
 
"Windows Media Player 9 instaltion failed." 
[Check disk space, admin. permissions... - all was fine.] 
"The comuputer must be rebooted" [a single Finish (i.e. Reboot) button]!!! 
I killed the installer and WMP worked without a reboot... 
--- >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.