MeldaProduction

Svama · Post by **Svama** » Wed Mar 04, 2015 7:42 am

Hi Vojtech,

in my opinion the AGC responding of your Eq´s and MCompare for example is to slow. It should be realtime, if possible. Take a look at the tdr slickeq with their automated volume, it´s superb and really usefull. No pumping effects, like I got from your eq´s.
Maybe you can improve that?!

Something new about release of version 9????????

Thanks and greets

Marek

MeldaProduction · Post by **MeldaProduction** » Wed Mar 04, 2015 10:36 am

Hi Marek,

I don't know about slickeq and don't really have time to try, but this CANNOT be done, it's impossible. In slickeq they possibly calculate magnitude difference of white noise and use that for output volume (just guessing), but that's just wrong. Yes, it's stable, no pumping or whatsoever, but it's wrong.

Why? Simple. Imagine you feed it with sine 1k into a static eq (the simplest case of all). The processor will be a steep lowpass at 100Hz, so it should destroy the sine completely, right? So if my guess above is true, such compensation wouldn't work at all, because there will be something remaining from a white noise. But I shall explain why it can never work. Let's imagine that at one moment the input sine changes into a white noise. Now you should already see the problem. While the processor kills everything from the sine, so the theoretical ideal "gain" would be like +200dB, there was lots left from the white noise, so it became say +20dB. But the eq CANNOT KNOW THAT! And this doesn't even account loudness estimate etc. So I'm just hitting the ground...

Instead the AGC/ALC is measuring input loudness, which must always be done continually (see MLoudnessAnalyzer), and of course this causes a delay. And about lower the time - that's exactly what you DO NOT want! Because then you will have lots of distortion etc. Right now the window is about 3 seconds, which means it takes it 3 seconds to adapt to changes in the signal. The fact that your signal is too dynamic is really your problem, nothing can solve it for you (except for 1.5 look-ahead and I don't think that's what you want

). If it would be say 100ms, then yes, not much pumping, but distortion instead, nobody would want that.

Svama · Post by **Svama** » Wed Mar 04, 2015 11:14 am

Hi Vojtech,

thanks for your detailed response. That sounds logical.

This is what the manual says about there Automation gain:
The AUTO button activates the auto-gain mode. This mode tries to preserve the subjective loudness during EQ while operating the EQ. This mode gives a much better idea of what the EQ is really doing to the material, because it strongly reduces perception issues related to gain differences. In other words, boosts don’t automically give the impression to sound better and cuts tend to sound far less “boring” than they seem without auto-gain (or careful manual loudness matching). A blue LED indicates auto-gain activity.

AND WHAT'S ABOUT VERSION 9???

MeldaProduction · Post by **MeldaProduction** » Wed Mar 04, 2015 4:01 pm

Hi Svama, so it apears to be as I expected. This really is just a very very rough approximation...

About V9 - well, working on it

, lots of work

, but soon

.

alexis1 · Post by **alexis1** » Fri Mar 06, 2015 5:01 am

Appreciate the short "teaser" vid, but would love to see one of the full length vids on MCompare!

MeldaProduction · Post by **MeldaProduction** » Fri Mar 06, 2015 10:33 am

Will do! When time allows

. I'd like to do many videos myself, but first I need to get some good english accent

Svama · Post by **Svama** » Tue Mar 10, 2015 8:22 am

Here is the respond the engineer of slickeq gave me after showing him your reply:

Hey Marek, I can’t really see the point, what exactly is wrong with SlickEQ’s equal loudness function?
To be honest, I don’t see the need to justify and explain a perfectly fine function. There’s neither a “window of 3 seconds” nor does SlickEQ introduce any form of distortion as long all sat modes are disabled, and of course, it doesn’t boost gain by 200dB at any point. All I can say is that your buddy isn’t the most creative when it comes to engineering.

But I know you are one of the best, should I delete Slickeq

Greets

Marek

MeldaProduction · Post by **MeldaProduction** » Tue Mar 10, 2015 1:26 pm

Hehe

Well, as I explained, it cannot be done

. So they indeed use a stable compensation as I suggested in the beginning, which is not truly "automatic loudness compensation", but whatever

.

I was actually curious, so I checked the demo, and it doesn't compensate at all... I tried the basic noises to see what it does, I assumed it would compensate well for them as these are the easiest signals and nope I'm afraid, it didn't work either, tried +18db of all filters, usually got like +5dB difference... So yes, it is based on some specific signal measurements, pretty much the most trivial approach with quite a few problems, e.g. that it doesn't really work

.

So yes, you should probably delete it

. So much for "not being creative when it comes to engineering"

, this really made my day

.

Svama · Post by **Svama** » Tue Mar 10, 2015 1:57 pm

Great,

So I will push the delete button.

Thanks for taking time, but don't waste it and please go on with v9

I posted your answer anonymous in their forum. I'm really tense about what will be the answer.

Greets

Marek

MeldaProduction · Post by **MeldaProduction** » Tue Mar 10, 2015 3:11 pm

Hehe, me too

Svama · Post by **Svama** » Tue Mar 10, 2015 7:29 pm

Here is the answer:

Forget all your (again: faulty) assumptions for a second and use the plugin on real world signals in real situations..

Feel free to post some worst case examples (audio + preset) popping up so that I can reproduce the “problem”.. You are calling the function broken/wrong/not working in a very aggressive manner, while thousands of satisfied users including our own very experienced test team and all three (!) developers greatly enjoy the function.

Please be more precise with your criticism, I have serious difficulties following your points. For example: “tried +18db of all filters, usually got like +5dB difference” what does this mean? Difference to what exactly? And at which frequency and shape settings? And which type of material? And what are “the basic noises”?

Sure it’s an approximation, but a very good one imho. By far the slickest I’ve seen to date on an EQ.

mljung · Post by **mljung** » Wed Mar 11, 2015 9:44 am

I have to jump in. SlickEQ is a wonderful EQ and the auto gain compensation works very well for me!

There's no need to look down at others developers fine work, please Vojtech you don't need to do that, just see it as different ways of doing things.

And to Marek - Seems that you prefer SlickEQs AGC maybe because it simply works better. You talked about pumping effects in the beginning of this thread (I certainly don't hope this was a result of any AGC). I have not tried Meldas AGC, personally - but I like Vojtechs plugins (have the total-bundle), just to make that clear.

::
Mads

Svama · Post by **Svama** » Wed Mar 11, 2015 10:04 am

Everything fine, but I was very interested why Melda plugins are pumping sometimes and are more slowly with AGC then SlickEq. But I´d like to use a real good plugin and no fake, vodoo, which is not working. Until now I also have no probs with SlickEq and I like the idea of the automatic gain compensation in realtime.

Greets

Marek

IIRs · Post by **IIRs** » Wed Mar 11, 2015 10:12 am

You guys seem to be talking at cross purposes. Slick EQ auto gain compensation is based on typical real world signals, and is therefore only an approximation. Same with the gain compensation in Pro-Q2. But it usually results in a much smaller volume difference than would otherwise be the case, works instantly, and therefore makes some EQ decisions easier and more intuitive.

AGC based on measurements of input and output levels will of course be more accurate, but can't be instantaneous, as you need some time to take meaningful measurements. I haven't tried the Melda version, but it seems to me the two features can't really be compared: they're just different.

One thing that did occur to me: why not provide a function where the EQ can analyse a portion of the input signal first, then provide an instantaneous Slick EQ style auto gain, but based on the actual input signal rather than just a pink noise spectrum, or some arbitrary "real world signal". You can have that idea for free

MeldaProduction · Post by **MeldaProduction** » Wed Mar 11, 2015 1:39 pm

Mads: No no, I didn't want to dig into this, I was just asked by Svama to look at it

.

IIRs: It's already there - play a portion, click "Set" (inside the AGC button) and it will set the output gain.
And you are right, this is not an approximation and indeed a correct AGC like this cannot be done without delay & changing gain (naturally). Sometimes you want this, sometimes you don't, nevertheless you can always click Set to make the output gain constant and be a true calculation of the gain compensation.

Svama: I checked again, I'm not really sure what their plugin measures, but it just works the exact way I told you it does. So it basically doesn't depend on the input signal. It's just something very different. It's not loudness compensation, it simply helps you avoid big output level jumps when you perform big changes in the eq, sometimes it will be accurate, sometimes not at all.

MeldaProduction

KVR Audio

Faster AGC responding