Jump to content
flkin

Convolution with Null filters are audible

Rate this topic

Recommended Posts

Around a month ago I used convolution for the first time to remove some bass room nodes. It went well and tamed a few room nodes that I had wanted removed and I started to advocate the use of convolution as a tool for better sound. But after a time of continued listening, I felt I had lost something in the process. And despite attempts to adjust for this I didn't find a way. Eventually I started to wonder if it was the process that was causing this to happen. So I tried to use a NULL convolution file to see if I could hear just the convolution module (in Roon) without any adjustments (frequency, phase, etc) to the audio file.

 

This experiment is described in the Roon community chat found here https://community.roonlabs.com/t/convolution-with-null-filters-are-audible/51732 . Here, around 5 persons found the same result as me. Convolution with Null filters are indeed audible.

 

The result is that it's quite clear to me (and others now) that the process of adding convolution even without frequency/phase/level changes still take away something from the music. I noticed that the mids and upper lost some dynamics, engagement and immediacy and it's not subtle. The loss is such that I am willing to look for alternative solutions for my room bass nodes rather than to use convolution.

 

I'm wondering if anyone else that is using convolution has experienced this and has found a solution for it?

Share this post


Link to post
Share on other sites

A NULL filter would be a convolution filter that does nothing. No frequencies or phase is adjusted. It's an empty WAV file (for Roon). 

 

This attenuation of the signal was suggested as a possible reason but it doesn't likely as I didn't find it possible to get back the same sound by adjusting the volume slightly louder.

Share this post


Link to post
Share on other sites

Do you have the means to capture the digital signal being sent to the DAC? If you do, compare a capture with and without the "null" filter (that's not a standard DSP term).

Share this post


Link to post
Share on other sites

If this was the case and I heard something, definitely something wrong with my brain then! ?

 

The NULL filter refers to the convolution filter that does nothing. In Roon's convolution, I can hear a difference between using a NULL filter and not. Shouldn't be any difference but it's there.

 

Going to try your suggestion Miska about the HQPlayer convolution with the 2 mono files and not using the Matrix option soon. Hope for the best

Share this post


Link to post
Share on other sites
1 hour ago, flkin said:

The NULL filter refers to the convolution filter that does nothing. In Roon's convolution, I can hear a difference between using a NULL filter and not. Shouldn't be any difference but it's there.

 

My point was that it is not standard nomenclature as mansr noted. So it can cause some misunderstandings and sounds a bit strange as a term in this context...

Share this post


Link to post
Share on other sites

Ok folks, I've ran HQPlayer with the mono Null filters and I cant really tell the difference between using the filters and not. Perhaps a slight worsening with the filters in but I wouldn't be able to tell in a blind test.

 

So I'm thinking there's something broken with the Roon convolution filter system. It's audibly damaging the signal even with a Null filter that should do nothing. Brought it to the attention of Brian at Roon and he's added it to his list of things to do but it's a long list and he won't be working on it anytime soon.

Share this post


Link to post
Share on other sites

Update on Roon convolution. Looks like there is indeed a bug in the convolution module in way resampling filters are handled. Alex Eiffel in the Roon communities found a way to measure the problem and deduced the issue.  CTO Brian from Roon Labs accepted his reasoning.

 

Full details are here in message 137.  

https://community.roonlabs.com/t/convolution-with-null-filters-are-audible/51732/138 

 

but probably safe to say this will eventually be fixed in Roon eventually. Convolution might be usable after all! ?

Share this post


Link to post
Share on other sites

It seems fine in JRiver. I cannot listen to analog xovers anymore after hearing properly implemented impulse response filters and convolution.

Share this post


Link to post
Share on other sites

Buf i

On 11/25/2018 at 7:34 AM, flkin said:

Update on Roon convolution. Looks like there is indeed a bug in the convolution module in way resampling filters are handled. Alex Eiffel in the Roon communities found a way to measure the problem and deduced the issue.  CTO Brian from Roon Labs accepted his reasoning.

 

Full details are here in message 137.  

https://community.roonlabs.com/t/convolution-with-null-filters-are-audible/51732/138 

 

but probably safe to say this will eventually be fixed in Roon eventually. Convolution might be usable after all! ?

 

Brian comitted to look into it and fix the bug in one upcoming version of Roon (no deadline given). 

In the meantime make sure your convolution .zip file contains filters at all the frequencies you are playing, as Roon is improperly resampling them. Or use another convolution engine such as HQPlayer or Jriver.

Share this post


Link to post
Share on other sites
On 11/16/2018 at 5:35 PM, LX521 said:

Then their convolution algo is broken.

Yes -- a filter which does NOTHING is effectively a single multiplication.  If someone can hear a *1.0 operation, then something is wrong somewhere.  It sure could be buggy software.  (There are definitely issues that can happen with precision truncation, but as long as someone is sanely using 24 bits or floating point, then there are seldom problems -- but there CAN be.)  When manipulating low frequencies, one might use decimation & interpolation, and bad algorithms for that can  be problematical.

In my project, I have avoided using decimation & interpoloation except for a singular rate conversion -- things can become complicated, and my project is complicated enough.

 

 

Share this post


Link to post
Share on other sites

By precaution I would keep convolution filters 32 bits or more. 

Maths shot from the hip:

- assuming 100000 tap filter

- implementation in the time domain 100000 multiplications, 100000 additions

- quantization noise grows proportional with square root of operations. I guess this coeff of proportionality is somewhere between 0.2 and 1. So 0.2x sqrt(100000+100000) = 90, thereof 6-7 bits “eaten” by the various operations. A 24bit file will turn into a 17-18 bit file, maybe worse.

Of course in real life, convolution is implemented through fast convolution and DFT, so maybe ultimately the addition of quantization errors is not as bad, but why take the risk ?

My 2 cents

Share this post


Link to post
Share on other sites

Nowadays, you often don't need to go through the fft mechanism for normal sized filters -- CPUS are pretty fast now, and some kinds of errors are less of a problem.  (There are other kidns of errors that are really unpleasant using the direct approach.)  On my project, using the FFT is probably more of a problem than it is worth, even though I have written FFT based NR programs in the past.  I need to be incredibly careful about any errors.  I guess if one is using a 'stupid' interpreter that doesn't use AVX/SSE2 (or NEON), then there is a real speed issue, but using AVX can often give an 8X speed increase when doing FIR over not using the instruction (almost) if one is very careful in the implementation. FFTs seem to get less of an advantage from SIMD instructions -- but I'd expect that some advanced FFT routines (probably GPLed like FFTW probably is) might be able to take advantage of the super useful SIMD instructions.  (The SIMD instructions can often give nearly the same speed of perhaps 8 multiplies as using 1 on normal multiply instr.)  There are even multiply-add instructions that can give an additional boost.  Also, some of the more advanced Intel machines can even do more SIMD operations.

 

So, for shorter filters (perhaps 512 or smaller), the idea that a 'null' filter (just passes the data) being a multiply by 1 is true.

 

BTW -- recent compilers are sometimes pretty good at finding ways of using SIMD, but the code still needs to consider the best way to write the code for the compiler to take maximum advantage.

 

John

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×