mad-dev-request@lists.mars.org mentioned:
Could be, but in my experience even something as simple as:
signed int MAD_SimpleScale( mad_fixed_t sample ) { // Round sample += ( 1L << (MAD_F_FRACBITS - 16) ) ;
// Clip if ( sample >= MAD_F_ONE ) sample = MAD_F_ONE - 1 ; else if ( sample < -MAD_F_ONE ) sample = -MAD_F_ONE ;
// Quantise return sample >> (MAD_F_FRACBITS + 1 - 16) ; }
... already produces nice results. If you forget about the clipping though, the quality s#cks! I'm not sure, but I believe the standard mad-example 'forgets' the clipping. (Could be wrong though!) I don't know what minimad.c uses ...
If that is not it, check the compiler settings. Some very agressive optimisations may cause rounding-errors, although this usually occures with floating point numbers, and MAD's strength is that it doesn't use them ...
I know, I'm just quessing, but maybe this helps somehow.
Regards,
Armin
Dear Armin,
Thanks for your information. I've check the scale function in minimad.c and it's the same as the one you mentioned. And I 've tried several ways to change the compiler flags, but still no work. I used dist10 decoder to generate another PCM raw data with the same demo.mp3 I also used Sound Forge to analyze these two PCM raw data. The one generated by minimad seems to be overflow in sample value, the maximum and minimun value are -32768 and 32768 (2^16). Any hint about this ?
I can email to statistic information to you if you'd like. Thnaks in advance.
Yeh You-Ying