Differences in Convolvers?

[GaryG]

Thanks for all the input, interesting reading.

I've played more and can actually get pretty similar results so think, in my case, it's down to level mismatching, not paying attention to the pre-delay accurately etc. Almost got them to null too so differences must be pretty small, not enough for me to worry about.

So, winner is Kilohearts Convolver for me, I like the simplicity of their plugs, gui etc.

[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.

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

No, linear convolution cannot add bandwidth. I suppose if the kernel already contained aliasing the results would sound a bit weird, but there is nothing the convolver can do about that.

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.

I suppose it is possible for a developer to badly mess up the IR resampling and create the effect described above. But that's more on the defective/incompetent end of the scale than a reasonable implementation difference.

I suspected OP's issue was more to do with level-matching or extra IR-tweaking features; looks like OP agrees!

[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?

No, linear convolution cannot add bandwidth. I suppose if the kernel already contained aliasing the results would sound a bit weird, but there is nothing the convolver can do about that.

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.

I suppose it is possible for a developer to badly mess up the IR resampling and create the effect described above. But that's more on the defective/incompetent end of the scale than a reasonable implementation difference.

I suspected OP's issue was more to do with level-matching or extra IR-tweaking features; looks like OP agrees!

Yes. And I've equally learned a few things.

My only previous experience was with implementing naïve FIR topology and DFT for analysis purposes - so I assumed similar design considerations were necessary when performing convolution using FFT. Good to know there is less to worry about when I eventually get round to trying that method!

My thinking regarding modulation though was on a similar line to direct modulation. Not a concern for FFT, of course - but for the FIR topology, I see little difference compared to straight modulation if the "IR" wasn't first band limited. Considering the kind of fluctuation that could occur early in an IR. Though this wouldn't be typically used for plugins due to the massive cost to CPU.

Indeed, I'm probably contemplating things that are highly unlikely when designing a solution.

[imrae]

Windowing for FFT analysis looks like a massive pain, I can believe that would be memorable!

I think you're right that modulating the IR could generate some content; after all, lots of IR plugins have drop-outs while rebuilding the kernel and those would be clicks/pops without smoothing! I guess I don't generally associate convolution with modulation... (And it isn't the convolution itself creating the problem, it's mashing together a series of different ones...)

[dreamvoid]

There is another difference for the hardware convolution: the IR sampling process. The Sony and the SREV1 allow multiple passes with a long sweep, then some averaging takes place and the noise/signal ratio can be much better than with a single pass IR sampling.

[Unaspected]

Windowing for FFT analysis looks like a massive pain, I can believe that would be memorable!

I think you're right that modulating the IR could generate some content; after all, lots of IR plugins have drop-outs while rebuilding the kernel and those would be clicks/pops without smoothing! I guess I don't generally associate convolution with modulation... (And it isn't the convolution itself creating the problem, it's mashing together a series of different ones...)

Synchronising everything is probably the biggest headache. When approaching any DSP I like to break things down into the smallest tasks and work in a modular fashion, so I left windowing until I had the main process working. Already having a basic granular engine under my belt probably made windowing more intuitive.

There is another difference for the hardware convolution: the IR sampling process. The Sony and the SREV1 allow multiple passes with a long sweep, then some averaging takes place and the noise/signal ratio can be much better than with a single pass IR sampling.

I don't know if multiple passes would be used when producing libraries for plugins but it would make sense to do this. Though I would think this should lead to engines that can play back multiple IRs at random for greater depth of sound. I'm sure there must be some out there.

[fotisandstuff]

Wow, perfect timing! I have my own convolver question...

I bought this EQ IR pack from PastToFuture Reverbs and I am looking for the cleanest convolver for EQ IRs. I tested MConvolutionEZ, ConvologyXT and Flandersh Tech's GFilter, but, when I place them inside Bertom's EQ Curve Analyzer and click "Show Phase", I see some weird phasing errors (MConvolutionEZ has the least amount of phasing errors, while GFilter is the worst offender). The same is true with IRs generated with Flandersh Tech's GGen.

[dreamvoid]

I don't know if multiple passes would be used when producing libraries for plugins but it would make sense to do this. Though I would think this should lead to engines that can play back multiple IRs at random for greater depth of sound. I'm sure there must be some out there.

I'm pretty sure, that this is the "secret" why some commercial IRs sound better than what the regular user can achieve. While sampling hardware devices with my SREV1 and then comparing the results with the original machine, the IR results often sounded significantly better than the original, noise wise.

[Samplicity]

I have tests in the "build pipelines" of my plugins that compare my FFT based convolution code with the direct approach to test for identical results (apart from ridiculously small rounding errors). If these tests fail, I must have accidentally introduced bugs somewhere in the convo code.

The direct and FFT approaches must deliver the same output, sample-by-sample, so, well written convolution engines must "sound" completely equal, identical. Quite boring, but it allows to focus on the quality of the impulses used with them.

Cheers