Just a clarification: I didn't meant that the fft you done is not optimal,
but that 1024 is perhaps not optimal
Gabriel Bouvigne - France
[EMAIL PROTECTED]
icq: 12138873
MP3' Tech: www.mp3tech.org
----- Message d'origine -----
De : Gabriel Bouvigne <[EMAIL PROTECTED]>
� : <[EMAIL PROTECTED]>
Envoy� : lundi 24 mai 1999 01:10
Objet : Re: [MP3 ENCODER] misc questions
> I'm not so sure that this 1024 points fft is optimal. I don't trust much
> dist10 about the fft. After all, the original one was even computing
> imaginary part, even if it's totally useless in our case.
>
> A thing that I don't understand is how a 1024 points fft can be used for
> 1152 samples.
>
>
> And what about using KLT?
>
>
> Gabriel Bouvigne - France
> [EMAIL PROTECTED]
> icq: 12138873
>
> MP3' Tech: www.mp3tech.org
>
> ----- Message d'origine -----
> De : James (Jasha) Droppo <[EMAIL PROTECTED]>
> � : <[EMAIL PROTECTED]>
> Envoy� : lundi 24 mai 1999 00:41
> Objet : Re: [MP3 ENCODER] misc questions
>
>
> > Chris Matrakidis writes:
> > >
> > > > What about using the FFTW package instead of our fft. Perhaps it
can
> be
> > > > faster? Perhaps Chris got an indication about this?
> > >
> > > The fft we have is quite fast and simple. There are faster ones (FFTW
> is one of
> > > the fastest as far as I know), but I the one I used was one of the
> fastest and
> > > simplest I could find and the only one that produced a binary
identical
> mp3
> > > file with the original fft.
> > > --
> > > MP3 ENCODER mailing list
> >
> > The split-radix FFT that was "lifted" from Rico Malvar's book has "the
> > lowest number of [real] multiplications and additions among all FFT
> > algorithms [for N=2^k] known to date [1992]".
> >
> > If we assume that statement is accurate, then the only way to get a
> > better FFT for N=2^k is to encode it more efficiently. That is, reduce
> > the necessary shuffling of inputs and outputs, and/or re-organize the
> > code to reduce cache misses, and/or make sure the processor's FPU
> > pipeline doesn't "stall". Unfortunately, I don't have the expertise to
> > do this. I just have enough knowledge to write the second sentence in
> > this paragraph.
> >
> > I'm currently working on implementing a N=4^k algorithm which can be
> > up to twice as fast as the N=2^k algorithm. Lucky us, 256=4^4, and
> > 1024=4^5.
> >
> > --
> > James 'Jasha' Garnet Droppo III [EMAIL PROTECTED]
> > Interactive Systems Design Lab ISDL:(206)543-7298
> > Department of Electrical Engineering, University of Washington
> > http://isdl.ee.washington.edu/isdl/jdroppo/
> >
> > --
> > MP3 ENCODER mailing list
> >
>
> --
> MP3 ENCODER mailing list
>
--
MP3 ENCODER mailing list
