mad-dev March 2003

mad-dev@lists.mars.org

5 participants
4 discussions

Odd noise output from libmad
by Robert John Shepherd 29 Mar '03

29 Mar '03

Hi all, Having problems with libmad, which I've been porting to the GP32 (ARM) so it can have a decent MP3 player, and am currently developing it using the Win32 SDK. So this isn't an ARM issue (but I may have those in the near future :) ). Using code taken from minimad.c as an example, I've got it reading and decoding mp3 streams but the resulting 16bit data (after using the supplied downsample routine) is flooded by static (or maybe its just so saturated?). It is recognisable (just) as the source, but it sounds like my Spectrum did when it shouted Ghostbusters all those years ago. I've tried swapping the high/low bits round and its not that, as this results in unrecognisable noise. Have also tried replacing the sample routine with a simple 16bit shift but that gives the same result. The version of libmad afaik is 0.14.2b if that makes a difference. Any help would be appreciated. Yours Unwhettedly, Robert John Shepherd. Technical Director DVD REVIEWER The UK's BIGGEST Online DVD Magazine http://www.dvd.reviewer.co.uk For a copy of my Public PGP key, email: pgp(a)robertsworld.org.uk

1 0

MAD_ERROR_BADHUFFDATA
by Fernando Ortiz 28 Mar '03

28 Mar '03

Hi... Does anyone know the cause of this error (MAD_ERROR_BADHUFFDATA)? Is it documented anywhere? Thanks a lot Fernando

2 1

Re: [mad-user] mad output tested for iso-compliance
by Rob Leslie 26 Mar '03

26 Mar '03

[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(a)mars.org

2 4

Re: mad-dev digest, Vol 1 #243 - 2 msgs
by nordin david 23 Mar '03

23 Mar '03

ist death? ----- Original Message ----- From: <mad-dev-request(a)lists.mars.org> To: <mad-dev(a)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(a)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(a)lists.mars.org > > You can reach the person managing the list at > mad-dev-admin(a)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: > > 1. Re: [mad-user] mad output tested for iso-compliance (Rob Leslie) > 2. 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(a)lists.mars.org > Cc: mad-dev(a)lists.mars.org > To: mad-user(a)lists.mars.org > From: Rob Leslie <rob(a)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(a)mars.org > > > --__--__-- > > Message: 2 > Date: Sat, 22 Mar 2003 07:43:31 +0000 (GMT) > From: =?iso-8859-1?q?Andre?= <armccurdy(a)yahoo.co.uk> > Subject: Re: [mad-dev] mad output tested for iso-compliance > To: mad-dev(a)lists.mars.org > > Rob Leslie <rob(a)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 >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

mad-dev March 2003