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.
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)
(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)
Thank you so much how can I get lame x64 to work with dbpoweramp? sorry for the noob question
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.
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).
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 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.
No problem with NOD32.
But I'll wait...
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)
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/)
From changelog:
Robert Hegemann
Fix for Bugtracker item [ 2973877 ] A problem regarding the new drain code
But what a problem was??
But what a problem was??
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
So now the smoke has cleared ... thanks for the heads-up (and the quick compile) tsnr.
A full set of win 32 builds of 3.98.4 is now at Rarewares as is the 3.99a3 bundle.
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.
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?
I confirm the rarewares problem too!
Same for me but I use this address (http://www.rarewares.org/mp3-lame-bundle.php)
So, what compile should I use? Posted by the topic starter or downloaded from rarewares? o.O
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!
It works now. Thanks.
It works now. Thanks.
Thank you kindly.
Can someone tell me why I'm getting different audiostreams with compiles by
tsnr and
john33??
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
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.
Can someone tell me why I'm getting different audiostreams with compiles by tsnr and john33??
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?
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...
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
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
WinXP 32bit. Core2 Duo E4600. lame -S --noreplaygain -b320 -q0.
rarewares:
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:
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.
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?
Interesting read:
Does Intel's compiler cripple AMD performance? (http://techreport.com/discussions.x/8547)
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.
Everyone talks about the differences in performance but nobody cares, what is the difference between the output files and where it come from??
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.
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.
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?
See post #24.
Audio steams are different, so the wave files will be different too and they can not be "bit-for-bit equal".
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!
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.
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...
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.
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.
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.
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...
.....
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.
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.
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
...(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.
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.
john33, thanks for all builds
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.
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!)
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?
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.
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.
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)
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!
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.
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)
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)
LAME 3.99alpha4 bundle now at Rarewares.
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.
Thanks
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)
I'll use Rare Wares. Hopefully, they'll update the compiler soon to 11.1.065.
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.)
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!
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)
3.99a9 bundle also at Rarewares.
Thanks!
<deleted>
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
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)
3.99a10 bundle also at Rarewares.
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)
Updated 3.99a10 bundle also at Rarewares.
Updated 3.99a10 bundle also at Rarewares.
...still no official x64 builds ?
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.
How much of a speed difference is there between 3.98.4 and 3.99.a10 ?
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.
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.
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.
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)
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) )
Have tried with different versions of iccpatch (GUIed one too). Didn't work.
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.
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.
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)
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
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)
Hm, I see that bitrate distribution is different for two compiles:
Alpha 10 from here:
http://lame.bakerweb.biz/ (http://lame.bakerweb.biz/)
and
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
Hm, I see that bitrate distribution is different for two compiles:
Alpha 10 from here:
http://lame.bakerweb.biz/ (http://lame.bakerweb.biz/)
and 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)
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)
Same file using -V2.
Rareware, My MSV VC9, Bakerweb, My MinGW build
(http://i467.photobucket.com/albums/rr37/fishman0919/all4builds.png)
Yes, different compiles produce different file.
But why??
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
So, now I must ask: which is the best? Of course, in terms of quality
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.
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.
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.
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>
Edit Makefile.MSVC and remove /opt:NOWIN98 around line 236.
Edit Makefile.MSVC and remove /opt:NOWIN98 around line 236.
Thank You
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
The difference between them was a small digital 1-bit noise.
Really? Usually differences are much bigger.
tsnr (bakerweb.biz)
tsnr is not bakerweb.biz.
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)
It's vbr new 2.0
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.
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.
http://www.hydrogenaudio.org/forums/index....st&p=741978 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85119&view=findpost&p=741978)
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
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
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)
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?
Interesting. Now last alpha preserves frequencies up to 22 Khz (V0).
What is vbr_mt exactly? And why it was set as default instead of the former vbr_new?
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.
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
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.
@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.
@Robert
Sorry for a little bit off-top, but When do you plan to come into 3.99beta stage?
Alpha 13 bundles are at Rarewares.
@Robert
Sorry for a little bit off-top, but When do you plan to come into 3.99beta stage?
Probably in March...
I noticed that alpha 13 is not inserting the Lame Header??
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?
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
It seems, Foobar2000 assumes the "Encoder short VersionString" has to start with LAME.
@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.
Lame 3.99a14 is up... LINK -"http://www.mediafire.com/?7iva5wwo7ld4wr6"
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.
Alpha 14 bundles are now at Rarewares.
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.
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.
Where can I find an up to date ChangeLog for Lame?
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.
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
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.
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.
Not currently, but I'll have a look at producing one.
Much obliged, thanks again.
Lame 3.99a16 is available.
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.
Lame 3.99a16 is available.
At Rarewares.
Lame 3.99a16 is available.
At Rarewares.
Thank You!
Hi Guys!
What is the change list?
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
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/).
Beta 0 compiles now at Rarewares.
Still serious problems with this sample :
http://www.hydrogenaudio.org/forums/index....showtopic=55340 (http://www.hydrogenaudio.org/forums/index.php?showtopic=55340)
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.
IS V0 getting so high bit-rates to the point we can forget it ad just use 320 cbr
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
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%)
Where can I find a source tarball for 3.99b0?
Where can I find a source tarball for 3.99b0?
I'm not sure you can, you may have to do a CVS Checkout.
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
I can't believe I didn't see that. That whole page. Now bookmarked.
Thanks a lot!
Have the old psymodels been removed from the code? Is there any way to download a tarball of the CVS before March 5, 2011?
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).
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 ?
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.
I've recompiled this using static libraries in the same way the the regular .dll is compiled. I've re-uploaded to Rarewares.
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
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.
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)
Ah, that's good.
Is Lame on hold?
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)
I ask this again...
Is Lame on hold... Dead?
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.
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.
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?
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.
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)
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!
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.
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?
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.
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.
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.
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.
...
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.
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.
...
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.
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)
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).
Thank You too for bringing this out.
It makes me remember of the previous issues and re-think, improve some technics.
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...
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.
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.
3.99beta1 x86 and x64 compiles now at Rarewares.
WOOT
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.
Maybe 32-bit version was compiled with optimizations for Intel processors only.
Maybe 32-bit version was compiled with optimizations for Intel processors only.
maybe, but only the beta one?
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
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.
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.
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
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.
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.
Thanks guys, I'll replace the compiles on Rarewares with these.
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.
Thanks, Alex. I have the opposite problem, all my systems are now running Windows 7 x64!
i guess i'm gonna stick with visual c++ builds from now.
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:(
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.