ist death?
----- Original Message ----- From: mad-dev-request@lists.mars.org To: mad-dev@lists.mars.org Sent: Saturday, March 22, 2003 3:25 PM Subject: mad-dev digest, Vol 1 #243 - 2 msgs
Send mad-dev mailing list submissions to mad-dev@lists.mars.org
To subscribe or unsubscribe via the World Wide Web, visit http://www.mars.org/bin/mailman/listinfo/mad-dev or, via email, send a message with subject or body 'help' to mad-dev-request@lists.mars.org
You can reach the person managing the list at mad-dev-admin@lists.mars.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of mad-dev digest..."
Today's Topics:
- Re: [mad-user] mad output tested for iso-compliance (Rob Leslie)
- Re: mad output tested for iso-compliance (=?iso-8859-1?q?Andre?=)
--__--__--
Message: 1 Date: Fri, 21 Mar 2003 23:20:18 -0800 Reply-To: mad-dev@lists.mars.org Cc: mad-dev@lists.mars.org To: mad-user@lists.mars.org From: Rob Leslie rob@mars.org Subject: [mad-dev] Re: [mad-user] mad output tested for iso-compliance
[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
--__--__--
Message: 2 Date: Sat, 22 Mar 2003 07:43:31 +0000 (GMT) From: =?iso-8859-1?q?Andre?= armccurdy@yahoo.co.uk Subject: Re: [mad-dev] mad output tested for iso-compliance To: mad-dev@lists.mars.org
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
End of mad-dev Digest
-
nordin david