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