You can download this from here: http://homepage.ntlworld.com/jfe1205/lame4.0a6.zip.
This is compiled from Takehiro's experimental branch so, BEWARE!! I've only made this available for people to try for fun, it's not ready for general consumption. It sounds reasonable, but it's main claim to fame is that it is about 4 - 5 times faster than the current encoder!
Please note, it's not likely that Takehiro is looking for any feedback at this time, but any comments may be of general interest.
Let me make this quite clear again, this is NOT for use for archival purposes, it's only to give an idea of the direction that LAME may be going.
Full Version: LAME 4.0 alpha 6
4 to 5 times faster? Damn! Gotta try this when I get home.
Just a little curious on what Takehiro's experimental branch will accomplish when it is ready other then speed. The same quality as the current recommended compile or will the quality be better?
Just a little curious on what Takehiro's experimental branch will accomplish when it is ready other then speed. The same quality as the current recommended compile or will the quality be better?
You bet I'll play.
Thanks for the release, John.
Thanks for the release, John.
jesus.
Its fast alright!!!
file size is also a little bigger:
lame3.9 @ alt preset standard was around 180k
lame4.0 @ alt preset standard is around 194k
With my really cheap speakers, I cant tell the difference between the two!!!
file size is also a little bigger:
lame3.9 @ alt preset standard was around 180k
lame4.0 @ alt preset standard is around 194k
With my really cheap speakers, I cant tell the difference between the two!!!
How many alpha branches of LAME is there? There's 3.90.3, 3.95 and now 4.0? How many of the features of 3.90.3 and 3.95 are incorporated into 4.0? What about -Z and -Y switches?
3.90.x - Hydrogenaudio Branch; based on version 3.90
3.94 - Next stable official LAME version
4 - Takehiro's new experimental lame branch, which will become the next generation some day
3.94 - Next stable official LAME version
4 - Takehiro's new experimental lame branch, which will become the next generation some day
LAME v4.0!!! Yea!!! I can't wait until I get home to try this out.
Hmm I wonder whether it's due to x86 specific optimizations (SSE, SSE2, 3DNow!, etc.) like Gogo uses.
Just encoded 700Mb of wav files (whole CD) with --alt-preset standard in 3 minutes 29 seconds !!!
It was going well over 22x
Encoded the same CD with lame3.90.2 and it took 22 minutes 48 seconds !!!!
Thats nearly 7 times faster
by the way, I have an xp1900+
It was going well over 22x
Encoded the same CD with lame3.90.2 and it took 22 minutes 48 seconds !!!!
Thats nearly 7 times faster
by the way, I have an xp1900+
Wonder why they start with alpha6 or 7, why not alpha1?
maybe we're just too late ? 
Just doing some comparison encodes right now. These results are on a wav file that is approximately 73 mins long. The performance improvements are amazing. No difference between alt-preset standard and alt-preset fast standard (giving practically identical results when binary compared so option does nothing).
lame --alt-preset standard Test.wav newlame.mp3
LAME version 4.0 MMX, 3DNow!(alpha 6, May 9 2003 16:14:24) (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Test.wav to newlame.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=5
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
169823/169827(100%)| 2:37/ 2:37| 2:37/ 2:37| 28.203x| 0:00
32 [ 825] %*
40 [ 1] *
48 [ 9] %
56 [ 11] %
64 [ 30] %
80 [ 675] %
96 [ 5055] %******
112 [ 16935] %********************
128 [ 28530] %%*********************************
160 [ 54157] %%%%**************************************************************
192 [ 29247] %%**********************************
224 [ 19122] %%**********************
256 [ 8940] %%*********
320 [ 6290] %%******
average: 170.7 kbps LR: 9829 (5.788%) MS: 159998 (94.21%)
lame --alt-preset fast standard Test.wav newfastlame.mp3
LAME version 4.0 MMX, 3DNow!(alpha 6, May 9 2003 16:14:24) (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Test.wav to newfastlame.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=5
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
169823/169827(100%)| 2:40/ 2:40| 2:40/ 2:40| 27.748x| 0:00
32 [ 825] %*
40 [ 1] *
48 [ 9] %
56 [ 11] %
64 [ 30] %
80 [ 675] %
96 [ 5055] %******
112 [ 16935] %********************
128 [ 28530] %%*********************************
160 [ 54157] %%%%**************************************************************
192 [ 29247] %%**********************************
224 [ 19122] %%**********************
256 [ 8940] %%*********
320 [ 6290] %%******
average: 170.7 kbps LR: 9829 (5.788%) MS: 159998 (94.21%)
lame392 --alt-preset standard Test.wav oldlame.mp3
LAME version 3.92 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Test.wav to oldlame.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
169824/169826(100%)| 15:24/ 15:24| 15:25/ 15:25| 4.7996x| 0:00
32 [ 825] %*
128 [ 22507] %%%%***************************
160 [ 49357] %%%%%%%%%%%%%%****************************************************
192 [ 40464] %%%%%%%%%%%%%%*****************************************
224 [ 27555] %%%%%%%%%%%%%%***********************
256 [ 18292] %%%%%%%%%%%**************
320 [ 10827] %%%%%%*********
average: 193.7 kbps LR: 44849 (26.41%) MS: 124978 (73.59%)
lame --alt-preset standard Test.wav newlame.mp3
LAME version 4.0 MMX, 3DNow!(alpha 6, May 9 2003 16:14:24) (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Test.wav to newlame.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=5
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
169823/169827(100%)| 2:37/ 2:37| 2:37/ 2:37| 28.203x| 0:00
32 [ 825] %*
40 [ 1] *
48 [ 9] %
56 [ 11] %
64 [ 30] %
80 [ 675] %
96 [ 5055] %******
112 [ 16935] %********************
128 [ 28530] %%*********************************
160 [ 54157] %%%%**************************************************************
192 [ 29247] %%**********************************
224 [ 19122] %%**********************
256 [ 8940] %%*********
320 [ 6290] %%******
average: 170.7 kbps LR: 9829 (5.788%) MS: 159998 (94.21%)
lame --alt-preset fast standard Test.wav newfastlame.mp3
LAME version 4.0 MMX, 3DNow!(alpha 6, May 9 2003 16:14:24) (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Test.wav to newfastlame.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=5
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
169823/169827(100%)| 2:40/ 2:40| 2:40/ 2:40| 27.748x| 0:00
32 [ 825] %*
40 [ 1] *
48 [ 9] %
56 [ 11] %
64 [ 30] %
80 [ 675] %
96 [ 5055] %******
112 [ 16935] %********************
128 [ 28530] %%*********************************
160 [ 54157] %%%%**************************************************************
192 [ 29247] %%**********************************
224 [ 19122] %%**********************
256 [ 8940] %%*********
320 [ 6290] %%******
average: 170.7 kbps LR: 9829 (5.788%) MS: 159998 (94.21%)
lame392 --alt-preset standard Test.wav oldlame.mp3
LAME version 3.92 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow! (ASM used), SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Test.wav to oldlame.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
169824/169826(100%)| 15:24/ 15:24| 15:25/ 15:25| 4.7996x| 0:00
32 [ 825] %*
128 [ 22507] %%%%***************************
160 [ 49357] %%%%%%%%%%%%%%****************************************************
192 [ 40464] %%%%%%%%%%%%%%*****************************************
224 [ 27555] %%%%%%%%%%%%%%***********************
256 [ 18292] %%%%%%%%%%%**************
320 [ 10827] %%%%%%*********
average: 193.7 kbps LR: 44849 (26.41%) MS: 124978 (73.59%)
there is no difference between the fast and none fast standard, because there is no vbr-old anymore. the formerly known vbr-mtrh is the only vbr code now.
VERYYYYYYYYYYYY FAAAAAAAAAAAAAAAAAAAAAAAAAAAST!!!
I hope quality its OK?!
First TEST...
CU
Bobby Black
I hope quality its OK?!
First TEST...
CU
Bobby Black
This is interesting. I could use high speed + high quality to transcode my mpcs for my portable. If the quality is mediocre... no harm done.
How alpha is this version? Should we rather ensure a proper 3.94 final or start testing v4? Would testing at this early stage be usefull?
How alpha is this version? Should we rather ensure a proper 3.94 final or start testing v4? Would testing at this early stage be usefull?
QUOTE(Gecko @ May 10 2003 - 12:44 AM)
How alpha is this version? Should we rather ensure a proper 3.94 final or start testing v4? Would testing at this early stage be usefull?
IMHO, 4.0alpha6 is for quick test only, no harm if doing something not require quality.
It's really amazing fast, but I'll still wait for the official 3.94.
The --nogap option is nice, but I am unclear on what this means:
Note: Disabling VBR Xing/Info tag since it interferes with --nogap
What does the VBR Xing/Info tag do for me? Will I miss it?
Is there a distinction between --preset standard and --alt-preset standard?
Note: Disabling VBR Xing/Info tag since it interferes with --nogap
What does the VBR Xing/Info tag do for me? Will I miss it?
Is there a distinction between --preset standard and --alt-preset standard?
The speed improvements are not because of x86 assembly but mainly because of Takehiro's brain.
(btw think about how fast a Gogo based on this could be!)
(btw think about how fast a Gogo based on this could be!)
does lame 4.0 also include gabriel's development (3.94...) or are 4.0 and 3.94 two independent developments ?
Ha ha ha on my machine it encodes even faster than MPC, at 7x-8x and even 9x 
It only lacks of gapless playback and blah blah blah. I've also noticed that the algorithm used is q3 instead of q2 (did Takehiro tweak q3?)
It only lacks of gapless playback and blah blah blah. I've also noticed that the algorithm used is q3 instead of q2 (did Takehiro tweak q3?)
Speed is excellent (ca 15x on my Athlon TB 1333).
A quick test revealed problems with an Autechre track (no real surprise there) titled "Eidetic Casein". Right at the beginning there are some extremely short bursts of noise which I'd expect to cause smearing. However what first caught my attention was the slightly sound in the background (that "ding - ding - ding"). In the original the frequency is stable, in the mp3 it has a vibrato. No need to abx, damn obvious. My mother also noticed it right away over my pc speakers. The noisy reverb of the ding-ding sound is also shorter in the mp3.
First 6 seconds FLACed
edit: 3.90.2 aps sounds much better; would need abx for which I have no time now. Also worth mentioning are the bitrates for the short sample (no typo):
3.90.2 - 161
4.0a6 - 116
A quick test revealed problems with an Autechre track (no real surprise there) titled "Eidetic Casein". Right at the beginning there are some extremely short bursts of noise which I'd expect to cause smearing. However what first caught my attention was the slightly sound in the background (that "ding - ding - ding"). In the original the frequency is stable, in the mp3 it has a vibrato. No need to abx, damn obvious. My mother also noticed it right away over my pc speakers. The noisy reverb of the ding-ding sound is also shorter in the mp3.
First 6 seconds FLACed
edit: 3.90.2 aps sounds much better; would need abx for which I have no time now. Also worth mentioning are the bitrates for the short sample (no typo):
3.90.2 - 161
4.0a6 - 116
The quality seems to have taken a turn for the worse, at least in --preset standard using the fatboy sample. This is a super earley alpha, so this is to be expected though. I have very high hopes for v4.0 when it matures. FAST is an understatement!
whoah fast speeds 
even on aps. I haven't tested lame since 3.94 alpha something and I have to say this is amazingly fast! LAME is definitely cleaning up the slow speeds, and lag on machines when encoding is gone.
4.77 mb - for the new alpha
4.37 mb - for 3.90.2
both are --alt-preset standard this makes me":angry:" because it is CONSIDERABLY higher, this makes me angry as either lames new compile is made to trick you into thinking its fast and more accurate while it could just randomly be picking bitrates and stumbling across encodes.
3.90.2 - 19 -128, 25 -160, 28 -192, 14 -224, 8 -256, 6 -320 average bitrate: 189
3.4 alpha whatever (the one you just linked
) - 83 -192, 4 -224, 3 - 256, 9 -320
...used EncSpot as always!!!
My final guess (or conclusion either way you look at it)- It seems that LAME's speeds are a fluke. Sure they are significantly faster than 3.90.2 and may foul many of you but, comparing bitrates shows that its more like a non-variable bitrate, as most of them are 192. And you already get good speeds with 192 on 3.90.2. In other words, 3.4's aps ripping is a RIP and stick with 3.90.2 because I think thats the best compile we'll EVER find of LAME.
Lame 4.0 alpha whatever's alt-preset standard is a cheap, defective 192 kbps encode setting practically! If you want 192 or GOOD aps stick with --alt-preset standard.
even on aps. I haven't tested lame since 3.94 alpha something and I have to say this is amazingly fast! LAME is definitely cleaning up the slow speeds, and lag on machines when encoding is gone. 4.77 mb - for the new alpha
4.37 mb - for 3.90.2
both are --alt-preset standard this makes me":angry:" because it is CONSIDERABLY higher, this makes me angry as either lames new compile is made to trick you into thinking its fast and more accurate while it could just randomly be picking bitrates and stumbling across encodes.
3.90.2 - 19 -128, 25 -160, 28 -192, 14 -224, 8 -256, 6 -320 average bitrate: 189
3.4 alpha whatever (the one you just linked
) - 83 -192, 4 -224, 3 - 256, 9 -320...used EncSpot as always!!!
My final guess (or conclusion either way you look at it)- It seems that LAME's speeds are a fluke. Sure they are significantly faster than 3.90.2 and may foul many of you but, comparing bitrates shows that its more like a non-variable bitrate, as most of them are 192. And you already get good speeds with 192 on 3.90.2. In other words, 3.4's aps ripping is a RIP and stick with 3.90.2 because I think thats the best compile we'll EVER find of LAME.
Lame 4.0 alpha whatever's alt-preset standard is a cheap, defective 192 kbps encode setting practically! If you want 192 or GOOD aps stick with --alt-preset standard.
Used --alt-preset fast extreme for encoding both files.
Lame 4.0 alpha6:
MPEG-1 Layer 3
286 Kbit VBR (with Xing header)
44.1 Khz Joint stereo
Artist: Mazzy Star - Tell Me Now
File size 8.983MB
Encoding time for this was approx: 19 seconds (Info from external compressor window)
Lame3.93:
MPEG-1 Layer 3
256 Kbit VBR (with Xing header)
44.1 Khz Joint stereo
Artist: Mazzy Star - Tell Me Now
Filesize: 8.063MB
Encoding time for this was approx: 19 seconds (Info from external compressor window)
Maybe should have used extreme or standard for both (tomorrow). In any case, they both sound passable, but it is late here and music is not very loud right now. Not much speed difference on this machine using this particular preset. Filesizes are little different and so are bitrates. Bitrate # from Media Center, which I think takes an overall average for the bitrates.
Pretty good though for an alpha version.
edit: cleaned pasted info up
Lame 4.0 alpha6:
MPEG-1 Layer 3
286 Kbit VBR (with Xing header)
44.1 Khz Joint stereo
Artist: Mazzy Star - Tell Me Now
File size 8.983MB
Encoding time for this was approx: 19 seconds (Info from external compressor window)
Lame3.93:
MPEG-1 Layer 3
256 Kbit VBR (with Xing header)
44.1 Khz Joint stereo
Artist: Mazzy Star - Tell Me Now
Filesize: 8.063MB
Encoding time for this was approx: 19 seconds (Info from external compressor window)
Maybe should have used extreme or standard for both (tomorrow). In any case, they both sound passable, but it is late here and music is not very loud right now. Not much speed difference on this machine using this particular preset. Filesizes are little different and so are bitrates. Bitrate # from Media Center, which I think takes an overall average for the bitrates.
Pretty good though for an alpha version.
edit: cleaned pasted info up
hehe! yeah its kind of hard to compare with two different settings 
but, i'd be interested in your results when you re-test it
but, i'd be interested in your results when you re-test it
QUOTE(feces1223 @ May 9 2003 - 11:56 PM)
hehe! yeah its kind of hard to compare with two different settings but, i'd be interested in your results when you re-test it
but, i'd be interested in your results when you re-test it What are you talking about?
QUOTE(MachineHead @ May 9 2003 - 09:01 PM)
QUOTE(feces1223 @ May 9 2003 - 11:56 PM)
hehe! yeah its kind of hard to compare with two different settings but, i'd be interested in your results when you re-test it
but, i'd be interested in your results when you re-test it What are you talking about?
you said that its better to test with 2 of the same either both extreme or both standard than have two different bitrates tested. I just meant that its incomparible if you have two different settings to look at back to back so in other words ( i like to say that) i was agreeing
We need to petition Dibrom back for -alt preset tuning & tweaks once 4.0 is released 
.
.
LAME 3.90 + LAME 3.94 + LAME 4 = LAME 5
How about creating another LAME 5 branch,
compile all three branches of LAME into one (3-in-one) B)
Remove all the quality string -q 0 to 9
and change it to
-fast = LAME 4
-med(ium) = LAME 3.94
-hi(gh) = LAME 3.90
must be kidding?
How about creating another LAME 5 branch,
compile all three branches of LAME into one (3-in-one) B)
Remove all the quality string -q 0 to 9
and change it to
-fast = LAME 4
-med(ium) = LAME 3.94
-hi(gh) = LAME 3.90
must be kidding?
QUOTE
For High Quality backups:
Ripper: Christoph Schmelnik's Digital Audio Copy - WinDAC
- Analog, SB Live
- Normalize 100%
Encoder: Xing X3Enc
-128kbps
-ID3v2 tags
Ripper: Christoph Schmelnik's Digital Audio Copy - WinDAC
- Analog, SB Live
- Normalize 100%
Encoder: Xing X3Enc
-128kbps
-ID3v2 tags
Long time not writing here, but it seems this is time to do so....
First, DO NOT COMPLAIN ABOUT LAME4. LAME4 IS COMPLETELY PRE ALPHA STAGE.
I am currently focussing on developping LAME4. I want LAME4 to be completely brand new encoder.
Gabriel is doing good job on official LAME 3.94 tuning and I only advise on some point for LAME3.94.
There were LAME4 alpha1-6. But all of them are completely experimental.
Still fatal bugs are arround (for some songs, it goes infinite loop or segmentation fault.)
Some switches(-k or so) are not tested at all.
VBR code is completely rewritten, based on vbr-new and vbr-old is removed. But there's still some bugs, rooms to improve speed, and so on. And, note that almost all the VBR presets are broken.
Psymodel is very optimized and fixed many odd "features"(not bug:p) based on nspsytune and gpsycho is removed. There's some room to improve, but I feel some barrier to improve. My "goal" is to build completely new psymodel. I am checking nspsytune2 code and I think it's hard but I can do.
Intensity stereo is "must" item before public testing, but it is completely new code and it takes long time to finish implementing.
ABR/CBR noise shaping code are almost finished. But bit resovoir code need to be tuning for short blocks and lower bitrate. This tuning will start after implementing i-stereo.
Assembler code from GoGo is "should" item before official LAME4 release. Currently no new asm-code are ported from GOGO. From this point of view, it is same since LAME3.9x.
Many many things are planned to do, and it takes long time to complete them.
And, Last of all, I repeat the caution.
LAME4 IS COMPLETELY PRE ALPHA STAGE.
LAME4 IS COMPLETELY PRE ALPHA STAGE.
LAME4 IS COMPLETELY PRE ALPHA STAGE.
First, DO NOT COMPLAIN ABOUT LAME4. LAME4 IS COMPLETELY PRE ALPHA STAGE.
I am currently focussing on developping LAME4. I want LAME4 to be completely brand new encoder.
Gabriel is doing good job on official LAME 3.94 tuning and I only advise on some point for LAME3.94.
There were LAME4 alpha1-6. But all of them are completely experimental.
Still fatal bugs are arround (for some songs, it goes infinite loop or segmentation fault.)
Some switches(-k or so) are not tested at all.
VBR code is completely rewritten, based on vbr-new and vbr-old is removed. But there's still some bugs, rooms to improve speed, and so on. And, note that almost all the VBR presets are broken.
Psymodel is very optimized and fixed many odd "features"(not bug:p) based on nspsytune and gpsycho is removed. There's some room to improve, but I feel some barrier to improve. My "goal" is to build completely new psymodel. I am checking nspsytune2 code and I think it's hard but I can do.
Intensity stereo is "must" item before public testing, but it is completely new code and it takes long time to finish implementing.
ABR/CBR noise shaping code are almost finished. But bit resovoir code need to be tuning for short blocks and lower bitrate. This tuning will start after implementing i-stereo.
Assembler code from GoGo is "should" item before official LAME4 release. Currently no new asm-code are ported from GOGO. From this point of view, it is same since LAME3.9x.
Many many things are planned to do, and it takes long time to complete them.
And, Last of all, I repeat the caution.
LAME4 IS COMPLETELY PRE ALPHA STAGE.
LAME4 IS COMPLETELY PRE ALPHA STAGE.
LAME4 IS COMPLETELY PRE ALPHA STAGE.
QUOTE
Intensity stereo is "must" item before public testing, but it is completely new code and it takes long time to finish implementing.
Here my alarm bell rang. Please make sure this doesn't destroy Dolby Surround (2) recordings/encodings. Though current Lame is not perfect in maintaining this, it does it in a decent manner. Or you could even tweak the new encoder to specifically take care of it, as most (really!) music is DS encoded!
QUOTE(DarkAvenger @ May 9 2003 - 11:13 PM)
QUOTE
Intensity stereo is "must" item before public testing, but it is completely new code and it takes long time to finish implementing.
Here my alarm bell rang. Please make sure this doesn't destroy Dolby Surround (2) recordings/encodings. Though current Lame is not perfect in maintaining this, it does it in a decent manner. Or you could even tweak the new encoder to specifically take care of it, as most (really!) music is DS encoded!
Don't worry.
The lack of intensity stereo is the main reason why fhg is better than lame at <128kbps. It'll be an additional feature and is not supposed to replace the other stereo modes.
Original Wave = Avril Lavigne - Sk8er Boi
my processor is P4 1.4 GHz
Summary
why there is no SSE2 opt.?????????
and too many j-s
QUOTE
E:\>lame4 --preset standard -Z -b 128 "t.wav" "lame4.mp3"
LAME version 4.0 MMX, 3DNow!(alpha 6, May 9 2003 16:14:24) (http://www.mp3dev
rg/)
CPU features: i387, MMX (ASM used), SIMD, SIMD2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding t.wav to lame4.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=5
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
7832/7835 (100%)| 0:29/ 0:29| 0:29/ 0:29| 6.9610x| 0:00
32 [ 51] %
128 [ 261] %***
160 [ 331] %%***
192 [ 278] %***
224 [ 630] %********
256 [1373] %%%****************
320 [4911] %%%%%%************************************************************
average: 281.5 kbps LR: 942 (12.02%) MS: 6893 (87.98%)
E:\>lame394 --preset standard -Z -b 128 "t.wav" "lame394.mp3"
LAME version 3.94 MMX (alpha 13, Apr 20 2003 18:47:06) (http://www.mp3dev.org/
warning: alpha versions should be used for testing only
CPU features: i387, MMX (ASM used), SIMD, SIMD2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding t.wav to lame394.mp3
Encoding as 44.1 kHz VBR(q=4) j-stereo MPEG-1 Layer III (ca. 10x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
7832/7834 (100%)| 1:11/ 1:11| 1:11/ 1:11| 2.8740x| 0:00
32 [ 53] %*
128 [ 96] %*
160 [ 261] %%****
192 [1621] %%%%%%%%%%%%%%%%%%%***************
224 [3209] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
256 [1749] %%%%%%%%%%%%%%%%%%******************
320 [ 846] %%%%%%%%%%%*******
average: 230.3 kbps LR: 4246 (54.19%) MS: 3589 (45.81%)
E:\>lame --alt-preset standard "t.wav" "lame390.mp3"
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), SIMD, SIMD2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding t.wav to lame390.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
7832/7835 (100%)| 0:52/ 0:52| 0:52/ 0:52| 3.8970x| 0:00
32 [ 53] %*
128 [ 65] %*
160 [ 230] %*****
192 [ 809] %%%%%%%%%**********
224 [1520] %%%%%%%%%%%%%%%%%%%%%%**************
256 [2306] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%******************
320 [2852] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
average: 261.1 kbps LR: 4863 (62.07%) MS: 2972 (37.93%)
E:\>lame --alt-preset fast extreme -q 3 "t.wav" "lame390fastex.mp3"
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), SIMD, SIMD2
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding t.wav to lame390fastex.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
7832/7835 (100%)| 0:40/ 0:40| 0:40/ 0:40| 5.0869x| 0:00
32 [ 53] %
128 [ 115] %**
160 [ 228] %****
192 [ 550] %%%%*******
224 [1237] %%%%%%%%%%%%%%*********
256 [2034] %%%%%%%%%%%%%%%%%%%%%%%%**************
320 [3618] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%****************
average: 269.8 kbps LR: 5022 (64.10%) MS: 2813 (35.90%)
LAME version 4.0 MMX, 3DNow!(alpha 6, May 9 2003 16:14:24) (http://www.mp3dev
rg/)
CPU features: i387, MMX (ASM used), SIMD, SIMD2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding t.wav to lame4.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=5
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
7832/7835 (100%)| 0:29/ 0:29| 0:29/ 0:29| 6.9610x| 0:00
32 [ 51] %
128 [ 261] %***
160 [ 331] %%***
192 [ 278] %***
224 [ 630] %********
256 [1373] %%%****************
320 [4911] %%%%%%************************************************************
average: 281.5 kbps LR: 942 (12.02%) MS: 6893 (87.98%)
E:\>lame394 --preset standard -Z -b 128 "t.wav" "lame394.mp3"
LAME version 3.94 MMX (alpha 13, Apr 20 2003 18:47:06) (http://www.mp3dev.org/
warning: alpha versions should be used for testing only
CPU features: i387, MMX (ASM used), SIMD, SIMD2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding t.wav to lame394.mp3
Encoding as 44.1 kHz VBR(q=4) j-stereo MPEG-1 Layer III (ca. 10x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
7832/7834 (100%)| 1:11/ 1:11| 1:11/ 1:11| 2.8740x| 0:00
32 [ 53] %*
128 [ 96] %*
160 [ 261] %%****
192 [1621] %%%%%%%%%%%%%%%%%%%***************
224 [3209] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
256 [1749] %%%%%%%%%%%%%%%%%%******************
320 [ 846] %%%%%%%%%%%*******
average: 230.3 kbps LR: 4246 (54.19%) MS: 3589 (45.81%)
E:\>lame --alt-preset standard "t.wav" "lame390.mp3"
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), SIMD, SIMD2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding t.wav to lame390.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
7832/7835 (100%)| 0:52/ 0:52| 0:52/ 0:52| 3.8970x| 0:00
32 [ 53] %*
128 [ 65] %*
160 [ 230] %*****
192 [ 809] %%%%%%%%%**********
224 [1520] %%%%%%%%%%%%%%%%%%%%%%**************
256 [2306] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%******************
320 [2852] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
average: 261.1 kbps LR: 4863 (62.07%) MS: 2972 (37.93%)
E:\>lame --alt-preset fast extreme -q 3 "t.wav" "lame390fastex.mp3"
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), SIMD, SIMD2
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding t.wav to lame390fastex.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
7832/7835 (100%)| 0:40/ 0:40| 0:40/ 0:40| 5.0869x| 0:00
32 [ 53] %
128 [ 115] %**
160 [ 228] %****
192 [ 550] %%%%*******
224 [1237] %%%%%%%%%%%%%%*********
256 [2034] %%%%%%%%%%%%%%%%%%%%%%%%**************
320 [3618] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%****************
average: 269.8 kbps LR: 5022 (64.10%) MS: 2813 (35.90%)
my processor is P4 1.4 GHz
Summary
QUOTE
LAME Settings speed (X) bitrate (kbps) m/s stereo (%)
3.90.3 standard 3.897 261.1 37.93
3.90.3 fast extreme 5.0869 269.8 35.90
3.94.a14 standard 2.874 230.3 45.81
4.a6 standard 6.961 281.5 87.98
1.15r (MPC) standard 9.12 181.1
gt3b1 (OGG) -q 5 5.3846 189.6
3.90.3 standard 3.897 261.1 37.93
3.90.3 fast extreme 5.0869 269.8 35.90
3.94.a14 standard 2.874 230.3 45.81
4.a6 standard 6.961 281.5 87.98
1.15r (MPC) standard 9.12 181.1
gt3b1 (OGG) -q 5 5.3846 189.6
why there is no SSE2 opt.?????????
and too many j-s
QUOTE(tigre @ May 9 2003 - 11:50 PM)
The lack of intensity stereo is the main reason why fhg is better than lame at <128kbps.
GoGo 3 sounds better to me at lower bitrate when forced m/s is used............but GoGo has more "ring ring" effect while "hiss" on FhG
QUOTE(kotrtim @ May 10 2003 - 12:06 AM)
Original Wave = Avril Lavigne - Sk8er Boi
my processor is P4 1.4 GHz
Summary
LAME Settings speed (X) bitrate (kbps) m/s stereo (%)
3.90.3 standard 3.897 261.1 37.93
3.90.3 fast extreme 5.0869 269.8 35.90
3.94.a14 standard 2.874 230.3 45.81
4.a6 standard 6.961 281.5 87.98
1.15r (MPC) standard 9.12 181.1
gt3b1 (OGG) -q 5 5.3846 189.6
why there is no SSE2 opt.?????????
and too many j-s
my processor is P4 1.4 GHz
Summary
QUOTE
LAME Settings speed (X) bitrate (kbps) m/s stereo (%)
3.90.3 standard 3.897 261.1 37.93
3.90.3 fast extreme 5.0869 269.8 35.90
3.94.a14 standard 2.874 230.3 45.81
4.a6 standard 6.961 281.5 87.98
1.15r (MPC) standard 9.12 181.1
gt3b1 (OGG) -q 5 5.3846 189.6
why there is no SSE2 opt.?????????
and too many j-s
Is your computer ok? My P4 2,533GHz 3.90.2 -aps (without -Z) runs on 4,5-5x and 4.00a6 speed was almost 6 times faster.
I ripped a few tracks with 3.90.3 and 4alpha6 and there were no obvious differences. I'm sure in the morning I'll find some problem spots, but overall it was quite listenable. I can't wait for stable builds.
QUOTE(kotrtim @ May 10 2003 - 01:06 AM)
why there is no SSE2 opt.?????????
and too many j-s
and too many j-s
Maybe because, like Takehiro said, this is a pre-alpha, hence not feature complete or even stable.
Whoa that is a lot of stuff Takehiro is going to do, and if he is going to optimise Lame4 like Gogo, is it possible that it'll be faster to encode a CD in mp3 than to boot a computer? I'm looking forward to it!
It sounds reasonable even though it's a pre-alpha version and the speed is amazing! I can't believe people already cuttin' on it saying it's a regression in quality bla bla bla... hello?!
Interesting to hear that there's LOTS of improvements to be made! HEh he heh..! Takko, you da man!
Interesting to hear that there's LOTS of improvements to be made! HEh he heh..! Takko, you da man!
Did a little more tinkering this morning. Some results...
Using --alt-preset extreme
Time to encode format mm:ss
4.0 alpha 6:
Time to encode - 1:41
File size - 15.479MB
3.93:
Time to encode - 1:22
File size - 11.294MB
3.90.2
Time to encode - 1:30
File size - 11.633MB
Using 192CBR
4.0 alpha 6:
Time to encode - 2:25
File size - 9.510MB
3.93:
Time to encode - 00:23
File size 9.510MB
3.90.2:
Time to encode - 00:22
File size - 9.510MB
Obviously this isn't very scientific, but it shows there are some areas where the older encoders have significant speed advantage over this alpha. And that should be expected at this point I'd think.
For just downright fast encoding, the fast addition when using the alt presets works pretty good. Kind of a personal thing I suppose.
I'm looking forward to seeing where this will go.
Using --alt-preset extreme
Time to encode format mm:ss
4.0 alpha 6:
Time to encode - 1:41
File size - 15.479MB
3.93:
Time to encode - 1:22
File size - 11.294MB
3.90.2
Time to encode - 1:30
File size - 11.633MB
Using 192CBR
4.0 alpha 6:
Time to encode - 2:25
File size - 9.510MB
3.93:
Time to encode - 00:23
File size 9.510MB
3.90.2:
Time to encode - 00:22
File size - 9.510MB
Obviously this isn't very scientific, but it shows there are some areas where the older encoders have significant speed advantage over this alpha. And that should be expected at this point I'd think.
For just downright fast encoding, the fast addition when using the alt presets works pretty good. Kind of a personal thing I suppose.
I'm looking forward to seeing where this will go.
QUOTE(askoff @ May 10 2003 - 01:09 AM)
Is your computer ok? My P4 2,533GHz 3.90.2 -aps (without -Z) runs on 4,5-5x and 4.00a6 speed was almost 6 times faster.
3.90 with -Z is around 4x that's ok but lame4 is twice faster only 6x
GoGo3 192 kbps mmx/3dnow joint-stereo ~34x
FhG fastenc mmjb 7.5 192 kbps joint-stereo ~20x
my machine ok? i'm using xp... 256mb pc800
Huh stronger ringing with the ultimate commandline!!! Great improvement!
However, in Lame 4.0 --noshort command doesn't exist, so Bubblebath-II.0©®™ algorithm doesn't work at its full
EDIT: The ultimate commandline's purpose is to freak newbies so they avoid using r3mix-type commandlines (because the result is really catastrophic)
stronger ringing with the ultimate commandline!!! Great improvement!However, in Lame 4.0 --noshort command doesn't exist, so Bubblebath-II.0©®™ algorithm doesn't work at its full
EDIT: The ultimate commandline's purpose is to freak newbies so they avoid using r3mix-type commandlines (because the result is really catastrophic)
why don't LAME developers stop developing lame 3.9x and focus only on LAME 4?
QUOTE(kotrtim @ May 10 2003 - 04:46 AM)
QUOTE(askoff @ May 10 2003 - 01:09 AM)
Is your computer ok? My P4 2,533GHz 3.90.2 -aps (without -Z) runs on 4,5-5x and 4.00a6 speed was almost 6 times faster.
3.90 with -Z is around 4x that's ok but lame4 is twice faster only 6x
lame4.00a6 is 6x faster than lame3.00.2 so encoding speed is around 27-29x speed from normal play speed.
I should be more acurate next time.
QUOTE(alfa156 @ May 10 2003 - 05:49 AM)
why don't LAME developers stop developing lame 3.9x and focus only on LAME 4?
You should read Takehiros last post. I think after Lame 3.94 final all Lame developers will begin to develope Lame 4. But this is just reading between the lines of Takehiros last post and all other posts in this thread.
Judging from the time that has passed developing 3.94, developing 4.00 will take at least a year?
@John33: Do you think you could give a quick explaination of how to get the code for this branch in CVS?
QUOTE(alfa156 @ May 10 2003 - 09:49 PM)
why don't LAME developers stop developing lame 3.9x and focus only on LAME 4?
I think the quality control of 3.9x is better.
Takehiro want to do something else (speed, new code) but the fine tuning psymodel in 3.9x will have some feedback and the result will become good pratice to improve LAME4.
Thanks Takehiro.
Why does this alpha score only 3.6X on my PIII@500 with a simple -b192, while 3.90.2 does about 6.8X?
3.6X is about the same encoding speed of ap CBR 192 (always with 4.0a6), which is about 2.8X with 3.90.2...
3.6X is about the same encoding speed of ap CBR 192 (always with 4.0a6), which is about 2.8X with 3.90.2...
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.