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/ )

Reply via email to