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