Problem with Frequency Response with EQ Filters

2777 Views 18 Replies 3 Participants Last post by JohnM, Nov 18, 2017

Ligo

Discussion Starter · Nov 13, 2017 (Edited)

Problem with simulation of Frequency Response with EQ Filters

In order to investigate the impact of the EQ Filters into Step Response, ETC, T60 and so on, I've tried to obtain an impulse response of my mesaurement with EQ Filters applied.
To do so, I have followed these steps:
1) Export EQ Filters Impulse Response as WAV
2) Import EQ Filters IR just saved
3) Use trace arithmetic A*B to multiply the measurement and the Filters IR

I expected the result of the trace arithmetic operation to have a frequency response similar, if not equal, to that obtained applying the filters saved as .req to the measurement. Instead it's very different.

Perhaps the procedure i followed is wrong or i miss something, can anyone help me to understand the reason of this difference and which graph i have to trust?

1 - 19 of 19 Posts

subterFUSE

· #2 · Nov 13, 2017

Which DSP?

I can tell you that for the Helix Pro, the EQ filters behave exactly as expected.

I use a very advanced software called Smaart, which is like REW only it can measure with multiple microphones and can also measure more than 1 transfer function at once.

I have personally measured the electrical output from the DSP in real time while I am tuning, which shows me the exact effect of the EQ filters on the signal coming out of the DSP.

The point of this is that if you take a static measurement of the frequency response of a speaker, and then save that on the screen, and then view a live measurement of the electrical output of the DSP (but inverted), then you can add EQ filters to the DSP and trace the inverse EQ filter plot on top of the unfiltered speaker response and the result will be a perfectly flat speaker response.

It’s a very interesting method that can help us EQ a speaker quickly with as few parametric filters as necessary.

It also shows us how well EQ filters actually correlate to what comes out of the DSP.

I took a video of myself doing this. I will post it if I can find it and upload it.

Sent from my iPhone using Tapatalk

See less See more

Ligo

Discussion Starter · #3 · Nov 13, 2017

I use the EQ filters generated with REW to feed Jriver parametric EQ, so I've set generic EQ in REW.
I understand that the best way to evaluate the effect of a filter is to measure it, and I can do that, but I also wish to rely on a good simulation to set up a filter that most likely suite my needs, letting the measurement to be the final check.
So, my problem is that I have two different simulated FR results when in my thought they won't have to be different at all and I would like to undesrtand if and where I'm wrong with my presumption and in which of the two I can trust more.

JohnM

· #4 · Nov 13, 2017

The process you describe sounds right, though you can also see the predicted response with less effort on the Predicted SPL graph of the Overlays window. You don't mention in what way the responses differ, but a critical factor is how the JRiver equaliser filters interpret the Q value, which depends on the filter implementation. If the filter implementation is the same as REW's Generic EQ setting the prediction should be very accurate. Could always post an mdat for further investigation, make sure you load the filters you are using before saving the mdat.

Ligo

Discussion Starter · #5 · Nov 13, 2017

Sorry, english is not my language so my post wasn't clear enough.
When I compare the spl in the predicted spl tab to the spl result of the trace arithemtic function I expect them to be equals but they are not.
I need the equalized IR to perform analisys on the predicted step response, etc, T60, ..., while in the eq window I can only look at the spl and wateffall graphs.

JohnM

· #6 · Nov 13, 2017

They should be equal. When you exported the EQ filters IR did you normalise it? Did the imported response match the original filter response? It will be easier to investigate if you post the files.

Ligo

Discussion Starter · #7 · Nov 14, 2017

3

Yes, I exported them normalized.
In attach the measurement of one channel and the filter in .req format.
The image shows the predicted SPL vs the SPL of the A*B result.

See less See more

JohnM

· #8 · Nov 14, 2017

They overlay precisely when I do it, once the SPL is offset (can be done on the result or the imported filter response).

Text Line Plot Parallel Font

See less See more

JohnM

· #9 · Nov 14, 2017

The issue might have been with the windowing you were using, you appear to be using FDW in your plot - carry out the trace arithmetic on traces without FDW then apply FDW to the result as you wish.

Ligo

Discussion Starter · #10 · Nov 14, 2017 (Edited)

Thank you for your help, happy to know that I can have a reliable filtered IR simualtion for my analisys purpose. This evening (local time :smile

I'll try to verify once again but I'm not sure to have understood what's gone wrong and why your plots overlap exactly as opposed to mine, so I have some further question.

What do you mean exactly when you say "once the SPL is offset"? Do you refer to the level parification of the spl result of the trace arithmetic operation with the predicted spl or something else?

I set up this EQ filter using a FDW windowing and I put FDW in the name of the saved IR filter file just to remember it.
However, although for sure I have not applied FDW windowing to the traces, may be that I applied some kind of smoothing like Psychoacoustic or 1/3 octave before performing the trace arithmetic operation on them. So my question is: does the smoothing applied to the traces before performing the Trace arithmetic operation affect the result?

JohnM

· #11 · Nov 14, 2017

Smoothing doesn't matter if the traces have compatible sample rates (same or integer multiple), the result has the smoothing of trace A applied after calculation but that can be changed afterwards as desired.

When the traces are multiplied the level of the result will depend on the level of the traces. If the SPL Offset control is used to shift the filter response so it lies around 0 dB then when you apply it the result will have the same overall level as the signal it was applied to, which can be convenient. Or you can just use the SPL offset control on the result to align it with your other traces.

Ligo

Discussion Starter · #12 · Nov 15, 2017 (Edited)

Yesterday evening I have repeated several times all the steps to compare Trace arithmetic A*B with Predicted SPL, using two different mesaurements and two different filters. It seems unbelievable but the result remains the same for me: they always look quite different.
I can't see what is wrong with my way to operate and I really would like to understand it.
I'll post again with the files and the screenshots, hoping it can help to discover the reason of this anomalous behaviour.

JohnM

· #13 · Nov 15, 2017

Strange. Include the imported filter responses when you save the mdat files.

Ligo

Discussion Starter · #14 · Nov 15, 2017 (Edited)

9

I've set the frequency limit of the bandwiidth in the graphs to 8K and no somoothing is applied.
First three images are the SPL of the measurement, the filter window and the predicted SPL.
Fourth image is the SPL together with the imported filter.
Fifth image is the Trace Arithmetic A*B (measurement mutliplied by the filter) with predicted SPL and no smoothing.
Sixth image is the same as fifth with 1/6 smoothing.
In attach the .mdat of the measurement, the .req of the filter and the .mdat containing the measurement and the imported filter.
Please, let me know if something else is needed.

See less See more

JohnM

· #15 · Nov 16, 2017

Looks like you exported the filter IR at 16 bits. 16-bit data doesn't have sufficient dynamic range to properly capture the IR for your filters, which is why the imported IR isn't the same as the filter response shown in the EQ window. Should be fine if you use 24 or 32-bit data when exporting the filter IR.

Ligo

Discussion Starter · #16 · Nov 17, 2017 (Edited)

2

Well, I exported the filter in 32bit wav but nothing has changed. :dontknow:
The first image is the screenshot of Trace Arithmetic vs Predicted (Psy smoothing).
The imported filter shape doesn't change between 16bit and 32bit too.
If it can help, I've convolved the measurement with the filter using SOX. A lot of steps and some pain with the various conversions but at the end the results of trace arithmetic and convolution are identical, as I expected.
The second image is trace arithmetic vs convolution.
My ears tell me that the predicted SPL is the true FR, so somethng is going wrong with export operation I guess.

See less See more

JohnM

· #17 · Nov 18, 2017

As I mentioned previously, you are applying a Frequency Dependent Window to the imported responses, hence the [FDW] in their names. Perhaps you have selected FDW as your default in the Analysis preferences for Impulse Response Window Defaults, but in any event if you remove that and use 32 bit data you should see an exact match between the predicted response and the trace arithmetic result.

Ligo

Discussion Starter · #18 · Nov 18, 2017

Problem solved!
I had "add frequency dependent window" selected in analisys preferences. I didn't understand that FDW would have beeen the default for every imported IR.
Thank you very much for your help and for your patience. :smile:

JohnM

· #19 · Nov 18, 2017

Phew! Got there in the end.

1 - 19 of 19 Posts

This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.