Quote:
Originally Posted by edva  Not a correction exactly, but from my admittedly limited understanding, nebula is much more than "standard" convolution. My ears tell me without question it sounds better than other convolution programs I have heard. |
I'm sure it is. It's porobably playing the kinds of tricks I mentioned above, of mixing some algorithmic stuff in there to help make up for the lack of amplitude sensitivity of convolution, using multiple IRs and so forth. But the other thing, I assume because of how people talk about how heavy weight it is, is that they are using sample based convolution, instead of frequency based.
Basically, convolution works by taking a sample of a space or device. For a device the sample may be fairly short, maybe half a second or less. For a space it might be a few seconds or more. If you are working at 96K and it's a second long, that's 96 thousand samples in the impulse response. If stereo it's 192 thousand samples.
To do sample based convolution, every sample of the input signal has to be multiplied by every one of those samples. That's typically considered just too heavy to do, because it would end up in the situation like I always hear about with Nebula where you can't run many instances at once, and probably can only run a couple because of them being short device type impulse responses instead of the longer ambience type ones.
To get around that, what a lot of programs will do is to break the IR into a set of chunks of, say, 128 samples. On each of those they will perform a Fast Fourier Transform. This extracts the frequency content of the chunk of samples. Each of the small chunks is actually overlapped a bit so as to avoid creating discontinuities, and the start and tail of each are ramped up and down so that they blend together.
So now they are working in the frequency realm and can use this information to apply far fewer operations to the incoming samples, by applying the resulting FFT info to the samples. But, the result is far less accurate, because in order to get a reasonable image of the frequency content you have to work in some reasonable sized chunks of samples. If you don't get an fairly reasonable respresentation of the frequency content, then the results will be off. But, that means that the more accurate the frequency (larger the window) the less accurate the timing is, because the amplitude changes that caused those frequency changes are less and less and accurately applied to the time at which they occurred. And the need to overlap the chunks also introduces inaccuracy.
So your options are far less overhead but considerably less accuracy, or complete accuracy and a lot of overhead. For reverb type IRs the frequency style is probably all that's doable for real time processing, once you get up to more than second or two at high sample rates. With an IR of 1 second at 96K and the incoming signal it's being applied to being at 96K, then one seconds worth of audio being run through the IR results in 9.2 billion floating point calculations. If stereo, then 18.4 billion.
Then you start playing the tricks where you are either just basically interpolate the result from a single IR process (not very accurate), or you run three or four IR processes and interpolate from those and the overhead starts going up to three or four times that.
Though in theory Intel CPUs can do that kind of processing, the advertised numbers are the theoretical maximums when the machine is completely dedicated to that and nothing else, not when it's running lots of other programs and also required to do real time processing of the audio through various plugins and fancy interfaces that are also sucking CPU, and being required to remain responsive to your mouse and keyboard interactions. So it really puts a huge burden on the machine.