[linux-audio-dev] Paper on dynamic range compression

[Andres Cabrera]

Hi,

First, let me clarify that my main intent with this paper is not to bash 
linux plugins or demerit people's work, but to see how other commercial 
plugins compare to the linux ones, to be able to make the best possible 
compressors as open source. I'm just presenting my results, it's a 
learning experience for me, so I appreciate all comments.


 Alfons Adriaensen wrote:
> On Wed, Oct 04, 2006 at 10:51:08PM -0500, Andres Cabrera wrote:
>
>   
>> I've written a paper analyzing the characteristics of some software 
>> dynamic range compressors. The interesting part concerning linux, is 
>> that all my results show jaggedness on the gain reduction curves. I did 
>> the tests using Ardour, Audacity and Rezound with the same results, 
>> which points to something strange in some part of the process.
>>     
>
> Or in your measurement methods which are ill-defined, making it all but
> impossible to correctly interpret some of the results.
>
> - How do you measure gain ? By comparing single input/output samples ?
>   It seems so, otherwise how do you obtain a gain vs. time curve at
>   50 Hz with sub-millisecond resolution (Fig. 3) ?
>   This will be invalid in many cases, for example if the plugin includes
>   audio delay to achieve 'zero latency', as you suggest some of them do.
>   
Yes, gain change was measured comparing individual samples, this 
measures the exact effect of the plugin on a known signal. The csound 
program compensates for any delay introduced by the plugin by not 
comparing exact times, but rather by looking for the start sample for 
each section. When I talk about latency in the paper, I'm not referring 
to audio latency or latency introduced by the plugin from a look-ahead 
method, but rather about a latency (or delay) in the start of gain 
reduction by the plugin, which is probably dictated by the 'windowed' or 
integration mechanism used by the plugin to calculate the envelope.
It's worth noting that the Renaissance Compressor does not introduce 
this type of latency (i.e. gain reduction is applied to a signal from 
the start of the first sample), but still it does not introduce any 
delay in the audio signal. The first sample of the waves is exactly in 
the same position for both the source signal and the processed signal. 
This seems to point to a compression algorithm that relies on additional 
mechanisms to follow an envelope, which can track gain from a few 
samples (probably within the process buffer size, to keep the signal in 
time). I'm thinking that maybe Sonar (which I used to process audio with 
the RCompressor plugin) has applied some sort of delay compensation 
mechanism, and maybe there is after all a delay in the plugin that is 
later compensated...

> - This delay is the first thing that should be measured. Without
>   this information it is impossible to evaluate the results.
>   
True, but since either the plugin produces no delay, or Sonar has 
compensated the delay, this is not evident. I'll see if I can find a 
simple host that can load Rcompressor and can process the file without 
delay compensation, to check for plugin delay (or see if there's a way 
in Sonar to turn delay compensation off).

> - How on earth do can you define the level of a white noise signal 
>   by a peak value ?
>   
Since the source white noise is known, it was possible to compare the 
effect sample by sample. As said in the paper, there was no effect on 
the phases of the sound (so each sample was still in the same place, but 
its gain had changed)

> - What is a square wave at 0dB FS ? Positive and negative samples 
>   at the maximum amplitude ? That does no correspond to a analog
>   square wave signal.
>   
True, but I'm measuring the audio processed in the digital domain. I 
included square waves and saw waves (saw waves used are also not 
band-limited) in the test sample for completeness and to see whether 
they yield significant results, but most of the conclusions are drawn 
from the pure sine waves.
> - How do you expect to measure distortion using square waves ?
>
>   
I don't.... Sine waves would show this better.


What I think is most significant in the paper is not the fact that the 
linux plugins tested introduced 'compression latency', but that they 
produced jagged gain reduction curves. This jaggedness is periodic and 
independent of the processed signal. This either points to a user error 
that is hard to avoid (I tried to be as thorough and careful as I 
could), that might (or might not) be affecting audio quality, or to some 
problem somewhere in the audio chain (maybe it's not the plugin). I'm 
very interested in finding out the reason for this if only to learn I'm 
doing something wrong.

Cheers,
Andrés