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

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
Received on Thu Oct 5 20:15:01 2006