On 23 Jan, Tony Clark wrote:
>> or
>> - a buggy compiler
>
> From Debian 2.95-4 and 3.03 I also built a version of 3.03. They all gave
> more or less the same sort of performance. Used versions of NASM from Debian
> stable and testing. I suspect there is no NASM code though?
There should be NASM code...
Have a look at the output of configure, there should be a line with
"assembler routines for this processor type".
>> > I have tired the cvs version as well as 3.91. I find that 3.91 seems
>> > better than cvs, but I guess that could vary. I also find that variable
>> > bit rate>
>> The only significant difference between 3.91 and CVS is: the CVS
>> contains a workaround for a bug with gcc 3.0.3 and "-O3 -funroll-loops"
>> (use "-O -funroll-loops" instead).
>>
> I would now agree with that. I've done further testing today and found
> basically no difference between 3.91 and todays CVS. Neither does the choice
> of compiler seem to make any difference when you do controlled testing.
So this may be a bug in LAME. Maybe Mark is able to help more.
>> > seems more robust than constant bit rate. That could be because mencoder
>> > defaults to vbr where as transcoder defaults to cbr. I use the following
>> > line for configuring lame.
>> > CFLAGS="-O -march=athlon -mcpu=athlon -malign-functions=4 -malign-double"
>> > ./configure
>>
>> Did you tried to use the CVS version without your own CFLAGS? If not,
>> please do so (and don't forget to "make distclean" before "configure" if
>> you use an already configured CVS version).
>
> I have been using the following
>
> rm config.cache ; make clean ; ./configure --enable-debug ; make
Ok.
Bye,
Alexander.
--
The three Rs of Microsoft support: Retry, Reboot, Reinstall.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
_______________________________________________
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder
