mad-dev

mad-dev@lists.mars.org

682 discussions

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

libmad for 68k w/ CodeWarrior
by Boris Raicheff 28 Feb '03

28 Feb '03

Hi there I tried to compile libmad & minimad for Motorola 68k target using CodeWarrior. Everything went fine, it compiled without problems (except a few warnings about uninitialized variables). I wrote a simple decoder which takes an mp3-file and decodes it into a .raw file (using madlld as a reference). The output is AWFUL, the song is just about recognisable, but sounds noisy, and has a very strange distortion effect applied to it - it sounds like its played underwater. I digged deeply in the source but unfortunately I couldn't find what the problem is. The README says the source is not endianess-sensitive, what am I doing wrong? Any help will be greatly appreciated. - Boris _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

standalone ARM version of MAD
by J.A.O.Netterville-00＠student.lboro.ac.uk 12 Feb '03

12 Feb '03

Hi there I'm a student here at Loughborough university in the UK. Every year, people taking my degree have to take a course where we have to make an ARM AEB1 (with ARM7DI core) turn magically into an MP3 player. Of course, it's a rubbish MP3 player, but nonetheless we have to do it to get marks. Questions: 1) I am trying to use the arm-elf-*** set of tools both under Linux RH7.2 and Cygwin. I have no idea where the cygwin tools came from, but I can trace back the heritage of the arm-elf-*** tools under linux to the guy at uni who installed them. Which system would you guys recommend I use to do the development, bearing in mind the cygwin machine is my home machine and the linux machine is not on a network and only has a floppy drive and a CD drive. 2) Aside from the above recommendation, I have been playing with the configure script under both systems, but I am a little shakey in my knowledge of what it does exactly. Could someone explain it's precise function (or an approximation of it, any way) 3) With respect to my playing around with ./configure, I am having problems getting it to recognise my cross compiler both under Linux AND Cygwin. I know enough about configure to know that it's going to try to detect gcc, the type of host etc., and take some parameters/options which help it build a makefile for my target. So, when I do shell$ CC=/usr/local/bin/arm-elf-gcc ./configure --target=arm-elf I get this in config.log: configure:744: checking for a BSD compatible install configure:797: checking whether build environment is sane configure:854: checking whether make sets ${MAKE} configure:900: checking for working aclocal configure:913: checking for working autoconf configure:926: checking for working automake configure:939: checking for working autoheader configure:952: checking for working makeinfo configure:980: checking host system type configure:1005: checking for gcc configure:1118: checking whether the C compiler (gcc ) works configure:1134: gcc -o conftest conftest.c 1>&5 /usr/local/arm-elf/bin/ld: cannot open crt0.o: No such file or directory collect2: ld returned 1 exit status configure: failed program was: #line 1129 "configure" #include "confdefs.h" main(){return(0);} I copied across the crt0.o file I have (full of ARM assembly) to the directory where I am running configure, and the error progresses to ...SNIP configure:952: checking for working makeinfo configure:980: checking host system type configure:1005: checking for gcc configure:1118: checking whether the C compiler (gcc ) works configure:1134: gcc -o conftest conftest.c 1>&5 /usr/local/arm-elf/bin/ld: cannot find -lc collect2: ld returned 1 exit status configure: failed program was: #line 1129 "configure" #include "confdefs.h" main(){return(0);} I am no expert in these matters, but if someone could point me in the right direction, I'd be appreciative. I know that copying across the compiler runtime object file (crt0.o) into the same directory as configure isn't going to be the fix, but I just did it to debug what's going on, and it looks like when my arm- elf-*** tools are compiling anywhere but in a subdirectory of themselves, it doesn't know where it's files are. regards Alex *************************************************************************** Alex Netterville. Student - Third Year - Electronics and Software Engineering (MEng) Loughborough University

1 0

Problems with ARM using GCC 3.2 (and 3.2.1)
by Jeff Mock 18 Jan '03

18 Jan '03

I'm having some problems with libmad running on ARM using GCC-3.2. I verified that I have the same problems with GCC-3.2.1, but I'm using GCC-3.2 for most of this. My GCC is built for armv4 architecture, I'm running on a Cirrus ARM7 part. I've worked through the issues enough to sort out my problems, but I would like to get to the bottom of the problem if anyone has insights. Built as released in 0.14.2b with gcc-3.2 (or gcc-3.2.1), the decoder produces odd sounding artifacts in typical layer-3 MP3 files. It sounds to me like some sort of aliases of high frequencies and lower frequencies sound fine, but I'm no expert in this sort of thing. Let's just say it sounds weird. If I change the optimization of layer3.c from the default "-O" to "-O2" the decoder behaves correctly and nicely decodes MP3s. To make things a little more complicated, if synth.c is changed from "-O" to "-O2", the text segment of synth.o gets quite a bit larger and the performance of the decoder degrades to the point where a 128kbps 44.1k layer3 MP3 no longer decode in real-time on a 74MHz ARM7tdmi. Bleh. With "-O2" the dct32() routine in synth.c blows up into a lot more code that I have a difficult time understanding. It seems to put a large number of loads and stores at the beginning and end of the routine that doesn't make sense to me. Anyway, for things to work properly it seems that layer3.c needs to be "-O2" and synth.c needs to be "-O". Okay, I've now done a little more refinement on this problem and it seems that the problems with both synth.c and layer3.c are related to the optimization option "-fschedule-insns". layer3.c must have the option -fschedule-insns (which is included by default with -O2), and synth.c must not have -fschedule-insns. So, my workaround is to change the default optimization in libmab to "-O2" and twiddle the makefile to add the option "-fno-schedule-insns" to synth.c. If anyone has any similar experiences or ideas, please let me know. jeff

2 1

how to get time when play a mp3 using libmad
by Zhiwen Yang 31 Dec '02

31 Dec '02

who can tell me how to get the time when i play a mp3 file using libmad ? which function can i use ?

2 1

Merry Christmas & a Query ;-)
by kaiwei 20 Dec '02

20 Dec '02

Hiya, I'm not sure if you guys have been reading the hydrogen audio forums but there's currently a promising player in dev call foobar2000. it's by Peter, of winamp's directsound output fame. Anyway, he just released an SDK http://foobar2000.hydrogenaudio.org/ would it be difficult to port MAD over to it? kaiwei

1 0

Mad winamp plugin bug
by Robert K Marlton 14 Dec '02

14 Dec '02

Sorry to post twice in a row, but I've now got a more specific question. I've been looking at the mad winamp plugin source code, and I've worked out what causes the bug. When winamp tells the plugin to seek it basically calculates a file position to seek to by doing:- (seekpos / song length) * (filelength). This works with CBR files but not with VBR files as they have different data rates throughout the files. I assume that the mad library seeks correctly and I would like to be able to use it to do the seeking with the winamp plugin (as my alternative would be to cludge it by reading frames from the beginning of the file until I got to the right time). Any pointers on what functions I could use in the library?

2 1

Mad winamp plugin bug
by Robert K Marlton 12 Dec '02

12 Dec '02

The mad plugin for winamp stops reporting the correct time after seeking in a VBR file. The time reported is normally about a couple of seconds too low (that is if you have lyrics playing along to the music, the lyrics are shown before they are played). Has anybody got any idea what might be causing this problem or know of a quick and dirty fix I can do to the mad winamp plugin source to fix it? The problem only occurs after a certain amount in to the file (and if you seek before this point, it's still in sync, seeking afterwards though it starts reporting wrong times again). It occurs regardless of the setting of fast playing time in the plugin configuration, regardless of whether xing or lame was used to encode the file and regardless of if the file contains a VBR header. If anybody wants to try and fix this, I can send them a sample lyrics file and a sample mp3 to test it against.

1 0

← Newer
1
...
35
36
37
38
39
40
41
...
69
Older →

Jump to page:

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