Re[2]: 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 better
RL> fixed-point multiplication in the last step that happens to yield the
RL> 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]