There is a bug with the Audacity compressor that has been an issue for many years now, so I’m guessing nobody has reported it?
When applying a compression directly to a selected region of audio, the effect of the compression will fade in at the beginning of the selection. So when compressing a block of speech, the first few words will get reduced in volume.
Therefore, if I want an even compression throughout a selection, I now need to add dummy content before the start to let the compressor get time to kick in.
I assume this must be a bug as I can see no practical reason to complicate the process of applying compression in this manner.
When I set a Threshold and Ratio on a compression level for a selection, I expect those values to apply to the entire selection. Not just most of the selection with the first half
second spent fading in.
I very rarely use compression but yeah, it looks like a bug to me.
There are optional compressors and the “famous” Chris’s Compressor. From what I’ve read Chris’s compressor has an oddity at the end (I assume because it’s using look-ahead) and it works best if you add a bit of silence at the end.
Or, since compression is one of the “big 3” effects, there are tons of 3rd-party VST compressors and I’m sure some of them work in Audacity.
I agree that it “looks” like a bug, but really I think it is expected behaviour.
Audacity’s compressor effect uses “look ahead” to determine whether the gain should be increased or decreased. (See: Compressor - Audacity Manual)
When it sees audio coming up that has a level above the “threshold” level, then it starts to progressively compress the audio, so that it achieves the necessary amount of compression when it reaches that high level audio.
The problem is that if the audio is above the threshold level near the start of the track, it does not have time to gracefully ramp up the amount of compression.Hence the “fading in” of the effect that you observe.
A workaround is to pad the start of the track with a few seconds of silence, so that the compressor has enough time to set the compression amount before it hits loud audio.
Note that not all compressors use “look-ahead”. Compressors that don’t use look-ahead do not have this limitation, but do have an arguably worse limitation that transients (sudden short high peaks) don’t get compressed at all.
The minimum attack time on Audacity’s native compressor is 0.1s =100ms
The minimum release time on Audacity’s native compressor is 1s =1000ms
These are both ~10x too slow for compressing speech
