What's the quality difference between convution reverbs?

VST, AU, AAX, CLAP, etc. Plugin Virtual Effects Discussion
RELATED
PRODUCTS

Post

gonzo wrote:OK then why is the quality difference?
In time domain, with no filters involved, surely two impulses must sound the same in two different reverbs. Is it because of FFT/inverse FFT is involved?
You are correct that any two plugins that use the same exact algorithm should produce identical results. But - the problem is that there are a great many algorithms and nuances available for convolution.

Linear convolution happens in the time domain and yields 'perfect' convolution. It is, however, incredibly CPU intensive and is completely unsuitable for realtime signal processing. Maybe when quantum computing comes along, but for now, it's out of reach.

So ... any convolution plugin you use is almost certainly going to be some variant of FFT-convolve-iFFT. Anytime an FFT is performed you are introducing sonic compromises. How the FFT is done can significantly impact the sound. How the windowing is done can significantly influence the results. The size of the FFT buffer is significant. Even the FFT algorithm chosen can be significant, because there's not just one way to skin that cat.

So anyway, yes there can (and are) real sonic differences between convolution plugins. The best convolution plugins will have the most ideal balance between sonic quality and CPU intensiveness. For me, my $ went to Voxengo, but there are others that are right up there in terms of quality and bang for buck.

Post

Reverend Rhythm wrote:Why don't you try some convos out and report what you find.
fwiw, i just did an informal listening test of ir's from altiverb, space designer, ir1 and tl space. i chose similar impulses (emt halls/plates, lex 480l, etc) and i converted them to WAV files. after that, i loaded the WAVs into several instances of pristine space and ir1.

what i found was that the ir1 impulses sounded the best. big and 3d-sounding. the altiverb ir's were a close second but they sounded a bit flat/2d. tl space's ir's were decent but a little bit thin sounding. space designer's ir's were dark and filtered-sounding - yech...

as for the interfaces, i liked the tweakability of ir1. altiverb's interface is pretty slick, though. too bad there's not a pc version :(

Post

sidrat wrote:what i found was that the ir1 impulses sounded the best. big and 3d-sounding. the altiverb ir's were a close second but they sounded a bit flat/2d. tl space's ir's were decent but a little bit thin sounding. space designer's ir's were dark and filtered-sounding - yech...
Interesting ... did you do all of these tests on a Mac?

Also - did you happen to notice the relative CPU-hungriness of the plugs? For convolution, there is usually a direct tradeoff between quality and CPU hogging ... ?

Post

dburgan wrote:Interesting ... did you do all of these tests on a Mac?

Also - did you happen to notice the relative CPU-hungriness of the plugs? For convolution, there is usually a direct tradeoff between quality and CPU hogging ... ?
actually, i used a pc. i used 4 instances of ir1 then 4 instances of pristine space. also, i used the 2 channel versions of each plug without too significant a cpu hit. all things being equal, i was pretty impressed with the sound of the ir1.

if you want to try the same thing, there's a conversion utility called SDTwoWav that was very helpful in converting some of the ir's. it's pc only, but it might work within virtualpc. it'd be interesting to hear what others think...

Post

Wait I'm confused - I thought you said you used Altiverb and Space Designer ... ? Aren't those Mac-only?

Post

dburgan wrote:Wait I'm confused - I thought you said you used Altiverb and Space Designer ... ? Aren't those Mac-only?
no, i said i used -impulse responses- for altiverb, space designer, tl space and ir1. i converted the impulses to wav and loaded them into ir1 and pristine space on my pc so i could compare their sound...

Post

Oh gotcha, so you weren't testing the convolution algorithm but rather the bundled IR libraries.

Post

exactly...

Post

But sidrat, isn't the point of this thread to see how the same impulse response, fed into different convo reverbs, would sound? We all know the IR1 impulses are great - but then IR1 costs crazy money.

Post

dburgan wrote: So ... any convolution plugin you use is almost certainly going to be some variant of FFT-convolve-iFFT.
You mean FFT-multiply-IFFT, right? Doing convolution in frequency domain would result in amplitude modulation.
dburgan wrote: Even the FFT algorithm chosen can be significant, because there's not just one way to skin that cat.
Well, no matter how you are calculating DFT (discrete fourier transform), the results should always be the same. If it doesn't then it means that something is wrong with a particular algorithm.
The same rule applies to convolution, which can be fully described by math equations, and therefore should produce the same result. If two "convolution plugins" produce different results then it may mean that:
a.) they are not doing it properly (not likely IMO)
or
b.) they are doing something besides convolution

cheers,
Bart

Post

Ok, I have a VERY limited knowledge of dsp, just to get that out of the way!

Id imagine that the direct convolution would always be the same, right? Like someone said earlier, the maths will always churn out the same result.

However, convo reverbs us FFT and inverse FFT. So surely the analysis would account for something? Im assuming they dont all use the same analysis algorithm.

Post

tee boy wrote:Ok, I have a VERY limited knowledge of dsp, just to get that out of the way!

Id imagine that the direct convolution would always be the same, right? Like someone said earlier, the maths will always churn out the same result.
Right.
tee boy wrote: However, convo reverbs us FFT and inverse FFT. So surely the analysis would account for something? Im assuming they dont all use the same analysis algorithm.
Sure - there can be a different FFT block size, different windowing function and window overlap factor (which depends on windowing function), but still, when done properly the result should always be the same, regardless of these parameters.
As I haven't used IR-1 (to expensive), AltiVerb or Space Designer (MAC only) I can't say for sure, but from what I see, they are specificly designed to be used as a reverbs (not as a general purpose convolvers). In that case I would imagine that the authors of these programs "optimized" their products for that specific task and made some additional mechanisms (like impulse prefiltering for example) that are supposed to "boost" (make better sounding) output. These could be the things that make a difference betweens those plugins.


cheers,
Bart

Post

FEV wrote:
dburgan wrote: So ... any convolution plugin you use is almost certainly going to be some variant of FFT-convolve-iFFT.
You mean FFT-multiply-IFFT, right? Doing convolution in frequency domain would result in amplitude modulation.
Precisely. Of course freq domain multiplication is equivalent to time domain convolution.

FEV wrote:
dburgan wrote: Even the FFT algorithm chosen can be significant, because there's not just one way to skin that cat.
Well, no matter how you are calculating DFT (discrete fourier transform), the results should always be the same. If it doesn't then it means that something is wrong with a particular algorithm.
The same rule applies to convolution, which can be fully described by math equations, and therefore should produce the same result. If two "convolution plugins" produce different results then it may mean that:
a.) they are not doing it properly (not likely IMO)
or
b.) they are doing something besides convolution
Or:

c.) they are using an optimized FFT algorithm that does things like precompute lookup table values for sin/cos, etc. to support fast-but-approximate trig functions

d.) they are using a different internal resolution (e.g. long double v. float) which results in different rounding error behavior

e.) they are using a different FFT block size to process the audio stream

f.) they are using a different windowing function to deal with the fact the audio stream is chunked up into a number of discrete blocks

etc.

From a mathematical view you're right of course. FFT = FFT = FFT. But when you implement the FFT in VST, it's a whole new ballgame. Differences can and do arise, simply because we're dealing with a realtime stream that must be blocked, and because we have the need to optimize and are willing to take approximations for certain things to get there.

Post

dburgan wrote: Linear convolution happens in the time domain and yields 'perfect' convolution. It is, however, incredibly CPU intensive and is completely unsuitable for realtime signal processing. Maybe when quantum computing comes along, but for now, it's out of reach.
Sorry, but you are way off, it is most definately feasible to implement normal linear convolution in the time domain only. In fact there is a tradeoff point, a point where if the window size is short enough, performing an FFT/IFFT is MORE computationally intensive.

You are correct of course concerning most IR reverb type filters, where the IR will be quite long. But in the case of simple filtering, for real-time processing, linear convolution may actually be preferred.

Just wanted to point out that it is definately not cut & dry. And that CPUs today have no problem with simple linear convolution.

Anyone interested in the math, here is a nice site I used to send students to. It has a very cool Java app that performs simple linear convolution graphically.
note: you have to click on the text "x[n - k] and h[k]" after selecting or drawing new waveforms.
http://www.jhu.edu/~signals/discreteconv/

Post

birrbits wrote:
dburgan wrote: Linear convolution happens in the time domain and yields 'perfect' convolution. It is, however, incredibly CPU intensive and is completely unsuitable for realtime signal processing. Maybe when quantum computing comes along, but for now, it's out of reach.
Sorry, but you are way off, it is most definately feasible to implement normal linear convolution in the time domain only. In fact there is a tradeoff point, a point where if the window size is short enough, performing an FFT/IFFT is MORE computationally intensive.
Right, but the number of operations required to do linear convolution increases exponentially with the length of the IR and the size of the window, no? So for audio processing purposes, convolving any real world audio impulse response (e.g. room impulse response) with a signal is just plain going to require FFT-based convolution. I was oversimplifying, obviously.

Post Reply

Return to “Effects”