Help - Search - Members - Calendar
Full Version: Problems with Lame3.90 alpha 8
Hydrogenaudio Forums > Lossy Audio Compression > MP3 > MP3 - General
RD
I've been playing around with Lame 3.90 alpha 8 and I noticed some things:

(1) It's Slower
Alpha 8 is slower than Alpha 7 even
when it encodes the same .wav file and even when the resulting .mp3 file is identical bit for bit...

(2) Truncation
Alpha 8 seems to truncate/leave out some samples when encoding.

I encoded "Thorns of Crimsion Death", Track 6 of Dissection's Storm of the Light's Bane, using Lame 3.90 alpha 7 (adding -X3 to bring it up to date) and alpha 8 (adding -b112 and -t) and both produced identical .mp3 files, except for a truncation....

For example, if you decode both files to .wav using Cool Edit 2000, and do a .wav compare with Exact Audio Copy you see that all of the samples are identical, except that alpha 8 has truncated (Cut-off) 1152 samples of music.

See the image below for this:



Someone should have Lame developers fix this truncation bug.....

RD

PS On a different topic the "fast" option does not seem to give me much more speed on my pentium 3... only about 33% faster when comparing:

--dm-preset fast standard
AND
--dm-preset standard
Dibrom
QUOTE
Originally posted by RD
I've been playing around with Lame 3.90 alpha 8 and I noticed some things:

(1) It's Slower 
Alpha 8 is slower than Alpha 7 even
when it encodes the same .wav file and even when the resulting .mp3 file is identical bit for bit...


Hrmm.. I'm not quite sure where the speed difference would come from. You are using 2 compiles from the same source? Dmitry's compile is often the fastest, if you used another compile it may not be quite as fast.

QUOTE
(2) Truncation 
Alpha 8 seems to truncate/leave out some samples when encoding.


You sure this isn't on the decoding side? Alpha 8 now compensates for the added delays normally associated with decoding (I think).. so the file could be longer with Alpha 7 and not 8 simply because of this.

QUOTE
I encoded "Thorns of Crimsion Death", Track 6 of Dissection's Storm of the Light's Bane, using Lame 3.90 alpha 7 (adding -X3 to bring it up to date) and alpha 8 (adding -b112 and -t) and both produced identical .mp3 files, except for a truncation.... 

For example, if you decode both files to .wav using Cool Edit 2000, and do a .wav compare with Exact Audio Copy you see that all of the samples are identical, except that alpha 8 has truncated (Cut-off) 1152 samples of music.


Great album btw biggrin.gif And this 1152 samples is from the issue I spoke of above of I'm almost sure. I think the VBR header is now used to determine the exact length of samples to skip to prevent adding silence to the file upon decoding or something.

Edit: Er.. misread the part about using cool edit to decode.. hrmm. I dunno what would be the situation here then really..

QUOTE
PS On a different topic the "fast" option does not seem to give me much more speed on my pentium 3... only about 33% faster when comparing:

--dm-preset fast standard 
AND
--dm-preset standard


Can you give some details on the exact compiles you are using for both versions (where you got them) as well as your processor speed? I'm not actually sure you will get that much more than a 33% increase (I haven't measured it on a faster processor in awhile) though.
Gabriel
I'm not sure if -t is really a good idea, but it's your choice.

Please try decoding with Lame and not CoolEdit. If Lame can decode without truncating, then the problem is from Syntrilium.
Perhaps it's not the case, but we need to know first.
PatchWorKs
Heyha guyz... LAME & COOLEDIT decode suck: switch to MAD instead !!!

biggrin.gif
auldyin
Agree 100% with Patchworks. MAD is the biz!!

auldyin

Edit

Me too about very slow alpha 8

I used Mitioks version, downloaded yesterday (6/11/01), and it took nearly 8 minutes to encode a 4 minute track.
RD
Originally posted by Gabriel

I'm not sure if -t is really a good idea, but it's your choice.
Please try decoding with Lame and not CoolEdit. If Lame can decode without truncating, then the problem is from Syntrilium.
Perhaps it's not the case, but we need to know first.


I only did -t to try to make the .mp3 files identical in CRCs (like Winzip CRC) but forgot that one will write alpha 7 inside the file and the other alpha 8 and hence ruin that plan...

I am at work now, but I will decode both with lame when I get home and post the results.


Originally posted by Dibrom
Can you give some details on the exact compiles you are using for both versions (where you got them) as well as your processor speed? I'm not actually sure you will get that much more than a 33% increase (I haven't measured it on a faster processor in awhile) though.

The compiles were:
(1) Alpha7 from win32lame.exe downloaded from Citay's website
(2) Alpha8 from Dmitry's (mitiok's) site, 11/06/2001 version.

The speed difference was something like (I'm going from memory):
3.5 x realtime with alpha 8 vs.
4.6 x realtime with alpha 7

My home built rig is:
1000 MHz PENTIUM III (133 Mhz Bus)
(cC0 Malay w/Thermalright Sk-6 w/
Artic Silver II and Sunon vapo fan
Quiet and cool: Load 41C, Mobo 31C)
Asus Cusl2-C (1007 final bios)
256 MB PC133 (Mushkin rev. 2)
60 GB IBM Deskstar (7200 RPM)
12x Liteon LTD122 DVD-ROM
20x Yamaha CRW2200e CD-Writer
ATI All-In-Wonder Radeon 32MB DDR
Sound Blaster Audigy Platinum
CWS DTT2200 5.1 Speakers
17" (15.8 VA) KDS AV-7T Trinitron
EPSON Stylus Photo 700
SAMSUNG ML-4500 Laser Printer
Epson Perfection 640U Scanner
3Com/USR Gaming Modem 56K V.90
MS IntelliMouse Optical mouse
Lian Li PC-61 Alluminum w/ 3 Fans
Windows 2000 & Windows ME & 98SE

BUT I RAN Windows 98SE for the lame alpha7/8 tests.

I just had to post the home-built baby I'm proud of biggrin.gif, even though my friends 1.4 Athlon blows it away... sad.gif
RD
Ok this truncation thing is getting weird again...

I decided to do things afresh.

I ripped track 6 from Dissections CD.

Saved it as 6.wav

Encoded it as --dm-preset xtreme -X3 with lame 3.90alpha7

Encoded it as --dm-preset xtreme -b 112 with lame
3.90alpha8

Decoded both mp3s with lame 3.90a7 and used EAC to compare; Result: the mp3 encoded with alpha8 was 0:00:00.026 longer...


Decoded both mp3s with lame 3.90a8 and used EAC to compare; Result: the mp3 encoded with alpha8 was
missing 576 samples and was 0:00:00.013 longer.



Obviously the alpha 7 and alpha 8 lame.exe --decoders are performing differently... either both are flawed or one is...
When I decode both mp3s with cool edit 2000 I get the same results as the 3.90alpha7 lame...

Btw alpha 8 is even slower than alpha 7 in this test:



RD
Dibrom
RD, could you provide a dump of both of those lines with the --verbose option specified? I won't be able to encode some stuff for the time being so it would be helpful if you could do that. Considering the fact that both of the files appear identical (except upon decoding) it's doubtful that some internal setting has been modified which is causing this slow down but who knows...
RD
Sure Dibrom,

I'd be willing to help... but actually i don't know how to do the verbose dump.

I mean, I know the commandline:

--dm-preset xtreme --verbose 6.wav 6.mp3

But verbose is so big/long in the dos box that a screen caputre will only get a small part of it (it scrolls so fast).

How do i capture it all to a .txt file?

--dm-preset xtreme --verbose 6.wav 6.mp3 info.txt

????

RD

PS I have to help a friend tonight (nimbda virus...) but when i get your instructions i'll do it tommorrow.

PS how is your special compile coming along?
Maybe we shall all have a treat by Christmas?
CiTay
> How do i capture it all to a .txt file?

Quite easy. Get "stderr" from here: http://www.teaser.fr/~amajorel/stderr/

Put it into your C:WindowsCommand directory. Then you can make a text file with the output like this:

"stderr lame --dm-preset xtreme --verbose 6.wav 6.mp3 >info.txt"


The text file will look a bit funny, because it includes every screen update of the LAME output. biggrin.gif But it's also good for "stderr lame --longhelp >longhelp.txt" etc...
mitiok
QUOTE
Originally posted by RD


The compiles were:
(1) Alpha7 from win32lame.exe downloaded from Citay's website
(2) Alpha8 from Dmitry's (mitiok's) site, 11/06/2001 version.



there are two different version in winlame, one is default and the second was compiled with special optimization for p2, p3, k7, and not fully tested

which one do you use?

i upload only default versions to my page
CiTay
> PS I have to help a friend tonight (nimbda virus...) but when i
> get your instructions i'll do it tommorrow.

The virus is called "Nimda"... Hint: Try to pronounce it backwards wink.gif
RD
QUOTE
Originally posted by mitiok



there are two different version in winlame, one is default and the second was compiled with special optimization for p2, p3, k7, and not fully tested

which one do you use?

i upload only default versions to my page


Concerning the winlame 3.90alpha7 I used the pentium 3 optimized version of lame.exe...

It is faster...

Is your lame11062001 alpha8 not optimized for pentium 3 then?
If it is optimized for p3 there is still a problem since alpha8 is slower than the p3 optimized alpha 7....

RD
mitiok
QUOTE
Originally posted by RD


Concerning the winlame 3.90alpha7 I used the pentium 3 optimized version of lame.exe...

It is faster...

Is your lame11062001 alpha8 not optimized for pentium 3 then?
If it is optimized for p3 there is still a problem since alpha8 is slower than the p3 optimized alpha 7....

RD


once again, on my page at this time i have only 'default compiles' with 'defaut optimization'.
these compiles have optimization for p3 but they also have optimization for other cpu types. so these compiles are slow but they should run on most cpu types.

i want to upload compile with optimization only for k6,k7,p2,p3,p4 in the future when beta/stable will be released. i think that it will be slower than version from win32lame, but it will run on k6 too. ('fast' version from win32lame crashes on k6
RD
Dibrom

Here is the "dump of both of those lines with the --verbose option specified..."

http://home.earthlink.net/~rad123b/lameinfo.zip

Much thanks to Citay for his help on the great stdeer utility!

Mitiok
I have aways been thankful for your compiles...
I guess, and correct me if i am wrong, alapha8 is slower than alpha7 because alpha8 is NOT optimized for pentium 3s...

I must go because an hour ago i dropped a microphone stand base on my index finer and the blood and the pain are bad...
I had to type this all with my left hand...

R "pray for my bleeding finger" D
sad.gif sad.gif sad.gif
mitiok
QUOTE
I have aways been thankful for your compiles...
I guess, and correct me if i am wrong, alapha8 is slower than alpha7 because alpha8 is NOT optimized for pentium 3s...


no

that compile of alpha7 from win32lame that you are using is faster than that compile of alpha8 from my page because they were compiled with different compiler's options
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.