mad-dev August 2000

mad-dev@lists.mars.org

2 participants
4 discussions

Re: [mad-dev] MPEG audio decoder compliance
by Andre McCurdy 12 Sep '00

12 Sep '00

Rob, Interesting. If you have them, I would also be interested in figures for MAD which compare multiplies using FPM_64BIT, a version which truncates the LSBit (eg FPM_ARM), and FPM_APPROX. Thanks Andre -- ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie

3 2

MPEG audio decoder compliance
by Rob Leslie 18 Aug '00

18 Aug '00

I thought people might be interested in some results I'm putting together of tests for MPEG audio decoder accuracy. These are the same tests I wrote about some time ago, but now I have results for a much wider range of decoders, and across all three layers. MAD is still showing well, and is in fact the only decoder I am aware that will produce 24-bit output. The results are interesting: http://www.mars.org/home/rob/proj/mpeg/compliance/ Worth noting is that MAD is the only decoder in the class of integer decoders that can produce fully compliant output. Does anyone have any suggestions for decoders to test that are not listed? I would like to test the ARM decoder somehow, but I don't know if I can get access to it. Cheers, -rob

1 0

Layer3 III_imdct_l() in ARM Assembler.
by Andre McCurdy 16 Aug '00

16 Aug '00

Rob + others, Please find attached a version of the layer3 III_imdct_l() function I've written in ARM assembler. I've been messing around with it for a while, mainly as an exercise to learn ARM assembler, but hopefully the end result is worth sharing. Performance wise, it should be quite a bit faster than the current C version (and slightly more accurate as well since the multiply-accumulate steps accumulate into 64bits, then round back to 32bits only when finished). Unfortunately, I don't actually have any ARM based hardware that will play audio, so its only been tested standalone with a small range of test cases on the 'armulator' ARM simulator. Any feedback (especially overall performance) or bug reports from anyone actually able to test it for real would be appreciated. It assembles for me (using gcc v2.95.2) with just: arm-elf-gcc -c arm_III_imdct_l.S (making sure that the extension is .S rather then .s to cause gcc to run it though the C pre-processor). I'd appreciate some feedback, even if the performance increase isn't big enough to bother including it in future releases. Andre -- ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie

2 1

MAD 0.11.1b available
by Rob Leslie 04 Aug '00

04 Aug '00

I made a new release of MAD (0.11.1b) with the following changes: - the libmad code is now in a separate directory - the robustness of the Win32 audio output module is much improved - the SSO is now disabled by default, as output accuracy is deemed to be more important than speed in the general case - a bug in the Layer III sanity checking was fixed that could have caused a crash on certain random data input - the Layer III requantization table was extended from 8191 to 8206 values as some encoders are known to use these values, even though ISO/IEC 11172-3 suggests the maximum should be 8191 (and I couldn't convince anyone on the LAME mailing list that this could be a bug in LAME) - a short man page for madplay was added - a new `madtime' program (not yet built or installed by default) accurately calculates average bitrate and playing time for any file, including VBR - a new experimental multi-stream mixer `madmix' was added (--enable-experimental during configure to add -x option support for this to madplay) The experimental mixer code is designed to minimize CPU involvement in decoding multiple bitstreams; subband synthesis is performed only once after all the mixing has taken place on the intermediate decoded data. Here's an example usage: madmix <(madplay -Qx one.mp3) <(madplay -Qx two.mp3) Any number of input streams can be given on the command line to be mixed. You can also use the same -o option as for `madplay'. If your shell doesn't support process substitution with named pipes, you'll have to mess around and make them yourself. Currently the mix is fixed at 100% for all streams, but this can be adjusted on line 330 of madmix.c. I think there's potential for command-line or file-based configuration to further make this useful, or possibly even a GUI. As always, the release can be found here: ftp://ftp.mars.org/pub/mpeg/ Cheers, -rob

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 August 2000