[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.
Rob Leslie rob@mars.org wrote:
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.
Would it perhaps be better to clip at less than full scale during requantisation ?? This would reduce the chance of overflow in the IMDCT routine (which potentially corrupts far more data).
Andre --
__________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
On Friday, March 21, 2003, at 11:43 PM, Andre wrote:
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.
Would it perhaps be better to clip at less than full scale during requantisation ?? This would reduce the chance of overflow in the IMDCT routine (which potentially corrupts far more data).
There are many reasons not to. Subband samples above full scale may just as well be canceled during IMDCT rather than overflow. Also the mere time required to check each sample would affect performance.
I intentionally avoid clipping at any point during the decoding process so that the decision to clip can be left to the application. That's why I leave 3 dB of headroom in the PCM sample format, so signals slightly above full scale can still be accurately represented.
In any case, I've never seen samples wildly beyond full scale occur in practice. The actual signal described by the test bitstream in question is nearly 18 dB above full scale. That bitstream is synthetic, and I doubt any real signal (with 0 dB maximum peak) could be encoded in such a way as to peak anywhere near 18 dB when decoded.
Hi Rob,
Rob Leslie rob@mars.org wrote:
On Friday, March 21, 2003, at 11:43 PM, Andre wrote:
Would it perhaps be better to clip at less than full scale during requantisation ?? This would reduce the chance of overflow in the IMDCT routine (which potentially corrupts far more data).
There are many reasons not to. Subband samples above full scale may just as well be canceled during IMDCT rather than overflow.
Each value returned by III_requantize is used multiple times within the imdct. Although the chance of an individual addition/subtraction overflowing is 50:50, the chance of an overflow happening at some point is much higher.
Also the mere time required to check each sample would affect performance.
III_requantize checks each value for overflow already ?!? My suggestion was simply to clip values caught by this test to a slightly lower level. Performance cost is zero.
diff -ruN mad-0.14.2b_orig/libmad/layer3.c mad-0.14.2b/libmad/layer3.c --- mad-0.14.2b_orig/libmad/layer3.c Thu Nov 8 15:28:02 2001 +++ mad-0.14.2b/libmad/layer3.c Tue Mar 25 15:21:12 2003 @@ -910,7 +910,7 @@ fprintf(stderr, "requantize overflow (%f * 2^%d)\n", mad_f_todouble(requantized), exp); # endif - requantized = MAD_F_MAX; + requantized = MAD_F_MAX / 2; } else requantized <<= exp;
In any case, I've never seen samples wildly beyond full scale occur in practice.
I'm sure I had a version of Lame from about a year ago which produced streams which regularly caused III_requantize to clip ('value' was always 1 when clipping occurred, but 'exp' was way off in the clouds somewhere). I don't know if more recent versions of Lame have fixed the bug or not...
Andre --
__________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Hi Andre,
Also the mere time required to check each sample would affect performance.
III_requantize checks each value for overflow already ?!? My suggestion was simply to clip values caught by this test to a slightly lower level. Performance cost is zero.
diff -ruN mad-0.14.2b_orig/libmad/layer3.c mad-0.14.2b/libmad/layer3.c --- mad-0.14.2b_orig/libmad/layer3.c Thu Nov 8 15:28:02 2001 +++ mad-0.14.2b/libmad/layer3.c Tue Mar 25 15:21:12 2003 @@ -910,7 +910,7 @@ fprintf(stderr, "requantize overflow (%f * 2^%d)\n", mad_f_todouble(requantized), exp); # endif
requantized = MAD_F_MAX;
requantized = MAD_F_MAX / 2;
Ah, I misunderstood. Good point.
There is another problem here too, in that a negative overflow value is replaced with a positive one.
In any case, I've never seen samples wildly beyond full scale occur in practice.
I'm sure I had a version of Lame from about a year ago which produced streams which regularly caused III_requantize to clip ('value' was always 1 when clipping occurred, but 'exp' was way off in the clouds somewhere). I don't know if more recent versions of Lame have fixed the bug or not...
Do you have any sample streams with this problem?
Cheers, -rob
-
Andre -
Rob Leslie