Hi!
I've yesterday downlaoded the mad source (latest beta).. mad-0.13.0b.
ok.. my quest was (or is...) to compile mad to cris (made by Axis, 32 bit RISC, also know as etrax_lx) platform. Some tweaking with env. vars (CC=cris_gcc, etc)...
made a little ./configure "wrapper": #! /bin/sh rm config.cache
CC='gcc_cris -mlinux -DCRISMMU -muclibc=/home/antti/axis/devboard_lx/eroot' \ OBJCOPY=objcopy-cris \ LD=ld-cris \ AR=ar-cris \ RANLIB=ranlib-cris \ ./configure --host=unknown --target=cris --disable-nls --disable-aso --enabl e-fpm=approx
I had to do something bad also with the main configure script to avoid a problem with the big-endian test (system couldn't run the cris code... compiling under intel x86 ... with cris_gcc cross compiler..)
Ok.. with this setup (and some additional work before, cause cris uC-lib didn't have any native math suopport, which i had to add ... well... ) I managed to compile the whole thing without any ugly errors...
After this I naturally tested the thing with the native cris platform.. Madplay could read the mp3:s very well, but the output (to a wav file) wasn't too good.. I coud hear that the music was there, but there was also some additional noice a lot. any pointers where i shuld start digging... (?)
/Antti
--- Antti Antinoja antinoja@netlife.fi wrote:
ok.. my quest was (or is...) to compile mad to cris (made by Axis, 32 bit RISC, also know as etrax_lx) platform.
Sounds interesting...
./configure --host=unknown --target=cris --disable-nls --disable-aso --enable-fpm=approx
It might not help your immediate problem, but unless you have cycles to burn (or think you can hear 24bits of audio resolution... :-) you could try adding '--enable-speed' and eventually '--disable-debugging'
Also, depending on the cris multiplier, FPM_64BIT may be faster than FPM_APPROX (I believe this is the case with MIPS, and maybe others ??).
Ok.. with this setup (and some additional work before, cause cris uC-lib didn't have any native math suopport, which i had to add ... well... ) I managed to compile the whole thing without any ugly errors...
Native math support required ?? What exactly ??
After this I naturally tested the thing with the native cris platform.. Madplay could read the mp3:s very well, but the output (to a wav file) wasn't too good.. I coud hear that the music was there, but there was also some additional noice a lot. any pointers where i shuld start digging... (?)
'Awful but just about recognisible' _might_ be the result of byte swapping on the output: try double checking that the endian-ness in the audio output quantisation is correct.
Also worth a try is disabling dithering, and having a look at the data output in HEX output format (requires re-configuring with --enable-debugging).
Failing that, the next step is probably to put some printf's in the code and compare the values at certain stages with the values output by the same code and mp3 file run on a PC. (That should tell you at what point things start going wrong).
Places to start might be:
- The values returned by III_requantize() - Some of the IMDCT results (x[0..35] at the end of imdct36()) - Some results picked out of mad_synth_frame()
Good luck !
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
Andre wrote:
It might not help your immediate problem, but unless you have cycles to burn (or think you can hear 24bits of audio resolution... :-) you could try adding '--enable-speed' and eventually '--disable-debugging'
This post caught my eye. Are you saying that --enable-speed decodes to 16-bit samples instead of 24? If so what else is different by enabling speed?
I'm sorry if this is documented somewhere as I have not been able to find it.
Thanks, Ira Weiny iweiny@acm.org
--- Ira Weiny iweiny@acm.org wrote:
It might not help your immediate problem, but unless you have cycles to burn (or think you can hear 24bits of audio resolution... :-) you could try adding '--enable-speed' and eventually '--disable-debugging'
This post caught my eye. Are you saying that --enable-speed decodes to 16-bit samples instead of 24? If so what else is different by enabling speed?
Its not quite as simple as that... :-)
There are many places in MAD where there are alternative ways to code a particular operation. Sometimes you can rewrite a function faster _and_ more accurate, but usually there are trade offs. This is especially true of MAD because it contains specific optimisations for particular processor architectures.
--enable-speed basically brings in a number of go faster tweaks, but still avoids doing anything to cause a significant reduction in sound quality. It certainly hasn't been 'tuned' to give 16bits (and the final accuracy is architecture dependent anyway).
You might want to look at the decoder compliance tests on the MAD homepage:
http://www.mars.org/home/rob/proj/mpeg/compliance/
These tests (with a synthetic benchmark....) would suggest that MAD with --enable-speed still gives _better_ than 16bits.
As always though, do some of your own listening tests before you decide :-)
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
Ira Weiny wrote:
This post caught my eye. Are you saying that --enable-speed decodes to 16-bit samples instead of 24? If so what else is different by enabling speed?
In addition to what Andre said, an important distinction is that while --enable-speed reduces the accuracy of the output, it doesn't affect the sample size. In other words you still get 24 bits if you like; they're just not as accurate. If you're not going to use more than about 16 bits anyway, this may be an acceptable trade-off for speed.
-
Andre -
Antti Antinoja -
Ira Weiny -
Rob Leslie