# [FFmpeg-devel] PATCH: COOK audio decode infastructure to support fixpoint optimization

Marc Hoffman mmhoffm
Sun Jul 15 23:00:04 CEST 2007

```On 7/15/07, Marc Hoffman <mmhoffm at gmail.com> wrote:
>
>
>
> On 7/15/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> >
> > Hi
> >
> > On Sun, Jul 15, 2007 at 07:59:22PM +0200, Benjamin Larsson wrote:
> > [...]
> > > > I guess you might be correct. Initially I was thinking we might be
> > able to
> > > > use 16-bit ints to represent the signal and not 32-bits.  I'm still
> > not sure
> > > > if the implementation requires the higher precision to be maintained
> > does
> > > > anyone know if the algorithm requires the 24bits?
> > > >
> > >
> > > Well what I meant was that I don't think 16 bits is enough for the
> > > transform step to keep a good enough precision. So if 32 bits is
> > needed
> > > in the transform step then why not use 32bits in all the calculations
> > > for simplicity.
> >
> > the general rule of thumb is that a n point decorrelation transform
> > needs
> > log2(n)/2 bits more for the values in the frequency domain than in the
> > time domain
> >
> > so 16bit is definitly not enough if you have 16bit audio
>
>
> Agreed. so whats your take on 16bit phase factors?
>

However, you can scale each of the add subs, so that you lose some precision
to eliminate overflow and obtain reasonable results.

Something like this would lose log(n)-bits of precision for  n  point fft.

tr        = (X[k2*2]*wwr - X[k2*2+1]*wwi + 0x4000)>>15;
ti        = (X[k2*2]*wwi + X[k2*2+1]*wwr + 0x4000)>>15;

X[k2*2]   = (X[k*2]   - tr)>>1;
X[k2*2+1] = (X[k*2+1] - ti)>>1;

X[k*2]    = (X[k*2]   + tr)>>1;
X[k*2+1]  = (X[k*2+1] + ti)>>1;

```