[This message is more appropriate for mad-dev; I have set the Reply-To header accordingly.]
On Friday, March 21, 2003, at 11:13 PM, Praseetha K K wrote:
I would like to know if anybody has done a testing of MAD decoder output for MPEG1 iso-streams and compared them with the standard iso decoder(l3dec) output.
I find that si_huff.bit(this is an iso-stream) shows a difference from iso decoder o/p in the frames 4,5 and 6.Possibly it could be in the tables or in implementaion of huffmann in MAD.
If anybody has already cleared out thsi problem, please help.
This bitstream was created synthetically, and is meant to test the Huffman decoder. I have verified that MAD correctly decodes all of the Huffman data by comparing the output of 'l3dec -dhu' with MAD's internal data.
The reason you find a difference in the PCM output has to do with the fact that the synthetically created Huffman data in turn causes overflow conditions in the subsequent IMDCT calculations due to MAD's limited fixed-point representation. This representation is limited to fractional numbers in the range [-8.0, +8.0). Normal full-scale values are in the range [-1.0, +1.0).
If you examine the output PCM values, you'll find a number of continuous values at full-scale, 7fffff and 800000, indicating that clipping has occurred. In fact, the actual signal is nearly 18 dB above full-scale. This kind of signal nevers occurs in practice. Remember full-scale is 0 dB, and anything above this will be clipped, i.e. distorted.
I would take the si_huff bitstream for what it's worth: testing the Huffman decoder. The only bitstream whose PCM output must match within tolerance to be compliant is the compl.bit stream. The other bitstreams do help to detect potential problems, but they are only informative, not normative.