Equalizer Question (Slope?)

[Ghoost666]

Hello, can someone explain me what the slope setting is exactly for ? as far i understand it the q factor determines the slope, so im unsure what the slope setting is actually for

[wwmm]

as far i understand it the q factor determines the slope

The quality factor is just the ratio between the center frequency and the full width at half maximum https://en.wikipedia.org/wiki/Q_factor. You still have some freedom about how fast the curve is going from the top to the bottom. That is where the slope control should be acting. As I have never looked at this part of the Linux Studio Plugin https://lsp-plug.in/?page=manuals&section=para_equalizer_x32_lr code there may be some small differences in how it is being defined there. But the slope parameter is the one controlling what you are thinking about and not the q factor.

[Ghoost666]

but what slope setting i need to mirror for example what equalizerAPO is doing, as far i remember equalizerapo doesnt have a slope setting, there are many EQ`s that just rely on q factor for the "slope" of the filter

the only thing that makes kinda sense is that the slope setting is just for low/high pass filters

overall without any visualizing of the EQ curve the equalizer is kinda hard to use to be honest

[Ghoost666]

slope shouldnt do anything on a peaking filter, q factor determines slope and the gain how high the peaking filter goes

if this is the case, the slope setting should be "greyed out" in the UI

[wwmm]

but what slope setting i need to mirror for example what equalizerAPO is doing, as far i remember equalizerapo doesnt have a slope setting, there are many EQ`s that just rely on q factor for the "slope" of the filter

As I am not the equalizer's author it is better to ask him directly at https://github.com/sadko4u/lsp-plugins since all we do is exposing the plugins settings. But my guess is that in general when an equalizer does not allow the slope to be set it is just because an implicit fixed slope of 6 dB for each octave is being used. In other words it is not that the quality factor is fixing the slope but just that the plugin author decided to use the typical slope value instead of allowing it to be customized. Assuming that in LSP slope x1 is the usual 6dB/octave when using the APO mode this setting probably should be left at x1.

overall without any visualizing of the EQ curve the equalizer is kinda hard to use to be honest

Yes. But as discussed at #1433 and #515 it is far from trivial to do that when using third party plugins. Unfortunately.

if this is the case, the slope setting should be "greyed out" in the UI

I agree partially. If the plugin's author confirm that when using APO mode the slope setting is ignored and a fixed slope value is used then we should grey it when using APO mode. Remember that this equalizer has other modes other than APO and they probably use that slope setting.

[Ghoost666]

i just installed "Carla" to check what the plugin graph is actually showing, slope has a effect, but for example for bell/notch the effect of slope seems to be just the same as a different q factor visually

i was also surprised that the APO Mode (which im using) messes with low frequencys (under 20-30hz) if you apply filters under 20-30hz the graph is rather choppy compared to RLC

overall i really feel like i want having a graph or applying settings feels a bit like roulette

im not sure if this is in the scope of easyeffects but instead of making a own user interface, why not just show the plugin itself inside easyeffects? easyeffects could bundle up some plugins (and actually allow for using any VST plugin with proper support implemented, even if the already offered plugins are for most cases enough) but supporting other VST plugins would be a huge plus for easyeffects in my book (and showing the original plugin GUI)

[wwmm]

im not sure if this is in the scope of easyeffects but instead of making a own user interface, why not just show the plugin itself inside easyeffects?

Because unfortunately it isn't as simple as "just show the plugin interface". I think I have talked about this in more detail at #1433 but long story short the big DAWs also have some annoyances with this. If the app is written in gtk4 you can't just show a plugin interface written in QT or GTK3 and vice versa. Some DAWs use a library called suil to handle this mess but as far as I remember suil does not support gtk4 yet. And even if it does once gtk5 is available we will be at the library mercy again and would not be able to upgrade to a new toolkit just because suil will be lacking support to the new gtk version again.

There is also the translation and custom themes drama. Once you use the plugin interface you have lost control over translations. Something many EasyEffects users seem to like. And the plugin interface won't follow the user theme. What I am sure some people will complain... But these are things that people could get used to. The main blockers are the technical annoyances involved in loading the plugin ui inside the app window.

easyeffects could bundle up some plugins (and actually allow for using any VST plugin with proper support implemented, even if the already offered plugins are for most cases enough)

In a way scope is a little involved in this. Being a general purpose DAW like Ardour or Carla was never my intention. Initially I just wanted a fast way to apply some global tweaks to the audio system. And as a result this is reflected in our code. As things are right now trying to load arbitrary plugins is a pain because our whole presets infrastructure, settings database and gtk window widgets are specialized to the plugins we have. And as the gsettings database is based on xml schemas I am not sure if it is even possible to allow user plugins settings to be saved as there won't be xml schemas for them.

VST plugins would be in the same situation as the LV2 plugins. First we would need to write a simple wrapper for them. From this point on is the same story. Custom gtk window, custom preset classes, etc.

[wwmm]

overall i really feel like i want having a graph or applying settings feels a bit like roulette

What some people do is opening the plugin ui in Carla/Ardour and exporting an APO preset after tuning the curves shape according to what has to be done. From an usability point of view it is horrible... But it is what is possible now...

[Ghoost666]

hmm this sounds really unfortunate, maybe it would be easier to implement the qt/gtk3/gtk4 in a way that we need to open a seperate window for each plugin? but it would be not as straightforward as the current UI

im also not sure if the equalizer is the only problematic one in this regard, maybe it would be easier to just implement this for the equalizer where its most needed

but yea, checking Carla/Ardour is probably what i will do from now on

overall it was just a idea, but you are kinda right, if someone wants to use any VST plugin, Carla or similar software is probably the way to go even if it comes with its own quircks then (like handling settings)

[Ghoost666]

one other thing that might be worth checking: slope doesnt do anything for high/low shelf filters, so maybe it would be a good idea to grey out the slope setting in this case i checked with RLC(BT) and APO(DR)

[drzraf]

Same here, I've an equalizer config, like:

  "left": {
    "band0": {
      "type": "Bell",
      "mode": "RLC (BT)",
      "slope": "x1",
      "solo": "false",
      "mute": "false",
      "gain": "-19",
      "frequency": "22.59",
      "q": "4.3600000000000003"
    },
    "band1": {
      "type": "Bell",
      "mode": "RLC (BT)",
      "slope": "x1",
      "solo": "false",
      "mute": "false",
      "gain": "-23.888888888888889",
      "frequency": "28.440000000000001",
      "q": "4.3600000000000003"
    },
[28 more bands]

that I'd like to convert to ffmpeg equalizer command line so that I create an equalized version of the file. Problem is the difficulty to understand how to map (type + mode + slope + q) settings to ffmpeg width + width_type.

[wwmm]

Problem is the difficulty to understand how to map (type + mode + slope + q) settings to ffmpeg width + width_type.

Based on the link you provided ffmpeg has a two-pole peaking equalisation (EQ) filter. What is called Bell in Linux Studio Plugins is sometimes called Peak on other equalizers. So you probably do not need to worry about the type.

The quality q probably means the same in both equalizers.

For the slope it will probably be better to ask directly to Linux Studio Pluings developer in his github project page. Different filters may define the value of each slope value in a different way. You will also need to find out what ffmpeg is doing to it.

But of all these things the mode will probably be the harder to match because it is directly related to the equalizer implementation. The modes provided by the Linux Studio Plugins are probably more complex than the one in ffmpeg. And as a result may have a different frequency response. Only if the algorithms are identical the same parameters will lead to the same response.

You can have more information about the LSP equalizer we use in their page https://lsp-plug.in/?page=manuals&section=para_equalizer_x32_lr

[drzraf]

https://www.mdpi.com/2076-3417/6/5/129 ISO. ISO 266, Acoustics—Preferred frequencies for measurements. 1975.

At first glance it sounds like there is no 30 (one-third octave frequency) bands configuration provided by default so I don't see where these are configured.

but the exported values looks a lot likes the lower-end of the ISO bands (a mistake?)

"band0": {
      "type": "Bell",
      "mode": "RLC (BT)",
      "slope": "x1",
      "solo": "false",
      "mute": "false",
      "gain": "-19",
      "frequency": "22.59",
      "q": "4.3600000000000003"
    }

is either similar to:

• ffmpeg -af equalizer=f=22.59:width_type=q:width=4.360:g=-19 or
• ffmpeg -af equalizer=f=$((22.59+22.59/4.36/2)):width_type=q:width=4.360:g=-19

(but how to verify this?)

[richardpl]

The only scientific way to verify what is happening is taking frequency and/or phase and group delay filter response of both filters from single impulse input, this is well known fact.

[drzraf]

I tried to convert EE settings to ffmpeg using various logic (eg: jq -r '[.output.equalizer.left[]|"equalizer=f=" + (((.frequency|tonumber)*(1+1/(.q|tonumber)/2))|tostring) + ":width_type=q:width=" + .q + ":g=" + .gain]|join(",")') but the resulting output is nowhere near the EE-equalized one.

[richardpl]

I will repeat once more, you first need to take frequency and/or phase and group delay filter response from EE-equalized ones. And that depending on received graphical outputs emulate it to some extent. There are myriad ways to implement IIR equalizers and not going to give more detail unless explicitly asked for. For FIR equalizer you normally have linear phase and min-phase but that one introduces delays.