RE: Re[2]: III_requantize() accuracy

"Tony Francis" <[email protected]>
Newsgroups gmane.comp.audio.mad.devel
Message-ID <[email protected]>
Hello Gregory,

 With 16 bit implementation on TI55x how much accuracy you got? And how much accuracy improvement was there by changing the multiplication into 4.28 by 1.31 instead of 4.28 by 4.28 used in MAD decoder?

 I am not very sure whether a floating point version of MAD is there, but if not what about creating one? Some RISC processors have fpu now and it may be of interest for some.

Cheers,
Tony

 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Grigory A.
Sent: Thursday, March 25, 2004 7:06 AM
To: Rob Leslie
Cc: [email protected]
Subject: Re[2]: [mad-dev] III_requantize() accuracy


Hello Rob,

Wednesday, March 24, 2004, 7:12:59 PM, you wrote:
RL> Keeping in mind that 2^(-36.75) = 2^(-36) ? 2^(-3/4), you will find 
RL> that III_requantize(210, -147) calculates:

RL>               210^(4/3)    ? 0x04e0393e ? 2^12
RL>    0x04e0393e ? 2^(-36+12) ? 0x00000005
RL>                 2^(-3/4)   ? 0x09837f05
RL>    0x00000005 ? 0x09837f05 ? 0x00000002

RL> I think the difference is due to rounding errors from the limited
RL> precision of the fixed-point type. You're talking about a difference of
RL> 3.725e-9, pretty insignificant in the grand scheme of things.

RL> If you configure with --enable-accuracy, you'll get a slightly 
RL> better fixed-point multiplication in the last step that happens to 
RL> yield the value you were expecting.

Yes I am agree. Only one difference in my calculation scheme I firs multiply on root - in this case 2^(-3/4) and next rounding and shifting. This small changes give more precise result.

And why I am talking about it. Now I am "porting" MAD 0.15 to 3DSP platform www.3dsp.com this is 32 bits dsp with 32x32 multiplier - so I am expect good result.

Now at my decoder differences after III_requantize() are +-1  only - but at synthesis time sbsamples have +-25 with average rms ~1.2e-8 compare to MAD. My calculation is performed in 4.28x1.31 format - so error coming from this last bit in 4.28 representation of Xr data.

And - I have working "MAD" decoder for TI tms320vc55xx series dsp - but it is 16 bits implementation - so only limited accuracy and some time even worst :). If some one need - I can send it. Later I will publish it on web.



-- 
Best regards,
 Grigory                            mailto:[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.