From: MartynS<haw@ao...>  20050823 01:13:18
Attachments:
Message as HTML

Dominic I will pass this on to students and see if I can get any takers. Martyn In a message dated 22/08/2005 05:55:35 GMT Standard Time, dominic@... writes: Martyn, Right now the easiest way to achieve an FIR or IIR filter if you know the coefficients is using Nyquist. And note that some of the effects (Bass Boost, for example) is really just an FIR filter. However, I would love to see a unified "Filter" effect that takes over the jobs of the current FFT Filter and Equalizer, and gives the user the option of FFT, FIR, or IIR. Here are some specific milestones that could lead towards that goal: 1. How about a very basic class to apply an FIR or IIR filter to a stream of samples, something like this: class Filter { Filter(bool iir, int num_coefs, float *coefs); void Reset(); void Apply(int len, float *samples); } Note that the samples should be "streamed", i.e. I should get the same result if I pass the samples one at a time or all in a chunk. Also note that the FIR case is really just a convolution. I'm not sure how IIR relates to convolution. Anyway, a basic convolution function can be optimized by 23x over naive code using, e.g. SSE or AltiVec, which could be a fun project. 2. Next, how about trivially reimplementing Bass Boost to make use of this? 3. Write an effect that automatically computes FIR or IIR coefficients given a graphical frequency envelope (e.g. from the FFT Filter effect)  I think you can do this using the first few coefficients of an IFFT. The user chooses the number of coefficients, of course. Add an interface that lets the user see the frequency response of the filter (which will differ from what they drew, especially with few coefficients). When you get close to step #3, let's work together on some screenshot mockups for how a unified Filter dialog would work. I'm envisioning something that would have a lot of power, but would hide most of the advanced options by default, providing a list of predefined filters.  Dominic MartynShaw@... wrote: > Hi all > > I notice that there are no FIR or IIR filters available in Audacity (or > have I just missed them in a menus somewhere?). Would this be useful > functionality to be added? I could put it up as a student project and > see if there are any takers. > > For those not familiar with FIR and IIR filters, they are filters that > do not have the same problems that FFT methods do with pre and post echo > (this is not closely related to the bug that I dealt with) and more > closely relate to analogue filters that we are familiar with on 'normal' > analogue mixing desks. I believe that a lot of other programs (such as > CoolEdit) have them. > > Do you have any other suggestions for functions that I could get > students involved in? > > Martyn >  SF.Net email is Sponsored by the Better Software Conference & EXPO September 1922, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & PlanDriven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Audacitydevel mailing list Audacitydevel@... https://lists.sourceforge.net/lists/listinfo/audacitydevel 
From: MartynS<haw@ao...>  20050906 00:06:01
Attachments:
Message as HTML

Monty True that FFT filters have a finite impulse response, True that IIR filters have their own limitations. However if you look in a textbook, you will find FIR and IIR filters in a different section to FFT filters as they behave quite differently; FFT filters have a preecho effect whereas (conventionally speaking) FIR and IIR filters don't. FFT filters work on a block of samples whereas (conventional) FIR and IIR filters go along on a sample by sample basis. Your point is...? Martyn In a message dated 05/09/2005 09:09:25 GMT Standard Time, xiphmont@... writes: On Sun, Aug 21, 2005 at 08:09:51PM 0400, MartynShaw@... wrote: > For those not familiar with FIR and IIR filters, they are filters that do > not have the same problems that FFT methods do with pre and post echo (this is > not closely related to the bug that I dealt with) An FFT filter *is* an FIR filter. And IIR filters have their own limitations :) Not to say they're not useful! Monty  SF.Net email is Sponsored by the Better Software Conference & EXPO September 1922, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & PlanDriven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Audacitydevel mailing list Audacitydevel@... https://lists.sourceforge.net/lists/listinfo/audacitydevel 
From: <xiphmont@xi...>  20050908 05:51:44

On Mon, Sep 05, 2005 at 08:05:42PM 0400, MartynShaw@... wrote: > > Monty > > True that FFT filters have a finite impulse response, True that IIR filters > have their own limitations. However if you look in a textbook, you will find > FIR and IIR filters in a different section to FFT filters as they behave > quite differently; FFT filters have a preecho effect whereas (conventionally > speaking) FIR and IIR filters don't. Not true. FFT filters need not 'preecho' and FIR filters may have a 'preecho' reaction. The implementation distinction makes some sense in the analog electronics world, but in the digital world, the distinction is entirely artificial. The math is 100% equivalent unless the coefficients of the filter are changing. Nearly all digital FIR filters are actually implemented as FFT filters (faster convolution). There is no difference whatsoever in the output. Monty 
From: MartynS<haw@ao...>  20050914 00:44:51
Attachments:
Message as HTML

Monty OK, so I was wrong about FFT filters. Please pardon my ignorance and arrogance. I have been reading up on overlapadd and overlapsave methods and working through simple examples and I can see how they are equivalent to 'traditional' implementations of FIR filters (but I haven't actually implemented one). I can also see how FFT methods may be faster, depending on the block size and implementation architecture. My reading has related to taking the padding of both x(n) and h(n) in the time domain but my question is, when H is specified in the frequency domain, what is the relevance/equivalent of the padding? And how, if at all, does this relate to the 'lapped windows' that are being used in the current Audacity equaliser? Can you recommend any text books or papers where I can read up on this? TTFN Martyn In a message dated 08/09/2005 06:52:24 GMT Standard Time, xiphmont@... writes: On Mon, Sep 05, 2005 at 08:05:42PM 0400, MartynShaw@... wrote: > > Monty > > True that FFT filters have a finite impulse response, True that IIR filters > have their own limitations. However if you look in a textbook, you will find > FIR and IIR filters in a different section to FFT filters as they behave > quite differently; FFT filters have a preecho effect whereas (conventionally > speaking) FIR and IIR filters don't. Not true. FFT filters need not 'preecho' and FIR filters may have a 'preecho' reaction. The implementation distinction makes some sense in the analog electronics world, but in the digital world, the distinction is entirely artificial. The math is 100% equivalent unless the coefficients of the filter are changing. Nearly all digital FIR filters are actually implemented as FFT filters (faster convolution). There is no difference whatsoever in the output. Monty  SF.Net email is Sponsored by the Better Software Conference & EXPO September 1922, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & PlanDriven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Audacitydevel mailing list Audacitydevel@... https://lists.sourceforge.net/lists/listinfo/audacitydevel 
From: <xiphmont@xi...>  20050914 04:52:01

On Tue, Sep 13, 2005 at 08:44:34PM 0400, MartynShaw@... wrote: > > Monty > > OK, so I was wrong about FFT filters. No worries :) > I have been reading up on overlapadd and overlapsave methods and working > through simple examples and I can see how they are equivalent to 'traditional' > implementations of FIR filters (but I haven't actually implemented one). I > can also see how FFT methods may be faster, depending on the block size and > implementation architecture. > > My reading has related to taking the padding of both x(n) and h(n) in the > time domain but my question is, when H is specified in the frequency domain, > what is the relevance/equivalent of the padding? Not sure what you mean; when doing FIRequivalent work with H, the padding in the time domain generally causes smoothing of H (where H is magnitude, leaving out phase). The padding can be centered around zero or not; H will be the same, but the phase will change. > And how, if at all, does this > relate to the 'lapped windows' that are being used in the current Audacity > equaliser? I'm not sure what you mean; they're inextricably intertwined. > Can you recommend any text books or papers where I can read up on this? Are you interested in the lapping or the behavior of specific windows? Monty 
From: Dominic Mazzoni <dominic@au...>  20050914 06:37:11

Martyn, A few things that might help in your understanding: 1. Any FIR filter can be computed exactly using FFTs, aside from issues of numerical precision. Audacity uses singleprecision for almost everything, and this tends to cause problems with FFT sizes above 2048. I can't remember, but I think that IIR filters can't be computed this way. 2. Audacity's FFT filter, when the user creates an arbitrary filter shape, usually does not correspond to any actual FIR filter. Short length FIR filters are often more "stable" and more smooth in their effect on the audio 3. Your best source for more information is probably a signal processing textbook, rather than a paper. I couldn't find a good website at first glance.  Dominic On Sep 13, 2005, at 9:50 PM, Monty wrote: > > > > On Tue, Sep 13, 2005 at 08:44:34PM 0400, MartynShaw@... wrote: > >> >> Monty >> >> OK, so I was wrong about FFT filters. >> > > No worries :) > > >> I have been reading up on overlapadd and overlapsave methods >> and working >> through simple examples and I can see how they are equivalent to >> 'traditional' >> implementations of FIR filters (but I haven't actually >> implemented one). I >> can also see how FFT methods may be faster, depending on the >> block size and >> implementation architecture. >> >> My reading has related to taking the padding of both x(n) and h(n) >> in the >> time domain but my question is, when H is specified in the >> frequency domain, >> what is the relevance/equivalent of the padding? >> > > Not sure what you mean; when doing FIRequivalent work with H, the > padding in the time domain generally causes smoothing of H (where > H is magnitude, leaving out phase). The padding can be centered > around zero or not; H will be the same, but the phase will change. > > >> And how, if at all, does this >> relate to the 'lapped windows' that are being used in the current >> Audacity >> equaliser? >> > > I'm not sure what you mean; they're inextricably intertwined. > > >> Can you recommend any text books or papers where I can read up on >> this? >> > > Are you interested in the lapping or the behavior of specific windows? > > 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 > _______________________________________________ > Audacitydevel mailing list > Audacitydevel@... > https://lists.sourceforge.net/lists/listinfo/audacitydevel > 
From: MartynS<haw@ao...>  20050914 21:39:38
Attachments:
Message as HTML

Dominic Thanks for this. A further question then, since I have not made myself very clear perhaps ... > 2. Audacity's FFT filter, when the user creates an arbitrary filter > shape, usually does not correspond to any actual FIR filter. Short > length FIR filters are often more "stable" and more smooth in their > effect on the audio ... This is one of the bits I'm having trouble with. If we took the IFFT of the arbitrary filter shape, we would get a time domain function but it would (most probably) not have the appropriate zero padding to avoid polluting the 'other end' of the result, due to the circular convolution. I believe that is what Monty meant by 'Similarly, the frequencydomain transfer response function (mFilterFunc) is not being smoothed, truncated or padded in time and as such is going to exhibit both nasty timedomain ringing and an abrupt truncation at the edges of the lapping window. This also contributes to the timedomain wrapping problem above.' back on 7/7/2005. However the method used 'seems' reasonable. Is this an illusion, or am I missing something? Martyn 
From: MartynS<haw@ao...>  20050914 21:56:44
Attachments:
Message as HTML

Monty Thanks for this. One or two more questions, if I may. > Not sure what you mean; when doing FIRequivalent work with H, the > padding in the time domain generally causes smoothing of H (where > H is magnitude, leaving out phase). The padding can be centered > around zero or not; H will be the same, but the phase will change. 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 overlapadd and overlapsave methods. Is this true? > > And how, if at all, does this > > relate to the 'lapped windows' that are being used in the current Audacity > > equaliser? > > I'm not sure what you mean; they're inextricably intertwined. I was referring to the way the Filter function is used in Audacity. EffectEqualization::ProcessOne seems to take the data in windowSize samples at a time, do Filter (which includes applying the Hanning window to the timedomain data) and then add the result into the output, overlapping the samples with the previous output by 50% of windowSize. I had kindof assumed that the Hanning window was to smooth out end effects but it obviously also affects the filter response as well. Is it there for a good reason, do you think? I must admit that I could not follow what you meant back in July about it causing frequency modulation  how does that occur? Martyn 
From: <xiphmont@xi...>  20050921 22:51:03

(In addition to the below, the Audacity overlap/add also has some mundane oneoff 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, MartynShaw@... 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 overlapadd and overlapsave methods. Is this true? You can make it work very well, Audacity simply misses in implementation. If all you're doing is draw/multiply/overlapadd, 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 timeversion 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 nonzero section of the time signal. Do that and retransform 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 frametoframe. 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 