mad-dev November 2000

mad-dev@lists.mars.org

7 participants
8 discussions

dithering
by Gabriel Bouvigne 28 Nov '00

28 Nov '00

I thinked again about the dithering stuff. Dithering is usefull when we normalized, mixed, or subquantized the audio. In the case of mp3, we done a subquantization. But this subquantization was not done in the time space, but in the frequency space. That's what make me think that dithering could be better used if applied in the frequency space. But of course a constant dithering factor over a granule would a totaly useless effect, as it wouldn't change over the granule duration. So I think that this should be done in the frequency space, but on time periods a lot shorter than a granule. Does anyone have any opinion about this? Do you think it makes sense? Would it be feasible? Regards, -- Gabriel Bouvigne - France bouvigne(a)mp3-tech.org mobile phone: gsm(a)mp3-tech.org icq: 12138873 MP3' Tech: www.mp3-tech.org

1 0

autoconf problem with mad-0.12.2b
by Jason R. Mastaler 28 Nov '00

28 Nov '00

Are there any autoconf gurus out there that can figure out why mad can't handle certain CFLAGS invocations properly? For example, try the following in the mad-0.12.2b source directory: $ env CFLAGS="-O1 -O2" ./configure configure will eventually crash with something like this: checking for gcc... (cached) gcc checking whether the C compiler (gcc 2 ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. configure: error: ./configure failed for libmad Removing the first `-O1' fixes it, but this should not be necessary since gcc should pick up the latter. >From gcc(1): "If you use multiple -O options, with or without level numbers, the last such option is the one that is effective." Further, this isn't a problem on several other autoconf driven packages I tested this with. Thanks.

1 0

MAD 0.12.2b available
by Rob Leslie 20 Nov '00

20 Nov '00

For anyone who wasn't paying attention, I released 0.12.1b a few days ago, but I decided there were a few more improvements I could make before this announcement, thus 0.12.2b. Highlights of this release include: - source for a Winamp plug-in - resolved MS+I stereo issue (no more OPT_ISKLUGE) - FreeBSD sound compatibility fixes - updated Winamp extensions to the ID3 genre list - Croatian, Norwegian, and Spanish translations for madplay - new ABX testing script - libmad API changes - bug fixes In addition, this release includes several performance enhancements: - rearranged the synthesis polyphase filterbank memory vector for better locality of reference - new combination of compiler optimization flags - some miscellaneous layer3.c changes - rewrote the audio PCM packing routines These changes have resulted in a drop from 53MHz to 50MHz CPU usage requirement on my StrongARM 1100 test platform. Unfortunately this release breaks Andre's requantization optimization patch, but I've put together a revised patch that can be applied cleanly to 0.12.2b. With Andre's patch included, CPU usage further drops to 49MHz on my SA-1100. The release is available here: ftp://ftp.mars.org/pub/mpeg/ Andre's modified patch is here: ftp://ftp.mars.org/pub/mpeg/contrib/ I will update the SourceForge mirror as soon as their site behaves again. In other news, I have set up two new mailing lists. One is an announcement-only list, mad-announce, for messages like this one (new releases, news, etc.) The other is a user-oriented list, mad-user, for people to discuss MAD (and the new MAD plug-in for Winamp) from a user and music listener perspective. In the future, messages sent to mad-announce will automatically get forwarded to both mad-dev and mad-user, so it's not necessary to change your (mad-dev) subscription unless you only want to receive announcements and not other development chatter. Details for subscribing to any list are on the MAD home page: http://www.mars.org/home/rob/proj/mpeg/ Cheers, -rob P.S. Thanks to Simon Burge, Thomas Klausner and others for nominating MAD (madplay) for NetBSD's October Package of the Month!

2 2

dithering
by Gabriel Bouvigne 12 Nov '00

12 Nov '00

It seems to me that usually dithering is done in time space. In case of PCM coding, it's comprehensible as the data is represented in time space. But what about transform coders? In our case we can access to both representations, time and frequency spaces. So I've had an idea. Perhaps it's full of nonsense, perhaps it needs to be corrected, in this case I'd like to be corrected in order to learn. My idea is to use an adaptative dithering in frequency space. As in decoding we know how much bits were used in a sfb, we could perhaps use this data to adjust the amount of dithering. This way we could dither more when less bits were used, and dither less when more bits were used. Any comments about this? Regards, -- Gabriel Bouvigne - France bouvigne(a)mp3-tech.org mobile phone: gsm(a)mp3-tech.org icq: 12138873 MP3' Tech: www.mp3-tech.org

2 2

seeking a fixed point tutorial
by Sean 'Shaleh' Perry 10 Nov '00

10 Nov '00

I am seeking a fixed point math tutorial that does not use asm (I do not speak asm yet). Suggestions?

2 2

Re: [mad-dev] seeking a fixed point tutorial
by Andre 09 Nov '00

09 Nov '00

--- Sean 'Shaleh' Perry <shaleh(a)via.net> wrote: > I am seeking a fixed point math tutorial that does not use asm (I > do not speak asm yet). Suggestions? There is a reasonable introduction on the ARM website: http://www.arm.com/sitearchitek/armwww.ns4/html/documentation Look for Application Note 33. 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

1 0

Layer III intensity stereo fix
by Rob Leslie 06 Nov '00

06 Nov '00

I feel stupid. I think I have solved the M/S + intensity joint stereo problem. I had thought the issue had to do with an ambiguous standard since my first attempt produced output quite different from two other references (mpg123 and Xaudio). After tweaking the algorithm (OPT_ISKLUGE) I ended up with something that sounded like Xaudio. However, it was inferior to the sound from mpg123. While I still think ISO/IEC 11172-3 is ambiguous if not outright wrong -- it was clarified somewhat in ISO/IEC 13818-3 -- I discovered the cause of the inferior sound as a bug in my code. I feel stupid because the fix is trivial: --- layer3.old.c Mon Nov 6 01:56:35 2000 +++ layer3.c Mon Nov 6 01:57:57 2000 @@ -1112,7 +1112,7 @@ lsf_scale = lsf_is_table[right_ch->scalefac_compress & 0x1]; for (i = bound; i < 576; ++i) { - unsigned int is_pos = 7; + unsigned int is_pos; if (f-- == 0) { if (w-- == 0) { This is actually what I had written originally, but I had changed it due to a compiler warning. :-/ With this fix, the sound is now more like mpg123, much improved, and hopefully, correct in conjunction with OPT_ISKLUGE -- which may not really be a kluge any more. Ironically, Xaudio must have a similar bug, even though I can't look at their code! :-) Cheers, -rob

3 4

Mixed blocks
by Robert Hegemann 05 Nov '00

05 Nov '00

Hello to the list! Why are mixed blocks forbidden in mid/side stereo mode? error: frame 5583: incompatible block_type for MS Even if one uses mixed blocks for stereo only, it seems to sound a bit off. Has mixed block decoding been tested with MPEG test streams? Ciao Robert

3 4

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