Hi,
I'm back (since a couple of days), and I've started making a little
better makefile (closer to the original) for the free Borland C++
compiler. A few more changes where required this time (when using lame
3.86):
* The file "quantize-pvt.c" needs to be called "quantize_pvt.c" - or the
ar-like utility thinks an option starts in the middle of the file name.
* choose_table.nas needs to be changed (I've mentioned this before):
"segment_code" should be replaced with "segment code class=code use32"
and "segment_data" with "segment data class=data use32". Otherwise BCC
won't find the function entry. Perhaps a conditional fix?
* To compile the DLL, I had to make sure BladeMP3EncDLL.c included
"machine.h" before it includes "BladeMP3EncDLL.h" (machine.h wasn't
included at all). Don't know if it works yet, but at least it compiles.
:)
I've timed lame with and without MMX_choose_table defined, and I am
unable to notice any speed difference (when encoding a 45 second test
sample, using the command "lame test.wav"). Shouldn't there be easily
noticable difference on a 400 MHz PII system?
By using the fft_FPU_FXCH code, as well as TAKEHIRO_IEEE754_HACK, I
managed to get speed to within about 50 percent of the 3.80 DLL I use
with CDEx (I've no idea on the options used there). How much of a
speed-up could ASM_QUANTIZE give?
Btw, after a test run, I noticed that 405 bytes differ (at least
according to the simple cmp program I wrote :). Is that something to
worry about?
--
Magnus Holmgren
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )