mad-dev

mad-dev@lists.mars.org

682 discussions

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

Why libmad is compiled with -O1
by Andre 30 Oct '00

30 Oct '00

I don't remember who it was, but someone was asking about why libmad is compiled with -O1 optimisation (instead of eg -O3). Anyway, I just found the results of some profiling tests I did a while back using the Pentium Time Stamp Counter to profile the imdct36() function in layer3.c, mad-0.11.0b. Hopefully the results are of interest, although I can't really offer too much explanation except to suspect 'features' in the gcc optimiser.... All results are in clock cycles on a Pentium III: gcc version egcs-2.91.66 (ie stock RH 6.2): gcc -O1 : 1329 clocks (asm mad_f_mul), 1529 clocks (C mad_f_mul) gcc -O2 : 1607 clocks (asm mad_f_mul), 2176 clocks (C mad_f_mul) gcc -O3 : 1608 clocks (asm mad_f_mul), 2186 clocks (C mad_f_mul) gcc version 2.95.2 19991024: gcc -O0 : 2946 clocks (asm mad_f_mul), 2616 clocks (C mad_f_mul) gcc -O1 : 1735 clocks (asm mad_f_mul), 1201 clocks (C mad_f_mul) gcc -O2 : 1380 clocks (asm mad_f_mul), 1567 clocks (C mad_f_mul) gcc -O3 : 1380 clocks (asm mad_f_mul), 1567 clocks (C mad_f_mul) Rob, any news on an ETA for the next release ?? 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

4 5

MAD plug-in for Winamp
by Rob Leslie 30 Oct '00

30 Oct '00

All, I've completed a beta version of a MAD plug-in for Winamp. You can download it from the MAD home page: http://www.mars.org/home/rob/proj/mpeg/ It currently lacks streaming support, but will handle all *.MP[123] files. One of the goals of the plug-in is to provide 24- and 32-bit output if your soundcard supports it. However, it is not known whether any Winamp output plug-ins (including the Nullsoft waveOut plug-in) support any resolution greater than 16 bits. I don't have the necessary hardware to test this, so I'm hoping to get feedback from anyone who can try it. I will be releasing source for the plug-in along with the next regular source code release. Cheers, -rob

1 0

Re: [mad-dev] Why libmad is compiled with -O1
by Andre 25 Oct '00

25 Oct '00

--- Nicolas Pitre <nico(a)cam.org> wrote: > > On Wed, 25 Oct 2000, Andre wrote: > > > All results are in clock cycles on a Pentium III: > > > > gcc version egcs-2.91.66 (ie stock RH 6.2): > > > > gcc -O1 : 1329 clocks (asm mad_f_mul), 1529 clocks (C mad_f_mul) > > gcc -O2 : 1607 clocks (asm mad_f_mul), 2176 clocks (C mad_f_mul) > > gcc -O3 : 1608 clocks (asm mad_f_mul), 2186 clocks (C mad_f_mul) > > > > gcc version 2.95.2 19991024: > > > > gcc -O0 : 2946 clocks (asm mad_f_mul), 2616 clocks (C mad_f_mul) > > gcc -O1 : 1735 clocks (asm mad_f_mul), 1201 clocks (C mad_f_mul) > > gcc -O2 : 1380 clocks (asm mad_f_mul), 1567 clocks (C mad_f_mul) > > gcc -O3 : 1380 clocks (asm mad_f_mul), 1567 clocks (C mad_f_mul) > > This is strange. > > The gcc-2.95.2 results are somewhat different on a StrongARM. They > are more inline with the egcs-2.91.66 results above... > In terms of clock cycles, I would expect a (single issue) StrongARM to require a lot more than a (super-scalar) Pentium III for a given C function. Unfortunately though, I don't have a suitable ARM platform to do any gcc testing with, so haven't been able to test this. I have a copy of ARM's 'Armulator' simulator which gives very good profiling information, but only runs code compiled with ARM's C compiler. Unfortunately, ARM's C compiler makes such a bad job of 64bit data types that I don't think any MAD benchmarks generated this way are very useful as a guide to how fast the code would run when compiled with gcc. I do have an ARM Integrator board (ARM720T cpu), which I guess should be able to run Linux, but I haven't yet investigated the effort required to get it to do so.... Out of interest, the imdct36() part of my ARM assembler imdct36 + windowing function requires just under 1100 clock cycles on the simulator. So with a bit of assembler tweaking, a humble StrongARM can be faster than a Pentium III :-) 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

Requantisation optimisations.
by Andre 16 Oct '00

16 Oct '00

Rob + others, Attached is my latest effort at re-quantisation (+ other minor) optimisations for mad-0.11.4b. This patch supersedes all my previous patches for 0.11.4b (ie it also includes the imdct_s optimisation). Compared with an untouched 0.11.4b, on an AMD K6 I get: - Approx 4.1 % speed increase (MHz for realtime decode decreases from 45.7 to 43.8) when configured with --enable-accuracy. - Approx 9.4 % speed increase (MHz for realtime decode decreases from 34.8 to 31.5) when configured with --enable-speed. - Accuracy increases slightly. 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

Update
by Rob Leslie 13 Oct '00

13 Oct '00

There are a number of things worth mentioning about MAD of late. First, I have set up a SourceForge project which I plan to use for the public forums, bug manager, support manager, and patch manager, as well as to mirror the distributions. I may also use it for the task manager, although this is less clear to me at the moment. You are welcome to continue submitting patches on this mailing list, although you might prefer to post them on SourceForge instead (and follow-up with a note here) since there is no public archive for this list. I may also set up CVS on SourceForge at some point, if people are interested. The SourceForge project page is: http://sourceforge.net/projects/mad/ In other news, I have made some rather drastic changes to MAD which I plan to release soon as 0.12.0b. These changes include: Throughout: - use of automake - use of libtool (to simplify building shared libraries) libmad: - extended the timer API, making it very useful - the async API is almost finished - extended the decoder API to enable (fast) header decoding and an opportunity to preempt decoding the rest of the frame - numerous other API changes madplay: - support for long-style options - support for internationalization (via GNU gettext) - support for start/stop playing in the middle of a file - support for shuffle/repeat - modularized filter framework - new fade-in filter to start with (fade-out, inter-song gap, and cross-fade handling planned) Besides finishing up the above, I'm also currently trying to decide how best to deal with mpg123 compatibility. This is important because it will allow MAD to be used as the back-end decoder for many existing front-end GUIs. Tom Lawler has contributed a modified version of madplay that will emulate mpg123 output, enough to provide minimal functionality to work with gqmpeg. This apparently all runs quite well on the iPaq. :-) His package can be found here: ftp://handhelds.org/pub/apps/sound/ I'd like to incorporate something like this into the primary distribution, but I would like to do a more complete emulation, including support for all or most of mpg123's command-line options. Unfortunately, I think to do this right will cause the size of madplay to bloat too much, so I'm considering making this a separate program ("mad123") that just uses the MAD library. Is there anyone interested in working on this? I can do it, but I'd rather spend time finishing other things... Also speaking of sub-projects, since the next release of MAD will be internationalized, would anyone here with non-English speaking skills like to contribute translation(s)? Finally, since I've been working largely on the above, I haven't had a chance to incorporate some of the more recent patches, particularly Andre's imdct_s and requantization optimizations. I haven't rejected them, but they will probably have to wait until 0.12.1b. That's all for now. Cheers, -rob

1 0

No float point supported
by warmice 04 Oct '00

04 Oct '00

Hi,Andre: We want to port mad to a little system built up by ourselves . We use our own CPU ,controlers, complilers etc. Our CPU isn't so powerful yet so it cannot support floating point yet. So mad is perfect for our project . :-)

1 0

Re: [mad-dev] compile mad in VC
by Andre McCurdy 03 Oct '00

03 Oct '00

--- Zhang Tao <warmice(a)sina.com> wrote: > Hi, > Can someone tell me how to change the following statement so it > can be compliled in VC++? > > # define mad_f_mul(x, y) \ > ({ mad_fixed64hi_t __hi; \ > mad_fixed64lo_t __lo; \ > asm ("imull %3" \ > : "=a" (__lo), "=d" (__hi) \ > : "%a" (x), "rm" (y)); \ > mad_f_scale64(__hi, __lo); \ > }) > There are 2 main reasons why this will not compile with VC++. Firstly because it is a 'statement expression' (a gcc specific thing which I don't think exists in VC++), and secondly because it uses the gcc syntax for including inline assembler. The easiest way to get things working is to use FPM_64BIT rather than FPM_INTEL which will cause mad_f_mul to be defined as a regular macro, and not use any inline assembler. What platform are you planning to run the compiled code on ? If its PC, then maybe one of the floating point mp3 decoders might be a better choice than mad ?? 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

compile mad in VC
by Zhang Tao 03 Oct '00

03 Oct '00

Hi, Can someone tell me how to change the following statement so it can be compliled in VC++? # define mad_f_mul(x, y) \ ({ mad_fixed64hi_t __hi; \ mad_fixed64lo_t __lo; \ asm ("imull %3" \ : "=a" (__lo), "=d" (__hi) \ : "%a" (x), "rm" (y)); \ mad_f_scale64(__hi, __lo); \ }) Many thanks.

1 0

RE: [mad-dev] question about mmap
by David Van Brink 02 Oct '00

02 Oct '00

Warmice: > But I want to port mad to a simple system so there is no such complex > function call available.My question is how can I write someting to replace > mmap function call. That's exactly what we just did, ran mad on a little OS-less embedded system. To redundantly restate what Rob said: mmap() makes it *seem* as if the whole mp3 file has been read into an array. Reading it into an array yourself will do the same thing, and that's how we first got mad running (with rather short mp3 songs to fit in our 256k of RAM :-). Below is the main loop that we used instead of, more or less, the "decode()" routine in madplay.c. The routine that's called below, "WOSFS_Read()" is a simple file-read call. (But it sounds like the current version of mad will do this for you already...) -- David Van Brink /* * * nios_mp3_getNextFrame() fills up the nios_mp3.synth * with one frame's worth of data, or returns an error. */ 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 // memmove(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(result && nm->stream.error != 1) // "error" 1 is normal file-end printf("nios_mp3_getNextFrame: mad_frame_decode returned %d/%d\n", result,nm->stream.error); if(result == -1) goto goHome; nm->framesDecoded++; mad_synth_frame(&nm->synth,&nm->frame); nm->samplesGenerated += nm->synth.pcmlen; goHome: return result; } -----Original Message----- From: Rob Leslie [mailto:rob@mars.org] Sent: Sunday, October 01, 2000 9:00 AM To: warmice Cc: mad-dev(a)lists.mars.org Subject: Re: [mad-dev] question about mmap > The function mmap(....) appears several times in madplay.c and minimad.c > .I don't know what the function will exactly do ,bu I think it's related > with paging ? The function maps the file into the memory address space of the process. The file can then be accessed directly with memory references rather than by calling read(). This is helpful because it enables random access without worries about buffering, as this is done in the kernel -- the file is paged into memory only as needed. It also eliminates copying data from the kernel's buffer into user space. > But I want to port mad to a simple system so there is no such complex > function call available.My question is how can I write someting to replace > mmap function call. I don't know if Windows provides a similar capability. However, `madplay' has been written to work without it. Just don't define HAVE_MMAP. > Can I just allocate a mem buffer and read the file to the buffer and using > the pointer to buffer as void * fdm in the main()? I try it but it seems to > cause some error.When I decode to the almost end of a mp3 file ,it will > sometimes report 0x0101 error. > > /* fdm = mmap(0, stat.st_size, PROT_READ, MAP_SHARED, STDIN_FILENO, 0);*/ > fdm = malloc(stat.st_size); > inputstream = fdopen(STDIN_FILENO,"r"); > fread(fdm,sizeof(char),stat.st_size,inputstream); This will probably work, although it is perhaps a bit greedy to read the entire file into memory at once. You might prefer to read the file in chunks, as `madplay' will do when HAVE_MMAP is not defined. The 0x0101 error means MAD lost synchronization with the bitstream. I have found this to be common if the file contains an ID3v1 tag at the end of the file; the tag is apparently not always located at a frame boundary. I will try to work around this, but for now you can ignore the error. -- Rob Leslie rob(a)mars.org

1 0

question about mmap
by warmice 01 Oct '00

01 Oct '00

Hi,everyone: The function mmap(....) appears several times in madplay.c and minimad.c .I don't know what the function will exactly do ,bu I think it's related with paging ? But I want to port mad to a simple system so there is no such complex function call available.My question is how can I write someting to replace mmap function call. Can I just allocate a mem buffer and read the file to the buffer and using the pointer to buffer as void * fdm in the main()? I try it but it seems to cause some error.When I decode to the almost end of a mp3 file ,it will sometimes report 0x0101 error. /* fdm = mmap(0, stat.st_size, PROT_READ, MAP_SHARED, STDIN_FILENO, 0);*/ fdm = malloc(stat.st_size); inputstream = fdopen(STDIN_FILENO,"r"); fread(fdm,sizeof(char),stat.st_size,inputstream); Can someone give me some help? Many many thanks.

2 1

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

Re: [mad-dev] MAD 0.11.2b available
by Andre McCurdy 18 Sep '00

18 Sep '00

Rob, Before I forget, there is something else I looked at a while ago which I haven't had time to explore more fully.... The distribution of values fetched from rq_table[] seems to be far from even (certainly for the few files I tested it with): rq_table[0] gets by far the most hits, rq_table[1] gets a few percent, with values after that dropping off fairly quickly. Based on this, maybe putting 'if (value == 0) return (0);' at the top of III_requantize() might give a (very) small speed up ? Also, by removing the first few entries from the table and recognising them directly it would be possible to fit the range of exponents in 4 bits rather than 5 and increase accuracy slightly. Any thoughts ?? 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

Re: [mad-dev] MAD 0.11.2b available
by Andre McCurdy 16 Sep '00

16 Sep '00

Rob, Thanks for catching my stupid mistake. Maybe it will teach me to read my own comments while fixing code rather than just using a regular expression search and replace... ! Your patch looks fine. 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

Jump to page:

2025

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