Hi, I have a simple application which - continously ready samples at 96kHt sampling rate, - chops it into blocks of, let's say, 16384 samples, - multiplies each block with the Hann window function, - performs a 16384 point FFT (real->complex) on each block, - modifies the data (the frequency spectrum) from the FFT, - performs an iFFT (complex->real) on the data, - shoves it into the output buffer, with an overlap of 25%, adding the new data to the already present data, - repeats the whole thing (with an offset of 4096 samples). Obviously, the first FFT runs from samples 0..16383, the next one from sample 4096-20479, and so on. The reason why I do this that way? Simple, I read it in a book ;-) The application is supposed to split audio frequncies into different bands (a classical crossover application) and (optionally) also to apply a frequency response correction to the signal (a classical EQ). Tested it, appears to work with with noise from my, erm, ingenous noise source (attached a measurement/reference microphone to the input of the FW410, placed it near the fan of the laptop, and received plenty of noise...). Some more background: the application uses FFTW and runs on a dual core Intel processor, multi-threaded, of course. So what's my problem? Well, I'd rathe rlike to use the Blackman window function instead of the Hann ("Hanning") window function. However, while it is obvious for me (I think) why the overlap-add method method works with the Hann window, I have no idea which overlap is required for the Blackman window. Can anybody enlighten me? Yup, I am a NOOB. Try to keep math away from me ;-) Thanks, and best regards, Klaus
How do I perfrom the correct overlap after FFT/iFFT when using a Blackman window?
Started by ●February 26, 2007
Reply by ●February 26, 20072007-02-26
KlausS wrote:> Hi, > > I have a simple application which > - continously ready samples at 96kHt sampling rate, > - chops it into blocks of, let's say, 16384 samples,> - multiplies each block with the Hann window function,NO! Not with overlap. How did this nonsense get started? It just won't die!> - performs a 16384 point FFT (real->complex) on each block, > - modifies the data (the frequency spectrum) from the FFT, > - performs an iFFT (complex->real) on the data, > - shoves it into the output buffer, with an overlap of 25%, adding the new > data to the already present data, > - repeats the whole thing (with an offset of 4096 samples). > > Obviously, the first FFT runs from samples 0..16383, the next one from > sample 4096-20479, and so on. > > The reason why I do this that way? Simple, I read it in a book ;-)What book? It needs a few pages ripped out.> The application is supposed to split audio frequncies into different bands > (a classical crossover application) and (optionally) also to apply a > frequency response correction to the signal (a classical EQ). > > Tested it, appears to work with with noise from my, erm, ingenous noise > source (attached a measurement/reference microphone to the input of the > FW410, placed it near the fan of the laptop, and received plenty of > noise...). Some more background: the application uses FFTW and runs on a > dual core Intel processor, multi-threaded, of course. > > So what's my problem? Well, I'd rathe rlike to use the Blackman window > function instead of the Hann ("Hanning") window function. However, while > it is obvious for me (I think) why the overlap-add method method works > with the Hann window, I have no idea which overlap is required for the > Blackman window. Can anybody enlighten me? > > Yup, I am a NOOB. Try to keep math away from me ;-) > > Thanks, and best regards, Klaus > >-- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●February 26, 20072007-02-26
On Feb 26, 9:49 am, Jerry Avins <j...@ieee.org> wrote:> KlausS wrote: > > > I have a simple application which > > - continously ready samples at 96kHt sampling rate, > > - chops it into blocks of, let's say, 16384 samples, > > - multiplies each block with the Hann window function, > > NO! Not with overlap. How did this nonsense get started? It just won't die! > > > - performs a 16384 point FFT (real->complex) on each block, > > - modifies the data (the frequency spectrum) from the FFT, > > - performs an iFFT (complex->real) on the data, > > - shoves it into the output buffer, with an overlap of 25%, adding the new > > data to the already present data, > > - repeats the whole thing (with an offset of 4096 samples). > > > Obviously, the first FFT runs from samples 0..16383, the next one from > > sample 4096-20479, and so on. > > > The reason why I do this that way? Simple, I read it in a book ;-) > > What book? It needs a few pages ripped out.one thing Jerry, that for sure one does not Hann or Blackman window anything if they are using FFT/iFFT to do what we often call "fast convolution", but there are other transformations they do in the frequency domain (like phase-vocoder for time-scaling or pitch- shifting) where they do window the segments with a complementary Hann or something, FFT, do their thing in the frequency domain, iFFT, and overlap-add with the rising slope of the current frame overlapping the falling slope of the previous frame. this "overlap-add", which in and of itself is not a bad term for this operation, gets confused sometimes with the "overlap-add" of fast convolution. actually, it is not as efficient as OLA with a rectangular window, but you *could* use a complementary Hann (or some other complementary window) that is still no longer than N-L+1 (zero pad for the rest of L-1 samples so the FIR has room for "ringing" without wrapping in the circular FFT buffer), but you lose half of your frame hop distance (which becomes (N-L+1)/2) and nothing really to show for it. the cost of the frame is still the same. r b-j
Reply by ●February 26, 20072007-02-26
On 26 f=E9v, 14:48, "KlausS" <k...@stock-consulting.com> wrote:> Hi,Hi> > I have a simple application which > - continously ready samples at 96kHt sampling rate, > - chops it into blocks of, let's say, 16384 samples, > - multiplies each block with the Hann window function, > - performs a 16384 point FFT (real->complex) on each block, > - modifies the data (the frequency spectrum) from the FFT, > - performs an iFFT (complex->real) on the data, > - shoves it into the output buffer, with an overlap of 25%, adding the new > data to the already present data,You have two problem here. 1) You have applied a window function to your fft. You thus have to apply the "inverse windowing function" to your data before the ifft ! 2) Do you truncate your output signal in order to cancel the overlap effect ? In fact, you first compute the Short Time Fourier Transform (STFT) of your signal [1]. I think that you should use an inverse STFT in the last step of your application. If you use Matlab, have a look to the Matlab function called specgram.m (you can find it in the Signal Processing Toolbox) and its inverse function that you can find here : http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=3D= 4944 If it is not the case, you just will have to translate the m-code in the language you use. ;-)> - repeats the whole thing (with an offset of 4096 samples). > > [...] > > The reason why I do this that way? Simple, I read it in a book ;-)What is that book ?> > The application is supposed to split audio frequncies into different bands > (a classical crossover application) and (optionally) also to apply a > frequency response correction to the signal (a classical EQ). > > [...] > > So what's my problem? Well, I'd rathe rlike to use the Blackman window > function instead of the Hann ("Hanning") window function. However, while > it is obvious for me (I think) why the overlap-add method method works > with the Hann window, I have no idea which overlap is required for the > Blackman window. Can anybody enlighten me?If you apply a "good", i.e. with no bug, inverse STFT, you will be able to choose any overlap !> > Yup, I am a NOOB. Try to keep math away from me ;-) > > Thanks, and best regards, KlausHope this will help you. Matthieu [1] F. Hlawatsch, G.F. Boudreaux-Bartels: Linear and Quadratic Time- Frequency Signal Representations, IEEE SP Magazine, April 1992, pp. 21-67.
Reply by ●February 26, 20072007-02-26
Jerry Avins <jya@ieee.org> wrote in news:OoadnSZrAJXnbn_YnZ2dnUVZ_t7inZ2d@rcn.net:> NO! Not with overlap. How did this nonsense get started? It just won't > die!Isn't overlap, dentrending, and windowing central to the Welch periodogram technique? -- Scott Reverse name to reply
Reply by ●February 26, 20072007-02-26
robert bristow-johnson wrote:> On Feb 26, 9:49 am, Jerry Avins <j...@ieee.org> wrote: >> KlausS wrote: >> >>> I have a simple application which >>> - continously ready samples at 96kHt sampling rate, >>> - chops it into blocks of, let's say, 16384 samples, >>> - multiplies each block with the Hann window function, >> NO! Not with overlap. How did this nonsense get started? It just won't die! >> >>> - performs a 16384 point FFT (real->complex) on each block, >>> - modifies the data (the frequency spectrum) from the FFT, >>> - performs an iFFT (complex->real) on the data, >>> - shoves it into the output buffer, with an overlap of 25%, adding the new >>> data to the already present data, >>> - repeats the whole thing (with an offset of 4096 samples). >>> Obviously, the first FFT runs from samples 0..16383, the next one from >>> sample 4096-20479, and so on. >>> The reason why I do this that way? Simple, I read it in a book ;-) >> What book? It needs a few pages ripped out. > > one thing Jerry, that for sure one does not Hann or Blackman window > anything if they are using FFT/iFFT to do what we often call "fast > convolution", but there are other transformations they do in the > frequency domain (like phase-vocoder for time-scaling or pitch- > shifting) where they do window the segments with a complementary Hann > or something, FFT, do their thing in the frequency domain, iFFT, and > overlap-add with the rising slope of the current frame overlapping the > falling slope of the previous frame. this "overlap-add", which in and > of itself is not a bad term for this operation, gets confused > sometimes with the "overlap-add" of fast convolution. > > actually, it is not as efficient as OLA with a rectangular window, but > you *could* use a complementary Hann (or some other complementary > window) that is still no longer than N-L+1 (zero pad for the rest of > L-1 samples so the FIR has room for "ringing" without wrapping in the > circular FFT buffer), but you lose half of your frame hop distance > (which becomes (N-L+1)/2) and nothing really to show for it. the cost > of the frame is still the same.You can see from the rest of his post that he's filtering by fast convolution. That it can be made to work with a von Hann window (it's symmetrical about .5, offset) makes the idea that you need to window all the more pernicious. You can do it, but with needless cost. Bah! Humbug! Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●February 26, 20072007-02-26
Scott Seidman wrote:> Jerry Avins <jya@ieee.org> wrote in > news:OoadnSZrAJXnbn_YnZ2dnUVZ_t7inZ2d@rcn.net: > >> NO! Not with overlap. How did this nonsense get started? It just won't >> die! > > > Isn't overlap, dentrending, and windowing central to the Welch periodogram > technique?It isn't for fast convolution. Sauce for the goose isn't always good for the gander. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●February 26, 20072007-02-26
Jerry Avins <jya@ieee.org> wrote in news:XKOdnTqM5fzgln7YnZ2dnUVZ_trinZ2d@rcn.net:> Scott Seidman wrote: >> Jerry Avins <jya@ieee.org> wrote in >> news:OoadnSZrAJXnbn_YnZ2dnUVZ_t7inZ2d@rcn.net: >> >>> NO! Not with overlap. How did this nonsense get started? It just >>> won't die! >> >> >> Isn't overlap, dentrending, and windowing central to the Welch >> periodogram technique? > > It isn't for fast convolution. Sauce for the goose isn't always good > for the gander. > > JerryGotcha-- I missed the iFFT part. -- Scott Reverse name to reply
Reply by ●February 26, 20072007-02-26
"KlausS" <ks@stock-consulting.com> wrote in message news:LLadnYHpjPq2eH_YnZ2dnUVZ_oannZ2d@giganews.com...> Hi, > > I have a simple application which > - continously ready samples at 96kHt sampling rate, > - chops it into blocks of, let's say, 16384 samples, > - multiplies each block with the Hann window function, > - performs a 16384 point FFT (real->complex) on each block, > - modifies the data (the frequency spectrum) from the FFT, > - performs an iFFT (complex->real) on the data, > - shoves it into the output buffer, with an overlap of 25%, adding the newIndependent of whether using a window makes sense in your application, think of it this way perhaps: What if you didn't do the fft/filter/ifft part at all? Then you'd have a windowed version of the data that you want to add to subsequent delayed sequences that are also windowed. Presumably you want to get the same samples back again (as there is no filtering). How to do that? Assume that the record is all 1's. Now the exercise is to add the shifted windows together to get all 1's (representing the reconstructed overlapped windows). After the startup transient, all the window overlaps add to the same constant value. Window 1: 0 .25 .50 .75 1.0 .75 .50 .25 0 0 Window 2: 0 0 .25 .50 .75 1.0 .75 .50 .25 0 Window 3: 0 0 0 .25 .50 .75 1.0 .75 .50 .25 Window 4: 0 0 0 0 .25 .50 .75 1.0 .75 .50 Window 5: 0 0 0 0 0 .25 .50 .75 1.0 .75 Window 6: 0 0 0 0 0 0 .25 .50 .75 1.0 Window 7: 0 0 0 0 0 0 0 .25 .50 .75 Window 8: 0 0 0 0 0 0 0 0 .25 .50 Window 9: 0 0 0 0 0 0 0 0 0 .25 . Sum: 0 .25 .75 1.5 2.5 2.8 3.8 4.0 4.0 4.0 ....... In this case the windows fully overlapped always add to 4.0 which is also the integral of the window function i.e. sum of the samples. So, to normalize the result, divide somewhere in the process by the integral of the window function I do believe. The normalization is dependent on the amount of overlap of course. You should be able to construct this simple analysis for any window to convince yourself that it works. That is, what you're doing is independent of the window but not independent of whatever filtering you're doing. If it's independent of the window, then why use a window? I think that was Jerry's point..... Fred
Reply by ●February 26, 20072007-02-26
On Feb 26, 9:42 am, Scott Seidman <namdiestt...@mindspring.com> wrote:> Jerry Avins <j...@ieee.org> wrote innews:XKOdnTqM5fzgln7YnZ2dnUVZ_trinZ2d@rcn.net: > > > Scott Seidman wrote: > >> Jerry Avins <j...@ieee.org> wrote in > >>news:OoadnSZrAJXnbn_YnZ2dnUVZ_t7inZ2d@rcn.net: > > >>> NO! Not with overlap. How did this nonsense get started? It just > >>> won't die! > > >> Isn't overlap, dentrending, and windowing central to the Welch > >> periodogram technique? > > > It isn't for fast convolution. Sauce for the goose isn't always good > > for the gander. > > > Jerry > > Gotcha-- I missed the iFFT part. > > -- > Scott > Reverse name to replySome people seem to think that because their applications don't require windows, that they should tell others not to use windows. Windowing continues because some people have applications that should have windows. Fast convolution with a fixed pattern does not require windowing. But many people perform time varying fast convolution and want to minimize the blocking artifacts of the process. These people use windows with good effect, and may even use time varying windows. Some audio compression schemes transform data, determine a psychoacoustically based, data dependent convolution to apply, with many zeros allowing compressed storage and transmission and reconstitute at playback by inverse-transform--window--overlap-add. Windowing goes on because people use mp3 and other compression algorithms that use appropriate windows. A question for the original poster is: which 'Blackman' window do you mean and what do you think it will do for you? This answer might allow us to repond if windowing is appropriate for you or why not. Dale B. Dalrymple