Hi,
>> - multiplies each block with the Hann window function,
>NO! Not with overlap. How did this nonsense get started? It just won't
die!
<snip>
>> The reason why I do this that way? Simple, I read it in a book ;-)
> What book? It needs a few pages ripped out.
Sorry, I was a bit inaccurate there; it wasn't a printed book but
something I read on the Internet - took me a while to remember where I
read it, and then quite a bit longer to find it again. Here it is:
http://crca.ucsd.edu/~msp/techniques/latest/book-html/node172.html
> It isn't for fast convolution.
I never heard "fast convolution" before, but it *might* be what I'm trying
to accomplish. "Ordinary convolution" is, if I recall this correctly, the
process of multiplying an impulse response with every sample from the
input (and summing up the results from the individual samples). I would
have done this in favor of the FFT/iFFT approach which I described in the
original post, but the required length of the impulse response (aka the
filter kernel, if my memory serves me well) would have meant much too many
multiplies-and-adds (target platform is an ordinary PC, not a DSP). So I
tried an FFT/modify/iFFT approach instead. Is that approach "fast
convolutiuon", or is it something else?
>Some 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
I guess there must be a reason for windows; otherwise, there wouldn't be
soo many of 'em to choose from.
In my case, windowing seemed to be what I needed (from my newbie point of
view), since I process the data in blocks. I remember that an FFT always
considers the data as periodic. If I truncate a wave right in the middle
(which is likely to happen and the beginning and the end of the block), I
get harmonics. Yes, there is an approach which pads the block with zeros
at both sides, but this still resultzs in unwanted harmonic content - and
it does, as far as I can tell, not invalidate the idea of windowing (since
this approach is just a sort of rectangular window...).
> 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!
As far as I can see, windowing would not be needed if the added harmonic
content would cancel itself again during the iFFT stage. my math goes so
far that I believe that this is the case if I pass the result from FFT
back to the iFFT without any modification. However, I do modify the
spectrum between FFT and iFFT. Is the modification irrelevant, or does it
f*** up the signal beyond recognition?
>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.
Hm, I didn't know that where diifferent Blackmans. Or Blackmen? :-) I
mean, apart from Blackman-Harris and whatever. Okay, a quick search
revealed http://www.eng.vt.edu/me5714/textbook/windows.pdf - which indeed
lists Blackman and Exact Blackman. And I have no idea which one I want.
The reason for me asking about the Blackman windiow was I once saw a
comparision of different window functions, and how they affect things in
the frequency domain. The Blackman window appeared to have a better
stopband attenuation than the Hann window, while still not causing too
much other harm, so it appeared to me as a choice which I might prefer.
However, as I now have found the above mentioned paper, other questions
arise...
1. The paper has a table with a column "overlap correlation", for both a
50% and 75% overlap. Does this mean that, in practise, only two overlap
intervals are used? Are the values, which appear in these columns, the
"exactness" with which the recombination of the overlapping windowed
blocks works?
2. Am I using a Hann window with alpha=1 or with alpha=2 ("Hann squared")?
May seem to be a dumb question, but I apply the Hann window twice (before
FFT and after iFFT), so I guess that it might be that I'm performing some
sort of squaring to the window function which might be not totally obvious
to a newbie like me.
3. The table has a column "side lobe fall off (db/Oct)". Does that
correspond to the maximum attainable filter slope in my audio signal
application? In other words, if I choose a triangle window and filter a
signal by zeroing all frequencies below 1000 Hz (in the complex data,
which I have between FFT and iFFT step), that at 500 Hz the signal will be
only -12dB down? And with a rectangular window only -6dB? Or am I just
getting something wrong there?
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 ?
> 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 :
<snip>
I do not have Matlab, and it appears that the Matlab website is currently
experiencing a problem with my registration, so I can't get to the code
right now :-(
> If it is not the case, you just will have to translate the m-code in
the language you use. ;-)
My language is called "newbie babble" ;-)
> If you apply a "good", i.e. with no bug, inverse STFT, you will be
> able to choose any overlap !
I use the FFTW library (the precompiled version, so I'm sure that I didn't
break anything during compilation :-)), so errors can creep in only in my
choice of windowing or in the general concept (well, I guess I got the
complex*real multiplication in the frquency domain right...not so
difficult, I think).
> So, to normalize the result, divide somewhere in the process by the
integral
> of the window function I do believe.
Correct, I figured that out already, but didn't mention it in my
description. Without that normalization, the output signal is indeed +12dB
higher than the input signal. I measured only the peaks, though. One of my
concern is that the window adds some kind of modulation (AM) to the
resulting signal, despite overlapping, especially if the window function
does not add up to 100% (or 400%) after overlapping at each sample. Or are
all window function designed in way that this is always ensured? (I guess
my last question proves that I'm indeed a "math noob"...butter I think
it's better to ask than to stay a noob (or idiot)).
Best regards, Klaus