Audio-Limiter - which one do you use?

An audio limiter is very important because with digital sound the slightest overload, i.e. any value above 0 dB, ruins the audio. I like to use this: Fast Lookahead limiter with these settings.
I place this in the “Master” so that the sum of all audios together is limited.


What is your experience?

I also use the Fast Lookahead Limiter

I’ve been putting my limit a little lower, like -1.5 dB lately. I don’t feel like going and doing the math on my playback targets or worrying about transients. If I am worried about transients and getting it just right, I usually mix my audio through Ardour, which has a nice Loudness checker which also checks transients.

Transients are important because for high frequency sounds, the true peak of the wave can be substantially higher than the sampled value, as the peak is likely to fall between samples. Tools which only check the numerical value of the samples fail to account for these true peaks and will permit the signal to clip. I have not researched the FLL plugin thoroughly, but generally if a plugin does not reference true peaks, it likely is only looking at the sampled peak.

And regarding playback targets, each video and streaming tool will impose different peak limits, some as low as -2dB, and different loudness standards (LuFS). If your Loudness or peaks are outside their standards, they will use replayGain to boost or reduce your track volume so that it either begins to clip or becomes less loud.

If you want some good reading, research the loudness wars. Music before the 90s/2000s was in some ways better because we had more dynamic contrast. Lots of arguments that loudness squashing should be done on playback and radio transmitter equipment rather than on the track, but there really are so many compromises either way, and I digress…

Not to take anything away from the rest of what you said - and it is true that the real peak power can be higher than any of the individual sample values might suggest - but that on its own does not mean that signal will get clipped.

There may be some risk of a sample subsequently getting clipped if you’re performing further digital signal processing on it - but if all you do with it is play it, then the only way it would “clip” is if the analogue circuitry doesn’t have sufficient headroom. And that would be a design fault, in a system that probably has far more severe artifacts than a little clipping of loud transients :slight_smile:

Provided the sample values themselves were not clipped, the reconstruction will be perfect, even if the real peak power exceeds the naive “theoretical maximum dynamic range” based on just the number of bits per sample (or, with proper dithering, is significantly less than the theoretical minimum power for a simple “one bit” signal power level).

It can be a little counter intuitive at first for people who imagine digital audio as “stairsteps” rather than a time domain representation of a frequency domain signal, but the limits to fidelity are in the analogue parts of the system if the samples you do have are their true values. For 16-bit linear audio, the naive limit to quantizable dynamic range is only 96dB - but it is possible to record and reproduce signals with it that have a real range closer to 120dB …

OK. Very interesting, and I think what you are saying makes sense.

So in your workflow, do you care about transients at all if the sample values are within range for wherever you are publishing to?

I’d never heard of dithering in an audio context, but that also makes sense, I think.

I understand and agree with your point in the last paragraph. I think my assumption was that there was very high risk of issues with replication on the D->A side. You believe that is very low because products should be designed with plenty of headroom.

However, if I was to say apply time/pitch alterations to the final output after export, this might induce clipping in the subsequent project, but again this would be evident in the sample values. Am I understanding you correctly?

I appreciate your feedback!

It totally depends on whether you are creating a ‘final’ copy (for people to simply listen to), or a ‘master’ copy for further signal processing. But if you really care about the latter, you’re probably also working with a greater bit-depth and sampling rate to give you the headroom and precision you need for that… (and this probably gets a bit blurry if you intend publishing your ‘final’ copy through a service that will lossy->lossy transcode it - for that you probably do want to think a bit more like you are mastering rather than publishing).

24 or 32 bit audio with a 96kHz sample rate is snake oil if you’re sold it on the claim that you’ll Hear The Difference (most people can’t hope to hear even what 16-bit/48k can perfectly represent, let alone with everyday equipment in everyday locations) - but it does help with minimising the errors introduced by complex signal processing in the production stage.

It works the same way as it does for images, you hide the quantisation error distortion in a part of the spectrum that’s less perceptible. And for very low level signals, it can be remarkable how well a good noise shaping dither can make a signal that was totally lost in the noise become clearly recognisable.

I’m not sure I’d say the risk was “low” (on a simple proportion of products scale) - just that on any hardware where this is likely to be a problem, it’s probably among the least of the problems that hardware is introducing to the fidelity of your recording.

If you’re listening to it on beats headphones on the bus, you lost this game before you even got out of bed : ) You can’t fix that with a little extra headroom for your peak signal level.

Fewer and fewer devices have user adjustable analogue gain anymore, it’s all done in the digital domain, so it generally makes sense to maximise the dynamic range you want to offer (which minimises your quantisation distortion), and assume all non-distorting gain changes will be reducing the digital signal level.

Yes, absolutely. Anything that changes the sampled signal in a more complex way than simply scaling it up or down has the risk of landing a sample on an out-of-range transient and getting it clipped (and of introducing other distortions too, which is why the extra headroom is useful for production processing).

But if you are certain that none of your samples were clipped (either in the intermediate stages of processing or the final result), and your sampling frequency is greater than double the maximum frequency in your source - then the sampling theorem (correctly : ) says there is precisely one unique function (set of samples) that maps to each possible signal in that domain. Which means you both precisely recorded it, and can precisely reproduce it, only constrained by the accuracy of the analogue equipment you recorded and reproduced it with.

1 Like

That’s the one I use too. Although it wasn’t available when I installed Kdenlive 24.12.1 on Windows 10. Nor were any of the Steve Harris’ SWH plugins.
I had to “steal” this effect from my old Shotcut install. :sweat_smile:

Hello Miguel,
I don’t quite understand you yet. In the meantime, I no longer understand much about Windows. After 30 years I switched to Linux. I don’t know how to use Seve Harris’ SWH plugins on Windows. On Manjaro Linux it’s quite simple. But I can’t motivate you to switch to Linux, that cost me 1,000,000 nerves, even though I’m now very happy with Linux.

But what interests me now: How do you do it:

I had to “steal” this effect from my old Shotcut install. :sweat_smile:

Unfortunately, I can’t switch to Linux. I work remotely and the company I work for uses proprietary Windows-only applications, so I’m stuck… I’ve tweaked my Windows install to remove all the telemetry, AI, bloatware, ads, etc, so it’s not that bad.

I copied the file fast_lookahead_limiter_1913.dll from the Shotcut install to this folder: …/kdenlive/lib/ladspa

That’s great that you’ve found a method.
I’m sure you’ll find one for SWH plugins for MS Windows too, so keep us posted.
Here is the entire content of my ladspa folder. Maybe this can help you:

However, they are .so files, not .dll

To convert .so files to .dll I’d need to recompile them, which is beyond my skills, but thanks micha!
The only SWH effect I need is the limiter, so no worries. :slight_smile: