DSPRelated.com
Forums

FIR filtering in the Fourier domain

Started by Philip de Groot July 8, 2005
"Philip de Groot" <groot877@zonnet.nl> wrote in message 
news:Xns9692B17C8595Agroot877zonnetnl@137.224.11.5...
> "Jon Harris" <jon99_harris7@hotmail.com> wrote in > news:v1aBe.73$LG4.42@trnddc04: > >> "Philip de Groot" <groot877@zonnet.nl> wrote in message >> news:Xns9692A07A07EC9groot877zonnetnl@137.224.11.5... >>> "Andor" <an2or@mailcircuit.com> wrote in >>> news:1121245285.319577.119480 >>> >>> I want to stabilize "speech" in broadcast recordings in real-time (FM >>> band). Therefore, the speech frequency range (800-6500 Hz) should be >>> amplified whereas the frequency regions that fall outside of this >>> should be reduced. Most importantly, the high frequencies should be >>> removed (to improve broadcasts that are somewhat difficult to >>> receive). Preferably without distorting the orginal audio signal to >>> much. That's my challenge. >> >> About your frequency range, speech, especially from male talkers, has >> significant energy in frequencies lower than 800 Hz. The common >> telephone specification keeps components down to 300 Hz. A bit lower >> is even better, maybe even down to 100-150 Hz to capture a deep-voiced >> talker. > > OK, thanks. I did not realise this...
This web page gives the frequency ranges of musical instruments and different singing voice types (bass, tenor, etc.) http://www.tnt-audio.com/topics/frequency_e.html
"Rune Allnor" <allnor@tele.ntnu.no> wrote in message 
news:1121293469.773673.204840@g43g2000cwa.googlegroups.com...
> >> I have noticed that keeping the lowest frequencies >> greatly improves the audio quality. But I do not quite understand why. > > This could be due to psycho acoustics, an expression that can be > interpreted in at least two ways. The properties of the human audio > perception system plays an at least as big part in this, as mere DSP.
I think it is simpler--he was filtering out frequencies with significant signal content. An earlier post indicated that he was filtering out everything below 800 Hz, whereas as Jerry and I pointed out, you want at go preserve at least down to 300 Hz even for telephone quality.
Hi jerry,

Winfilter allows to design FIR filters (BUTT, CHEB, BESS, RCOS and
RECT).

For the "Raised Cosined" and "Rectangle": The cosine transform is
applied to a rectangular or raised cosine window.

I know that BUTT, CHEB and BESS models are for IIR.
I wanted just to be able to implement a IIR frequency response "shape"
in a FIR filter.
In other word, the same frequency response, but with a linear phase.
For this case, I calculate the IIR frequency response and apply also
the cosine transform to get the time domain coefficients.

Jerry Avins <jya@ieee.org> wrote in news:XdWdnZKNppz230jfRVn-uw@rcn.net:

> Philip de Groot wrote: >> "Andor" <an2or@mailcircuit.com> wrote in >> news:1121245285.319577.119480 @g14g2000cwa.googlegroups.com: >> >> >>>Philip de Groot wrote: >>> >>>... >>> >>> >>>>I have used winfilter to create a FIR filter (including source >>>>code), but the result was awful. Worse than with the OLS Fourier >>>>filtering. >>> >>>There are two issues here that you should seperate: >>>1. FIR design >>>Use some program (winfilter, scopeFIR, matlab, scilab, ...) to >>>compute the filter coefficients according to your specifications. >>> >>>2. FIR implementation >>>Once you have the coefficients, you can implement the FIR either by >>>time domain convolution or by frequency domain multiplication. >>>Remember, these two methods are equivalent and, given some specific >>>filter and input signal, result in exactly the same (modulo some >>>numerical errors) output signal! >>>... >>> >>> >>>>Hopefully, the slow decrease in signal also prevents the occurrence >> >> of >> >>>>audible artifacts, which I suffered most. I started this whole >> >> exercise >> >>>>to get rid of them in the first place. >>> >>>The most common error that people who come here make is that they try >>>to correct some problem by using a algorithm of their design, find >> >> that >> >>>it doesn't work, and wonder why. It would be much more sensible to >>>state the problem and ask whether anybody here has designed an >>>algorithm that works to solve their problem (instead of going off and >>>trying to cook up some ad hoc solution). >>> >>>In this spirit I ask you: what are the artefacts that you wanted to >>>reduce in the first place? Why do you want to filter? >>> >>>Regards, >>>Andor >>> >>> >> >> >> Hello Andor, >> >> I want to stabilize "speech" in broadcast recordings in real-time (FM >> band). Therefore, the speech frequency range (800-6500 Hz) should be >> amplified whereas the frequency regions that fall outside of this >> should be reduced. Most importantly, the high frequencies should be >> removed (to improve broadcasts that are somewhat difficult to >> receive). Preferably without distorting the orginal audio signal to >> much. That's my challenge. > > There's a lot of misdirected hard work been done here. I trust that it > was at least educational. I;d like to add a bit to the education. > >> When I started this little project, I had never heard of software >> audio filters like FIR or IIR, but - due to my scientific background >> - I was aware of Fourier analysis and thought: well, if I want to get >> rid of undesired frequencies, simply take the fft, set the undesired >> frequencies on zero, and do a ifft. >> >> As you undoubtedly know, this approach does not work very well. This >> is why I started searching on the subject and - at first - wanted to >> stay with my nicely customized and highly C++-code optimized >> (inverse) Fourier transformations. I put a lot of effort in it... > > You have it now. It will be useful for something someday. (But I bet > that the free (but licensed) FFTW is faster.) > >> However, I read that time-domain filtering prevent the problem that I >> suffer. > > The simplest way, and sometimes the fastest way. Be aware that > FFT-multiply-IFFT can reproduce what a time-domain FIR does bit for > bit, but you have to do it right. > >> And when I tried the winfilter software and saw how simple it is >> to apply a fir-filter in the time domain, I decided that I might try >> to use the time domain as well. Furthermore, if the number of taps is >> sufficiently low, time domain filtering *might* outperform the >> frequency domain filtering. >> >> The reason why I have the audible artifacts is because I am using >> frame blocks of 1024 samples (actually: 2048 because it is stereo). >> In the Fourier transformations, the whole frame block is used which >> causes these ringing artifacts at the end of the frame blocks. This >> problem needs to be solved and I thought that overlap add (OLA) or >> overlap save (OLS) was the solution for these kind of problems. But >> it did not work out in my situation, but I have to add to this that I >> do not known whether this is due to "bad filtering" (I just set all >> undesired frequencies on 0) or due to the OLS algorithm that cannot >> fix it all (in theory it should). I have noticed that keeping the >> lowest frequencies greatly improves the audio quality. But I do not >> quite understand why. > > It certainly is "bad filtering". Whether you wrote OLS properly > remains to be known. You can test it by taking the FFT of an FIR > filter's coefficients (zero padded to the length of the working FFT) > and using it as the bin multipliers, not just zero and one as you > tried. Note that if you FFT the filter coefficients and your audio > data using decimation in time and do the IFFT using decimation in > frequency (or vice versa), you will need no bit-reversed addressing.) > >> Using a lowpass filter also means keeping the lowest frequenties. >> Therefore, I hope that the filter design that I proposed previously >> will finally work out. > > For really good and short FIR filters, read the paper, then download > and compile the software at http://www.cs.princeton.edu/~ken/meteor. > ScopeFIR is a lot easier and nearly as good. > > Two more comments: > > You shouldn't need over 100 taps for a band-pass filter, but 3 seems > much too low for a low-pass. A high-pass may be all you need anyway. > > Decent voice audio goes below 400 Hz. Telephones go down to 300, and > male voices sound noticeably more natural when the band goes down to > 200. > > Jerry
Hello Jerry, Thanks for all your suggestions, but one thing is not quite clear to me.
> Decent voice audio goes below 400 Hz. Telephones go down to 300, and > male voices sound noticeably more natural when the band goes down to > 200.
If I need to keep frequencies down to 400 Hz, why should I apply a highpass filter??? And about the Fourier algorithm I had implemented. It is not as fast as the FFTW (I guess; I haven't tried it because it is licensed), but the possibility to simultaneously FFT and IFFT the left and right channels compensates quite a lot. :) (It did work out; see my previous post). Thanks for the link to the paper and the software. I still have to read the paper (I think I MUST to get a proper filter). If not to difficult to implement (i.e. does not require too much time), I might use the source code to generate filters on-the-fly (and hear their effects on the audio immediately). It will definitely be fun to play with. For now, I will use ScopeFIR to design a more appropiate filter to try out. (the 3-taps filter I described yesterday did not work out; probably because I removed important frequencies, although the graph did not show this). Thanks, Philip
"Mark" <makolber@yahoo.com> wrote in news:1121284765.129095.97470
@o13g2000cwo.googlegroups.com:

> Try > > http://www.mds.com/ > > see QED design. > > It was very good for a beginner like me. > > Does FIR IIR etc. > > I am not associated with MDS in any way exepct that I have purchased > their product. > > > Mark >
Hello Mark, I already found (and installed) this software. It suggested a few thousand taps for the FIR filter I wanted to design. So I did not consider it further. Regards, Philip
Philip de Groot wrote:
...
> Hello Andor, > > I want to stabilize "speech" in broadcast recordings in real-time (FM > band). Therefore, the speech frequency range (800-6500 Hz) should be > amplified whereas the frequency regions that fall outside of this should > be reduced. Most importantly, the high frequencies should be removed (to > improve broadcasts that are somewhat difficult to receive). Preferably > without distorting the orginal audio signal to much. That's my > challenge.
As Jerry said, you have done lots of misdirected work. The best solution for your problem is using an IIR lowpass and highpass filter. They are very simple to implement and use only a fraction of the processing power needed by FIR. One usually choses FIR over IIR if the phase response of the filter is an issue or if you need extremely small transition bandwidths. Neither seems to be the case here. I would suggest a second order lowpass with a second order highpass in series (I know Jerry is going to ask "why not design a bandpass directly?" - the obvious answer is the flat frequency response in the pass band). To see how to compute the coefficients read the cookbook: http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt And here is an implementation in C++: http://www.musicdsp.org/files/CFxRbjFilter.h I would drop the FIR approach and concentrate on the IIR.
> However, I read that time-domain filtering prevent the problem that I > suffer.
Time domain and frequency domain implementation result in the same thing. It's like linear and log domain multiplication: a*b = Exp(log(a)-log(b)) You can transform the problem into another domain where its solution is simpler. Afterwards, you have to inverse transform back to get the answer. Your implementation of the frequency domain FIR was flawed, that's why you heard artefacts. From your post I gather at least two mistakes which resulted in time domain aliasing and a zero-phase filter.
> And when I tried the winfilter software and saw how simple it is > to apply a fir-filter in the time domain, I decided that I might try to > use the time domain as well. Furthermore, if the number of taps is > sufficiently low, time domain filtering *might* outperform the frequency > domain filtering.
That's correct.
> > The reason why I have the audible artifacts is because I am using frame > blocks of 1024 samples (actually: 2048 because it is stereo).
No. The reason why you had artefacts was that you didn't use the correct frame hop length, and that you used the magnitude response of the FIR filter instead of the (signed but real) frequency response. This resulted in the two errors that I mentioned above.
> In the > Fourier transformations, the whole frame block is used which causes > these ringing artifacts at the end of the frame blocks. This problem > needs to be solved and I thought that overlap add (OLA) or overlap save > (OLS) was the solution for these kind of problems. But it did not work > out in my situation, but I have to add to this that I do not known > whether this is due to "bad filtering" (I just set all undesired > frequencies on 0) or due to the OLS algorithm that cannot fix it all (in > theory it should).
The problem was that you didn't implement OLS correctly.
> Is this lap of text a bit clear to you?
Well, I hope that I could help a little. Regards, Andor
"Rune Allnor" <allnor@tele.ntnu.no> wrote in 
news:1121293469.773673.204840@g43g2000cwa.googlegroups.com:

> > > Philip de Groot wrote: >> "Andor" <an2or@mailcircuit.com> wrote in
news:1121245285.319577.119480
>> @g14g2000cwa.googlegroups.com: >> >> > Philip de Groot wrote: >> > >> > ... >> > >> >> I have used winfilter to create a FIR filter (including source
code),
>> >> but the result was awful. Worse than with the OLS Fourier
filtering.
>> > >> > There are two issues here that you should seperate: >> > 1. FIR design >> > Use some program (winfilter, scopeFIR, matlab, scilab, ...) to
compute
>> > the filter coefficients according to your specifications. >> > >> > 2. FIR implementation >> > Once you have the coefficients, you can implement the FIR either by >> > time domain convolution or by frequency domain multiplication. >> > Remember, these two methods are equivalent and, given some specific >> > filter and input signal, result in exactly the same (modulo some >> > numerical errors) output signal! >> > ... >> > >> >> Hopefully, the slow decrease in signal also prevents the
occurrence
>> of >> >> audible artifacts, which I suffered most. I started this whole >> exercise >> >> to get rid of them in the first place. >> > >> > The most common error that people who come here make is that they
try
>> > to correct some problem by using a algorithm of their design, find >> that >> > it doesn't work, and wonder why. It would be much more sensible to >> > state the problem and ask whether anybody here has designed an >> > algorithm that works to solve their problem (instead of going off
and
>> > trying to cook up some ad hoc solution). >> > >> > In this spirit I ask you: what are the artefacts that you wanted to >> > reduce in the first place? Why do you want to filter? >> > >> > Regards, >> > Andor >> > >> > >> >> Hello Andor, >> >> I want to stabilize "speech" in broadcast recordings in real-time (FM >> band). Therefore, the speech frequency range (800-6500 Hz) should be >> amplified whereas the frequency regions that fall outside of this
should
>> be reduced. Most importantly, the high frequencies should be removed
(to
>> improve broadcasts that are somewhat difficult to receive).
Preferably
>> without distorting the orginal audio signal to much. That's my >> challenge. >> >> When I started this little project, I had never heard of software
audio
>> filters like FIR or IIR, but - due to my scientific background - I
was
>> aware of Fourier analysis and thought: well, if I want to get rid of >> undesired frequencies, simply take the fft, set the undesired >> frequencies on zero, and do a ifft. >> >> As you undoubtedly know, this approach does not work very well. This
is
>> why I started searching on the subject and - at first - wanted to
stay
>> with my nicely customized and highly C++-code optimized (inverse) >> Fourier transformations. I put a lot of effort in it... > > Well, highly optimized (I)FFTs are nice tools, but even the best > hammer doesn't do much good where a saw is needed.
You're right. I found it out the hard way. Fortunately, I learned quite a lot of it.
> > The filtering problem you describe - as well as the solution - is a > common on one. The problem is that "setting the frequencies to 0" > doesn't work, since the DFT provides a disxcretely sampled spectrum, > and this approach leaves no control of the frequency components in > between the discrete coefficients. Which is why more elaborate > filter design algorithms have been designed. >
Hmmm, this is a feasible explanation. I hadn't considered this.
>> However, I read that time-domain filtering prevent the problem that I >> suffer. And when I tried the winfilter software and saw how simple it
is
>> to apply a fir-filter in the time domain, I decided that I might try
to
>> use the time domain as well. Furthermore, if the number of taps is >> sufficiently low, time domain filtering *might* outperform the
frequency
>> domain filtering. > > Perhaps. It depends on whether you are doing on-line (real-time) or > off-line processing. I would not be surprised if time-domain filtering > would be preferable for on-line filtering, due to easier
implementation
> and no artefacts due to block boundaries, as with the OLA and OLS > methods. >
I do on-line (real-time) filtering. Therefore, ease of implementation is not the critical criterium. The processor requirements, however, are.
>> The reason why I have the audible artifacts is because I am using
frame
>> blocks of 1024 samples (actually: 2048 because it is stereo). In the >> Fourier transformations, the whole frame block is used which causes >> these ringing artifacts at the end of the frame blocks. This problem >> needs to be solved and I thought that overlap add (OLA) or overlap
save
>> (OLS) was the solution for these kind of problems. But it did not
work
>> out in my situation, but I have to add to this that I do not known >> whether this is due to "bad filtering" (I just set all undesired >> frequencies on 0) or due to the OLS algorithm that cannot fix it all
(in
>> theory it should). > > Could be both. I have noted that there have been several threads here > on comp.dsp, where people who use OLA or OLS filtering have problems > with merging the blocks seamlessly. >
Hmmm, I think an additional filter needs to be applied between IFFt'ed frames to get rid of the artifacts. This complicates a real-time stream and is undesirable (I would say).
>> I have noticed that keeping the lowest frequencies >> greatly improves the audio quality. But I do not quite understand
why.
> > This could be due to psycho acoustics, an expression that can be > interpreted in at least two ways. The properties of the human audio > perception system plays an at least as big part in this, as mere DSP. >
You're right. It should sound nice...
>> Using a lowpass filter also means keeping the lowest frequenties. >> Therefore, I hope that the filter design that I proposed previously
will
>> finally work out. > > If you use your filtered signals as input to a broadcast system, I'd > expect the system to have some higher and lower cut-off frequencies. > You would probably want to tune your signal to the system. There is > an off chance that the interaction by a (relatively) broad-band signal > and a not-quite-as-broad-band transmission system might cause audible > artifacts, although I can't quite see how that would happen. It might > be wise to use some sort of band-pass filter, where you can control > (at least in the design stage) the upper and lower cut-off
frequencies.
>
The filtered signal *MIGHT* be input to a broadcast system. And yes, weird interaction effects might occur, but I would say that a broadcasting system should be able to handle (filtered) speech anyway. If problems occur, at least I know where it originates from.
> Rune >
Regards, Philip ------------ And now a word from our sponsor ------------------ Do your users want the best web-email gateway? Don't let your customers drift off to free webmail services install your own web gateway! -- See http://netwinsite.com/sponsor/sponsor_webmail.htm ----
"Clay S. Turner" <Physics@Bellsouth.net> wrote in
news:ej9Be.96260$du.58059@bignews1.bellsouth.net: 

> >> >> I have used winfilter to create a FIR filter (including source code), >> but the result was awful. Worse than with the OLS Fourier filtering. >> Therefore, I studied the ScopeFIR tutorial and tried the trial >> version (thanks for the tip Jerry) and learned quite a lot by doing >> so (I recommend it to everyone who is interested to start from the >> ScoreFIR tutorial. It is a good starting point!). I also learned that >> the filter I created in WinFilter was a faulty one (not enough taps >> and therefore the specifications were not properly met...). >> >> Off course, I started with a bandpass filter, but the number of taps >> to obtain a convenient filter was very high (179). The trial version >> won't show the coefficients, but executing real-time code with such a >> large number of taps is in general not a good idea. >> > > Hello Philip, > > My program will design such filters and output the coefficients and it > is free. See my earlier link for the program. Let me know if you have > any questions. > > Clay > >
Hello Clay, I tried your software out and obtained a filter with 21 taps. This should also be possible to obtain in ScopeFIR, but I haven't tried this out. It is nice to see that your DOS-application has been nicely written. It runs smoothly in WinXP and the graphical output is no problem. Thanks, Philip

Philip de Groot wrote:
> "Rune Allnor" <allnor@tele.ntnu.no> wrote in > news:1121293469.773673.204840@g43g2000cwa.googlegroups.com: > >> However, I read that time-domain filtering prevent the problem that I > >> suffer. And when I tried the winfilter software and saw how simple it > is > >> to apply a fir-filter in the time domain, I decided that I might try > to > >> use the time domain as well. Furthermore, if the number of taps is > >> sufficiently low, time domain filtering *might* outperform the > frequency > >> domain filtering. > > > > Perhaps. It depends on whether you are doing on-line (real-time) or > > off-line processing. I would not be surprised if time-domain filtering > > would be preferable for on-line filtering, due to easier > implementation > > and no artefacts due to block boundaries, as with the OLA and OLS > > methods. > > > > I do on-line (real-time) filtering. Therefore, ease of implementation is > not the critical criterium. The processor requirements, however, are.
I can't see that your application is approaching any extreme limits, what processing power is concerned. It ought to be possible to achieve this filtering with a 15th - 20th or so, order IIR bandpass filter. That's almost low enough for your PC main CPU to keep up with it in a real-time application (depending on how streamlined the data I/O is), a PC sound card would have no problems whatsoever to keep up with this. This solution might not do the job in the lowest possible number of flops, but that's (usually) not a requirememnt as long as the processor keeps up with the data flow. Some of my friends who deal with the acoustics of rooms, started talking about FIR filters with 100000 (hundred thousand) or more coefficients for the room impulse response. I understood them to believe these kinds of filters can be implemented in real time with CD quality data. Of course, this would require quite powerful DSP chips and would be expensive, but apparently, this is possible. In my experience, it's often better to have something simple that works well enough, than something optimal (i.e. complicated) that works only marginally better or faster. Unless one is pushing the limits, one does not need the optimal solution. There are, of course, good reasons for wanting to use an optimal solution anyway (getting experience with "non-standard" methods would be a very good such reason), but one should make sure to have the non-optimal solution as backup, if attempting this. Rune
then that means your  filter specs may be too agressive....

ease up on the passband ripple or stop band ripple or whatever is
appropriate for your application.

did you enter the correct sampling rate and bandwidth...

if you ask it a hard question, it gives you a hard answer

Mark