john33
Jan 11 2004, 04:35
Available now at Rarewares. Highlights are:
QUOTE
LAME 3.95 January 11 2004
Gabriel Bouvigne:
- fixed lowpass values when using vbr with mono files
- faster quantization loops
- faster count_bits
- fixed a buffer requirement error in ACM codec
Takehiro TOMINAGA:
- fixed mpglib and other decoding support code to prevent the crash when invalid mp3 input
removed Layer I decoding support
use FastLog and IEEE 754 hack on PowerPC too (approx. 10 percent faster)
R.A.F.
Jan 11 2004, 04:39
Only 1 question: Does this new version of LAME work with the alt-presets? If not, the value for us users is not that big.
Gabriel
Jan 11 2004, 04:43
I have released it 5 minutes ago, so I am not totally sure that you have the very last files.
(Please grab the tarball from sourceforge to be sure)
john33
Jan 11 2004, 05:14
QUOTE(Gabriel @ Jan 11 2004, 10:43 AM)
I have released it 5 minutes ago, so I am not totally sure that you have the very last files.
(Please grab the tarball from sourceforge to be sure)
OK, just to be sure, I've done this, recompiled and uploaded again.
QUOTE(R.A.F. @ Jan 11 2004, 12:39 PM)
Only 1 question: Does this new version of LAME work with the alt-presets? If not, the value for us users is not that big.
They are probably included. Whether they
work correctly is another matter.
QUOTE(Garf @ Jan 11 2004, 12:22 PM)
QUOTE(R.A.F. @ Jan 11 2004, 12:39 PM)
Only 1 question: Does this new version of LAME work with the alt-presets? If not, the value for us users is not that big.
They are probably included. Whether they
work correctly is another matter.
That's why testing is needed.
If no testing happens 3.90.3 will still be the recommended version in 2006; it's as simple as that.
dev0
Althalus
Jan 11 2004, 05:39
Is this version going to be (systematically) thoroughly tested, or is the big task going to be delayed until v4?
note: Haven't followed development so don't know how advanced 3.95 is compared to the recomended releases
Big_Berny
Jan 11 2004, 05:40
Very good that you released a new stable version, so we can start testing.
Are the medium-presets included? Cause I want a preset with a bitrate around 160 for my portable!
Big_Berny
R.A.F.
Jan 11 2004, 05:42
QUOTE(dev0 @ Jan 11 2004, 12:38 PM)
If no testing happens 3.90.3 will still be the recommended version in 2006; it's as simple as that.
2006 ?! - Come on, donīt paint it all black in black.
Althalus
Jan 11 2004, 05:57
Offtopic: Garf happens to have posted 2006 posts just after Dev0's reply. It must be a sign.
john33
Jan 11 2004, 06:08
The standard range of presets is included, but they are the "Gabriel re-written" ones as in 3.94.x, not as Dibrom had them originally.
AstralStorm
Jan 11 2004, 06:39
They don't seem to have any special problems with standard music...
Of course, more testing is needed.
Well, you have to test it and report your results. If everybody just sits around waiting for somebody else to test it, nothing will happen at all. I'll throw my usual collection of samples at it later today, but that's nothing to justify a general recommendation. 3.90.3 is still the recommended/most tested version.
I have to admit that the idea of postponing the testing to 4 is tempting.
--preset medium is included.
Big_Berny
Jan 11 2004, 07:51
Thanx, dev0
Tomorrow I'll begin testing.
Big_Berny
yourtallness
Jan 11 2004, 08:03
Excuse me if I'm silly, but I don't understand the reluctance
to test new LAME versions... Don't get me wrong, v3.90.3 is just fine,
but does that mean that we will never need to look any further?
Isn't that like saying that "Let's not bother test-driving
Lancer Evo 8, 'cos 7 is already excellent!".
Sebastian Mares
Jan 11 2004, 08:20
I am glad that LAME development goes on!
Anyway, I will start testing 3.95 with some 80's Disco, Pink Floyd and Techno/Trance samples tomorrow.
I'm glad old frame count method is back, that saves me a lot of pain with trying to detect proper values from both new and old files.
Mitiok has also updated his binaries.
RIV@NVX
Jan 11 2004, 09:35
QUOTE(zZzZzZz @ Jan 11 2004, 04:31 PM)
I'm glad old frame count method is back, that saves me a lot of pain with trying to detect proper values from both new and old files.
Does it mean that gapless playback works properly again (compared to 3.94b)?
Sebastian Mares
Jan 11 2004, 09:41
QUOTE(RIV@NVX @ Jan 11 2004, 04:35 PM)
QUOTE(zZzZzZz @ Jan 11 2004, 04:31 PM)
I'm glad old frame count method is back, that saves me a lot of pain with trying to detect proper values from both new and old files.
Does it mean that gapless playback works properly again (compared to 3.94b)?
Yes.
so that's it? Will there be another stable release in the next month or do we have to wait another year or something (as usuall). Don't get me wrong, I'm very happy that there is finally another stable release available and I hope that this release will stop all the confusing about the different LAME versions
I think you guys should post the changes of 3.94 beta too since there wasn't any stable 3.94...
Edit: does --aps use "best huffman divide in the inner loop"? It says in the changelo that this improves the quality but his very slow...as for me, I rather like getting the best quality with best compression...so I wouldn't care if it takes a bit longer
mrfil13
Jan 11 2004, 10:05
Hi im about to start converting alot of songs to mp3, so i will give the new version a test, just a small question does the --vbr-new setting loose any quality over --vbr-old
Ive just tried a song with these settings and it sounded fine
-V 2 -h -m s -B 192 --vbr-new
are there any particular things that need testing, this was a metal hardcore song and came out well
Benjamin Lebsanft
Jan 11 2004, 10:19
QUOTE
Ive just tried a song with these settings and it sounded fine
-V 2 -h -m s -B 192 --vbr-new
the --presets need testing, not such homemade commandlines which will lead to lower quality...
Thanks to John, Gabriel and all others involved in the task of keeping Lame alive and updated.
/edit/ smile added.
odious malefactor
Jan 11 2004, 10:31
QUOTE(Benjamin Lebsanft @ Jan 11 2004, 08:19 AM)
QUOTE
Ive just tried a song with these settings and it sounded fine
-V 2 -h -m s -B 192 --vbr-new
the --presets need testing, not such homemade commandlines which will lead to lower quality...
Recommended Lame settingsHow to test (What is an ABX blind test?) 
mrfil13
Jan 11 2004, 11:23
Well i just tried the standard preset and the extreme, the only difference i could notice was the file size, thing is that ive tried lots of different settings, + the presets, but they all sound higher pitch than the original wav.
Benjamin Lebsanft
Jan 11 2004, 11:27
any proof ?
indybrett
Jan 11 2004, 11:39
Were there any changes from the 3.95 alpha, or was the 3.95a version just renamed to stable? Reason I ask is that I already did some personal listening tests with the 3.95a version.
mrfil13
Jan 11 2004, 11:43
These are 10mb files
(Removed by moderation, violating TOS #9)
The first bit seems to go up in pitch on the mp3 version, might just be my hearing but sounds higher pitched on the mp3
Gabriel
Jan 11 2004, 12:11
QUOTE
Were there any changes from the 3.95 alpha, or was the 3.95a version just renamed to stable?
No change impacting sound, except when using mono files with vbr.
QUOTE(mrfil13 @ Jan 11 2004, 06:43 PM)
The first bit seems to go up in pitch on the mp3 version, might just be my hearing but sounds higher pitched on the mp3
Quoting from our beloved
TOS:
QUOTE
Any statement about sound quality must be supported by the author responsible for such statements by a double blind listening test demonstrating that he can hear a difference, together with a test sample. Graphs, non-blind listening tests, subtracting two files and so on are definetely not considered as valid evidences of sound quality
Please back up your claims with ABX results otherwise you'll be warned a second time by the moderation.
rutra80
Jan 11 2004, 13:47
A week ago I wrote about a
problem with decoding an mp3 with Lame 3.94b. Lame 3.95 seems to decode it properly, but RazorLame returns an error after decoding. I tried to decode it in command-line first with Lame 3.93.1, and then with Lame 3.95. And this is what I saw:
3.93.1:
CODE
input: test.mp3 (44.1 kHz, 2 channels, MPEG-1 Layer III)
output: test.wav (16 bit, Microsoft WAVE)
skipping initial 1105 samples (encoder+decoder delay)
Frame# 20715/20715 192 kbps
3.95:
CODE
Input file is freeformat.
input: test.mp3 (44.1 kHz, 2 channels, MPEG-1 Layer III)
output: test.wav (16 bit, Microsoft WAVE)
skipping initial 1105 samples (encoder+decoder delay)
Frame# 20715/20710 192 kbps
Notice that 3.95 treats it as freeformat mp3 and decodes 20715 frames out of 20710...
Resulting wav is indentical to the one decoded with 3.93.1, but probably beacuse of that number of frames problem, RazorLame returns an error.
I'm pretty sure that structure of the mp3 I used is OK...
sony666
Jan 11 2004, 14:35
nice, big thanks L.A.M.E. team
QUOTE(sony666 @ Jan 11 2004, 09:47 PM)
Version from rarewarez crashed while encoding a file with --alt-preset fast standard
wasn't able to reproduce that, encodes just fine here (winxp, razorlame)
edit:
QUOTE
Body Count - Cop Killer.wav
ah, the gold old times...
funkyblue
Jan 11 2004, 15:05
Howdy,
John33, Will you please do a "LAME 3.95 Modified and with APE & Cuesheet support"
Cheers and Thanks,
Burgerings
Thanks Takehiro, Gabriel, Alexander and all the other (Dibrom, Frank, ...) who contributed to the lame project.
It is fascinating, that sometimes just a handfull gifted people beat any comercial competition.
I hope that this time enough testing is done to it. I think that the current situation in the HA community isn't any good with us recommending a version just by guessing. IMHO that contradicts any scientific aims, that we like to have in here.
c15zyx
Jan 11 2004, 15:44
Anyone have any problems accessing the "http://lame.sourceforge.net/download/download.html" page? I keep getting a 403. Can still access the files by going straight to sf.net/projects/lame tho.
AstralStorm
Jan 11 2004, 16:17
What are the limitations of the ACM work version (with Windows Media Player 9)?
rjamorim
Jan 11 2004, 16:28
You are so cheap, Gabriel. Releasing it just in time for my test
OK, so Lame 3.95 will be tested instead of 3.90.3.
I think, that is a good decision, rjamorim. So at least this gets some testing this way. Maybe we find a way to compare that with 3.90.3, too.
okay, i just tried encoding The Cure's "One Hundred Years" because it tended to bloat under 3.90.3 and 3.95 supposedly handles SFB-21 bloat better (according to the changelog)... here are the results:
3.90.3 took 58 seconds to encode, giving 235kbps average bitrate.
3.95 took 45 seconds to encode, giving 260kbps average bitrate.
260kbps!!! WTF? It was transparent under 3.90.3! I cannot ABX either one of them, but i'd gladly trade an extra 25% encoding time for a savings of ~1MB in filesize, wouldn't you?
chrisgeleven
Jan 11 2004, 17:19
I never figured out why a "stable" release is done when no real quality testing as been done on the alpha and beta versions. It makes it so confusing, especially when developers pick up the untested "stable" release while 3.90.3 is clearly the safer one to use at the time.
then why haven't you tested it, when it was beta? there has been a beta release.
I think that gabriel did some testing.
And why is using 3.90.3 safer? you can't claim a seatbelt to be safer if the other one wasn't tested as well. a car crash could prove you wrong...
EDIT: typo
indybrett
Jan 11 2004, 17:25
QUOTE(Jebus @ Jan 11 2004, 05:56 PM)
okay, i just tried encoding The Cure's "One Hundred Years" because it tended to bloat under 3.90.3 and 3.95 supposedly handles SFB-21 bloat better (according to the changelog)... here are the results:
3.90.3 took 58 seconds to encode, giving 235kbps average bitrate.
3.95 took 45 seconds to encode, giving 260kbps average bitrate.
260kbps!!! WTF? It was transparent under 3.90.3! I cannot ABX either one of them, but i'd gladly trade an extra 25% encoding time for a savings of ~1MB in filesize, wouldn't you?
Hmmmmm......
That is exactly the opposite of the tests I have done. Everything I have tested so far, everything, has had less bloating with 3.95.
Now I'm going to do some more tests to see if I can reproduce the results that you are seeing.
QUOTE(indybrett @ Jan 11 2004, 03:25 PM)
QUOTE(Jebus @ Jan 11 2004, 05:56 PM)
okay, i just tried encoding The Cure's "One Hundred Years" because it tended to bloat under 3.90.3 and 3.95 supposedly handles SFB-21 bloat better (according to the changelog)... here are the results:
3.90.3 took 58 seconds to encode, giving 235kbps average bitrate.
3.95 took 45 seconds to encode, giving 260kbps average bitrate.
260kbps!!! WTF? It was transparent under 3.90.3! I cannot ABX either one of them, but i'd gladly trade an extra 25% encoding time for a savings of ~1MB in filesize, wouldn't you?
Hmmmmm......
That is exactly the opposite of the tests I have done. Everything I have tested so far, everything, has had less bloating with 3.95.
Now I'm going to do some more tests to see if I can reproduce the results that you are seeing.
well, it is interesting to note that this particular track averages only around 223kbps with both 3.90.3 and 3.95 when using the "fast standard" profile, so this might be a problem with any tuning done to vbr-old since 3.90.
sony666
Jan 11 2004, 17:45
concerning SFB21 bitrate bloat, I tested with my known "bloaty" album 'Guns N' Roses - Appetite For Destruction'
3.90.3 aps, not replaygained
CODE
C:\_aurip>\util\lame --preset standard CDImage.wav cdimage_3903_aps.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 CDImage.wav to cdimage_3903_aps.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
123602/123604(100%)
32 [ 1010] %*
128 [ 971] %*
160 [ 7805] %%***********
192 [ 28935] %%%%%%%%%%%%%***********************************
224 [ 39914] %%%%%%%%%%%%%%%%%%%%%%%%%*****************************************
256 [ 32063] %%%%%%%%%%%%%%%%%%%%%*********************************
320 [ 12906] %%%%%%%%%%%***********
average: 228.5 kbps LR: 41322 (33.43%) MS: 82282 (66.57%)
Writing LAME Tag...done
3.95 aps, not replaygained
CODE
C:\_aurip>lame --preset standard CDImage.wav cdimage_395_aps.mp3
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding CDImage.wav to cdimage_395_aps.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
123602/123604(100%)
32 [ 1011] %*
96 [ 154] %
112 [ 338] %
128 [ 1727] %**
160 [ 18367] %%%%***********************
192 [ 46359] %%%%%%%%%%%%%%%***************************************************
224 [ 39411] %%%%%%%%%%%%%%%%*****************************************
256 [ 12466] %%%%%%%%**********
320 [ 3771] %%%%**
average: 205.3 kbps LR: 31195 (25.24%) MS: 92409 (74.76%)
Writing LAME Tag...done
ReplayGain: -12.6dB
3.90.3 aps, replaygained
CODE
C:\_aurip>\util\lame --preset standard --scale 0.4677 CDImage.wav cdimage_3903_a
ps_replaygained.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 CDImage.wav to cdimage_3903_aps_replaygained.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
123602/123604(100%)
32 [ 1013] %*
128 [ 2096] %***
160 [ 16252] %%%*********************
192 [ 44836] %%%%%%%%%%%%%%%%%%%%%*********************************************
224 [ 41438] %%%%%%%%%%%%%%%%%%%%%%%%%%***********************************
256 [ 13480] %%%%%%%%%%**********
320 [ 4489] %%%****
average: 207.8 kbps LR: 41318 (33.43%) MS: 82286 (66.57%)
Writing LAME Tag...done
3.95 aps, replaygained
CODE
C:\_aurip>lame --preset standard --scale 0.4677 CDImage.wav cdimage_395_aps_rep
aygained.mp3
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding CDImage.wav to cdimage_395_aps_replaygained.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
123602/123604(100%)
32 [ 1014] %*
96 [ 518] %
112 [ 398] %
128 [ 2102] %**
160 [ 24683] %%%%*************************
192 [ 56299] %%%%%%%%%%%%%%%%%*************************************************
224 [ 26046] %%%%%%%%%**********************
256 [ 9451] %%%%%%******
320 [ 3093] %%%*
average: 197.4 kbps LR: 31194 (25.24%) MS: 92410 (74.76%)
Writing LAME Tag...done
ReplayGain: -6.0dB
23kbps reduction (not Rgained) in 3.95.. thats substantial. excellent work
Rgaining reduces the difference as expected, some Ultra high Freq bloat stuff falls below ATH (correct me if I'm wrong there)
Madrigal
Jan 11 2004, 17:58
QUOTE(sony666 @ Jan 11 2004, 06:45 PM)
concerning SFB21 bitrate bloat, I tested with my known "bloaty" album 'Guns N' Roses - Appetite For Destruction'
-------------
23kbps reduction in 395.. thats substantial. excellent work
I note that with v3.95 qval=3 but with v3.90.3 qval=2. Could this have anything to do with the bitrate savings?
Regards,
Madrigal
sony666
Jan 11 2004, 18:00
3.95 q3 = 3.90 q2, as I read somewhere earlier
I will encode again with replaygain --scale factor, results should be much more similar then.
sony666
Jan 11 2004, 18:14
Sorry for posting again...
Edit: right Jebus, all LAME replaygain values have an offset of -6.0 dB...
How can I disable the LAME RG calculation (without disabling the whole lame tag)? I use --scale with album gain and don't want any future player to read that lame value.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please
click here.