RMS limiter module enhanced

Okay, I have started making the new limiter from all modules I have.

The signal chain will be: DC Cut Filter -> RMS Limiter -> Peak Clipper -> Peak Limiter -> Output Clipper

• DC Cut Filter – to cut unnecessary lows (and to remove DC offset);
• RMS Limiter – to stabilize crest factor and to average loudness;
• Peak Clipper – to cut very strong peaks to help peak limiter not to “thump” on them (can work in M/S mode, have different knees to switch);
• Peak Limiter – to limit peaks (can work in M/S mode, can work as high-frequency limiter just to soften the sound);
• Output Clipper – (can work in true peaks mode to avoid inter-sample clipping or in simple mode just to clip samples, has switchable auto-gain mode to automatically level up the sound to -0.3 dbFS).

Maybe soft-knee control can be useful for Peak Limiter (I’ll check this soon). Maybe DC Cut Filter is better to place just before output clipper (I’ll check this later). I have no ideas about GUI yet.

By the way, I found that use regular compression curves with no high ratios (4:1 for example) for RMS limiter is better than limiting curve. I reimplemented the last RMS Limiter module (see previous post) with “Ratio” parameter and I think it sounds now pretty good. (Actually, I love how it sounds .) If you interested in you can check this [RMS limiter VST plugin (x86,x64)].

Good luck!

PS. I think the idea to show each small step of development of new plugin is better than keeping silence for year and after that to show only the last final step: the release version. I prefer continuous development process on each step of that you have something to check and to listen.

Slow RMS limiter module prototype

Hi!

My idea is the slow RMS limiter before peak limiter/clipper helps to maintain constant crest factor and improves sound. So I did simple plugin to check this idea. Download it here: [slow RMS limiter VST plugin (x86,x64)].

The plugin parameters:

• “Gain” – input gain boost before any processing;
• “Thresh.” – RMS limiting threshold;
• “Attack” – think of it like RMS window size for signal level detector. The attack time is in seconds. The minimum value is 0.05 = 50 ms.
• “Release” – gain reduction release time. This time is time constant based (the time for GR to fall from 100% to 36.8%). In minimum “Off” position release time for gain reduction is not used;
• “Sidechn.” – sidechain high-pass filter (based on Molot one);
• “DryMix” – mix output with raw input (before gain boost) to fatten it up;
• “Lookahd.” – control lookahead. If “On” 10 ms lookahead is used. If “Attack” parameter has minimum value lookahead really helps to limit kick peaks for example. For greater attack times it helps to soften the sound. You can turn it off for taste or for realtime usage (if “Off” the plugin has zero latency).

The plugin is a bit tricky to tune up but I like it! Now I think it’s time to mix all my module prototypes to single cool limiter plugin!

PS. According to this site statistics “Most visitors came from The United States. Germany & Japan”. Maybe it’s a good idea to make translation of Molot GUI or even Molot manual to German & Japanese languages? Does anyone eager to help? Ж-)

32-bit vs. 64-bit. My version.

Hello!

Let’s talk about 32-bit vs. 64-bit sound processing in VST plugins (not only talk but also I have [3 plugins to perform audio tests]!)

1. 32-bit single precision floating point format (a.k.a. float)

Used in most DAWs. The main format for VST plugins to process (AudioEffect::processReplacing).

Got:
- Sign bit: 1 bit
- Exponent width: 8 bits
- Significand precision: 24 (23 explicitly stored)

The sample values for 0 dbFS are between -1.0 and 1.0. So it’s actually 24 bits per sample.

2. 64-bit double precision floating point format (a.k.a double)

Optional format for VST plugins to process (AudioEffect::processDoubleReplacing starting from VST 2.4). Some DAWs declare if all plugins in chain use 64-bit processing the whole signal chain has 64-bit processing.

Got:
- Sign bit: 1 bit
- Exponent width: 11 bits
- Significand precision: 53 bits (52 explicitly stored)

The sample values for 0 dbFS are between -1.0 and 1.0. So it actually 53 bits per sample.

There’re 2 main questions to use double instead of float:

1. How much is performance degradation?
2. Is it noticable audio quality enhance?