Bandfilters with FFT on Sampled in-/output

On Jun 24, 3:35&#4294967295;am, "basgoossen" <bas@n_o_s_p_a_m.2dive.nl> wrote:
> Thanks everybody for the answers,
>
> The matlab code mentionned is not something i use but an example of
> overlap-save progressing found on this forum. I implement the source in
> Java so i can't use the matlab's filter function ;-).
>
> For now i have got rid of 99% of the filter artifacts, my current approach
> is to use a buffer size that is twice the requested buffer size and use
> only the middle portion of the processed buffer to write the output. Since
> the chunks are only 20ms that adds a delay of roughly 5ms, which is
> acceptable in the application.
>

Bas,

is the impulse response or transfer function of your filter static or
is it changing?

FYI, there are two, slightly different, techniques both called
"overlap-add" or OLA.  one is for use with more esoteric algorithms
where the spectrum is often modified in a more sophisticated manner
than just a static FIR filter.  could be time-varying filtering or
compression or a phase vocoder or some kinda sinusoidal modeling.  in
this technique, you will likely use some kind of overlapping and
complementary windows, like the Hann window.  depending on what you
are doing, there may be zero padding in addition to the windowing.
the frame hop is half of the width of the complementary window.  there
*could* be artifacts because of framing (and whatever nasty thing your
algorithm is doing to the spectrum), even if you employ this OLA
properly.

the other OLA technique is for implementing "fast convolution" and is
the alternative to "overlap-save" or OLS.  in both of these cases,
your window is rectangular.  in OLS, it is essentially no-window (the
rectangular window width is the entire frame of data) and in OLA, the
rectangular window width is no larger than N-L+1 where N is the FFT
length and L is the FIR length.  in both cases, the frame hop is no
more than N-L+1 samples.  in both cases, the transfer function, H[k],
must be the DFT of an impulse response, h[n], that is finite (as in
"FIR") in length and with length L which should be quite a bit smaller
than N.  it can't be any ol' H[k] if you want to avoid artifacts at
the frame boundaries.  if h[n] is non-zero only for 0 <= n < L, and if
you do your OLS or OLA correctly, there should be *no* artifacts at
the frame boundaries (assuming no numerical issues because of
insufficient word width).  but if you dial in whatever H[k] your heart
desires (without guaranteeing that the length of h[n] is limited to L)
and use this technique, *even* in the static case, you can get
artifacts at the frontier between frames.

as with the time-variant case of OLA, there is no reason you cannot
change the H[k] between frames (but h[n] still must be limited in
length to L samples) in the "fast convolution" case, but you may very
well get artifacts at the frame boundaries.  you can get *click*
artifacts using OLS and changing H[k] (between adjacent frames) and a
somewhat better transition between frames using OLA.

r b-j