Hello,
I am trying to compile Madlib for PalmOS.Since Palm OS has the 68K limitation I removed last 20 entires from the rq_table.dat.Will this work w/o these entires,atleast a garbage output. Secondly the program is compiling now bu constantly crashes in the 'III_huffdecode' function.Can someone please help me I dont know whther I am doing the right thing or not.
Regards, Swapnil
Hello Swapnil,
Actually you can totally remove table and use simple calculation algorithm to make re-quantization.
32K table vs simple calculation. For sure table works faster but in case of calculation their relative weight in overall resource consumption is negligible.
simple explanation of calculation algorithm - we need: X = is^(4/3)*2^exp - it can be represented as: X = (1-x)^(4/3)*2^(int_exp)*2^(fract_exp)
(1-x)^(4/3) can be calculated by using Taylor approximation approximately 18-19 step is enough to achieve Q4.28 precision in worst case of x
*2^(int_exp) - it is just shift *2^(fract_exp) - it means only one multiplication on value from table { 2^(-0.25), 2^(-0.50), 2^(-0.75) }
in result: - completely remove 32K table - result with same precision - negligible increase of calculation - (I think less then 0.1%)
I use such method in my implementation of MAD for TI 55xx DSP so algorithm exists in 55xx dsp asm and it works well.
I think in future version of MAD there is no reason to use table for re-quantization process. Just put small routine on C instead.
About your III_huffdecode() problem - check carefully bit order in bit-field structure. It is compiler specific - in my case (of TI DSP) I had to reorder bit order in macros which describes haffman words in tables. You can compare memory (there table is) on your PC and on your PalmOS - they have to be same.
On Aug 18, 2005, at 2:21 AM, Swapnil Wagle wrote:
I am trying to compile Madlib for PalmOS.Since Palm OS hasthe 68K limitation I removed last 20 entires from the rq_table.dat.Will this work w/o these entires,atleast a garbage output.
There is another possibility in addition to Grigory's suggestion, although it will result in reduced accuracy.
The table size can be reduced from 32K to 4K by exploiting the following equality:
(8 x)^(4/3) = 16 x^(4/3)
Specifically, when x ≥ 1024, x^(4/3) can be calculated by:
16 (x/8)^(4/3)
Thus the table size can be reduced to 4K (for entries 0-1023), at the expense of a loss of audio quality due to the error introduced by the integer division.
-
Grigory A. -
Rob Leslie -
Swapnil Wagle