HydrogenAudio

Lossy Audio Compression => MP3 => MP3 - General => Topic started by: tsnr on 2010-03-23 05:45:00

Title: lame 3.98.4, 3.99 alpha
Post by: tsnr on 2010-03-23 05:45:00
LAME 3.98.4
download (mediafire) (http://www.mediafire.com/file/thyk5eiyvfz/lame3.98.4.rar)

LAME 3.99 alpha 3
download (mediafire) (http://www.mediafire.com/file/hfzgjmwnmtl/lame3.99a3.rar)


Win32:
lame.exe - the command line encoder, used from the Windows command shell
lame_enc.dll - LAME encoding library, generally used with CD rippers, etc
lame.acm - windows acm codec.

x64:
lame64.exe
lame_enc64.dll
lame64.acm

Bundle compiled with Intel Compiler 11.1.060.

Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2010-03-23 06:35:54
LAME 3.98.4
download (mediafire) (http://www.mediafire.com/file/thyk5eiyvfz/lame3.98.4.rar)

LAME 3.99 alpha 3
download (mediafire) (http://www.mediafire.com/file/hfzgjmwnmtl/lame3.99a3.rar)


Win32:
lame.exe - the command line encoder, used from the Windows command shell
lame_enc.dll - LAME encoding library, generally used with CD rippers, etc
lame.acm - windows acm codec.

x64:
lame64.exe
lame_enc64.dll
lame64.acm

Bundle compiled with Intel Compiler 11.1.060.



scam?

(Edit: full quote to protect against possible edits by OP)
Title: lame 3.98.4, 3.99 alpha
Post by: tsnr on 2010-03-23 06:53:58
(http://pic8.ohpy.com/up/elbbs/2010/03/23/20808/2097969124/mid_lame3984.png)

(http://pic8.ohpy.com/up/elbbs/2010/03/23/20808/185070842/mid_lame64_3984.png)

(http://pic8.ohpy.com/up/elbbs/2010/03/23/20808/434366379/mid_lame399a3.png)

(http://pic8.ohpy.com/up/elbbs/2010/03/23/20808/238993681/lame64_399a3.png)




Title: lame 3.98.4, 3.99 alpha
Post by: Larson on 2010-03-23 06:58:53
Thank you so much  how can I get lame x64 to work with dbpoweramp? sorry for the noob question
Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2010-03-23 07:24:30
At HA the OP is noobier than you. Let's see if the OP provides support for the release.

EDIT

http://www.virustotal.com (http://www.virustotal.com) didn't find anything scary in the exe files. Only "Symantec 20091.2.0.41, 2010.03.23" thinks that the files are suspicous.
Title: lame 3.98.4, 3.99 alpha
Post by: TechVsLife on 2010-03-23 07:26:52
Thank you so much  how can I get lame x64 to work with dbpoweramp? sorry for the noob question

I believe that you can't use a 64 bit dll/exe from within a 32 bit program (dbpoweramp is 32-bit) -- at least not easily (in any case you probably wouldn't see advantages from the switching/thunking).  (The 64-bit release of dbpoweramp is supposed to be rel. 15 or so.)
  p.s. this is a pure guess but you might be able to hardcode and call a 64-bit cmd.exe batch using the cli encoder, but I doubt it would work b/c dbpoweramp interfaces with it and probably calls 32-bit cmd there (I haven't tried).
Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2010-03-23 07:32:33
I sent also the acm and dll files to virustotal. The results are the same as earlier. The files appear to be clean, except that Symantec found them suspicious.
Title: lame 3.98.4, 3.99 alpha
Post by: tsnr on 2010-03-23 08:07:29
I sent also the acm and dll files to virustotal. The results are the same as earlier. The files appear to be clean, except that Symantec found them suspicious.

I do not know, why are the results from Symantec's.




I'm using Avast Pro 4.8.1368 (vps: 100322-0), Windows XP x64 SP2.







Title: lame 3.98.4, 3.99 alpha
Post by: Bodhi on 2010-03-23 08:28:18
No problem with NOD32.
But I'll wait...
Title: lame 3.98.4, 3.99 alpha
Post by: PeterJvM on 2010-03-23 09:07:50
No problem with NOD32.
But I'll wait...


Very wise since on sourcefoge.net you can find this:
Latest LAME release: v3.98.3 (February 2010)
Title: lame 3.98.4, 3.99 alpha
Post by: Larson on 2010-03-23 09:21:31
it's untrue,on lame website and sourceforge.net is already present the 3.98.4 version

http://sourceforge.net/projects/lame/files/lame/ (http://sourceforge.net/projects/lame/files/lame/)
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-03-23 10:03:10
From changelog:

Quote
Robert Hegemann
Fix for Bugtracker item [ 2973877 ] A problem regarding the new drain code


But what a problem was??
Title: lame 3.98.4, 3.99 alpha
Post by: Bodhi on 2010-03-23 10:06:13
But what a problem was??

Quote
Hi,

I'll release LAME 3.98.4 soon, because of a bug in 3.98.3, which may result
in a malformed bitstream sometimes (mostly high bitrate CBR). (Bugs item #2973877)
Has anyone else something that needs to get fixed before a 3.98-branch release?

Ciao Robert
Title: lame 3.98.4, 3.99 alpha
Post by: GeSomeone on 2010-03-23 11:23:48
So now the smoke has cleared ... thanks for the heads-up (and the quick compile) tsnr.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-03-23 12:25:02
A full set of win 32 builds of 3.98.4 is now at Rarewares as is the 3.99a3 bundle.
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2010-03-23 13:03:59
Btw. I would welcome some feedback on the unicode filename problematic. Prior to 3.99, filenames with unicode characters, that are not represented in 8-bit code pages, didn't work with LAME. I hope that 3.99 solves it. It would be nice, if windows users with non-latin1 character code pages could test it.
Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2010-03-23 13:14:08
Regarding Rarewares, the server may not work correctly at the moment.

The addresses:
http://rarewares.org/ (http://rarewares.org)
http://www.rarewares.org/ (http://www.rarewares.org)
- do not open the home page. No error message is displayed. The browser window stays empty.

The addresses:
http://rarewares.org/index.php (http://rarewares.org/index.php)
http://www.rarewares.org/index.php (http://www.rarewares.org/index.php)
- work normally.

I tested this with Firefox, Opera and I.E. Can anyone else confirm the problem?
Title: lame 3.98.4, 3.99 alpha
Post by: Larson on 2010-03-23 13:26:15
I confirm the rarewares problem too!
Title: lame 3.98.4, 3.99 alpha
Post by: Bodhi on 2010-03-23 13:58:11
Same for me but I use this address (http://www.rarewares.org/mp3-lame-bundle.php)
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-03-23 14:06:14
So, what compile should I use? Posted by the topic starter or downloaded from rarewares? o.O
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-03-23 14:52:22
Regarding Rarewares, the server may not work correctly at the moment.

The addresses:
http://rarewares.org/ (http://rarewares.org)
http://www.rarewares.org/ (http://www.rarewares.org)
- do not open the home page. No error message is displayed. The browser window stays empty.

The addresses:
http://rarewares.org/index.php (http://rarewares.org/index.php)
http://www.rarewares.org/index.php (http://www.rarewares.org/index.php)
- work normally.

I tested this with Firefox, Opera and I.E. Can anyone else confirm the problem?

This should now be resolved, I think!
Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2010-03-23 14:58:09
It works now. Thanks.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-03-23 15:01:09
It works now. Thanks.

Thank you kindly.
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-03-23 15:58:20
Can someone tell me why I'm getting different audiostreams with compiles by tsnr and john33??

Quote
Differences found: 4389914 sample(s), starting at 2.1563265 second(s), peak: 0.0983066 at 149.9082993 second(s), 2ch


Also encoding is about 1.5x faster with tsnr's compile 

Parameters (foobar2000):

--silent -b 320 -q 0 --noreplaygain - %d
Title: lame 3.98.4, 3.99 alpha
Post by: dv1989 on 2010-03-23 16:44:20
Different compilers produce different code. Different code may perform computations slightly differently, producing slightly different results, and/or be faster.

Edit: After john33's post, I realised that I should have mentioned that any such differences are almost certainly infinitesimal.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-03-23 16:50:24
Can someone tell me why I'm getting different audiostreams with compiles by tsnr and john33??

Quote
Differences found: 4389914 sample(s), starting at 2.1563265 second(s), peak: 0.0983066 at 149.9082993 second(s), 2ch


Also encoding is about 1.5x faster with tsnr's compile 

Parameters (foobar2000):

--silent -b 320 -q 0 --noreplaygain - %d

As already mentioned, different compilers and compiler options will produce differing results, but I don't believe anyone yet has been able to hear a difference.

I'd love to know what the compiler options used were that make that compile 1.5 times faster.

Edit: Well, having just run tsnr's 32 bit compile on my development system (e4300 @ 3.0GHz, 4GB RAM, XP Pro SP3) there is virtually no difference in speed between that compile and my own. What system are you using to get 1.5x faster running?
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-03-23 17:36:54
Quote
different compilers and compiler options will produce differing results


But I thought that the same LAME version/parameters will result in absolutely the same stream
And now I wonder what the differences (absolute, not audible!) can be between streams produced by different compiles...

Quote
What system are you using to get 1.5x faster running?


Pentium 4 631 3,75 GHz (MMX, SSE3), 2Gb DDR2-667 RAM, XP Pro SP3 32bit
Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2010-03-23 17:41:20
It is important to minimize all external factors that may affect the encoding speed before making any conclusions.

Just a few days ago I compared the encoding speeds of two 3.98.2 compiles: the MS compile from http://lame.bakerweb.biz (http://lame.bakerweb.biz) and John's Intel compile from rarewares.

I used foobar2000 on XP SP3 for encoding a set of 50 various FLAC tracks. The destination folder was set to be on a separate drive. Foobar was set to use all four cores of my AMD Phenom II CPU. Before testing I disabled the virus scanner and closed all other programs. I encoded the complete set with both encoders twice in a row and noted only the latter runs in order to avoid differences that could be caused by cached file data.

The results:

Rarewares
Total encoding time: 1:04.188, 118.47x realtime

Bakerweb
Total encoding time: 1:23.828, 90.71x realtime
Title: lame 3.98.4, 3.99 alpha
Post by: lvqcl on 2010-03-23 17:43:55
WinXP 32bit. Core2 Duo E4600. lame -S --noreplaygain -b320 -q0.

rarewares:
Quote
Kernel Time  =    0.140 = 00:00:00.140 =  0%
User Time    =    30.156 = 00:00:30.156 =  98%
Process Time =    30.296 = 00:00:30.296 =  99%
Global Time  =    30.531 = 00:00:30.531 = 100%


tsnr:
Quote
Kernel Time  =    0.156 = 00:00:00.156 =  0%
User Time    =    23.875 = 00:00:23.875 =  98%
Process Time =    24.031 = 00:00:24.031 =  98%
Global Time  =    24.328 = 00:00:24.328 = 100%


1.25x faster.
Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2010-03-23 17:52:47
OK, I'll repeat the my test using the new 32-bit 3.98.4 compiles. I still have the test files ready for use. Give me a few minutes.


john33,

Regarding AMD vs Intel, do you think that your binaries favour Intel processors?
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2010-03-23 18:10:50
Interesting read:
Does Intel's compiler cripple AMD performance? (http://techreport.com/discussions.x/8547)
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-03-23 18:15:10
I just re-tested on a q6600 with 8GB and XP x64 and, again, the speed difference was minimal. My compiles use the /arch:IA32 command line option.
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-03-23 18:18:26
Everyone talks about the differences in performance but nobody cares, what is the difference between the output files and where it come from??
Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2010-03-23 18:48:45
The results using -V2 --noreplaygain. I forgot to mention in my above description that I also always deleted the resulting files before each new run so that the destination drive would be in about the same state.


tsnr's compile:

The first run: Total encoding time: 1:03.266, 120.19x realtime

The second run in a row: Total encoding time: 1:01.578, 123.49x realtime


john33's compile:

The first run: Total encoding time: 1:02.015, 122.62x realtime

The second run in a row: Total encoding time: 1:00.484, 125.72x realtime


On my PC john's compile was slighly faster, but the difference is not significant. It may be caused by anything.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-03-23 18:59:10
Everyone talks about the differences in performance but nobody cares, what is the difference between the output files and where it come from??

From the fact that different compilers produce different object code. In this particular case, I believe that the difference is mainly due the use of different compiler options. Changing the compiler options allowed me to generate a compile that produces an encoded mp3 that is more similar in characteristics, according to the histogram, to tsnr's compile. Basically, the results of math calculations vary slightly when using SSE, SSE2, SSE3, SSSE3, etc.

The differences in encoded files resulting from encoders generated with different compilers has long been discussed but, as I said, I don't believe anyone has ever claimed to hear a difference and that is all that matters.
Title: lame 3.98.4, 3.99 alpha
Post by: timcupery on 2010-03-23 20:38:45
does the audio stream itself differ between the two compiles? and by this I mean, if you decode both files to wav files and compare those, are the wav files bit-for-bit equal?
Title: lame 3.98.4, 3.99 alpha
Post by: dv1989 on 2010-03-23 20:45:40
See post #24.
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-03-23 20:45:49
Audio steams are different, so the wave files will be different too and they can not be "bit-for-bit equal".
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-03-23 21:33:14
Whether, or not, the decoded streams are identical is somewhat irrelevant. People are getting hung up on whether the encoded files are identical and, as has been said many times before, different compilers and compiler options will necessarily produce different encoded results. The only concern is whether, or not, that difference can be heard and, so far, no one has even attempted to claim that.

At the end of the day, take a wave file and encode it with a variety of different encoders - different codecs -  and each of them will lack a significant amount of data when compared with the original wave file. That is a given and no one would contest that. At the expense of repetition, the only issue is whether a difference can be heard under reasonable listening conditions.

If paranoia has truly set in, then use a lossless codec, otherwise demonstrate via testing that you can discern a difference. We are dealing with a lossy codec here! A lot of data is being thrown away and only when you can genuinely hear that something is lacking is there an issue!
Title: lame 3.98.4, 3.99 alpha
Post by: dv1989 on 2010-03-23 22:08:42
Quote
People are getting hung up on whether the encoded files are identical

I mean no offence to Steve, but he seems to be the only person who is concerned.
Title: lame 3.98.4, 3.99 alpha
Post by: Light-Fire on 2010-03-24 00:12:01
does the audio stream itself differ between the two compiles? and by this I mean, if you decode both files to wav files and compare those, are the wav files bit-for-bit equal?

Audio steams are different, so the wave files will be different too and they can not be "bit-for-bit equal".


We are talking LOSSY encoding here kids. It doesn't matter if the compiles differ and streams are not bit-for-bit equal. What counts is:

...whether, or not, that difference can be heard and, so far, no one has even attempted to claim that...

Title: lame 3.98.4, 3.99 alpha
Post by: saratoga on 2010-03-24 00:23:04
Audio steams are different, so the wave files will be different too and they can not be "bit-for-bit equal".


If you want bit for bit identical, you need to use lossless.  Lossy codecs use floating point values, which are only approximate.  Different compiles, different CPUs, different operating systems, etc can and do give different output.  Thats how computers are supposed to work

If you don't like it, don't use MP3.
Title: lame 3.98.4, 3.99 alpha
Post by: gottogo99 on 2010-03-24 01:47:19
Another question, for john33:  why are there two slightly different versions of lame.exe in the new 3.98.4?  The one with libsndfile is one minute newer and 5KB smaller.  Seems like they should be the same but I'm no programmer.
Title: lame 3.98.4, 3.99 alpha
Post by: Andavari on 2010-03-24 04:35:33
http://www.virustotal.com (http://www.virustotal.com) didn't find anything scary in the exe files. Only "Symantec 20091.2.0.41, 2010.03.23" thinks that the files are suspicous.

The Symantec scanner on VirusTotal tags allot of stuff as "Suspicious.insight" for some particular reason, even if it's deemed clean by all the other scanners.

I wonder if those "MediaFire" compiles were just taken from Rarewares (http://www.rarewares.org/) to begin with since LAME 3.98.4 is on Rarewares right now.
Title: lame 3.98.4, 3.99 alpha
Post by: viktor on 2010-03-24 08:46:54
sadly x64 is about 15% slower than the x86 built with asm optimizations. it would be great if we could take advantage of the advanced architecture sometime.

http://www.phoronix.com/data/img/results/m...910_final/4.png (http://www.phoronix.com/data/img/results/macosx106_ubuntu910_final/4.png)

xvid x64 is 20% faster than x86, x264 x64 is 15% faster, but that could be due to the lack of optimizations in the x86 version...
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-03-24 08:51:24
.....
I wonder if those "MediaFire" compiles were just taken from Rarewares (http://www.rarewares.org/) to begin with since LAME 3.98.4 is on Rarewares right now.

No, they weren't, they were made available during the night (my time) before I'd even begun to build them.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-03-24 09:01:38
Another question, for john33:  why are there two slightly different versions of lame.exe in the new 3.98.4?  The one with libsndfile is one minute newer and 5KB smaller.  Seems like they should be the same but I'm no programmer.

There are, in fact, three versions currently offered:

The standard build with the dll and the documentation, a modified, unofficial build that will accept flat wav input and the version that uses the libsndfile dll that accepts FLAC input in addition to the usual inputs. The option to compile against libsndfile libraries to extend the input file options has existed for many years. It recently became more useful as it now takes FLAC input, along with many others. The .exe files differ because the standard one uses the native file reading routines provided within LAME whereas the libsndfile version hands input file handling to the libsndfile-1.dll. For like-for-like input files, the output will be identical for all versions.
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-03-24 10:25:14
Ok, people. Now I see that really getting too worried about such negligible things  And it really looks like some kind of paranoia
But it was a metter of principle for me.
Well, now I understand where those differences come from (floating-point values, approximation, etc.), so they are absolutely inaudible (maybe you will find it ridiculous, but I even tried to ABX them  )
Thank you
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-03-24 10:41:22
...(maybe you will find it ridiculous, but I even tried to ABX them  )
Thank you

Not ridiculous at all, the best way to establish whether the differences matter.
Title: lame 3.98.4, 3.99 alpha
Post by: gottogo99 on 2010-03-24 11:16:54
There are, in fact, three versions currently offered:

The standard build with the dll and the documentation, a modified, unofficial build that will accept flat wav input and the version that uses the libsndfile dll that accepts FLAC input in addition to the usual inputs. The option to compile against libsndfile libraries to extend the input file options has existed for many years. It recently became more useful as it now takes FLAC input, along with many others. The .exe files differ because the standard one uses the native file reading routines provided within LAME whereas the libsndfile version hands input file handling to the libsndfile-1.dll. For like-for-like input files, the output will be identical for all versions.

Thanks for clearing that up.  I figured there was a reason.
Title: lame 3.98.4, 3.99 alpha
Post by: ZinCh on 2010-03-24 18:43:53
john33, thanks for all builds
Title: lame 3.98.4, 3.99 alpha
Post by: [JAZ] on 2010-03-24 21:52:21
sadly x64 is about 15% slower than the x86 built with asm optimizations. it would be great if we could take advantage of the advanced architecture sometime.

http://www.phoronix.com/data/img/results/m...910_final/4.png (http://www.phoronix.com/data/img/results/macosx106_ubuntu910_final/4.png)

xvid x64 is 20% faster than x86, x264 x64 is 15% faster, but that could be due to the lack of optimizations in the x86 version...



x86 Assembly code is usually unavailable with x64. It has to be converted either to x64 assembler (not really different, but the compiler won't accept x86 assembler for x64 by default) or use intrinsics, which is just a way to write assembly code in C language.

So, yes. The compile being slower may simply mean that it is not using optimizations.
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-03-26 10:08:37
Quote
LAME 3.98.4 modified to add float wav input
2010-03-23

Bundle compiled with Intel Compiler 11.1.054.
Download (277kB)



But why actually this version clips all samples higher than 1.000000 ?  I thought that if there are fp support it means all samples will be processed and encoded (like in OggEnc - there are no clipping with any peaks!)
Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2010-03-26 11:06:45
But why actually this version clips all samples higher than 1.000000 ?

The encoder doesn't do that when the input is in the floating point format. Assuming you actually tested the behavior, how did you decode the files and how did you verify the clipping?

Quote
I thought that if there are fp support it means all samples will be processed and encoded (like in OggEnc - there are no clipping with any peaks!)

The decoded output will preserve the peaks that exceed "1" aka 0 dBFS as long as it is kept in a floating point format. When it is converted to an integer bit depth the peaks will be clipped unless the volume level is adjusted to prevent that. Ogg Vorbis and MP3 do not differ in this.
Title: lame 3.98.4, 3.99 alpha
Post by: lvqcl on 2010-03-26 15:40:00
But why actually this version clips all samples higher than 1.000000 ?  I thought that if there are fp support it means all samples will be processed and encoded (like in OggEnc - there are no clipping with any peaks!)

Maybe the code that handle 32-bit float was "borrowed" from LAME 3.99 alpha?
Then I can say that it converts 32-bit floats to 32-bit ints because LAME uses get_audio_common() function that returns ints, not floats.
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2010-03-26 15:58:42
Imho, going above full scale makes no sense.

See also: http://forum.audacityteam.org/viewtopic.php?f=11&t=5487 (http://forum.audacityteam.org/viewtopic.php?f=11&t=5487)
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-03-26 22:26:07
Oh, sorry people! I apologize, that was my mistake - I set 24 bit instead of 32 in foobar encoder settings. Now it's ok, and encoder works great with any peaks.
Big thanks to john33 for his work!

Quote
how did you decode the files and how did you verify the clipping?


foobar2000 converter - converting track that has 1.000000 peak with +6 dB gain, then playing it using ReplayGain: prevent clipping according to peak.

Quote
Imho, going above full scale makes no sense.


I do not think so... It can be useful while converting lossy->lossy (e.g. mp3 320 -> ogg vorbis q1) - to prevent clipping (otherwise replay gain or limiter needed)
Title: lame 3.98.4, 3.99 alpha
Post by: tsnr on 2010-04-07 06:38:25
LAME 3.99 alpha 3 (6 April 2010) - cvs snapshot

download (mediafire) (http://www.mediafire.com/download.php?tz2qwwd1zxz)

Changelog:
- preparing to use ieee float [-1,+1] as internal pcm sample representation in LAME frontend
- removing id3v2 picture size limit
- fixing id3v2 TXXX frame storage

Win32:
lame.exe - the command line encoder, used from the Windows command shell
lame_enc.dll - LAME encoding library, generally used with CD rippers, etc
lame.acm - windows acm codec.
libmp3lame.dll

x64:
lame64.exe
lame_enc64.dll
lame64.acm
libmp3lame64.dll

Bundle compiled with Intel Compiler 11.1.060.

LAME MP3 Encoders (mediafire) (http://www.mediafire.com/lame)

Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-04-15 16:38:19
LAME 3.99alpha4 bundle now at Rarewares.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-04-22 11:00:51
For those who are interested, there is a new compile of 3.98.4 that uses the libsndfile .dll. This has .ogg input activated in addition to FLAC input.
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-04-22 13:32:56
Thanks
Title: lame 3.98.4, 3.99 alpha
Post by: tsnr on 2010-05-07 05:13:01
LAME 3.99 alpha 7 (3 May 2010) - cvs snapshot

download (mediafire) (http://www.mediafire.com/download.php?hiz1rztwm20)

Changelog:
- work-in-progress: VBR scale tuning

LAME 3.99 alpha 6 (29 April 2010) - cvs snapshot

download (mediafire) (http://www.mediafire.com/download.php?yzxgyhn2maj)

Changelog:
- some work on VBR scale tuning, accessible with --vbr-new

-----------------------------------------------------------------------
Win32:
lame.exe - the command line encoder, used from the Windows command shell
lame_enc.dll - LAME encoding library, generally used with CD rippers, etc
lame.acm - windows acm codec
libmp3lame.dll

x64:
lame64.exe
lame_enc64.dll
lame64.acm
libmp3lame64.dll

Bundle compiled with Intel Compiler 11.1.065.

LAME MP3 Encoders (download homepage) (http://mediafire.com/lame)

Title: lame 3.98.4, 3.99 alpha
Post by: Sylph on 2010-05-15 20:23:17
I'll use Rare Wares. Hopefully, they'll update the compiler soon to 11.1.065.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-05-17 16:52:10
I'll use Rare Wares. Hopefully, they'll update the compiler soon to 11.1.065.

Done.  (At least as far as the 3.99a7 bundle and lamedrop 3.98.4.)
Title: lame 3.98.4, 3.99 alpha
Post by: Sylph on 2010-05-18 12:27:03
I'll use Rare Wares. Hopefully, they'll update the compiler soon to 11.1.065.

Done.  (At least as far as the 3.99a7 bundle and lamedrop 3.98.4.)


Marvellous! Thank you! 
Title: lame 3.98.4, 3.99 alpha
Post by: tsnr on 2010-06-02 09:51:32
 LAME 3.99 alpha 9 (1 June 2010) - cvs snapshot

download (mediafire) (http://www.mediafire.com/?mnanjhmnkyu)

Changelog:
- more tuning on vbr_mt

LAME 3.99 alpha 8 (1 June 2010) - cvs snapshot

download (mediafire) (http://www.mediafire.com/?jwi30zizyzk)

Changelog:
- some work on VBR scale tuning, accessible with --vbr-new

-----------------------------------------------------------------------
Win32:
lame.exe - the command line encoder, used from the Windows command shell
lame_enc.dll - LAME encoding library, generally used with CD rippers, etc
lame.acm - windows acm codec
libmp3lame.dll

x64:
lame64.exe
lame_enc64.dll
lame64.acm
libmp3lame64.dll

Bundle compiled with Intel Compiler 11.1.065.

LAME MP3 Encoders (download homepage) (http://mediafire.com/lame)

Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-06-02 11:14:16
3.99a9 bundle also at Rarewares.
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-06-02 12:18:38
Thanks!


<deleted>
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2010-06-02 13:19:07
So, who know where (on what samples) we can try to hear new vbr mode improvements?
With EncSpot I see that average bitreservoir value is highly increased (e.g. 34 in 3.98.4 VS 400 in 3.99a7).

Also I see that 3.99 --vbr-new uses new ATH (5), gives more bitrate to some problem samples and looks like it uses joint stereo more safely (lower number of mid stereo frames)

MP3 Packer shows that with 3.99 --vbr-new -V 0 some frames uses up to 460 (О_о) kbps, while with 3.98.4 -b 320 largest frame uses only ~350 kbps. Does this mean that 3.99 V 0 can give higher quality than 3.98.4 320 CBR in some cases?

Sorry for my English
Title: lame 3.98.4, 3.99 alpha
Post by: tsnr on 2010-06-06 06:25:21
LAME 3.99 alpha 10 (6 June 2010) - cvs snapshot

download (mediafire) (http://www.mediafire.com/?meqykm4jqjr)

Changelog:
- some further tweaking of vbr_new

-----------------------------------------------------------------------
Win32:
lame.exe - the command line encoder, used from the Windows command shell
lame_enc.dll - LAME encoding library, generally used with CD rippers, etc
lame.acm - windows acm codec
libmp3lame.dll

x64:
lame64.exe
lame_enc64.dll
lame64.acm
libmp3lame64.dll

Bundle compiled with Intel Compiler 11.1.065.

LAME MP3 Encoders (download homepage) (http://mediafire.com/lame)

Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-06-06 14:48:37
3.99a10 bundle also at Rarewares. 
Title: lame 3.98.4, 3.99 alpha
Post by: tsnr on 2010-06-07 05:05:42
LAME 3.99 alpha 10 (7 June 2010) - cvs snapshot

download (mediafire) (http://www.mediafire.com/?qexdtegxmqy)

download (mediafire) - TEST_2010_06_07_RH enabled (http://www.mediafire.com/?nw0nkmrymmt)

Changelog:
- something to try later: TEST_2010_06_07_RH

-----------------------------------------------------------------------
Win32:
lame.exe - the command line encoder, used from the Windows command shell
lame_enc.dll - LAME encoding library, generally used with CD rippers, etc
lame.acm - windows acm codec
libmp3lame.dll

x64:
lame64.exe
lame_enc64.dll
lame64.acm
libmp3lame64.dll

Bundle compiled with Intel Compiler 11.1.065.

LAME MP3 Encoders (download homepage) (http://mediafire.com/lame)

Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-06-07 11:33:45
Updated 3.99a10 bundle also at Rarewares.
Title: lame 3.98.4, 3.99 alpha
Post by: forart.eu on 2010-06-08 09:21:33
Updated 3.99a10 bundle also at Rarewares.


...still no official x64 builds ? 
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-06-08 10:44:10
Updated 3.99a10 bundle also at Rarewares.


...still no official x64 builds ? 

I wouldn't exactly describe the Rarewares compiles as 'official'!  However, I have posted 64bit compiles of the 3.98.4 and 3.99a10 bundles. Tested on XP x64 and Windows 7 64bit Ultimate, the 3.98.4 compile is, in fact, slower on both OSs, but the a10 compile is faster.
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2010-06-08 10:58:12
How much of a speed difference is there between 3.98.4 and 3.99.a10 ?
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-06-08 13:06:17
On Q6600 systems @ 3.2GHz, 3.98.4 64bit runs at approx 37x and 32bit at approx 41x. With 3.99a10 the numbers are similar only reversed.
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2010-10-11 06:23:18
john33,

I have a performance issue with 3.99a10 build from rarewares. It runs at half of speed comparing to 3.98.4 rarewares's build.
PC: AMD Turion II P540 http://www.cpu-world.com/CPUs/K10/AMD-Turi...540SGR23GM.html (http://www.cpu-world.com/CPUs/K10/AMD-Turion%20II%20Dual-Core%20Mobile%20P540%20-%20TMP540SGR23GM.html)
Windows 7 32 bits.


Both build run equally fast at Intel PC.


tsnr's build 3.99a10 directly doesn't run.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2010-10-11 13:25:10
john33,

I have a performance issue with 3.99a10 build from rarewares. It runs at half of speed comparing to 3.98.4 rarewares's build.
PC: AMD Turion II P540 http://www.cpu-world.com/CPUs/K10/AMD-Turi...540SGR23GM.html (http://www.cpu-world.com/CPUs/K10/AMD-Turion%20II%20Dual-Core%20Mobile%20P540%20-%20TMP540SGR23GM.html)
Windows 7 32 bits.


Both build run equally fast at Intel PC.


tsnr's build 3.99a10 directly doesn't run.

I'll take a look at this when I return home - I'm away at the moment, but it will probably not be until next week.
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2010-10-30 21:02:32
If somebody experiences the slow encode with 3.99a on AMD here is lvqcl's compilation.
http://filekeeper.org/download/shared/lame_a10.rar (http://filekeeper.org/download/shared/lame_a10.rar)
Title: lame 3.98.4, 3.99 alpha
Post by: lvqcl on 2010-10-30 22:29:11
tsnr's build 3.99a10 directly doesn't run.


BTW: try to patch it with iccpatch utility (e.g. from here:  http://www.hydrogenaudio.org/forums/index....74345&st=75 (http://www.hydrogenaudio.org/forums/index.php?showtopic=74345&st=75) )
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2010-10-31 19:10:26
Have tried with different versions of iccpatch (GUIed one too). Didn't work.
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2010-11-20 04:53:39
Some results for Windows 7 x64
CPU Turion II P540

LAME 3.99a10 (foobar converter, 2 cores)

Rarewares builds:
x64 - 47x
x32 - 24x

lvqcl's build http://filekeeper.org/download/shared/lame_a10.rar (http://filekeeper.org/download/shared/lame_a10.rar)
x32 - 44-45x

tsnr build http://www.hydrogenaudio.org/forums/index....st&p=708769 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79682&view=findpost&p=708769)
x64 - 42-43x
x32 - doesn't run.
Title: lame 3.98.4, 3.99 alpha
Post by: moozooh on 2010-12-16 10:39:21
Has anybody conducted any tests comparing the recent 3.99 alphas with 3.98.4? I'm lacking a proper equipment to test at the moment.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-01-13 23:01:49
Has anybody conducted any tests comparing the recent 3.99 alphas with 3.98.4? I'm lacking a proper equipment to test at the moment.


I've run several test with Lame 3.98.4 and 3.99a10... as of right now both seem to produce the same file. I built both build with the same settings.

Here's a pic from both on the same file.

(http://i467.photobucket.com/albums/rr37/fishman0919/lame3984.png)

(http://i467.photobucket.com/albums/rr37/fishman0919/lame399a10.png)
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2011-01-14 13:21:00
3.99a contains the new VBR mode which enables with --vbr-new key. In other modes the result will be the same as for lame 3.98.4
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-01-14 18:32:09
3.99a contains the new VBR mode which enables with --vbr-new key. In other modes the result will be the same as for lame 3.98.4


Sorry, yes, my bad... I don't use vbr-new because it make larger file using -V4 with 3.98.4 and 3.99a10.
Here are some shot of 3.97, 3.98.4 and 3.99a10 on the same file.

(http://i467.photobucket.com/albums/rr37/fishman0919/lame397-V4.png)

(http://i467.photobucket.com/albums/rr37/fishman0919/lame3984-V4.png)

(http://i467.photobucket.com/albums/rr37/fishman0919/lame399a10-V4.png)
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2011-01-14 19:00:33
Hm, I see that bitrate distribution is different for two compiles:

Alpha 10 from here:
http://lame.bakerweb.biz/ (http://lame.bakerweb.biz/)

and
Quote
lvqcl's build http://filekeeper.org/download/shared/lame_a10.rar (http://filekeeper.org/download/shared/lame_a10.rar)


--silent -V 2 --vbr-new --noreplaygain

bakerweb.biz - 216kbps avg
lvqcl's - 208 kbps avg

Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-01-14 19:32:05
Hm, I see that bitrate distribution is different for two compiles:

Alpha 10 from here:
http://lame.bakerweb.biz/ (http://lame.bakerweb.biz/)

and
Quote
lvqcl's build http://filekeeper.org/download/shared/lame_a10.rar (http://filekeeper.org/download/shared/lame_a10.rar)


--silent -V 2 --vbr-new --noreplaygain

bakerweb.biz - 216kbps avg
lvqcl's - 208 kbps avg





Yes, different compiles produce different file.

My MVS VC9 Build
(http://i467.photobucket.com/albums/rr37/fishman0919/lame399a10MVSVC9.png)

My MinGW Build
(http://i467.photobucket.com/albums/rr37/fishman0919/lame399a10MinGW.png)

Bakerweb Build
(http://i467.photobucket.com/albums/rr37/fishman0919/lame399a10bakerweb.png)

Rareware Build
(http://i467.photobucket.com/albums/rr37/fishman0919/lame399a10RarewareBuild.png)
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-01-14 20:59:15
4 Different builds. Same file using "lame.exe --noreplaygain -V 4 test.wav test.mp3"

Rareware Build
(http://i467.photobucket.com/albums/rr37/fishman0919/RaewaresBuild-V4.png)

My MVS VC9 Build
(http://i467.photobucket.com/albums/rr37/fishman0919/MyMVSVC9Build-V4.png)

Bakerweb Build
(http://i467.photobucket.com/albums/rr37/fishman0919/BakerwebBuild-V4.png)

My MinGW Build
(http://i467.photobucket.com/albums/rr37/fishman0919/MyMinGWBuild-V4.png)
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-01-14 21:36:02
Same file using -V2.

Rareware, My MSV VC9, Bakerweb, My MinGW build

(http://i467.photobucket.com/albums/rr37/fishman0919/all4builds.png)
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2011-01-14 21:46:28
Quote
Yes, different compiles produce different file.


But why??
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-01-14 22:10:10
Quote
Yes, different compiles produce different file.


But why??


Different Libraries used in compilers, diff settings used when compiling, diff compilers... which boils down to in the end, different rounding of numbers.

Though not sure why vbr-old doesn't differ so much(same bitrate size, a few different bitrates here and there) as where vbr-new differs alot in bitrate size between compiles with 3.99a10
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2011-01-15 12:25:52
So, now I must ask: which is the best? Of course, in terms of quality
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-01-16 17:32:42
So, now I must ask: which is the best? Of course, in terms of quality


That I can't answer... All of them I guess... I don't think there really is a BAD compiler for Final ver's of Lame.

Maybe robert or john33 could answer that better.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-01-17 11:44:27
So, now I must ask: which is the best? Of course, in terms of quality

That question has been asked many times before and to the best of my knowledge no one has yet been able reliably to differentiate between the outputs from the encoders compiled with different compilers. So it's safe to say that you can use whichever takes your fancy.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-01-26 06:58:51
Having an issue compiling Lame 3.98.4 or 3.99a10 with MSVS 2010... Lame 3.91-3.97 compiles fine.

Can compile Lame 3.98.4 and 3.99a10 fine with MSVS 2008.

Seems to be a linker option that is no longer valid but don't know where to start... any help would be appreciated.

Quote
Setting environment for using Microsoft Visual Studio 2010 x86 tools.

C:\Program Files\Microsoft Visual Studio 10.0\VC>cd lame3984

C:\Program Files\Microsoft Visual Studio 10.0\VC\lame3984>nmake -f Makefile.MSVC


Microsoft ® Program Maintenance Utility Version 10.00.30319.01
Copyright © Microsoft Corporation.  All rights reserved.

----------------------------------------------------------------------
building LAME featuring RH
+ ASM
+ MMX
using MS COMPILER
+ optimizing for Pentium II/III
+ using Single precision
----------------------------------------------------------------------
Pass GTK=YES to build the frame analyzer. (requires installed GTK)
.
.
.
main.c
LINK : fatal error LNK1117: syntax error in option 'opt:NOWIN98'
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 10.0\VC\BI
N\link.EXE"' : return code '0x45d'
Stop.

C:\Program Files\Microsoft Visual Studio 10.0\VC\lame3984>
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2011-01-26 07:53:59
Edit Makefile.MSVC and remove /opt:NOWIN98 around line 236.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-01-26 15:32:08
Edit Makefile.MSVC and remove /opt:NOWIN98 around line 236.


Thank You
Title: lame 3.98.4, 3.99 alpha
Post by: Steve Forte Rio on 2011-01-26 16:01:13
So, now I must ask: which is the best? Of course, in terms of quality

That question has been asked many times before and to the best of my knowledge no one has yet been able reliably to differentiate between the outputs from the encoders compiled with different compilers. So it's safe to say that you can use whichever takes your fancy.


I asked the same question about different bitstream of 320 CBR encoded with two compiles. The difference between them was a small digital 1-bit noise. These could be the results of some processing optimizations.
But here we have different bitrates, and I think this is very strange and must affect quality.

Again:

john33 build - 191 kbps
tsnr (bakerweb.biz) - 185 kbps
lvqcl - 185 kbps
Title: lame 3.98.4, 3.99 alpha
Post by: lvqcl on 2011-01-26 16:33:48
Quote
The difference between them was a small digital 1-bit noise.

Really? Usually differences are much bigger.

Quote
tsnr (bakerweb.biz)

tsnr is not bakerweb.biz.
Title: lame 3.98.4, 3.99 alpha
Post by: alter4 on 2011-01-31 20:51:03
3.99a contains the new VBR mode which enables with --vbr-new key. In other modes the result will be the same as for lame 3.98.4


Ha! AFAIK --vbr-new, which enabled a superior VBR mode in LAME 3.97 and some previous versions, is no longer needed with LAME 3.98 as it is now the default VBR mode
see Lame Wiki (http://wiki.hydrogenaudio.org/index.php?title=LAME#VBR_.28variable_bitrate.29_settings)
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-01-31 20:56:42
It's vbr new 2.0
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-01-31 21:22:11
So, now I must ask: which is the best? Of course, in terms of quality

That question has been asked many times before and to the best of my knowledge no one has yet been able reliably to differentiate between the outputs from the encoders compiled with different compilers. So it's safe to say that you can use whichever takes your fancy.


I asked the same question about different bitstream of 320 CBR encoded with two compiles. The difference between them was a small digital 1-bit noise. These could be the results of some processing optimizations.
But here we have different bitrates, and I think this is very strange and must affect quality.

Again:

john33 build - 191 kbps
tsnr (bakerweb.biz) - 185 kbps
lvqcl - 185 kbps

Sorry, but again, you may be able to see a difference, but can you hear one? The difference is only of any consequence if you can discern it accurately and repeatedly via blind listening tests.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-02-07 22:15:32
Does anyone know why this is not working anymore?

http://lame.cvs.sourceforge.net/viewvc/lam...tar.gz?view=tar (http://lame.cvs.sourceforge.net/viewvc/lame/lame.tar.gz?view=tar)

It will download a file but it is 0 bytes in size.


EDIT: Seems it's not work for some other programs as well.
Title: lame 3.98.4, 3.99 alpha
Post by: lvqcl on 2011-02-07 22:21:30
http://www.hydrogenaudio.org/forums/index....st&p=741978 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85119&view=findpost&p=741978)
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-02-07 22:22:26
http://www.hydrogenaudio.org/forums/index....st&p=741978 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85119&view=findpost&p=741978)


Thank You
Title: lame 3.98.4, 3.99 alpha
Post by: obones on 2011-02-12 18:54:00
Hello,

I have Vegas Pro in 64bit version installed under Windows 7 x64 and I would like to use the lame codec inside it. I believe this is what lame64.acm is for but I can't find a way to install it properly.
I believe there should be a .inf file with it that would tell windows how to install it but it's not there.
Can any of you give me instructions for installing the acm file under Windows 7 64 bits ?

I have had a look at the rarewares website, but it does not seem to offer any x64 ACM build. There are instructions as to how to install under Win7 x64, but it's to install the x86 version that would then not be accessible to x64 applications

Thank you for your help
Title: lame 3.98.4, 3.99 alpha
Post by: tsnr on 2011-02-18 18:52:14
LAME 3.99 alpha 12 (13 Feb 2011) - cvs snapshot

download (mediafire) (http://www.mediafire.com/?uf4ijt4j72b67ck)

Changelog:

- make vbr_mt the default vbr mode
- new mono encoding switches:
  -ml encodes left channel only
  -mr encodes right channel only
- small fixes for compiler warnings
  (vbrquantize.c) bug fix, out of bounds memory write
- reintroduction of fast encoding mode (-q7 / -f)  (vbr_mt / vbr_mtrh)
- minor fix for sfb21 encoding (vbr_mt / vbr_mrth)
- small tunings


-----------------------------------------------------------------------
Win32:
lame.exe - the command line encoder, used from the Windows command shell
lame_enc.dll - LAME encoding library, generally used with CD rippers, etc
lame.acm - windows acm codec
libmp3lame.dll

x64:
lame64.exe
lame_enc64.dll
lame64.acm
libmp3lame64.dll

Bundle compiled with Intel Compiler XE 12.0
 
LAME MP3 Encoders (download homepage) (http://mediafire.com/lame)



Title: lame 3.98.4, 3.99 alpha
Post by: obones on 2011-02-18 21:17:07
I tried the x64 ACM codec as it includes an INF file this time but it crashes Vegas Pro so it seems it is not working.
Does anyone have any idea?
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-02-19 22:40:03
Interesting. Now last alpha preserves frequencies up to 22 Khz (V0).
Title: lame 3.98.4, 3.99 alpha
Post by: Enig123 on 2011-02-20 05:17:05
What is vbr_mt exactly? And why it was set as default instead of the former vbr_new?
Title: lame 3.98.4, 3.99 alpha
Post by: Larson on 2011-02-20 07:39:15
What is vbr_mt exactly? And why it was set as default instead of the former vbr_new?


If I've understood well, until the previous alpha to access the new vbr mode (vbr new 2.0 some have called it) you had to make the command "-VX --vbr-new" otherwise it worked with the older and regular vbr. Now as far as I've seen it is enabled by default, tested with dbpoweramp.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-02-21 06:36:00
What is vbr_mt exactly? And why it was set as default instead of the former vbr_new?


What is vbr_mt exactly? = a vbr routine build into Lame

The old vbr new was "--vbr-mtrh" (I assume by Mark Taylor and Robert Hegemann) ... now the new vbr new is "--vbr-mt" (I'm assumming by Mark Taylor)... There's also a "--vbr-rh" (assumming by Robert Hegemann) which I beleave is the vbr-old routine

EDIT: So it's still "-Vx --vbr-new or just  -Vx" in the comandline.... it just routes to the vbr mt routine in Lame instead of vbr mtrh
Title: lame 3.98.4, 3.99 alpha
Post by: Aleron Ives on 2011-02-21 06:54:23
If I've understood well, until the previous alpha to access the new vbr mode (vbr new 2.0 some have called it) you had to make the command "-VX --vbr-new" otherwise it worked with the older and regular vbr.

I think that is correct, although the way you said it might still be confusing, since "the older and regular vbr" is not --vbr-old. To be clear, the "old" VBR mode that used to be default in LAME 3.97 and previous versions (vbr-rh) was deprecated for the "new" VBR mode in LAME 3.98. The "new" VBR mode is vbr-mtrh. Because the new VBR mode was made default in LAME 3.98, using the --vbr-new switch didn't actually do anything, since --vbr-new (vbr-mtrh) was the default VBR mode.

In LAME 3.99, the developers began to work on more VBR improvements, so they made the --vbr-new switch enable those improvements. As of the latest alpha, the --vbr-new switch is no longer needed, and running in VBR mode will use the new encoding method by default (vbr-mt). What I don't know is whether this vbr-mt mode is the same vbr-mt that was deprecated around 2002 in favour of vbr-mtrh, or if this vbr-mt is just vbr-mtrh + improvements.

If I've gotten everything completely muddled, feel free to just delete this post so as to not confuse people further, haha.
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2011-02-22 19:58:31
@Fisman0919: your guess about people involved in developing different variations of LAME's vbr code is correct.

There is some internal API enumeration of different VBR modes: vbr_rh, vbr_mt, vbr_mtrh
The command line switches to select one of those are: --vbr-old (vbr_rh), --vbr-mtrh and --vbr-new (vbr_mt)

It's been a long time, since the original vbr_mt code was discarded in favour of vbr_mtrh. The recent discrimination of vbr_mt and vbr_mtrh was only there to make experimentation easier for me. Now both modes do exactly the same again.


With 3.99 alpha 13 I'm starting to re-use some of the latest VBR code tunings in CBR/ABR.
Title: lame 3.98.4, 3.99 alpha
Post by: alter4 on 2011-02-23 10:17:20
@Robert

Sorry for a little bit off-top, but When do you plan to come into 3.99beta stage?
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-02-23 11:03:02
Alpha 13 bundles are at Rarewares.
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2011-02-23 20:46:39
@Robert

Sorry for a little bit off-top, but When do you plan to come into 3.99beta stage?

Probably in March...
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-02-24 16:40:00
I noticed that alpha 13 is not inserting the Lame Header??
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2011-02-24 17:10:45
Just checked john33's compiled binary, the header is there.
Do you do anything special? How do you call LAME? How do you determine the existence of the header?
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-02-24 17:33:23
Just checked john33's compiled binary, the header is there.
Do you do anything special? How do you call LAME? How do you determine the existence of the header?


Both with Foobar2000 "-S --noreplaygain -V 2 - %d" and command line "lame.exe --noreplaygain -V 2 test.wav test.mp3"

In Foobar2000, it's not showing the ver of Lame used to encoder and EncSpot is showing Gogo 3.0 as encoder with the Lame Header showing just Xing Tag
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2011-02-24 17:36:25
It seems, Foobar2000 assumes the "Encoder short VersionString" has to start with LAME.
Title: lame 3.98.4, 3.99 alpha
Post by: alter4 on 2011-02-25 11:32:22
@Robert

Sorry for a little bit off-top, but When do you plan to come into 3.99beta stage?

Probably in March...

Thank you Robert.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-02-27 18:32:50
Lame 3.99a14 is up... LINK -"http://www.mediafire.com/?7iva5wwo7ld4wr6"
Title: lame 3.98.4, 3.99 alpha
Post by: obones on 2011-02-28 09:02:00
I tried the x64 ACM codec as it includes an INF file this time but it crashes Vegas Pro so it seems it is not working.
Does anyone have any idea?

Well, still no luck here, but I found an interim solution as described here:

http://www.hydrogenaudio.org/forums/index....showtopic=87076 (http://www.hydrogenaudio.org/forums/index.php?showtopic=87076)

But I would very much prefer using an ACM codec based on LAME, should one be available and usable. I don't have the skills to create one myself, but I can test an already built one if need be.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-02-28 12:10:08
Alpha 14 bundles are now at Rarewares.
Title: lame 3.98.4, 3.99 alpha
Post by: jamesbaud on 2011-03-01 03:39:04
Just checked john33's compiled binary, the header is there.
Do you do anything special? How do you call LAME? How do you determine the existence of the header?


Both with Foobar2000 "-S --noreplaygain -V 2 - %d" and command line "lame.exe --noreplaygain -V 2 test.wav test.mp3"

In Foobar2000, it's not showing the ver of Lame used to encoder and EncSpot is showing Gogo 3.0 as encoder with the Lame Header showing just Xing Tag


I noticed this too. In prior versions of lame, prior versions of foobar would show the version of lame under the field "tool" in properties.

I don't know whether it's the version of lame (3.99 alpha 13 & 14) or the version of foobar (1.1.4 &  1.1.5) that's the problem.

Perhaps someone should notify the foobar people.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-03-02 05:45:15
Just checked john33's compiled binary, the header is there.
Do you do anything special? How do you call LAME? How do you determine the existence of the header?


Both with Foobar2000 "-S --noreplaygain -V 2 - %d" and command line "lame.exe --noreplaygain -V 2 test.wav test.mp3"

In Foobar2000, it's not showing the ver of Lame used to encoder and EncSpot is showing Gogo 3.0 as encoder with the Lame Header showing just Xing Tag


I noticed this too. In prior versions of lame, prior versions of foobar would show the version of lame under the field "tool" in properties.

I don't know whether it's the version of lame (3.99 alpha 13 & 14) or the version of foobar (1.1.4 &  1.1.5) that's the problem.

Perhaps someone should notify the foobar people.



It's not all Foobar... in alpha 13 and 14 the encoder short VersionString, which Foobar reads to show the ver used, was changed... older ver's of Lame were something like "LAME3.98r" now in Alpha 13 and 14 it's "L3.99a14". And it seems if Foobar doesn't see "LAME" it's doesn't think it Lame.

It seems, Foobar2000 assumes the "Encoder short VersionString" has to start with LAME.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-03-22 01:34:59
Where can I find an up to date ChangeLog for Lame?
Title: lame 3.98.4, 3.99 alpha
Post by: dv1989 on 2011-03-22 12:17:13
If all else fails, you can browse the CVS tree and check the latest changes there:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/ (http://lame.cvs.sourceforge.net/viewvc/lame/lame/)
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2011-03-22 12:36:53
Sorry, I'll update the changelog later.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-03-24 17:06:24
If all else fails, you can browse the CVS tree and check the latest changes there:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/ (http://lame.cvs.sourceforge.net/viewvc/lame/lame/)


Sorry, I'll update the changelog later.


Thank you and Thank you
Title: lame 3.98.4, 3.99 alpha
Post by: dxiv on 2011-03-31 19:09:39
Is there a v3.98.4 modified lame_enc.dll to use .ini settings? The latest I see on rarewares is v3.98.2. Thanks.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-03-31 21:09:20
Is there a v3.98.4 modified lame_enc.dll to use .ini settings? The latest I see on rarewares is v3.98.2. Thanks.

Not currently, but I'll have a look at producing one. Given personal commitments, it will probably be some time next week, I'm afraid.
Title: lame 3.98.4, 3.99 alpha
Post by: dxiv on 2011-03-31 21:39:36
Not currently, but I'll have a look at producing one.

Much obliged, thanks again.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-04-06 17:24:55
Lame 3.99a16 is available.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-04-06 17:30:45
Is there a v3.98.4 modified lame_enc.dll to use .ini settings? The latest I see on rarewares is v3.98.2. Thanks.

Now available at Rarewares.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-04-06 17:58:57
Lame 3.99a16 is available.

At Rarewares.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-04-06 19:13:40
Lame 3.99a16 is available.

At Rarewares.



Thank You! 
Title: lame 3.98.4, 3.99 alpha
Post by: alter4 on 2011-04-06 21:03:27
Hi Guys!
What is the change list?
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-04-08 18:49:13
I've tried 3.98.4 and 3.99a16 on EIG sample.  V0

3.99 has higher bitrate for V0 but it's ok because it's highest VBR mode.
3.99a16 - 295 kbps
3.98.4 - 249 kbps.



And those extra bits were useful

ABC/HR for Java, Version 0.53a, 08 April 2011
Testname:

Tester: IgorC

1L = D:\Public test\Sample12\LAME 3.99a16 V0 VBR NEW sample12.wav
2R = D:\Public test\Sample12\LAME 3.98.4 V0 sample12.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\Public test\Sample12\LAME 3.99a16 V0 VBR NEW sample12.wav
1L Rating: 4.5
1L Comment: distortion in the form of flat/soft pulses during 2.75-3.15 seconds. But it's still better than sample 2.
---------------------------------------
2R File: D:\Public test\Sample12\LAME 3.98.4 V0 sample12.wav
2R Rating: 3.0
2R Comment: more pronounceable/ stronger  pre-echo
---------------------------------------

ABX Results:
Original vs D:\Public test\Sample12\LAME 3.98.4 V0 sample12.wav
   5 out of 5, pval = 0.031
Original vs D:\Public test\Sample12\LAME 3.99a16 V0 VBR NEW sample12.wav
   5 out of 5, pval = 0.031


---- Detailed ABX results ----
Original vs D:\Public test\Sample12\LAME 3.98.4 V0 sample12.wav
Playback Range: 00.000 to 15.000
   2:35:03 PM p 1/1 pval = 0.5
   2:35:06 PM p 2/2 pval = 0.25
   2:35:10 PM p 3/3 pval = 0.125
   2:35:12 PM p 4/4 pval = 0.062
   2:35:16 PM p 5/5 pval = 0.031

Original vs D:\Public test\Sample12\LAME 3.99a16 V0 VBR NEW sample12.wav
Playback Range: 00.000 to 15.000
   2:38:32 PM p 1/1 pval = 0.5
   2:38:38 PM p 2/2 pval = 0.25
   2:38:43 PM p 3/3 pval = 0.125
   2:38:50 PM p 4/4 pval = 0.062
   2:38:57 PM p 5/5 pval = 0.031
Title: lame 3.98.4, 3.99 alpha
Post by: dxiv on 2011-04-09 09:19:47
Is there a v3.98.4 modified lame_enc.dll to use .ini settings?
Now available at Rarewares.

Thank you.

P.S. Not directly related, but the hak/plextools (http://wiki.hydrogenaudio.org/index.php?title=Plextools) entry seems to be outdated. Plextools Pro XL has been free since 2010, and v3.16 can be downloaded off Plextor's own site (http://www.plextor-digital.com/index.php/component/option,com_jdownloads/Itemid,/catid,86/task,viewcategory/).
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-04-15 12:48:20
Beta 0 compiles now at Rarewares.
Title: lame 3.98.4, 3.99 alpha
Post by: shadowking on 2011-04-17 06:54:59
Still serious problems with this sample :

http://www.hydrogenaudio.org/forums/index....showtopic=55340 (http://www.hydrogenaudio.org/forums/index.php?showtopic=55340)
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-04-28 07:19:06
LAME 3.99b0 produces more obvious warbling on hi-hat and voice (or flanging?) than 3.98.4  does on this sample
http://www.hydrogenaudio.org/forums/index....showtopic=88321 (http://www.hydrogenaudio.org/forums/index.php?showtopic=88321)


ABC/HR for Java, Version 0.53a, 23 April 2011
Testname:

Tester: IgorC

1R = D:\Artifacts_Training\A matter of time\3.99b0 V5.wav
2R = D:\Artifacts_Training\A matter of time\3.98.4 V5.7 original.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1R File: D:\Artifacts_Training\A matter of time\3.99b0 V5.wav
1R Rating: 3.5
1R Comment:
---------------------------------------
2R File: D:\Artifacts_Training\A matter of time\3.98.4 V5.7 original.wav
2R Rating: 4.0
2R Comment:
---------------------------------------

ABX Results:



Properties of Setup test: Additional offset 2000ms,  gain is calculated.
Though V2 is pretty good and it's difficult to say the difference between two versions of LAME.
Title: lame 3.98.4, 3.99 alpha
Post by: Billytheonion on 2011-04-28 10:44:02
IS V0 getting so high bit-rates to the point we can forget it ad just use 320 cbr
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-04-28 17:33:04
LAME 3.99b0 produces more obvious warbling on hi-hat and voice (or flanging?) than 3.98.4  does on this sample
http://www.hydrogenaudio.org/forums/index....showtopic=88321 (http://www.hydrogenaudio.org/forums/index.php?showtopic=88321)


ABC/HR for Java, Version 0.53a, 23 April 2011
Testname:

Tester: IgorC

1R = D:\Artifacts_Training\A matter of time\3.99b0 V5.wav
2R = D:\Artifacts_Training\A matter of time\3.98.4 V5.7 original.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1R File: D:\Artifacts_Training\A matter of time\3.99b0 V5.wav
1R Rating: 3.5
1R Comment:
---------------------------------------
2R File: D:\Artifacts_Training\A matter of time\3.98.4 V5.7 original.wav
2R Rating: 4.0
2R Comment:
---------------------------------------

ABX Results:



Properties of Setup test: Additional offset 2000ms,  gain is calculated.
Though V2 is pretty good and it's difficult to say the difference between two versions of LAME.


IgorC, if you could, could you please repeat the test but with -V 5 --vbr-old for 3.99 b0... I found on a few samples/test I've done that when 3.99b0 -V # fails against 3.98.4... 3.99b0 -V # --vbr-old seemed better
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-04-29 02:59:34
Yes, 3.99b0 VBR OLD was better than default VBR mode and was on par with 3.98.4.

It's very easy to spot the difference of Original vs Lossy. But the mind starts to play tricky games when it is Lossy A vs Lossy B. Especially when  it's the same encoder and artifacts are very similar.
To avoid such tricky mind games I have done blind test in two passes.
1.Exclusively ABC/HR + training mode. During this pass I put the mark to encoders (1.0 - 5.0).
2. Exclusively ABXY of Lossy A vs Lossy B. ABXY works better than ABX for similar artifacts.


ABC/HR log:
ABC/HR for Java, Version 0.53a, 28 April 2011
Testname:

Tester: IgorC

1R = D:\Artifacts_Training\A matter of time\3.99b0 V5.wav
2L = D:\Artifacts_Training\A matter of time\3.99b0 V5 VBR OLD.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1R File: D:\Artifacts_Training\A matter of time\3.99b0 V5.wav
1R Rating: 2.8
1R Comment:
---------------------------------------
2L File: D:\Artifacts_Training\A matter of time\3.99b0 V5 VBR OLD.wav
2L Rating: 3.3
2L Comment:
---------------------------------------

ABX Results:



ABX log:
foo_abx 1.3.4 report
foobar2000 v1.1.6
2011/04/28 22:26:02

File A: D:\Artifacts_Training\A matter of time\3.99b0 V5 VBR OLD.mp3
File B: D:\Artifacts_Training\A matter of time\3.99b0 V5.mp3

22:26:02 : Test started.
22:28:28 : 01/01  50.0%
22:28:34 : 02/02  25.0%
22:29:00 : 03/03  12.5%
22:29:04 : 04/04  6.3%
22:29:16 : 05/05  3.1%
22:29:35 : Test finished.

----------
Total: 5/5 (3.1%)
Title: lame 3.98.4, 3.99 alpha
Post by: The Sheep of DEATH on 2011-05-05 19:39:01
Where can I find a source tarball for 3.99b0?
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-05-05 19:50:12
Where can I find a source tarball for 3.99b0?

I'm not sure you can, you may have to do a CVS Checkout.
Title: lame 3.98.4, 3.99 alpha
Post by: lvqcl on 2011-05-05 19:50:22
http://lame.cvs.sourceforge.net/viewvc/lame/lame/ (http://lame.cvs.sourceforge.net/viewvc/lame/lame/)

"Download GNU tarball" link at the bottom of the page
Title: lame 3.98.4, 3.99 alpha
Post by: The Sheep of DEATH on 2011-05-05 19:58:45
I can't believe I didn't see that. That whole page. Now bookmarked.

Thanks a lot!
Title: lame 3.98.4, 3.99 alpha
Post by: The Sheep of DEATH on 2011-05-06 00:41:36
Have the old psymodels been removed from the code? Is there any way to download a tarball of the CVS before March 5, 2011?
Title: lame 3.98.4, 3.99 alpha
Post by: The Sheep of DEATH on 2011-05-06 01:48:09
Okay, to answer my own questions: yes, previously used psymodel functions have been stripped from the code as of March 5. Alpha 12 is the latest tagged release in CVS before that time. (I'm sorry for the repeated posts; after some interval of time, the forum no longer lets me edit my previous posts).
Title: lame 3.98.4, 3.99 alpha
Post by: KlameM on 2011-07-06 11:04:59
Is there a v3.98.4 modified lame_enc.dll to use .ini settings? The latest I see on rarewares is v3.98.2. Thanks.

Now available at Rarewares.


Something seems to wrong with this compile :
It requires LIBMMD.DLL which is neither included in the download package nor a part  of windows.
A dll of this name is part of Media Match Jukebox. I wonder why this should be required by a lame compile.
The previous modified lame_enc.dll (V3.98.2) was complete (almost twice the size) and worked under Windows versions from Win2000 and newer.
Could you please check the dependencies of your compilation ?
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-07-06 12:17:16
Is there a v3.98.4 modified lame_enc.dll to use .ini settings? The latest I see on rarewares is v3.98.2. Thanks.

Now available at Rarewares.


Something seems to wrong with this compile :
It requires LIBMMD.DLL which is neither included in the download package nor a part  of windows.
A dll of this name is part of Media Match Jukebox. I wonder why this should be required by a lame compile.
The previous modified lame_enc.dll (V3.98.2) was complete (almost twice the size) and worked under Windows versions from Win2000 and newer.
Could you please check the dependencies of your compilation ?

Will do, and I'll get back to you.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-07-06 15:11:54
I've recompiled this using static libraries in the same way the the regular .dll is compiled. I've re-uploaded to Rarewares.
Title: lame 3.98.4, 3.99 alpha
Post by: KlameM on 2011-07-08 10:04:06
I've recompiled this using static libraries in the same way the the regular .dll is compiled. I've re-uploaded to Rarewares.


Hi John33,

many thanks for your effort !

However, I've just tried to download the new version and sadly am still getting the version of April with approximatly 130 kB size 
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-07-08 10:39:09
I've recompiled this using static libraries in the same way the the regular .dll is compiled. I've re-uploaded to Rarewares.


Hi John33,

many thanks for your effort !

However, I've just tried to download the new version and sadly am still getting the version of April with approximatly 130 kB size 

That's odd!  I just downloaded it here and got the new version.
Title: lame 3.98.4, 3.99 alpha
Post by: KlameM on 2011-07-08 15:37:22
I've recompiled this using static libraries in the same way the the regular .dll is compiled. I've re-uploaded to Rarewares.


Hi John33,

many thanks for your effort !

However, I've just tried to download the new version and sadly am still getting the version of April with approximatly 130 kB size 

That's odd!  I just downloaded it here and got the new version.

Thanks a lot John33 !

I finally got a copy. (A proxy kept sending the older version until I tried another proxy) 
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-07-08 16:25:45
Ah, that's good.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-07-23 04:09:36
Is Lame on hold?
Title: lame 3.98.4, 3.99 alpha
Post by: lvqcl on 2011-07-23 08:10:02
Last update for LAME 3.99 was: May 24 20:45:55 2011 UTC

(BTW, this version can produce noticeable artifacts in CBR/ABR modes... example: florida_seq @128kbps CBR)
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-09-07 23:39:17
I ask this again...

Is Lame on hold... Dead?
Title: lame 3.98.4, 3.99 alpha
Post by: db1989 on 2011-09-08 10:39:35
Don’t you think that would have been announced if it were the case?

Anyway, “dead” how? It’s an open-source project, and I think we’d have to wait a while for the day when there isn’t at least one user interested in continuing to tweak its code with a view to optimisation.
Title: lame 3.98.4, 3.99 alpha
Post by: halb27 on 2011-09-08 15:08:35
Not to mention the fact that Lame 3.98.4 is pretty close to perfection with respect to the mp3 conditions.
AFAIK there are no flaws which can be contributed to implementation, not codec limitations.
Sure things can always be improved, but with the quality actually achieved it is hard to do so.
Title: lame 3.98.4, 3.99 alpha
Post by: db1989 on 2011-09-08 15:14:59
Well, in comparison to that current stable version, the in-progress 3.99 has another new VBR mode. This presumably represents a step closer to optimality, though I haven’t read much about it. Has there been much discussion here?
Title: lame 3.98.4, 3.99 alpha
Post by: Heemlock on 2011-09-08 15:34:27
Anyone can tell me what is the difference between the LAME 3.98.4 Bundles? I use the one i have found at RareWares (LAME 3.98.4 Bundle compiled with Intel Compiler 11.1) but i saw other LAME 3.98.4 Bundles from other sites and those have different files/sizes.
Title: lame 3.98.4, 3.99 alpha
Post by: db1989 on 2011-09-08 15:37:44
You hinted at it yourself; this is simply an inconsequential result of the differing executables having been created by different compilers. Read more here: http://www.hydrogenaudio.org/forums/index....showtopic=48978 (http://www.hydrogenaudio.org/forums/index.php?showtopic=48978)
Title: lame 3.98.4, 3.99 alpha
Post by: Heemlock on 2011-09-08 15:48:52
You hinted at it yourself; this is simply an inconsequential result of the differing executables having been created by different compilers. Read more here: http://www.hydrogenaudio.org/forums/index....showtopic=48978 (http://www.hydrogenaudio.org/forums/index.php?showtopic=48978)


Thank you!
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-09-13 00:05:02
Not to mention the fact that Lame 3.98.4 is pretty close to perfection with respect to the mp3 conditions.
AFAIK there are no flaws which can be contributed to implementation, not codec limitations.
Sure things can always be improved, but with the quality actually achieved it is hard to do so.

I found 3.98.4 -V0  and 3.99b0 -V0 --vbr-new  both are suitable for transparent encoding on my music (rock). -V2, -V1 weren't satisfactory.
Testing killer samples EIG, fatboy and castanets doesn't make much sense for me as I don't listen this kind of music.  These samples aren't transparent at any bitrate for LAME.

3.99b0 -V 0 --vbr-new uses a bit higher bitrate than 3.98.4 -V0  and does better on difficult samples (imho it's the main improvement of 3.99).

It's not a pure quality improvement because the bitrate has increased too. It's more like some sort of mixed class improvement (usability+quality). But it's still improvement.
Title: lame 3.98.4, 3.99 alpha
Post by: halb27 on 2011-09-13 06:53:28
It's good to hear about improvements with 3.99. I didn't even know that it's in beta stage now.
I don't care about bitrate increases. With today's storage capacities this isn't an issue for me and probably many other users. Those sporting for extremely good efficiency are better off using codecs like AAC.

What's your experience with quality improvements, what are the samples you can hear an improved quality using 3.99.b0 -V0 --vbr-new compared to 3.98.4 -V0?
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-09-14 04:07:50
What's your experience with quality improvements, what are the samples you can hear an improved quality using 3.99.b0 -V0 --vbr-new compared to 3.98.4 -V0?

Some of the results.

eig (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79682&view=findpost&p=751296)
Less pre-echo for 3.99

Sample 08 and 14 from the last public test (http://listening-tests.hydrogenaudio.org/igorc/aac-96-a/all_samples.zip)

Sample08

ABC/HR for Java, Version 0.53a, 12 September 2011
Testname:

Tester: IgorC

1R = sample08_399b0_V0_VNEW_3.wav
2R = sample08_3984_V0_2.wav
3R = sample08_397_V0_1.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1R File: sample08_399b0_V0_VNEW_3.wav
1R Rating: 4.2
1R Comment:
---------------------------------------
2R File: sample08_3984_V0_2.wav
2R Rating: 3.4
2R Comment:
---------------------------------------
3R File: sample08_397_V0_1.wav
3R Rating: 4.0
3R Comment:
---------------------------------------

ABX Results:


Also less pre-echo for 3.99

Sample14 (trumpet)

ABC/HR for Java, Version 0.53a, 12 September 2011
Testname:

Tester: IgorC

1L = sample14_3984_V0_2.wav
2R = sample14_399b0_V0_VNEW_3.wav
3L = sample14_397_V0_1.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: sample14_3984_V0_2.wav
1L Rating: 3.6
1L Comment:
---------------------------------------
3L File: sample14_397_V0_1.wav
3L Rating: 4.3
3L Comment:
---------------------------------------

ABX Results:

3.98.4 has an artifact which was known as paper sound in past (?)

Generally 3.98.4 and 3.99b0 both did great on all other samples. (the exclusion can be  fatboy sample. I was already tired on some samples). Shortly the average score and bitrates were higher for 3.99b0 (3.99b0>3.98.4>3.97). I don't post all results as it's just for personal interest.
Title: lame 3.98.4, 3.99 alpha
Post by: halb27 on 2011-09-14 08:41:22
Interesting to learn about improvements on trumpet which is the sample that made me aware of codec artefacts (in the days of 3.97) I didn't care about before.
Title: lame 3.98.4, 3.99 alpha
Post by: shadowking on 2011-09-14 11:35:29
I dunno. Years ago i encoded with mpc -standard. In recent times I tried lame -V3. Very similar bitrate to mpc / nero 0.5 and you what: its not too bad at all. Most tracks are transparent with headphones or close to it. It doesn't have the annoying scfb21 issue , its VBR and unlike mpc , its compatible with nearly anything out there  Mp3gain works on all hardware too. I guess i still really like efficiency .

So What i'm saying is that everything now is 250~300k. So why not just 256-320 CBR using lame from 2000 ? Its virtually the same. We have advanced so much yet ended up in the same place.
Title: lame 3.98.4, 3.99 alpha
Post by: halb27 on 2011-09-14 18:29:17
I came back to mp3 for the same reasons you've mentioned. And it's good enough for me.
Sure moderate bitrate users take better profit from Lame improvements. Whether or not that's essential is personal judgement.
Title: lame 3.98.4, 3.99 alpha
Post by: halb27 on 2011-09-14 18:58:55
...
Sample14 (trumpet)

ABC/HR for Java, Version 0.53a, 12 September 2011
Testname:

Tester: IgorC

1L = sample14_3984_V0_2.wav
2R = sample14_399b0_V0_VNEW_3.wav
3L = sample14_397_V0_1.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: sample14_3984_V0_2.wav
1L Rating: 3.6
1L Comment:
---------------------------------------
3L File: sample14_397_V0_1.wav
3L Rating: 4.3
3L Comment:
---------------------------------------

ABX Results:

3.98.4 has an artifact which was known as paper sound in past (?)

...

Oops, I didn't read carefully. Where's the result for 3.99? 3.97 -V0 better than 3.98.4 -V0 on trumpet? That can't be true. 3.97 had the sandpaper noise issue which 3.98 improved upon, and for 3.97 trumpet was a problem, whereas at least I am pretty content with 3.98.4 -V0 on it.

There must have gone something wrong.
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-09-14 21:19:08
That can't be true.

Different conditions: listener, hardware, room, time, mood and ... familiarity with  sample and/or artifact (see below)

Also it's something related to it
http://www.hydrogenaudio.org/forums/index....st&p=743184 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86650&view=findpost&p=743184)

In other words You can perform the blind tests for some particular sample again and again during one day but it doesn't guarantee the same results if you will perform it next day/week. I think what really counts it is a tendency (many results) not particular one result.

Where's the result for 3.99?

It wasn't. The absense of the score in ABX log means 5.0. But as I said it _was_. Now I listened it the second time and alter the initial perception completely. The results have changed drastically. That's  why I did quite a lot of samples (18 actually but didn't post them here) . It reveals the average tendency because most of all I care about average score. While there can be a statistical noise on single results.
Title: lame 3.98.4, 3.99 alpha
Post by: halb27 on 2011-09-14 22:29:47
...
Different conditions: listener, hardware, room, time, mood and ... familiarity with  sample and/or artifact (see below)
...
The absense of the score in ABX log means 5.0. But as I said it _was_. Now I listened it the second time and alter the initial perception completely. The results have changed drastically. That's  why I did quite a lot of samples (18 actually but didn't post them here) . It reveals the average tendency because most of all I care about average score. While there can be a statistical noise on single results.

I know the problem of different results with different tests very well. Ran upon it when testing lossyWav. It's annoying.
But in cases where I get totally different perceptions I'd rather not use the results. I'd only use results for those samples for which I can get perceptions which more or less reliably differentiate encoder versions.

If the a priori preferred encoder result of a sample is harder to ABX against the original (if in doubt because of equal or near-equal scores use the time it takes for ABXing as a measure for it) than is the alternative, this is kind of a confirmation for your initial perception. This is not foolproof of course, but it makes judgements on encoder results a little bit less personal.

As for my favorite mp3 problem sample trumpet I'd love to learn about your new results.
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-09-15 06:02:37
As for my favorite mp3 problem sample trumpet I'd love to learn about your new results.

I have no problem to provide the results. The problem is that they are variable.
During the day I have made 5 times the same trumpet sample. Now  3.98.4 was the best. All 5 times it was 3.98.4>3.97>3.99b0. When I  got back home at night and made the same test twice and twice time it was 3.98.4>3.99b0>3.97. 


Possible explanation is the the conditions of the test have changed.
During the day the level of noise was quite high at home (cars). The night was quite.

For now it's the last time for me I test trumpet sample.    I remember I have the same experience with sample Take Your Finger From My Head (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89518&view=findpost&p=762499).

P.S. Additional comparison codec A vs codec B (besides of codec A vs lossless, codec B vs lossless) doesn't help for these samples.
http://www.hydrogenaudio.org/forums/index....st&p=743197 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86650&view=findpost&p=743197)
Title: lame 3.98.4, 3.99 alpha
Post by: halb27 on 2011-09-15 06:36:51
Thanks a lot for your efforts.
As far as 3.98.4 is concerned your overall results on trumpet agree with mine (definitely compared to 3.97, but I can't talk about 3.99b0 which I have no experience with, just with early alpha versions with which I could not hear an improvement on trumpet).
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-09-15 06:58:09
Thank You too for bringing this out.
It makes me remember of the previous issues and re-think, improve some technics.
Title: lame 3.98.4, 3.99 alpha
Post by: DigitalDictator on 2011-09-15 12:52:04
As for my favorite mp3 problem sample trumpet I'd love to learn about your new results.

I have no problem to provide the results. The problem is that they are variable.
During the day I have made 5 times the same trumpet sample. Now  3.98.4 was the best. All 5 times it was 3.98.4>3.97>3.99b0. When I  got back home at night and made the same test twice and twice time it was 3.98.4>3.99b0>3.97. 


Possible explanation is the the conditions of the test have changed.
During the day the level of noise was quite high at home (cars). The night was quite.

For now it's the last time for me I test trumpet sample.    I remember I have the same experience with sample Take Your Finger From My Head (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89518&view=findpost&p=762499).

P.S. Additional comparison codec A vs codec B (besides of codec A vs lossless, codec B vs lossless) doesn't help for these samples.
http://www.hydrogenaudio.org/forums/index....st&p=743197 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86650&view=findpost&p=743197)

I've been meaning to ask about this "phenomenon" before. Does this indicate that, for example, the last public test @96 kbps would come out differently if the same people did the tests a second time? I mean, if the artifacts are so subtle and it has a lot to do with your own personal state of mind (eg. tired, bored, stressed out etc.), the outcome is mererly a result of the testers' shape that day, and not so much the encoder itself? Just a thought...
Title: lame 3.98.4, 3.99 alpha
Post by: halb27 on 2011-09-15 15:48:08
The outcome can change, but as there are many testers who contributed to the listening test, I can't imagine things would change significantly.
The exact numerical outcome shouldn't be taken too serious anyway, and the confidence intervals should be respected.

The main outcome of the test can be trusted IMO which is:
- Apple Quicktime is better than Nero
- Apple Quicktime TVBR is not better than CVBR
- new FhG encoder is in the quality range of Apple Quicktime
- CT encoder is between Apple Quicktime and Nero qualitywise
- looking at the outcome of the individual samples there is no significant deviation of relative encoder quality from the average outcome over all the samples.
  As a consequence looking at the average result is sufficient for comparing encoder quality (with the last mp3@128 kbps test it was a different story).
- at least for the better encoders quality is very high for 96 kbps encodings - with sample 3 being an exception to this.
Title: lame 3.98.4, 3.99 alpha
Post by: IgorC on 2011-09-15 20:07:21
Does this indicate that, for example, the last public test @96 kbps would come out differently if the same people did the tests a second time?

No, it wouldn't be different at all. This phenomenon is canceled between different results of the listeners. It will be already  canceled on large number  of the samples for the same listener.
Testing AAC at 96 kbps isn't the same thing as testing LAME V0 (far from that).  The correlation between the average results and results of particular listener was quite high (70%).

Also this phenomenon doesn't happen for each sample and listener.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-09-28 22:35:12
3.99beta1 x86 and x64 compiles now at Rarewares.
Title: lame 3.98.4, 3.99 alpha
Post by: Fishman0919 on 2011-09-30 04:35:47
WOOT
Title: lame 3.98.4, 3.99 alpha
Post by: viktor on 2011-09-30 09:53:33
3.99beta1 x86 and x64 compiles now at Rarewares.


interesting results:

- 3.98.4 x86: 4:20
- 3.98.4 x64: 4:32
- 3.99b1 x86: 6:06
- 3.99b1 x64: 3:15

on the same sample with default settings.
Title: lame 3.98.4, 3.99 alpha
Post by: lvqcl on 2011-09-30 17:52:25
Maybe 32-bit version was compiled with optimizations for Intel processors only.
Title: lame 3.98.4, 3.99 alpha
Post by: viktor on 2011-09-30 23:53:34
Maybe 32-bit version was compiled with optimizations for Intel processors only.


maybe, but only the beta one?
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2011-10-03 10:17:30
John, there is something very odd with your x86-32 build, it's way too slow.
Just for comparison, mine compiled with VC9 Express edition (32 bits, haven't figured out how to set it up for x86-64 builds), running on AMD Athlon 64 X2, Win7-64:

Debug: 51
Release: 19
NASM: 17
SSE2: 14

now John's (Intel?) builds:
x86-32: 22
x86-64: 12

Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-10-03 11:48:18
Robert, having just tested the 32bit compile on a 1075T, hex core @3.6, it runs at about half the speed of the 64 bit compile, which is bizarre to say the least! I can't immediately think of anything that may be responsible, but I'll look into it and report back.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-10-03 16:11:47
OK, having recompiled using VS2008, not Intel, it would seem that this is the Intel screwing AMD issue! Here are two compiles x86 and x64, both non-Intel that I would like to be tested please:

x86 - http://homepage.ntlworld.com/jfe1205/LAME/lame3.99.b1_1.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.99.b1_1.zip)

x64 - http://homepage.ntlworld.com/jfe1205/LAME/....99.b1-64_1.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.99.b1-64_1.zip)

The testing I have done suggests that the speed of these is very little different on Intel CPUs to what it was using the Intel compiler. However, on AMD (I only have the hex core 1075T to test on) the x64 compile is around the same speed as before, but the x86 compile is around 50% faster.

I'd be interested in other peoples experiences and any other comments.
Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2011-10-03 18:49:17
A quad-core AMD Phenom II, XP Pro 32-bit, foobar2000, four simultaneous encoding processes, -S -V2 --noreplaygain - %d, source: 25 various wave tracks.

3.99b1 (x86)
Total encoding time: 1:23.719, 65.66x realtime

3.99b1_1 (x86)
Total encoding time: 0:53.688, 102.40x realtime

3.98.4 (the main bundle from Rarewares)
Total encoding time: 0:40.922, 134.34x realtime

3.98.4 (the VC6 compile from Rarewares)
Total encoding time: 0:41.625, 132.07x realtime
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-10-03 21:55:32
New Intel compiles with the 'icc-patcher' applied to both compiles. Seems to have no effect on running on Intel CPUs, but improves AMD CPU performance.

x86 - http://homepage.ntlworld.com/jfe1205/LAME/lame3.99.b1_1.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.99.b1_1.zip)

x64 - http://homepage.ntlworld.com/jfe1205/LAME/....99.b1-64_1.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.99.b1-64_1.zip)

Comments, etc., would be appreciated.
Title: lame 3.98.4, 3.99 alpha
Post by: robert on 2011-10-04 09:07:53
Your new Intel compiles seem OK, the x64-32 improved from 22 to 15 seconds in the same test as before.
I couldn't test your VS2008 ones, I was too late to the party, as you already replaced them with the IC ones.
Thanks John.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-10-04 09:54:44
Thanks guys, I'll replace the compiles on Rarewares with these.
Title: lame 3.98.4, 3.99 alpha
Post by: Alex B on 2011-10-04 11:09:50
The 'icc-patcher' compile (x86):
Total encoding time: 0:51.359, 107.04x realtime

It is slightly faster than the VS2008 compile. 3.98.4 is still quite a bit faster, but perhaps that is caused by the differences in the encoders.

I don't have a 64-bit OS installed so I can't compare the x86 and x64 versions.
Title: lame 3.98.4, 3.99 alpha
Post by: john33 on 2011-10-04 11:37:33
Thanks, Alex. I have the opposite problem, all my systems are now running Windows 7 x64!
Title: lame 3.98.4, 3.99 alpha
Post by: viktor on 2011-10-04 12:40:42
i guess i'm gonna stick with visual c++ builds from now.
Title: lame 3.98.4, 3.99 alpha
Post by: exx on 2011-10-09 10:34:43
Was using dbPowerAmp (which uses LAME) to convert some FLAC for my ipod and noticed it wasn't using my CPU to its full potential.

http://i.imgur.com/Kv9bR.png (http://i.imgur.com/Kv9bR.png)

Only goes up to ~15% per process. Total encoding speed was around 120-130x, which is much slower than normal. I was doing the same thing yesterday and all 4 cores were maxed. I don't have anything running in the background (besides the other 101 processes...lol). Could it be a HD speed issue? The input and output paths were on the same drive, but it's a WD Black so it's not terribly slow, and I didn't hear any drive noise.

Any ideas? 2x+ longer transcodes suck:(
Title: lame 3.98.4, 3.99 alpha
Post by: greynol on 2011-11-09 19:47:50
The Lame 3.99 Release thread can be found here:
http://www.hydrogenaudio.org/forums/index....=91372&st=0 (http://www.hydrogenaudio.org/forums/index.php?showtopic=91372&st=0)

This one will now close.  Thanks to everyone for their participation.