Old 09-20-2020, 09:59 AM   #1
Colox
Human being with feelings
 
Join Date: Feb 2012
Location: Sweden
Posts: 1,206
Default Add auto volume compensation to JS EQ, possible?

I need to equip my customized JS EQs with a Volume Compensation functionally. In other words, a function which reduces- or increases the plugin's output volume relative to the filter settings, so the average output is always (roughly) the same no matter what volume changes is caused by the filter settings.
Doesn’t need to be dead accurate. If it ends up +/- 1.5db from actual, I think it could do.

I imagine that this may not be too difficult to do, however my EEL is a one step short of pulling it off myself. I'm thinking like this:

Say you got a JS EQ with 8 bands (low and high cut, hi and low shelf and 4 bell filters), RBJ base design. If it is possible to find- and use a formula to real-time calculate relative volume change for every filter – i.e. filter amplitude relative to frequency and filter width – and then add all those volume changes (every filter) together, and then divide the result of it by the number of currently active filters in the EQ (filters set to other than 0dB, or similar condition) and finally have this outcome automatically affect the output volume of the plugin. In realtime. Not sure how it would be best formulated, but like ..
Code:
spl0 *= Gain/(sqrt(GainCompensationL));     
spl0 *= Gain/(sqrt(GainCompensationR));
And as mentioned, needs only to be real close, not exact.

Is this thinking completely out the window, or quite possible?
And would it produce a compensational result that will be useful?

Would love some initial comments on this, of any kind.

PS. Just realized I didn't search the forum first. Maybe someone else already made this kind of functionaloty? if so, would love a link. .DS
__________________
There are only two kinds of people in the world: those who entertain, and those who are absurd.
- Britney Spears

Last edited by Colox; 09-20-2020 at 10:34 AM.
Colox is offline   Reply With Quote
Old 09-20-2020, 11:49 AM   #2
Fabian
Human being with feelings
 
Fabian's Avatar
 
Join Date: Sep 2008
Location: Sweden
Posts: 7,416
Default

This functionality (sort of) already exists, yes.

If I understand correctly, you want to measure the RMS of the signal before and after EQ is applied, and then adjust the wet signal (with EQ applied) so that the RMS is the same as that of the incoming signal.

I made a JSFX for this https://forum.cockos.com/showpost.ph...93&postcount=6

And there is also a similar thing from TBProAudio https://forum.cockos.com/showthread.php?t=141370

Both of them require splitting the incoming audio into two separate channel pairs before the EQ (or whatever general FX chain), essentially a side chain, see my post linked to above. My version is just a single JSF put at the end of the FX chain, while TBProAudio's way of doing it requires a "source" FX at the front of the FX chain and a "controller" after the FX chain, but basically they work the same.

You could of course code this yourself in a single JSFX, measuring the RMS (or LUFS) befor4e and after applying EQ and then adjust the output by RMS_out divided by RMS_in. If you check the source codes you'll see. The trickiest part for me was getting the PDC correct
__________________
// MVHMF
I never always did the right thing, but all I did wasn't wrong...
Fabian is offline   Reply With Quote
Old 09-20-2020, 02:23 PM   #3
Colox
Human being with feelings
 
Join Date: Feb 2012
Location: Sweden
Posts: 1,206
Default

Quote:
Originally Posted by Fabian View Post
This functionality (sort of) already exists, yes.

If I understand correctly, you want to measure the RMS of the signal before and after EQ is applied, and then adjust the wet signal (with EQ applied) so that the RMS is the same as that of the incoming signal.

I made a JSFX for this https://forum.cockos.com/showpost.ph...93&postcount=6

And there is also a similar thing from TBProAudio https://forum.cockos.com/showthread.php?t=141370
Nice work. And yes, measuring the input/output RMS difference sounds like a better- more direct idea.
TBProAudio's link however doesn't work, but this plugin is available through Reapack anyway.

Quote:
Originally Posted by Fabian View Post
You could of course code this yourself in a single JSFX, measuring the RMS (or LUFS) before and after applying EQ and then adjust the output by RMS_out divided by RMS_in.
That would've been nicer. Simpler, more direct usage. Probably won't need to mess with PDC either.
The EQ I'm trying to work is a mod off of Stillwell's "RBJ 7-Band Graphic EQ".
I will try, see if I can manage to transform the code into some internal function.

Quote:
Originally Posted by Fabian View Post
If you check the source codes you'll see. The trickiest part for me was getting the PDC correct
__________________
There are only two kinds of people in the world: those who entertain, and those who are absurd.
- Britney Spears

Last edited by Colox; 09-20-2020 at 02:54 PM.
Colox is offline   Reply With Quote
Old 09-20-2020, 09:45 PM   #4
TBProAudio
Human being with feelings
 
TBProAudio's Avatar
 
Join Date: May 2014
Location: Germany
Posts: 643
Default

Quote:
Originally Posted by Colox View Post
Nice work. And yes, measuring the input/output RMS difference sounds like a better- more direct idea.
TBProAudio's link however doesn't work, but this plugin is available through Reapack anyway.
This is the correct link: https://www.tb-software.com/TBProAud...tagingJSFX.zip
__________________
www.tbproaudio.de
TBProAudio is offline   Reply With Quote
Old 09-21-2020, 09:54 AM   #5
Fabian
Human being with feelings
 
Fabian's Avatar
 
Join Date: Sep 2008
Location: Sweden
Posts: 7,416
Default

Quote:
Originally Posted by Colox View Post
Nice work. And yes, measuring the input/output RMS difference sounds like a better- more direct idea.
TBProAudio's link however doesn't work, but this plugin is available through Reapack anyway.

That would've been nicer. Simpler, more direct usage. Probably won't need to mess with PDC either.
The EQ I'm trying to work is a mod off of Stillwell's "RBJ 7-Band Graphic EQ".
I will try, see if I can manage to transform the code into some internal function.
If you are to measure RMS (or LUFS) you have to buffer the incoming and outgoing audio, otherwise you cannot determine how much to adjust the outgoing, thus you need to handle PDC. But once you get the hang of it, it is not really complicated.
__________________
// MVHMF
I never always did the right thing, but all I did wasn't wrong...
Fabian is offline   Reply With Quote
Old 09-22-2020, 01:20 AM   #6
Colox
Human being with feelings
 
Join Date: Feb 2012
Location: Sweden
Posts: 1,206
Default

Quote:
Originally Posted by TBProAudio View Post
Ah thank you.

Quote:
Originally Posted by Fabian View Post
If you are to measure RMS (or LUFS) you have to buffer the incoming and outgoing audio, otherwise you cannot determine how much to adjust the outgoing, thus you need to handle PDC. But once you get the hang of it, it is not really complicated.
Not complicated .. to you perhaps

Seems I must've confused myself a bit with the RMS suggestion.

These plugins seems to work well, but they seem to analyse the overall sound of the music, including the filter effect, and then try to pin the music's overall level to a relative average level. Almost like a music volume leveller, or slow compressor. I'm assuming I'm not using them wrong.

And if so ... the output adjustment must probably be relative to what each individual filter does, not to the overall average level of the throughput itself.

For example: if I raise +10dB at 100Hz, with a certain filter width, and measure the difference in output this causes, it increase the level of a static noise +5.2dB. If I lower the EQ output slider -5.2dB, and listen, and turn the EQ on and off repeatedly, then I can confirm I'm getting exactly the desired effect. EQs such as Fabfilter Pro-Q, TDR SlickEQ and AOM Tranquilizr and others, works like that (if the option is ticked).

So I assume one must calculate the relative volume effect that each filter exerts, dynamically depending on setting, and have the EQ output affected by that. This will probably also mean that if there is no sound material around 100hz and I raise +10dB at 100hz, the volume compensation feature will still lower the volume -5.2dB (or whatever) because it reads off of the filter setting, not listening to the throughput/output.

Problem is I don't have 1 filter on the EQ, but 8 filters. So I'm guessing one would have to add together the effect of all active filters (active as in "not set to 0dB"), and divide this by the number of active filters, and finally have the result of that division affect the output.

Or am I still misconscrewing something`with this?
__________________
There are only two kinds of people in the world: those who entertain, and those who are absurd.
- Britney Spears

Last edited by Colox; 09-22-2020 at 01:52 AM.
Colox is offline   Reply With Quote
Old 09-22-2020, 03:10 AM   #7
Fabian
Human being with feelings
 
Fabian's Avatar
 
Join Date: Sep 2008
Location: Sweden
Posts: 7,416
Default

Quote:
Originally Posted by Colox View Post
<snip>

Problem is I don't have 1 filter on the EQ, but 8 filters. So I'm guessing one would have to add together the effect of all active filters (active as in "not set to 0dB"), and divide this by the number of active filters, and finally have the result of that division affect the output.

Or am I still misconscrewing something`with this?
If you want "perceived volume out" to be equal to "perceived volume in", then I do not think that your approach (as I understand it) will work. You must measure the perceived volume of a chunk of the incoming audio before EQ, and compare to the corresponding chunk of audio after EQ, and adjust that before outputting it. RMS and LUFS are both measures of "perceived volume", LUFS is maybe more accurate.

I might be wrong, both in what you really want and what it is you suggest, but try it, it cannot break anything.
__________________
// MVHMF
I never always did the right thing, but all I did wasn't wrong...
Fabian is offline   Reply With Quote
Old 09-22-2020, 07:16 AM   #8
Colox
Human being with feelings
 
Join Date: Feb 2012
Location: Sweden
Posts: 1,206
Default

Quote:
Originally Posted by Fabian View Post
If you want "perceived volume out" to be equal to "perceived volume in", then I do not think that your approach (as I understand it) will work. You must measure the perceived volume of a chunk of the incoming audio before EQ, and compare to the corresponding chunk of audio after EQ, and adjust that before outputting it. RMS and LUFS are both measures of "perceived volume", LUFS is maybe more accurate.

I might be wrong, both in what you really want and what it is you suggest, but try it, it cannot break anything.
Thanks for suggestions

My absolute bottom line, is to create a functionality like what Fabfilter Pro-Q, TDR SlickEQ etc offers. These EQs got the option of maintaining the perceived volume the same level (roughly) all the time, in a way that feels very useful and workable. That's what I'm after, in JS. I imagine that should be possible. And other users may feel they can use such a solution too.

Further, I don't think I got skills enough to pull off a potentially advanced coding feat on my own, not from scratch anyway - depending of course on what solution we're talking about. Sometimes it is more simple than what one first imagines.

Or else, I will have to provide some motivation to get help with getting this done.

Since my coding got limits, I can't make a real suggestion on which schematics are the most practical to achieve what Pro-Q, SlickEQ etc got going. My 'meta-suggestions' above is more a way of saying I'm no a complete spoiled dummy when it comes to these matters, but also a bait to get a conversation going about this.

So initially, for anybody reading, I'd be interested in however it would be possible to do a similar thing in EEL that Pro-Q, SlickEQ and others got going. Secondly, skilled estimations on how difficult it may or may not be, the workload and overfall complexity level. And finally I'd want to find a way to make it happen.
__________________
There are only two kinds of people in the world: those who entertain, and those who are absurd.
- Britney Spears

Last edited by Colox; 09-22-2020 at 07:28 AM.
Colox is offline   Reply With Quote
Old 09-22-2020, 11:43 AM   #9
Fabian
Human being with feelings
 
Fabian's Avatar
 
Join Date: Sep 2008
Location: Sweden
Posts: 7,416
Default

I am quite sure that what SlickEQ calls "auto gain" is exactly what I've been talking about and what my JSFX as well as TBProAudio's do; it measures the RMS/LUFS before and after the filter section and then adjusts the output to match the RMS/LUFS of the input. I do not see any other way to do it, and from the results google gives me on "auto gain compensation", though none of them really say *exactly* how it is done, reading between the lines tell me that this is the way it works.

EDIT: I now experimented with white noise into SlickEQ and with its auto gain on and off, and with my own StageGainer. The big difference seems to be that SlickEQ uses LUFS (or something similar), while StageGainer uses RMS. LUFS is frequency weighted RMS, which is a better measure of perceived volume. But other than that, I think it does the same thing.
__________________
// MVHMF
I never always did the right thing, but all I did wasn't wrong...

Last edited by Fabian; 09-22-2020 at 11:50 AM.
Fabian is offline   Reply With Quote
Old 09-24-2020, 02:53 PM   #10
SaulT
Human being with feelings
 
Join Date: Oct 2013
Location: Seattle, WA
Posts: 876
Default

Take the RMS of the pre-effected signal. Window size should be in the 300-500 ms range.

Take the RMS of the post-effected signal. Use the same window size.

Divide the first RMS by the second RMS. Multiply your output by that amount.

It will be close enough. No buffering required.
SaulT is offline   Reply With Quote
Old 09-25-2020, 03:43 AM   #11
Colox
Human being with feelings
 
Join Date: Feb 2012
Location: Sweden
Posts: 1,206
Default

Quote:
Originally Posted by SaulT View Post
Take the RMS of the pre-effected signal. Window size should be in the 300-500 ms range.
Take the RMS of the post-effected signal. Use the same window size.
Divide the first RMS by the second RMS. Multiply your output by that amount.
It will be close enough. No buffering required.
Yo, Saul Hope you're doing well. I thought of asking you but I didn't wanna bug you.

Quote:
Originally Posted by Fabian View Post
I am quite sure that what SlickEQ calls "auto gain" is exactly what I've been talking about and what my JSFX as well as TBProAudio's do; it measures the RMS/LUFS before and after the filter section and then adjusts the output to match the RMS/LUFS of the input. I do not see any other way to do it, and from the results google gives me on "auto gain compensation", though none of them really say *exactly* how it is done, reading between the lines tell me that this is the way it works.
Mm. I'm not so sure. I'm not being argumentative here. I just wish to explain my impression, and make sure this doesn't end up becoming something else than I hope.

In order to 'measure' the volume effect of a current filter setting, you'd have to let the original streaming sound through and measure the level before and after filtering. But how is a comparison process going to be able to differentiate between a sound level change in the source sound itself, and a sound level changed caused by a filter setting?
I fear this risks reducing the output level just because the song is in a louder part at the moment. Becomes sort of an auto volume leveller or slow compressor.
And the only way I see this method as possible - and bare with a non math-minded person who could certainly be wrong - would be by comparing the input/output on a binary level, sample for sample bit in real-time (and then removing the processing delay from doing so). Not from a loudness measuring process.

Unless I'm misusing TB's and Fabian's plugins, none of them seems to simply lower the volume to the same amount the volume gets raised. If I use my JS EQ, and raise 10dB at 100hz, with a certain q width, I get an overall volume increase of +5.2dB. Unless I'm misusing the plugins, none of the lowers the output in such a way that toggling between FX on and FX off sounds very much the same level. And if I measure the levels before and after filtering (using a static input signal) then the level compensation doesn't seem to be around 5dB, for me anyway. I'm not saying they're bad or erroneous, just that they may not be doing things in a way I feel is needed for this. Or, again, I'm not using them right.

When I turn the controls of EQs like Fabfilter, SlickEQ and above mentioned EQs, the output seems to be adjusted in correspondence to how I turn the controls, rather than from the actual input/output difference.

I just played back a pink noise, and set a 4-pole high pass filter at 1kHz over the noise. I sent this filtered noise into SlickEQ, and set a bell filter on SlickEQ at 50Hz - where almost no audio material sounds, because I filtered it out. When I turn the filter amplitude up/down for the bell filter on the SlickEQ, the tonal balance of the sound barely changes at all (which is to be expected) but the output volume still increases/decreases in a way that feels relevant to the amplitude amount. This suggests to me that filter amplitude setting is at least part of the method for determining output volume compensation on the SlickEQ.

If however the output level was connected to listening for an output/input difference, the SlickEQ shouldn't have changed the output volume much at all when I adjusted the filter amplitude, because the filter amplitude change did not result in an actual volume change (I was filtering at 50Hz where no audio material is sounding atm).

This is my impression, and that is where my idea came from, about measuring the filter setting rather than actual input/output difference. But this has got my mind twisted now. The SlickEQ lowers the output even when the EQ exerts no actual effect. It could be better to determine the actual effect instead of changing the volume based on an algorithm or formula, and compensating for that. But .. I just don't see this as possible or at least practical, functionally. I don't know how you guys see it?
__________________
There are only two kinds of people in the world: those who entertain, and those who are absurd.
- Britney Spears

Last edited by Colox; 09-28-2020 at 01:40 AM.
Colox is offline   Reply With Quote
Old 09-25-2020, 09:39 AM   #12
Fabian
Human being with feelings
 
Fabian's Avatar
 
Join Date: Sep 2008
Location: Sweden
Posts: 7,416
Default

I do not get what the problem is... I have explained the exact same thing as SaulT. Measure the RMS/LUFS before and after the filter and adjust the after-signal to have the same RMS/LUFS as the before-signal.

Good luck.
__________________
// MVHMF
I never always did the right thing, but all I did wasn't wrong...
Fabian is offline   Reply With Quote
Old 09-26-2020, 07:42 AM   #13
Zeno
Human being with feelings
 
Zeno's Avatar
 
Join Date: Sep 2018
Location: HH
Posts: 916
Default

Quote:
Originally Posted by Colox View Post
But how is a comparison process going to be able to differentiate between a sound level change in the source sound itself, and a sound level changed caused by a filter setting?
I fear this risks reducing the output level just because the song is in a louder part at the moment. Becomes sort of an auto volume leveller or slow compressor.
If the RMS/LUFS level at the output is compared to the RMS/LUFS level at the input and the level at the output is different from the input level, the level change must have occurred somewhere between these two measuring points. Not before and not after. Logic!

Automatic volume compensation is auto-leveling. But it is not compression.
In the unlikely event that you want to do some super crazy filter-gain automation with the EQ, auto-leveling could become a problem. But that is the nature of the thing itself.
Zeno is offline   Reply With Quote
Old 09-27-2020, 01:27 PM   #14
Colox
Human being with feelings
 
Join Date: Feb 2012
Location: Sweden
Posts: 1,206
Default

Quote:
Originally Posted by Zeno View Post
If the RMS/LUFS level at the output is compared to the RMS/LUFS level at the input and the level at the output is different from the input level, the level change must have occurred somewhere between these two measuring points. Not before and not after. Logic!

Automatic volume compensation is auto-leveling. But it is not compression.
In the unlikely event that you want to do some super crazy filter-gain automation with the EQ, auto-leveling could become a problem. But that is the nature of the thing itself.
I hear how you mean.

I was looking for nothing more than the same behaviour that pretty much all EQs with this feature displays. But as we were talking, above, using an RMS method appealed to me. I didn't know of that approach before. But none of the above mentioned EQs uses an RMS or LUFS-based method for compensation. You can hear that, plus I tested it out (above), and the makers of two of the mentioned plugins have now confirmed to me they don't use RMS/LUFS method (but more composite methods), and there are instructional material available on the subject which confirms this as well.

My concerns above was written from the perspective of TB's plugin (suggested above) was having to either compress the music to a pre-set RMS level, or pre-gather RMS data of the whole song (or a part of it), before applying volume levelling. The plugin even changed the volume when no in-between processing was applied.
This made me feel that it wouldn't be able to differentiate between song level difference and difference caused by an EQ, measuring that way. In the end, neither of the above two suggested plugins achieved actual and relevant volume levelling.

As I wrote above: "The only way I see this method as possible /../ would be by comparing the input/output on a binary level, sample for sample in real-time." I still feel this, and I'm trying to experiment with this method now. Though I'm afraid it will create too much zipper noises and stuff.

This thread was a hope to get thoughts about methods, feasibility, and hopefully a start in getting this done. Seems to have coagulated, and my own scripting isn't up for this, it seems.
__________________
There are only two kinds of people in the world: those who entertain, and those who are absurd.
- Britney Spears

Last edited by Colox; 09-28-2020 at 01:39 AM.
Colox is offline   Reply With Quote
Old 02-18-2021, 06:53 PM   #15
Hypex
Human being with feelings
 
Join Date: Mar 2015
Location: Australia
Posts: 451
Default

Just found this EQ FX when looking up spectrograms. It contains an AGC function. Could be worth a look as it's in JSFX.



https://forum.cockos.com/showthread....ht=spectrogram
Hypex is offline   Reply With Quote
Old 09-16-2023, 10:17 PM   #16
bill89
Human being with feelings
 
Join Date: Sep 2023
Posts: 1
Default

Quote:
Originally Posted by Colox View Post
I hear how you mean.

I was looking for nothing more than the same behaviour that pretty much all EQs with this feature displays. But as we were talking, above, using an RMS method appealed to me. I didn't know of that approach before. But none of the above mentioned EQs uses an RMS or LUFS-based method for compensation. You can hear that, plus I tested it out (above), and the makers of two of the mentioned plugins have now confirmed to me they don't use RMS/LUFS method (but more composite methods), and there are instructional material available on the subject which confirms this as well.

My concerns above was written from the perspective of TB's plugin (suggested above) was having to either compress the music to a pre-set RMS level, or pre-gather RMS data of the whole song (or a part of it), before applying volume levelling. The plugin even changed the volume when no in-between processing was applied.
This made me feel that it wouldn't be able to differentiate between song level difference and difference caused by an EQ, measuring that way. In the end, neither of the above two suggested plugins achieved actual and relevant volume levelling .

As I wrote above: "The only way I see this method as possible /../ would be by comparing the input/output on a binary level, sample for sample in real-time." I still feel this, and I'm trying to experiment with this method now. Though I'm afraid it will create too much zipper noises and stuff.

This thread was a hope to get thoughts about methods, feasibility, and hopefully a start in getting this done. Seems to have coagulated, and my own scripting isn't up for this, it seems.
Hey,

I want to know that the what measure show the blue line?
Attached Images
File Type: jpeg check Blue line curve.jpeg (95.3 KB, 29 views)
bill89 is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 05:31 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.