(In addition to the below, the Audacity overlap/add also has some

mundane one-off bugs where the window it's using is the wrong size

by a single sample, etc).

On Wed, Sep 14, 2005 at 05:56:31PM -0400,

[hidden email] wrote:

> I think I am seeing from Dominic's response and your earlier post that the

> method of drawing an arbitrary curve in the frequency domain and then applying

> it to the FFT of the input signal and taking an IFFT does not work, at least

> for overlap-add and overlap-save methods. Is this true?

You can make it work very well, Audacity simply misses in

implementation.

If all you're doing is draw/multiply/overlap-add, you're missing two

additional necessary steps. These steps apply to both the drawn

frequency response as well as the PCM fram you're applying it to.

1) Multiplying in the frequency domain is a circular convolution in

the time domain. If there's no padding in the time-version of that

curve, you're mixing signal from the front of the frame into the end

of the frame and vice versa. Think of the frame being plotted on a

strip of paper; tape the end to the beginning to make a circular loop.

Now smuge it all up (what a convolution does); the end smudges into

the beginning and the beginning into the end.

2) If you are properly padding the signal, the beginning and end of

the original are discontinuous with the silence; there will be a

sudden stairstep into the signal and again when the signal ends. That

is, after padding the frequency response with silence in time, take it

back to frequency and look at it: not at all what you started with!

That can be 'corrected' by applying a good window to the non-zero

section of the time signal. Do that and re-transform to frequency;

you'll see now that the original drawn response has been smoothed a

bit, but otherwise maintains the desired response.

Padding and windowing must be applied to both the PCM signal and the

manufactured response. Naturally, one would do the actual

EQ/filtering in frequency, but the padding and windowing steps are

more easily approached in time.

A third caveat, which doesn't apply in this case but is a big deal if

you try to generalize this convolution approach: It doesn't work

correctly if your 'EQ curve' is changing from frame-to-frame. The

problem is this; we're building a fast linear infinite convolution out

of a finite circular convolution technique. The math is only correct

if what we're convolving by doesn't change from frame to frame (the EQ

curve must stay the same). If the 'EQ curve' changes from frame to

frame, our convolution is varying *by a regular frequency*, the size

of the window. We end up doing a frequency multiplication (actually,

we end up multiplying by a derivative of the window transfer

function). That causes aliasing and frequency shifts. This is why

you can't use this technique to build a fast compressor or other

things with a continuously varying filter response.

(JAMMIN', an early Jack utility for Linux, does multiband compression

this way because it's really really fast, even if the results are

poor. Run solo vocals through it and listen to what happens).

Monty

-------------------------------------------------------

SF.Net email is sponsored by:

Tame your development challenges with Apache's Geronimo App Server.

Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP. Click here to play:

http://sourceforge.net/geronimo.php_______________________________________________

Audacity-devel mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel