FFT and EQ

Hello,

I have a short question for you.

I am working with blocks of audiosamples which will be calculated like this.
Audiosamples-in -> windowing -> FFT -> iFFT -> windowing ->
Audiosamples-out.
This works fine. I.e. the result of audiosamples-out after all is like the
starting point audiosamples-in.

Now, I want to build up a FFT EQ. I thought that I just simple set the
calculated real and imaginary part to "0" (for the frequency I
don't want to
hear) and let it calculated back with the iFFT. The result is what I expected
but there are some strange noises in the result...
I think this way is to easy and wrong.

So, I am asking you which point(s) I forgot to think about.
	Thanx,
Micha.
	

Hi,

I think the noise you are hearing is a "blocking artifact". Try using
overlapped windows. This should solve your problem.

regards
Ragh
  -----Original Message-----
  From: audiodsp@audi... [mailto:audiodsp@audi...]On Behalf
Of 2spork@2spo...
  Sent: Thursday, October 20, 2005 2:14 PM
  To: audiodsp@audi...
  Subject: [audiodsp] FFT and EQ
	  Hello,

  I have a short question for you.

  I am working with blocks of audiosamples which will be calculated like
this.
  Audiosamples-in -> windowing -> FFT -> iFFT -> windowing ->
Audiosamples-out.
  This works fine. I.e. the result of audiosamples-out after all is like the
  starting point audiosamples-in.

  Now, I want to build up a FFT EQ. I thought that I just simple set the
  calculated real and imaginary part to "0" (for the frequency I
don't want
to
  hear) and let it calculated back with the iFFT. The result is what I
expected
  but there are some strange noises in the result...
  I think this way is to easy and wrong.

  So, I am asking you which point(s) I forgot to think about.
	  Thanx,
  Micha.
	

The FFT/IFFT method for EQ requires more DSP computational power.
You can try time-domain filtering method.
The EQ filter is calculated from IFFT calculation.
You needs to perform IFFT while the EQ spectrum changes.
Regards,
Nick
	--- Raghavendra C V <raghu@ragh...> G
	---------------------------------
Hi,

I think the noise you are hearing is a "blocking artifact". Try using
overlapped windows. This should solve your problem.

regards
Ragh
  -----Original Message-----
  From: audiodsp@audi... [mailto:audiodsp@audi...]On Behalf
Of 2spork@2spo...
  Sent: Thursday, October 20, 2005 2:14 PM
  To: audiodsp@audi...
  Subject: [audiodsp] FFT and EQ
	  Hello,

  I have a short question for you.

  I am working with blocks of audiosamples which will be calculated like
this.
  Audiosamples-in -> windowing -> FFT -> iFFT -> windowing ->
Audiosamples-out.
  This works fine. I.e. the result of audiosamples-out after all is like the
  starting point audiosamples-in.

  Now, I want to build up a FFT EQ. I thought that I just simple set the
  calculated real and imaginary part to "0" (for the frequency I
don't want
to
  hear) and let it calculated back with the iFFT. The result is what I
expected
  but there are some strange noises in the result...
  I think this way is to easy and wrong.

  So, I am asking you which point(s) I forgot to think about.
	  Thanx,
  Micha.
	

Hello,

Thanx for getting back to me...
Your answers gave me many answer and new questions :-)

I have to go one step back and I hope you're with me...

I realised that I'm only working with a "Rectangle" Window and I
started to
implement "Overlapping Windows 50% with Hann". Am I correct to build
it up like
this...? My callback is always waiting for 4 Samples (to simplify it).
I get samples "1234", hann-window, FFT, iFFT and hann-window-back
them. I catch
the calculated iFFT samples "12". Then I get the new "5678"
samples. I take
"3456" and do the calculation again. Now I catch "34" and
return the new
calculated "1234" back. And so on...
-> Is this correct?
	Thanx again,
Micha.
	

From: <2spork@2spo...>

> My callback is always waiting for 4 Samples (to
simplify it).
> I get samples "1234", hann-window, FFT, iFFT and hann-
> window-back them. I catch the calculated iFFT samples "12".
> Then I get the new "5678" samples. I take "3456" and do
the
> calculation again. Now I catch "34" and return the new
> calculated "1234" back. And so on...

There are several issues with what you describe. First, when you
convolve a block of N samples with a filter whose impulse
response has length K, the result is N+K-1 samples long. So you
need to zero-pad input blocks to the next larger power of two, P
say, to keep the response tail from wrapping back into the
beginning of the buffer upon IFFT. Here is the overlap-add
process:

1. there is the tail [z1 ... z(P-N)] from previous block (see
below)
2. get input and window, giving [a1 ... aN]
3. pad with P-N zeros to [a1 ... aN 0 0 ... 0]
4. FFT, multiply, IFFT giving [b1 ... bP]
5. output [b1+z1 ... bN+zN]
6. store [b(N+1)+z(N+1) ... b(P-N)+z(P-N) b(P-N+1) ... bP]
   to act as z values for next block.

Second is the way to specify the filter spectrum. The above
implies that you must ensure it corresponds to a short enough
impulse response. You must also take the phase response into
account -- IFFT a lowpass spectrum with values 0 and 1 only to
see what the problem is. The simplest way to satisfy both points
is to set up a response in the time domain, pad it to length P,
and FFT to get what goes into step 4 above. That response, in
turn, might be a "windowed sinc" (google that, the first hit is a
good starting point) with the desired bandwidth, modulated with a
sinusoid at the band-center frequency.

Third, FFT convolution only becomes more efficient than
time-domain convolution from moderate block sizes upwards, i.e.,
a couple dozen to a couple hundred samples per transform. This is
one influence on the choice of N and K. Another factor is that
the transition band gets narrower in the windowed-sinc method the
larger K is; generally, more stringent specifications become
feasible. Finally, the processing latency is N samples for data
acquiry, plus the time from the beginning of the impulse response
to its main peak. For linear-phase filters such as windowed sincs
the latter is K/2 samples.
	Martin
	

Sorry Micha, my previous email first said something I then took
out, failing to make all necessary changes, so the filtering
process decription got out of sync with the prose. What I decided
to omit was that windowing is not needed for filtering as such
but only for smooth transition between blocks treated with
different response parameters. If there will be little online
tweaking and you can accept a click at the affected block
boundary, you do not need a window. Note that in any case, the
IFFT output is never windowed in filtering, though it is in
(re-)synthesis.

If you decide you need it, let N be the window length and M <= N
the hop size. Then the process is this:

1. from previous block, there are the input segment
   [y1 ... y(N-M)] and the tail [z1 ... z(P-M)]
2. append M new inputs to y and window, giving [a1 ... aN]
3. pad with P-N zeros to [a1 ... aN 0 0 ... 0]
4. FFT, multiply, IFFT giving [b1 ... bP]
5. output [b1+z1 ... bM+zM]
6. for next block, replace y with [y(M+1) ... yN] and z with
   [b(M+1)+z(M+1) ... b(P-M)+z(P-M) b(P-M+1) ... bP].

When M = N this yields the description I gave before, so that did
correctly describe filtering with a rectangular window.
	Martin