Hello.
As most people around here I have been using EAC/LAME for my MP3 encodes.
I have started using EAC 0.9 Beta 2 (the newest one) and LAME 3.97a10 (I know it is not recommended, but I am not archiving and it is hel of a lot faster that the "recommended compile").
As some of you should know, there was a bug a while back on the EAC encoder settings that it you selected "LAME MP3 Encoder", the drop-down quality menu would affect the VBR Tag (IIRC), altough not the file itself, which would be the same file produced using the "User Defined Encoder" setting.
I made some encodes this past weekend, using the "LAME MP3" setting, command line "-V 4 --vbr-new" and the drop-down menu set to 160k.
The files came almost CBR 160. They have very little variation on that rate. Almost as if it where ABR.
I encoded those same files using foobar2000, and they came up as expected (maybe a little higher, averaging 180 per file).
Is the EAC "bug" made worse on this version?
I have not been able to do a bit comparison between the tracks after decoding them to wav to look for actual differences, because I don't have access to those files now.
But I will try to do it tonight.
Does anyone know anything about this?
Full Version: EAC, LAME and the drop-down bug
Don't know. Why not simply set up a decent command line + cl encoder and thus getting rid of any nasty bug?
QUOTE(AtaqueEG @ Jun 24 2005, 06:00 AM)
Hello.
As most people around here I have been using EAC/LAME for my MP3 encodes.
I have started using EAC 0.9 Beta 2 (the newest one) and LAME 3.97a10 (I know it is not recommended, but I am not archiving and it is hel of a lot faster that the "recommended compile").
As some of you should know, there was a bug a while back on the EAC encoder settings that it you selected "LAME MP3 Encoder", the drop-down quality menu would affect the VBR Tag (IIRC), altough not the file itself, which would be the same file produced using the "User Defined Encoder" setting.
I made some encodes this past weekend, using the "LAME MP3" setting, command line "-V 4 --vbr-new" and the drop-down menu set to 160k.
The files came almost CBR 160. They have very little variation on that rate. Almost as if it where ABR.
I encoded those same files using foobar2000, and they came up as expected (maybe a little higher, averaging 180 per file).
Is the EAC "bug" made worse on this version?
I have not been able to do a bit comparison between the tracks after decoding them to wav to look for actual differences, because I don't have access to those files now.
But I will try to do it tonight.
Does anyone know anything about this?
As most people around here I have been using EAC/LAME for my MP3 encodes.
I have started using EAC 0.9 Beta 2 (the newest one) and LAME 3.97a10 (I know it is not recommended, but I am not archiving and it is hel of a lot faster that the "recommended compile").
As some of you should know, there was a bug a while back on the EAC encoder settings that it you selected "LAME MP3 Encoder", the drop-down quality menu would affect the VBR Tag (IIRC), altough not the file itself, which would be the same file produced using the "User Defined Encoder" setting.
I made some encodes this past weekend, using the "LAME MP3" setting, command line "-V 4 --vbr-new" and the drop-down menu set to 160k.
The files came almost CBR 160. They have very little variation on that rate. Almost as if it where ABR.
I encoded those same files using foobar2000, and they came up as expected (maybe a little higher, averaging 180 per file).
Is the EAC "bug" made worse on this version?
I have not been able to do a bit comparison between the tracks after decoding them to wav to look for actual differences, because I don't have access to those files now.
But I will try to do it tonight.
Does anyone know anything about this?
I've ran into this problem before with older EACs (though I haven't tried it with the newer one)... It seems that when you use the LAME Encoder in the pulldown and select a bitrate, it adds "-b [bitrate]" to the command line... The best thing to do would be to just select "User Defined Encoder".
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.