DSPRelated.com
Forums

FFT convolution giving different results from convolution

Started by Michel Rouzic July 25, 2005

Andor wrote:
> If you want to insist on overlap-add, then you have to use the whole > (M+L-1)-point output of the IFFT. Use M points to reconstruct the > signal, and let the remaining L-1 points overlap into the next > frame(s), where you have to add them to the M points that you get from > the IFFT.
yeah but, i thought that already what i was doing (besides the fact that i havent made any overlap-add function yet), but i've got aliasing...
> It's kind of tedious, because depending on the length of L, > you have to keep track of several IFFT frames and add all the correct > values to get the proper convolution. Overlap-save is really much > simpler (and also more efficient, as you don't have to do any adding > after the IFFT). > > Regards, > Andor
the other thing is that i know what overlap-add consists in, but i dont know about overlap-save (it wasn't in the dspguide.com thing). would there be any resource you could indicate me on overlap-save that would be explained as nicely as on dspguid.com?
Michel Rouzic wrote:
> Unfortunatly I don't think I got it all, but it seems to me that with > what you're trying to explain me, you're still getting a M size output > signal, as what i'm looking forward doing is obtaining a M+L-1 points > output signal, exactly in the same way as the convolution described in > chapter 6 of dspguide.com, except that it would be using FFT. so, > what's the simplest way for me to get to that considered what i've > already done?
I think you are mixing two ideas from the book, but I haven't pulled it out to be sure. Any filter has beginning and end transients, but we usually accept them as insignificant if the signal to be filtered is long. When implementing an FFT-based FIR, there are end transients on each block that must be dealt with even when the issue of circularity is resolved. M transient-free output points is all you get. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Michel Rouzic wrote:

> ... I still can't > understand why I get aliasing with what I do, but I hardly could follow > when they started with their BASIC code thing. they really should have > used something like C rather than BASIC..
... His reason for using BASIC is clearly stated: It's probably more widely known to his intended audience than any other language, and (at the time the book was written) it was installed on most computers. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������

Michel Rouzic wrote:
> i forgot to mention that i realloc both the input signal and kernel and > zero-pad them so that there length is for both of them the length of > the input signal plus the length of the kernel minus one. thus i avoid > circular convolution, right?
That should do it. Usually both input and kernel are of the same length, a power of two, and they are zero extended to twice that length rather than twice minus one because FFT's like powers of two. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein

Jerry Avins wrote:
> Michel Rouzic wrote: > > > ... I still can't > > understand why I get aliasing with what I do, but I hardly could follow > > when they started with their BASIC code thing. they really should have > > used something like C rather than BASIC.. > > ... > > His reason for using BASIC is clearly stated: It's probably more widely > known to his intended audience than any other language, and (at the time > the book was written) it was installed on most computers.
Which is a good reason why one would want to publish pseudo code, not source code, if one would want one's work to stand the test of time. Rune
Rune Allnor wrote:
> > Jerry Avins wrote: > >>Michel Rouzic wrote: >> >> >>> ... I still can't >>>understand why I get aliasing with what I do, but I hardly could follow >>>when they started with their BASIC code thing. they really should have >>>used something like C rather than BASIC.. >> >> ... >> >>His reason for using BASIC is clearly stated: It's probably more widely >>known to his intended audience than any other language, and (at the time >>the book was written) it was installed on most computers. > > > Which is a good reason why one would want to publish pseudo code, not > source code, if one would want one's work to stand the test of time.
There is no particular reason that pseudocode has to be reminiscent of Pascal. BASIC is a reasonable alternative. It has the additional advantage that it can (could) be entered into most computers and run. Some would say that Matlab is executable pseudocode, but few computers have it loaded. I see Smith's use of BASIC as an poor illustration of Gresham's Law. http://en.wikipedia.org/wiki/Gresham's_law Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������

Jerry Avins wrote:
> Rune Allnor wrote: > > > > Jerry Avins wrote: > > > >>Michel Rouzic wrote: > >> > >> > >>> ... I still can't > >>>understand why I get aliasing with what I do, but I hardly could follow > >>>when they started with their BASIC code thing. they really should have > >>>used something like C rather than BASIC.. > >> > >> ... > >> > >>His reason for using BASIC is clearly stated: It's probably more widely > >>known to his intended audience than any other language, and (at the time > >>the book was written) it was installed on most computers. > > > > > > Which is a good reason why one would want to publish pseudo code, not > > source code, if one would want one's work to stand the test of time. > > There is no particular reason that pseudocode has to be reminiscent of > Pascal. BASIC is a reasonable alternative. It has the additional > advantage that it can (could) be entered into most computers and run. > Some would say that Matlab is executable pseudocode, but few computers > have it loaded.
Well, if given a choise, I would prefer a pseudocode that has no similarity to any existing programming languages. If pseudocode mimices a language, it could be seen as an indication that there is a "best" language for the algorithm. Actually, I saw that Golub & van Loan basically used matlab as their pseudocode language in their 3rd edition of the book on matrix computations. The pseudocode in that book *is* relatively easy to read, and matlab *is* well suited for those types of algorithms... hey, did I just contradict my first paragraph? Rune
Rune Allnor wrote:

> ... I would prefer a pseudocode that has no > similarity to any existing programming languages. If pseudocode > mimices a language, it could be seen as an indication that there > is a "best" language for the algorithm. > > Actually, I saw that Golub & van Loan basically used matlab as their > pseudocode language in their 3rd edition of the book on matrix > computations. The pseudocode in that book *is* relatively easy to read, > > and matlab *is* well suited for those types of algorithms... hey, did > I just contradict my first paragraph?
Maybe not. Think of a pseudocode as a pidgin language. The closer the linguistic roots of the people among whom the pidgin develops, the more like a variant of that language will it become. Esperanto, although completely artificial, is nevertheless largely Romance. It might make a good linguistic "pseudotongue". Among earthlings, Klingon would not. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
um... i'm trying to do a convolution with a input signal of 2,103,154
samples and a kernel filter of 3 samples, both brought back to
2,103,156 samples. is that wrong?

Bob Cain wrote:
> Michel Rouzic wrote: > > i forgot to mention that i realloc both the input signal and kernel and > > zero-pad them so that there length is for both of them the length of > > the input signal plus the length of the kernel minus one. thus i avoid > > circular convolution, right? > > That should do it. Usually both input and kernel are of the > same length, a power of two, and they are zero extended to > twice that length rather than twice minus one because FFT's > like powers of two. > > > Bob > -- > > "Things should be described as simply as possible, but no > simpler." > > A. Einstein
Michel Rouzic wrote:
> um... i'm trying to do a convolution with a input signal of 2,103,154 > samples and a kernel filter of 3 samples, both brought back to > 2,103,156 samples. is that wrong?
Yes. FFT convolution is useful for long filter kernels; the signal length is nearly immaterial. You are going after mosquitoes with a rifle, wondering if there may be better bullets. Your swatter is a simple MAC. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������