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

[Michael Niedermayer]

Hi

On Sun, Jul 15, 2007 at 05:00:04PM -0400, Marc Hoffman wrote:
> 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;

you can, but there will be audible artifacts if you do things with 16bit
(that is assuming you have average ears, good headphones and listen to
the correct thing, it wont be audible with every random sample)

... i of course dont know if cook is high enough quality for this to matter
but with our mp3 decoder using 16bit internally just sounds bad with some
mp3s, and for that 16bit is used just for some parts, not even the whole
transform IIRC
you coul of course follow a similar path and use CONFIG_MPEGAUDIO_HP
so the user can decide if they want high quality or high speed and
quality similar to 5 year old hw mp3 players

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070716/64030e74/attachment.pgp>