Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

EQ matching

DSP related issues, mathematics, processing and techniques

EQ matching

Postby KG_is_back » Mon Apr 25, 2016 12:51 am

Here's the basic idea... As you probably know, you can emulate an EQ by capturing its impulse response and use it in a FIR filter. You can capture the IR in various ways, most common being passing known testing signal (usually a sine sweep or white noise) through the filter and then calculate the IR using deconvolution.
Problem is, FIR filters tend to be ridiculously CPU expensive and have poor precision in the low-end, because their frequency resolution is linear (instead of logarithmic like human ear).

Lately I've been working on different method. From the known dry and wet testing signal it is possible to estimate coefficients for a IIR filter. They can be much more CPU friendly and do not have the frequency resolution problem. In future I can even add non-linearities estimation, which would allow to emulate wide variety of devices (including guitar amps, analogue EQ's etc.). Kind of like Acustica Nebula or Kemper profiling amp.

Now, my current schematic is rather sparse. It contains a makeshift filter (coded in code component). The schematic passes a testing signal through it (impulse) and then estimates the coefficients from the captured wet and dry signals. You can compare (just numerically, not visually, sorry for my laziness) the original vs estimated coefficients, as well as original vs. estimated impulse response.

I've been kind of burned out lately with this project and flowstone in general, so I'm hoping to catch a fresh wind from your opinions and ideas guys...
Attachments
EQmatch.fsm
(9.24 KiB) Downloaded 1482 times
KG_is_back
 
Posts: 1196
Joined: Tue Oct 22, 2013 5:43 pm
Location: Slovakia

Re: EQ matching

Postby RJHollins » Mon Apr 25, 2016 4:04 am

Hi KG.

OK ... definitely got my attention :lol:

Just loaded up schematic, and looking around, looking to grasp what you've created here.

1st mystery setting. Into the 'least squares method fitting' module, you have a BOOLEAN [set to FALSE]. Inside this is connected to a 'pp' value. What is this ?

.... more questions and interest to follow 8-)
RJHollins
 
Posts: 1567
Joined: Thu Mar 08, 2012 7:58 pm

Re: EQ matching

Postby KG_is_back » Mon Apr 25, 2016 1:16 pm

RJHollins wrote:1st mystery setting. Into the 'least squares method fitting' module, you have a BOOLEAN [set to FALSE]. Inside this is connected to a 'pp' value. What is this ?


The entire process is based on least squares method. The equation of the filter is:
y[0] = k00*x[0] + k01*x[1] + ... +k11*y[1] + k12*y[2] +...
x is the dry signal and y is the wet signal (y[1] is the wet signal delayed by 1 sample for example) and both are known. It is a linear equation and coefficients K may be estimated via least squares method. The estimated coefficients is what is being displayed in the schematic.
Problem is, that LSM (least squares method) needs to solve a matrix of linear equations, which turns out to be singular in most cases (namely, when the selected order is higher than the order of original filter). If that turns out to be the case, I set the least significant coefficient to 0 and try to solve the smaller matrix.
You can see this in the resulted coefficients (the last few are zero). The "mystery setting" merely changes which coefficients should be prioritized. Unfortunately, the result was kind of opposite to what I've expected...

Another important fact is, that the dry and wet signal need to be latency compensated within +-ORDER samples (preferably perfectly matched). I will try to automate this process in the future.

I'm also considering moving some calculations into blue. In the future, the testing signal might be several seconds long, which will result in some matrices being several thousand elements wide. Ruby might not handle this well (you can see this - just set "analysis length" to several thousand and FS will most likely freeze). This might be solved by putting in some sort of progress bar (I've done something similar in the past using threads).
KG_is_back
 
Posts: 1196
Joined: Tue Oct 22, 2013 5:43 pm
Location: Slovakia

Re: EQ matching

Postby RJHollins » Mon Apr 25, 2016 5:55 pm

I'm gonna try and learn something from your efforts and postings.

Thanks KG !

8-)
RJHollins
 
Posts: 1567
Joined: Thu Mar 08, 2012 7:58 pm

Re: EQ matching

Postby cbbuntz » Sat Jul 02, 2016 3:20 am

It appears to be working nicely! I have been down this rabbit hole before too. I have tries several methods of curve fitting IIR filters with mixed success.

Least squares:
+ Tends to have lower average error
+ Can yield a smoother response than other methods

- Rounding error can go * really * haywire when the filter order gets high, even with double precision
- You can sometimes get really strange looking curves with overshoots in places they shouldn't be

Solving a matrix by evaluating transfer function at predefined points
+ When using Chebyshev (or similar) points, it tends to have lower maximum error
+ Less expensive computationally
+ You can explicitly define the response at user-defined frequencies. This is really cool for designing allpass filters. It works perfectly! Well, aside from the fact than many solutions have unstable poles. Regardless, it can still be useful for interpolating the response to generating stable FIR coefficients.

------------

I came to the conclusion that curve fitting IIRs is probably something you would want to evaluate beforehand. Results are often erratic, unpredictable and many solutions are unstable. I've had better results just correcting error with a short FIR. It's predictable, stable and more straightforward to solve.
cbbuntz
 
Posts: 10
Joined: Sat May 07, 2011 5:50 pm

Re: EQ matching

Postby RJHollins » Sat Jul 02, 2016 3:47 am

Might you have a FS soluion .... that you'd share :mrgreen:

I honestly wish that I had studied these concepts in college ... except ... these ideas were not around :| [punch cards and later, Z-80 chip ... one step up from a Ech-a-Sketch and an abacus].
RJHollins
 
Posts: 1567
Joined: Thu Mar 08, 2012 7:58 pm

Re: EQ matching

Postby gerardnorris549 » Sat Nov 12, 2016 9:18 am

Information post. learn new thing from your post.
gerardnorris549
 
Posts: 1
Joined: Fri Sep 30, 2016 6:50 am
Location: US


Return to DSP

Who is online

Users browsing this forum: No registered users and 14 guests