Hi all,
I'm really happy that LAME 3 has sparked a lot of input: keep those
patches coming! :)
I have more ideas than I have time, so I'll just unload them on the
mailing list so that they're out in the open... (Jan is this mailing list
archived somewhere?)
Mark wrote
> Another good patch! Chris Matrikidis send me a replacement for
> subs.c. It replaces the FFT with a Hartley transform, (bit for bit
Can someone do a short tech discussion on the Hartley Transform (Fast Hartley
Transform FHT). I remember vaguely that it has something to do with "easier"
computations to do the FHT and then a "twiddle" to convert the output to that
of an equivalent FFT. But info that i've seen says that the best real valued
FFT will *always* be better than the best FHT. See either of the following for
example:
http://www.jjj.de/fxt/fftnote.txt
http://x30.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=106197033&CONTEXT=926668604.122
7227221&hitnum=7 (or do a dejanews keywords search for "fast hartley
transform fft sorenson" this has some good references)
So I was wondering whether we can find an even faster FFT to replace this
faster FHT :)
> identical answers though) and makes the overall code 20% faster on a
> Sun Ultra 30. (10% faster on my PII 266). The code is also much
> simpler.
Simple? Who wants simple? I want faaaaast :)
> http://www.geocities.com/ResearchTriangle/8869/fft_summary.html
These page seems to indicate that FFTW may also be a good way to go for general
FFTs on different platforms. Someone want to work on an FFTW switch at compile
time?
Another idea: approximate FFTs! Do we *need* accurate FFTs in order to do all
the calculations? Would less accurate, but faster, FFTs do the job? Saw an
article in the ICAASP proceedings about doing apporoximate FFTs with wavelets.
The more wavelet iterations you do, the more accurate the FFT. Something to
think about.
Other things people may want to think about
- configure script
- install script
- proper WAV support
later
mike
