Differences in Convolvers?

[GaryG]

I'm just trying out some IRs in a different convolver and can't quite get the same results. I think the character is there but can't quite get the overall sound the same. One sounds more upfront etc. Can the actual process vary on how the convolution is applied (obvs know nothing about the DSP involved )

I'm guessing there's small differences in the audio handling around the process (slightly different mix law etc), certainly one seems a few DBs louder. Maybe I should just set up a more thorough test (proper metering etc)

For the record, Kilohearts Convolver and MConvolutionEZ, trying the Melda IRs in both (prefer the UX and stretch feature in KH).

Cheers.

[imrae]

Without any stretching etc enabled there is a mathematically "correct" result people should be agreed on.

Normalisation is arbitrary though, so well worth tweaking the levels

[Unaspected]

Convolution in the time domain is multiplication in the frequency domain.

There are two methods that I know that can arrive at this:

A naïve, brute force, method would be to use a FIR filter configuration and load the IR sample values as the filter coefficients. This, however, can be quite expensive in terms of CPU - though I imagine a graphics processor would find this kind of operation less of a problem.

A more efficient method is to use some form of Fourier Transform and then multiply the spectra with that of the IR.

I can think of a couple of ways to address the FIR, with the second being a recursive method; where feedback is employed about the central FIR topology - which does not traditionally employ any feedback.

When it comes to Fourier Transforms, there are loads of variables at play which can impact on the final sound: Different methods, window shapes, bin size/frequency division, etc. So I would expect for different convolution engines to sound different.

[imrae]

I had the impression the typical overlap-add and overlap-save methods are exact when implemented correctly? https://en.wikipedia.org/wiki/Overlap%E ... add_method

[Unaspected]

Oh, I would expect results [created using the same or comparable methods and similar design parameters] to be indistinguishable by ear. However, I doubt it would be the only method employed in all plugins. Given plenty of choices for design, I see potential for audible sonic differences between plugins. Though this also might not be what GaryG is picking up on.

[dreamvoid]

Convolution in the time domain is multiplication in the frequency domain.

There are two methods that I know that can arrive at this:

A naïve, brute force, method would be to use a FIR filter configuration and load the IR sample values as the filter coefficients. This, however, can be quite expensive in terms of CPU - though I imagine a graphics processor would find this kind of operation less of a problem.

A more efficient method is to use some form of Fourier Transform and then multiply the spectra with that of the IR.

I think the first method is used for hardware convolution like in the Sony DRE777 and the Yamaha SREV1, the second method for plug ins.
There is a difference in sound for the same IRs between these methods in my experience.

[CinningBao]

Fascinating.

From what you say, dreamvoid, in hardware, if the IR is converted into a set of filter coefficients, which sounds like a destructive process, it isn't as 'clean' as the software process? Are these different methods perhaps a result of the cost of memory? What advantage would there be to doing it the hardware way if it's gone through the conversion process? Fewer abstracted software layers?

Quite curious, as you can probably tell.

[Unaspected]

Fascinating.

From what you say, dreamvoid, in hardware, if the IR is converted into a set of filter coefficients, which sounds like a destructive process, it isn't as 'clean' as the software process? Are these different methods perhaps a result of the cost of memory? What advantage would there be to doing it the hardware way if it's gone through the conversion process? Fewer abstracted software layers?

Quite curious, as you can probably tell.

It isn't a destructive process but like for like. A digital audio stream will have values ranging from -1 to 1 and these are the exact same values that would be used within the FIR topology. No conversion required at all.

[Unaspected]

Convolution in the time domain is multiplication in the frequency domain.

There are two methods that I know that can arrive at this:

A naïve, brute force, method would be to use a FIR filter configuration and load the IR sample values as the filter coefficients. This, however, can be quite expensive in terms of CPU - though I imagine a graphics processor would find this kind of operation less of a problem.

A more efficient method is to use some form of Fourier Transform and then multiply the spectra with that of the IR.

I think the first method is used for hardware convolution like in the Sony DRE777 and the Yamaha SREV1, the second method for plug ins.
There is a difference in sound for the same IRs between these methods in my experience.

Makes sense: Those hardware units will employ specific DSP chips that are capable of running filters with several taps. As this design has the fewest variables it is probably more like to produce results that are identical.

Methods for dealing with alias frequencies would also present several design variables that can also impact on the perceived sound.

I think that GPUs would probably take well to processing FIR filters as should NPUs or any system that is designed for handling multiplication on a massive scale. There was a YouTube video I watched recently which was discussing the potential for analogue boards being used for NPU duties and this could really open up a new world for audio processing ITB.

[Music Engineer]

When it comes to Fourier Transforms, there are loads of variables at play which can impact on the final sound: Different methods, window shapes, bin size/frequency division, etc. So I would expect for different convolution engines to sound different.

Such things should not matter in the case of FFT convolution because in this case, you are actually not supposed to do any windowing, i.e. the engine would just rectangular windows. The only real difference between different convolution algorithms should be different roundoff noise.

[imrae]

Methods for dealing with alias frequencies would also present several design variables that can also impact on the perceived sound.

What aliasing? It's linear.

[Unaspected]

When it comes to Fourier Transforms, there are loads of variables at play which can impact on the final sound: Different methods, window shapes, bin size/frequency division, etc. So I would expect for different convolution engines to sound different.

Such things should not matter in the case of FFT convolution because in this case, you are actually not supposed to do any windowing, i.e. the engine would just rectangular windows. The only real difference between different convolution algorithms should be different roundoff noise.

Ah. Thank you. I was unaware of that!

Just done a little reading on this and it seems some people still window when designing algorithms for this purpose - likely out of habit - though it does seem to be unnecessary.

[Unaspected]

Methods for dealing with alias frequencies would also present several design variables that can also impact on the perceived sound.

What aliasing? It's linear.

Shouldn't a signal convolved with the output of a high rate modulator produce sidebands which could alias?

There is also possible requirement for resampling to meet the sample rate of the program - This will require some form of AA filtering. So this might be another reason for hearing a difference, if the same IR is loaded into various convolution plugins and it requires resampling prior to use.

[dreamvoid]

Fascinating.

From what you say, dreamvoid, in hardware, if the IR is converted into a set of filter coefficients, which sounds like a destructive process, it isn't as 'clean' as the software process? Are these different methods perhaps a result of the cost of memory? What advantage would there be to doing it the hardware way if it's gone through the conversion process? Fewer abstracted software layers?

Quite curious, as you can probably tell.

Sorry, I'm not into the technical details that deep, especially not into the used math. Casey, the developer of the Bricasti M7, wrote on Gearslutz/Gearspace about hardware convolution:
"The Sony performs the convolution in the time domain. The plugins do it in the frequency domain.
In theory these should be the same. In reality the Sony just sounds better."
I do think the same goes for the Yamaha SREV1. One of mine has 64 DSPs built in (32 are standard, plus the 32 DSP extension board) and makes a fabulous surround convolution reverb I use for bigger or important productions.
SOS wrote in their review: "the SREV1 employs no fewer than 32 DSPs designed specifically to perform the many calculations required for real-time convolving reverberation — up to 520,000 steps per sample!"
Yamaha wrote about the history of the SREV1: "The DSP capacity of the SREV1 ran into several GFLOPS, an absolutely impressive level at that time."

[mystran]

I had the impression the typical overlap-add and overlap-save methods are exact when implemented correctly? https://en.wikipedia.org/wiki/Overlap%E ... add_method

Yes, they are mathematically equivalent to the brute-force approach. In practice any efficient low-latency convolver is actually going to have to use slight more complex strategies than either naive brute force or a simple FFT convolution, but again you can do this in a way that's mathematically equivalent. So unless one convolution processor runs into significant numerical precision problems, the actual convolution should always give the same results with any of them. There is very little room for any quality differences here (beyond taking care of numerical precision) as it's either correct or it's not.

However, practically speaking there might be other things going on that don't really have anything to do with convolution for example resampling IRs to the correct sampling rate, envelopes, EQ might vary slightly from one plugin to the next. Once we get into processing like stretching, then that's going to vary even more. None of these are cases where the convolution itself would give different results, but they are things often found in convolution processors where there is a lot more room for different results.