mad-dev September 2000

mad-dev@lists.mars.org

8 participants
15 discussions

Re: [mad-dev] what's the meaning of this statement
by Andre McCurdy 29 Sep '00

29 Sep '00

Sorry, forgot the attachment.... 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

Re: [mad-dev] what's the meaning of this statement
by Andre McCurdy 29 Sep '00

29 Sep '00

I ran into the same problem testing with the ARM compiler a while ago. I've attached my hacked solution, which might gives one possible solution. It contains hacked versions of huffman.h, huffman.c and layer3.c, although they are from mad-0.11.0b so won't drop straight into a more recent version. Hope this is useful. Andre -- --- warmice <wzyzht(a)163.net> wrote: > > Hi,everyone: > I want to port mad to windows(VC++).The follwoing statement > will be a > syntax error in VC++. > > # define PTR(offs, bits) { ptr: { 0, bits, offs } } > (huffman.c) > > What's the meaning of this statement ,what's the meaning of "ptr:" > ? How > can I change it in VC++? > > Many many thanks. > ____________________________________________________________ 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

what's the meaning of this statement
by warmice 29 Sep '00

29 Sep '00

Hi,everyone: I want to port mad to windows(VC++).The follwoing statement will be a syntax error in VC++. # define PTR(offs, bits) { ptr: { 0, bits, offs } } (huffman.c) What's the meaning of this statement ,what's the meaning of "ptr:" ? How can I change it in VC++? Many many thanks.

2 1

MAD 0.11.4b available
by Rob Leslie 28 Sep '00

28 Sep '00

MAD 0.11.4b is now available. Highlights include: - Free format bitrate discovery is now working. - There is now a Sun/NeXT 8-bit mu-law audio file output module. - The OSS module now supports 32-bit output if also supported by your sound card and the version of OSS on your system. - The output sample frequency match requirement has been relaxed. (Thanks to Dominic for suggesting a fix.) - An endian assumption problem in audio_sun.c is fixed. (Thanks to Simon Burge for discovering this.) - Some changes affecting SSO have been implemented, courtesy of Nicolas Pitre. - A small patch to imdct_l_arm.S for a.out compatibility has been applied, courtesy of Simon Burge. As a result of Nicolas's SSO changes, SSO now produces fully compliant, not limited accuracy, output. The trick was to do some extra rounding and shifting at compile-time, instead of shifting-only at run-time. SSO is also faster now as a result, even slightly faster than the default configuration for ARM, so it can be enabled with --enable-speed now on all architectures. Get the new version here: ftp://ftp.mars.org/pub/mpeg/ Cheers, -rob

3 4

Experimental layer3 requantisation patch.
by Andre McCurdy 28 Sep '00

28 Sep '00

For those interested, please find attached a patch for 0.11.4b which includes some optimisation of the layer3 requantisation function. Its slightly rough around the edges at this stage, but the brief highlights are: - stripped x86 madplay binary reduced in size from 109k to 77k - peformance improves by approx. 3 percent (although my previous imdct_s() optimisation is included as well which helps towards this). - audio quality should hopefully be improved ?? Any feedback welcome. 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

imdct_s optimisation.
by Andre McCurdy 25 Sep '00

25 Sep '00

Rob, It doesn't make a huge difference to the overall execution time, but the following patch almost doubles the speed of III_imdct_s() (and reduces code size slightly). Could you please do a quick sanity check on the accuracy for me. I would expect it to be about the same as the old version, but checksums of wav file outputs seem to be different (suggesting differences at least as significant as bit 16). Is there an obvious reason for this ? 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 diff -u -r mad-0.11.3b_original/libmad/imdct_s.dat mad-0.11.3b/libmad/imdct_s.dat --- mad-0.11.3b_original/libmad/imdct_s.dat Sun Sep 24 09:20:09 2000 +++ mad-0.11.3b/libmad/imdct_s.dat Sun Sep 24 09:58:28 2000 @@ -19,50 +19,26 @@ * $Id: imdct_s.dat,v 1.1 2000/08/02 05:48:51 rob Exp $ */ - { 0x09bd7ca0L /* 0.608761429 */, -0x0ec835e8L /* -0.923879533 */, /* 0 */ - -0x0216a2a2L /* -0.130526192 */, 0x0fdcf549L /* 0.991444861 */, - -0x061f78aaL /* -0.382683432 */, -0x0cb19346L /* -0.793353340 */ }, - - { 0x061f78aaL /* 0.382683432 */, -0x0ec835e8L /* -0.923879533 */, /* 1 */ - 0x0ec835e8L /* 0.923879533 */, -0x061f78aaL /* -0.382683432 */, - -0x061f78aaL /* -0.382683432 */, 0x0ec835e8L /* 0.923879533 */ }, - - { 0x0216a2a2L /* 0.130526192 */, -0x061f78aaL /* -0.382683432 */, /* 2 */ - 0x09bd7ca0L /* 0.608761429 */, -0x0cb19346L /* -0.793353340 */, - 0x0ec835e8L /* 0.923879533 */, -0x0fdcf549L /* -0.991444861 */ }, - - { -0x0216a2a2L /* -0.130526192 */, 0x061f78aaL /* 0.382683432 */, /* 3 */ + { -0x0216a2a2L /* -0.130526192 */, 0x061f78aaL /* 0.382683432 */, /* 0 */ -0x09bd7ca0L /* -0.608761429 */, 0x0cb19346L /* 0.793353340 */, -0x0ec835e8L /* -0.923879533 */, 0x0fdcf549L /* 0.991444861 */ }, - { -0x061f78aaL /* -0.382683432 */, 0x0ec835e8L /* 0.923879533 */, /* 4 */ + { -0x061f78aaL /* -0.382683432 */, 0x0ec835e8L /* 0.923879533 */, /* 1 */ -0x0ec835e8L /* -0.923879533 */, 0x061f78aaL /* 0.382683432 */, 0x061f78aaL /* 0.382683432 */, -0x0ec835e8L /* -0.923879533 */ }, - { -0x09bd7ca0L /* -0.608761429 */, 0x0ec835e8L /* 0.923879533 */, /* 5 */ + { -0x09bd7ca0L /* -0.608761429 */, 0x0ec835e8L /* 0.923879533 */, /* 2 */ 0x0216a2a2L /* 0.130526192 */, -0x0fdcf549L /* -0.991444861 */, 0x061f78aaL /* 0.382683432 */, 0x0cb19346L /* 0.793353340 */ }, - { -0x0cb19346L /* -0.793353340 */, 0x061f78aaL /* 0.382683432 */, /* 6 */ + { -0x0cb19346L /* -0.793353340 */, 0x061f78aaL /* 0.382683432 */, /* 3 */ 0x0fdcf549L /* 0.991444861 */, 0x0216a2a2L /* 0.130526192 */, -0x0ec835e8L /* -0.923879533 */, -0x09bd7ca0L /* -0.608761429 */ }, - { -0x0ec835e8L /* -0.923879533 */, -0x061f78aaL /* -0.382683432 */, /* 7 */ + { -0x0ec835e8L /* -0.923879533 */, -0x061f78aaL /* -0.382683432 */, /* 4 */ 0x061f78aaL /* 0.382683432 */, 0x0ec835e8L /* 0.923879533 */, 0x0ec835e8L /* 0.923879533 */, 0x061f78aaL /* 0.382683432 */ }, - { -0x0fdcf549L /* -0.991444861 */, -0x0ec835e8L /* -0.923879533 */, /* 8 */ - -0x0cb19346L /* -0.793353340 */, -0x09bd7ca0L /* -0.608761429 */, - -0x061f78aaL /* -0.382683432 */, -0x0216a2a2L /* -0.130526192 */ }, - - { -0x0fdcf549L /* -0.991444861 */, -0x0ec835e8L /* -0.923879533 */, /* 9 */ + { -0x0fdcf549L /* -0.991444861 */, -0x0ec835e8L /* -0.923879533 */, /* 5 */ -0x0cb19346L /* -0.793353340 */, -0x09bd7ca0L /* -0.608761429 */, - -0x061f78aaL /* -0.382683432 */, -0x0216a2a2L /* -0.130526192 */ }, - - { -0x0ec835e8L /* -0.923879533 */, -0x061f78aaL /* -0.382683432 */, /* 10 */ - 0x061f78aaL /* 0.382683432 */, 0x0ec835e8L /* 0.923879533 */, - 0x0ec835e8L /* 0.923879533 */, 0x061f78aaL /* 0.382683432 */ }, - - { -0x0cb19346L /* -0.793353340 */, 0x061f78aaL /* 0.382683432 */, /* 11 */ - 0x0fdcf549L /* 0.991444861 */, 0x0216a2a2L /* 0.130526192 */, - -0x0ec835e8L /* -0.923879533 */, -0x09bd7ca0L /* -0.608761429 */ } + -0x061f78aaL /* -0.382683432 */, -0x0216a2a2L /* -0.130526192 */ } diff -u -r mad-0.11.3b_original/libmad/layer3.c mad-0.11.3b/libmad/layer3.c --- mad-0.11.3b_original/libmad/layer3.c Sun Sep 24 09:20:09 2000 +++ mad-0.11.3b/libmad/layer3.c Sun Sep 24 15:02:20 2000 @@ -222,10 +222,10 @@ * IMDCT coefficients for short blocks * derived from section 2.4.3.4.10.2 of ISO/IEC 11172-3 * - * imdct_s[i][k] = cos((PI / 24) * (2 * i + 7) * (2 * k + 1)) + * imdct_s[i][k] = cos((PI / 24) * (2 * (i+3) + 7) * (2 * k + 1)) */ static -mad_fixed_t const imdct_s[12][6] = { +mad_fixed_t const imdct_s[6][6] = { # include "imdct_s.dat" }; @@ -1555,32 +1555,40 @@ static void III_imdct_s(mad_fixed_t const X[18], mad_fixed_t z[36]) { - unsigned int w, i, k; - mad_fixed_t y[3][12]; + static const unsigned char map_duplicates[6] = { 2, 1, 0, 11, 10, 9 }; - /* IMDCT and windowing */ + int i, k; + mad_fixed_t y[36]; - for (w = 0; w < 3; ++w) { - for (i = 0; i < 12; ++i) { - register mad_fixed_t sum; - - sum = 0; - - for (k = 0; k < 6; ++k) - sum += mad_f_mul(X[6 * w + k], imdct_s[i][k]); + /* IMDCT */ - y[w][i] = mad_f_mul(sum, window_s[i]); + for (i = 0; i < 6; i++) + { + mad_fixed_t sum0 = 0, sum1 = 0, sum2 = 0; + + for (k = 0; k < 6; k++) + { + sum0 += mad_f_mul(X[k ], imdct_s[i][k]); + sum1 += mad_f_mul(X[k+ 6], imdct_s[i][k]); + sum2 += mad_f_mul(X[k+12], imdct_s[i][k]); } + + y[i+ 3] = sum0; y[map_duplicates[i] ] = (i < 3) ? -sum0 : sum0; + y[i+15] = sum1; y[map_duplicates[i]+12] = (i < 3) ? -sum1 : sum1; + y[i+27] = sum2; y[map_duplicates[i]+24] = (i < 3) ? -sum2 : sum2; } - /* overlapping and concatenation */ + /* Windowing, overlapping and concatenation */ - for (i = 0; i < 6; ++i) z[i] = 0; - for (i = 6; i < 12; ++i) z[i] = y[0][i - 6]; - for (i = 12; i < 18; ++i) z[i] = y[0][i - 6] + y[1][i - 12]; - for (i = 18; i < 24; ++i) z[i] = y[1][i - 12] + y[2][i - 18]; - for (i = 24; i < 30; ++i) z[i] = y[2][i - 18]; - for (i = 30; i < 36; ++i) z[i] = 0; + for (i = 0; i < 6; i++) + { + z[i ] = 0; + z[i+ 6] = mad_f_mul(y[i+ 0], window_s[i+0]); + z[i+12] = mad_f_mul(y[i+ 6], window_s[i+6]) + mad_f_mul(y[i+12], window_s[i]); + z[i+18] = mad_f_mul(y[i+18], window_s[i+6]) + mad_f_mul(y[i+24], window_s[i]); + z[i+24] = mad_f_mul(y[i+30], window_s[i+6]); + z[i+30] = 0; + } } /*

2 1

Trying To Stream MAD
by David Van Brink 21 Sep '00

21 Sep '00

Rob Leslie (or anyone else who cares to help), Hi! First -- Thanks for making this body of code available. Overall it's been quite easy to work with, and works, and reads nicely, too. Second -- I haven't updated to the latest source release... We're using MAD in a demonstration of our new little embedded CPU ("Nios"). I'm running into one little bit of confusion. We're running our board with no OS, so we don't have memory mapped files or anything. So I'm trying to stream frame-by-frame as needed. (I'm using the "lower level API" that the README suggests I don't. :-) I call mad_frame_decode(&frame,&stream), and if it returns a recoverable error, I try to read more data in. It appears that I should preserve the tail end of the stream's buffer, specifically, everything from stream.next_frame to stream.bufend. So, I copy that tail end down to stream.buffer, and load new data past it. This seems to work *almost* all the time. Am I thinking correctly? Thanks for any insight. -- David Van Brink P.S. In case you're inspired to muddle through someone else's code, my main routine follows. Feel free not to, though. As ever, pardon the horrific formatting. My real question is, can I always assume that everything from stream.next_frame to stream.bufend is the part to keep when the stream is lacking for more bits. int nios_mp3_getNextFrame(nios_mp3 *nm) { int result = 0; result = mad_frame_decode(&nm->frame,&nm->stream); // // the decode may fail due to a lack of source data, // in which case we'll read some and try again // if(result == -1 && (nm->stream.error == MAD_ERR_BUFLEN || nm->stream.error == MAD_ERR_BUFPTR)) { long tailSave; // how much is still good in the buffer long size = kFileBufferSize; // amount we'll try to have on-hand if(nm->currentFilePosition >= nm->fileLength) { result = -1; goto goHome; } tailSave = nm->stream.bufend - nm->stream.next_frame; size -= tailSave; #if NIOS_MP3_DEBUG printf("nios_mp3_getNextFrame: size = %d, tailSave = %d\n",size,tailSave); #endif // Copy the tail to the head // memcpy(nm->fileBuffer,nm->fileBuffer + nm->currentBufferSize - tailSave,tailSave); // Clamp size to fileLength // if(nm->currentFilePosition + size > nm->fileLength) size = nm->fileLength - nm->currentFilePosition; // Read in the new bytes // WOSFS_Read(nm->fileNumber,nm->currentFilePosition,size,nm->fileBuffer + tailSave); nm->currentBufferSize = size + tailSave; nm->currentFilePosition += size; // Give new buffer to the stream // mad_stream_buffer(&nm->stream, nm->fileBuffer, nm->currentBufferSize); // And try that frame decode again (but no more after this!) // result = mad_frame_decode(&nm->frame,&nm->stream); } #if NIOS_MP3_DEBUG || 1 if(result) printf("nios_mp3_getNextFrame: mad_frame_decode returned %d/%d\n", result,nm->stream.error); #endif if(result == -1) goto goHome; nm->framesDecoded++; mad_synth_frame(&nm->synth,&nm->frame); nm->samplesGenerated += nm->synth.pcmlen; goHome: return result; }

2 1

Is it possible to d/l binaries for win32/dos somewhere?
by igo shte 21 Sep '00

21 Sep '00

Is it possible to d/l binaries for win32/dos somewhere? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.

2 1

Re: [mad-dev] MAD 0.11.3b available
by lwong＠hongkong.com 21 Sep '00

21 Sep '00

A simple patch to solve the problem of sample frequency not available. at decode_output of madplay.c int decode_output ( ... { ... else { if (audio->quiet < 1) { error("output", "sample frequency %u Hz not available; closest %u Hz", frame->sfreq, control.config.speed); + + if (abs(frame->sfreq - control.config.speed) <1000 ) { + audio->channels = nchannels; + audio->speed_out = frame->sfreq; + goto start; } } ... +Start: control.command = audio_cmd_play; if (audio->resampled) { control.play.nsamples = resample_block(&audio->resample[0], synth->pcmlen, ... } I set the limit before the diff. between frame->sfreq and control.config.speed is 1000. I think it is enough for general case. Regards, Dominic. ---------------------------------------------- ÅwªïšÏ¥Î hongkong.com ¹q€l¶l¥óšt²Î Thank you for using hongkong.com Email system

1 0

MAD 0.11.3b available
by Rob Leslie 21 Sep '00

21 Sep '00

I made another significant improvement to MAD under ARM: using 64-bit multiply/accumulate instead of scaling after each multiply during synthesis, both performance and accuracy is increased. The performance is increased so much, in fact, it is faster than using SSO. I decided it was best to change the way MAD is configured, since individual options can now have unpredictable effects on performance and accuracy... instead of specifying SSO, ASO etc. explicitly, there are now three general options: (the default) produce optimum accuracy and speed --enable-speed optimize for additional speed over accuracy --enable-accuracy optimize for additional accuracy over speed The idea is to specify how to compromise between the two goals. The default is not to make any compromises, and deliver good accuracy with reasonable performance. Configuring with --enable-speed now automatically enables SSO, if that will make things faster. Likewise --enable-accuracy gets better accuracy wherever possible, at the expense of performance. It turns out this doesn't make any difference now for FPM_ARM, but it does for FPM_64BIT and FPM_INTEL. Andre's ARM code is now always enabled for ARM hosts, since it always improves both speed and performance; it must be explicitly disabled if not wanted. Here's some updated statistics I measured with the new 0.11.3b: (StrongARM 1100 220 MHz, accuracy and %CPU speed) Layer I Layer II Layer III FPM_64BIT default 6.198e-8/F 20% 6.198e-8/F 20% 6.931e-8/F 29% FPM_64BIT OPT_SPEED 8.482e-6/F 17% 1.144e-5/L 18% 1.008e-5/L 26% FPM_64BIT OPT_ACCURACY 4.715e-8/F 25% 4.941e-8/F 24% 5.375e-8/F 33% FPM_APPROX * 7.880e-5/L 17% 6.627e-5/L 17% 6.431e-5/L 25% FPM_ARM * 4.667e-8/F 16% 4.906e-8/F 16% 5.338e-8/F 24% /F means full compliance, /L means limited accuracy. Smaller numbers are better in all cases. Using FPM_ARM is obviously a big win. :-) By these numbers, MAD is now tied with Xaudio for Layer III decoding speed! Layer I and Layer II have been faster than Xaudio for some time, and in any case, MAD has always been much more accurate. Get the new release here: ftp://ftp.mars.org/pub/mpeg/ Cheers, -rob

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