Release notes:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=HEAD
Rogério Brito
Don't include the debian directory as one that is needed during builds. Patch taken from Debian's packaging of lame.
Resurrect Owen Taylor's code dated from 97-11-3 to properly deal with GTK1. This was transplanted back from aclocal.m4 with a patch provided by Andres Mejia. This change makes it easy to regenerate autotools' files with a simple invocation of autoconf -vfi.
Fix possible race condition causing build failures in libmp3lame. Discovered in automated builds by the Debian project with patch provided by Andres Mejia.
Robert Hegemann
Improved detection of MPEG audio data in RIFF WAVE files. Tracker item [ 3545112 ] Invalid sampling detection
New switch --gain <decibel>, range -20.0 to +12.0, a more convenient way to apply Gain adjustment in decibels, than the use of --scale <factor>.
Fix for tracker item [ 3558466 ] Bug in path handling
Fix for tracker item [ 3567844 ] problem with Tag genre
Fix for tracker item [ 3565659 ] no progress indication with pipe input
Fix for tracker item [ 3544957 ] scale (empty) silent encode without warning
Fix for tracker item [ 3580176 ] environment variable LAMEOPT doesn't work anymore
Fix for tracker item [ 3608583 ] input file name displayed with wrong character encoding (on windows console with CP_UTF8)
Fix for bug ticket [ #447 ] Fix dereference NULL and Buffer not NULL terminated issues. Thanks to Surabhi Mishra
Fix for bug ticket [ #445 ] dereference of a null pointer possible in loop. Thanks to Renu Tyagi
Fix for bug ticket [ #449 ] Make sure functions with SSE instructions maintain their own properly aligned stack. Thanks to Fabian Greffrath
Fix for bug ticket [ #458 ] Multiple Stack and Heap Corruptions from Malicious File. Thanks to Gareth Evans and Elio Blanca
Fix for bug ticket [ #460 ] A division by zero vulnerability. Thanks to Wang Shiyang, Liu Bingchang
Fix for bug ticket [ #461 ] CVE-2017-9410 fill_buffer_resample function in libmp3lame/util.c heap-based buffer over-read and ap
Fix for bug ticket [ #462 ] CVE-2017-9411 fill_buffer_resample function in libmp3lame/util.c invalid memory read and application crash
Fix for bug ticket [ #463 ] CVE-2017-9412 unpack_read_samples function in frontend/get_audio.c invalid memory read and application crash
Fix for bug ticket [ #434 ] clip detect scale suggestion unaware of scale input value
HIP decoder bug fixed: decoding mixed blocks of lower sample frequency Layer3 data resulted in internal buffer overflow (write). Thanks to Henri Salo
Alexander Leidinger
Feature request, patch ticket [ #27 ] Add lame_encode_buffer_interleaved_int() by Michael Fink
Windows binaries by Chocobo1 at GitHub
https://github.com/Chocobo1/lame_win32-build/releases/tag/2017.10.15
Here too, much faster: http://tmkk.undo.jp/lame/index_e.html
Here too, much faster: http://tmkk.undo.jp/lame/index_e.html
Yup. i7-4700MQ 4GB wave64 to lame -V1, Chocobo1 about 43x realtime, tmkk about 62x.
I'm happy to see the security issues fixed and shipped, while sticking to the well-tested 3.99.5 quality.
There was a quality change, which was included in the Lame 3.100 alpha2, but removed in the Lame 3.100 main.
PSY model tunings, to improve audio quality of problem sample 'lead voice'
https://web.archive.org/web/20170608104650/http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=HEAD
I think there is not enough reason to believe the change improves the overall quality, based on my personal listening test below.
https://hydrogenaud.io/index.php/topic,113324.0.html
LAME development is culminated. Last quality changes were made 6 years ago.
In the other hand LAME developers have squeezed all out of what MP3 can do.
Thank You for release.
:) life continues ...
http://tmkk.undo.jp/lame/index_e.html
So, it's incorporating the latest changes but reports itself as version 3.99.5 to reassure users?
http://tmkk.undo.jp/lame/index_e.html
So, it's incorporating the latest changes but reports itself as version 3.99.5 to reassure users?
I see "LAME3.100".
Here too, much faster: http://tmkk.undo.jp/lame/index_e.html
Curious why the SSE stuff wasn't merged? Is there some downside?
Sorry for the absence of compiles on Rarewares, but I have been away from home for the last 2 weeks and I don't return until the end of this week. I will post compiles as soon as I'm able. :)
I was too impatient waiting for Windows binaries ;) - here https://1drv.ms/u/s!AL7dMfpnifu2gw4 (https://1drv.ms/u/s!AL7dMfpnifu2gw4) are my latest binaries of LAME 3.100, LAME 3.99.5 and GoGo-no-coda 3.13.
Compiled with GCC/MinGW using the original source code and safe compiler optimization flags. The binaries should perform equally well on Intel and AMD platforms.
Thanks, testing in few and btw ...the first two links have Win binaries.
WTF? The first one I tried goes at 450x. I'll keep testing then, thanks for this pack. Oh ok, GoGo is LAME 3.88.
gogo-313-sse2.exe give an error and the process stops, using Windows 10 Pro 64bit, I now realize that it was probably made for older Windows, right when it came out, since GoGo hasn't been developed in a long time.
Other 3.100 bins have similar speed to tmkk (but tmkk is still a little faster), I'll keep tmkk for now.
Thanks for the update, finally i can remove the "3.100 alpha2" from my laptop :)
You're welcome.
The reason i compiled the binaries by myself is that MSVC or ICL builds often do not perform as expected on the older AMD system i am using.
This is also the case for the Chocobo1 build. I'd like to have generic builds with a balanced performance across several platforms.
According to the website the modified AltiVec/SSE Optimized LAME Encoder version is specifically targeted on Intel processors (...binaries and
patches optimized for Intel and PowerPC G4/G5 processor.). As the GCC compiler is used, this one is quite speedy even on my AMD system.
Hmm - right now i have no idea why only the SSE2 version of GoGo crashes. I added this just for fun anyway...
I have tried to compile new lame 3.100 on macOS 10.13, but fails with the following portion:
> ./configure
> make
[SNIP]
libtool: link: gcc -dynamiclib -o .libs/libmp3lame.0.dylib .libs/VbrTag.o .libs/bitstream.o .libs/encoder.o .libs/fft.o .libs/gain_analysis.o .libs/id3tag.o .libs/lame.o .libs/newmdct.o .libs/presets.o .libs/psymodel.o .libs/quantize.o .libs/quantize_pvt.o .libs/reservoir.o .libs/set_get.o .libs/tables.o .libs/takehiro.o .libs/util.o .libs/vbrquantize.o .libs/version.o .libs/mpglib_interface.o -Wl,-force_load,../libmp3lame/vector/.libs/liblamevectorroutines.a -Wl,-force_load,../mpglib/.libs/libmpgdecoder.a -lm -install_name /usr/local/lib/libmp3lame.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module -Wl,-exported_symbols_list,.libs/libmp3lame-symbols.expsym
Undefined symbols for architecture x86_64:
"_lame_init_old", referenced from:
-exported_symbol[s_list] command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [libmp3lame.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
lame 3.99.5 can compile fine. I don't know what is wrong. Please help me!!!
I have tried to compile new lame 3.100 on macOS 10.13, but fails with the following portion:
> ./configure
> make
[SNIP]
libtool: link: gcc -dynamiclib -o .libs/libmp3lame.0.dylib .libs/VbrTag.o .libs/bitstream.o .libs/encoder.o .libs/fft.o .libs/gain_analysis.o .libs/id3tag.o .libs/lame.o .libs/newmdct.o .libs/presets.o .libs/psymodel.o .libs/quantize.o .libs/quantize_pvt.o .libs/reservoir.o .libs/set_get.o .libs/tables.o .libs/takehiro.o .libs/util.o .libs/vbrquantize.o .libs/version.o .libs/mpglib_interface.o -Wl,-force_load,../libmp3lame/vector/.libs/liblamevectorroutines.a -Wl,-force_load,../mpglib/.libs/libmpgdecoder.a -lm -install_name /usr/local/lib/libmp3lame.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module -Wl,-exported_symbols_list,.libs/libmp3lame-symbols.expsym
Undefined symbols for architecture x86_64:
"_lame_init_old", referenced from:
-exported_symbol[s_list] command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [libmp3lame.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
lame 3.99.5 can compile fine. I don't know what is wrong. Please help me!!!
See https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-lame/0006-dont-use-outdated-symbol-list.patch
See https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-lame/0006-dont-use-outdated-symbol-list.patch
Applied patch but still compile fails... ;(
No idea then, sorry :/
Remove the line containing 'lame_init_old' from the file 'include/libmp3lame.sym'
Remove the line containing 'lame_init_old' from the file 'include/libmp3lame.sym'
Wow!
Now I can compile lame 3.100 successfully!! I'm so happy!! :-)
Does the removed line is really needless one?
Sorry for the absence of compiles on Rarewares, but I have been away from home for the last 2 weeks and I don't return until the end of this week. I will post compiles as soon as I'm able. :)
Thanks John! Can you update the libmp3lame (x86 and x64) compiles too? I might be the only one using them, but I do use them!
Every time I want to get sources for lame, I have to navigate through these damn horrible sourceforge pages.
It get's me every friggin time! Finding the correct link or page where the actual code is at for me to download, etc. jeebus.
Maybe I'm just spoiled, but navigating github and gitlab is just so much easier and loads more pleasant, than that sf.net horribleness.
Kids: if you want the latest development tree for LAME: https://sourceforge.net/p/lame/svn/HEAD/tree/trunk/lame/
Finding the release source is much easier, though. Still, that friggin sf.net website...
maybe start with lame.sf.net and click get lame and folllow the link to source tarballs?
maybe start with lame.sf.net and click get lame and folllow the link to source tarballs?
Note the tarballs, the development tree. Especially /just/ the lame development tree of lame, not the entire trunk.
Once at https://sourceforge.net/projects/lame/files/lame/ you click on Code (SVN), then navigate to trunk > lame, and there's the code.
If you check out the code or click on "download snapshot" (which actually drops the file tree view), you get the entire code tree snapshot, you cannot checkout just this one project.
You always need to check out the entire trunk codebase, which contains several projects, instead of having a trunk for each project.
I've spent ages to figure out how to download / checkout the trunk sources for just one project (just lame), until finally realizing it's just not possible. Each time using a website that simply acts in completely weird ways. instead of giving me just a download link (for instance, when it has to be prepared beforehand, etc.) the download just starts, and then changes part of the view after the fact. If you navigate away from it, and then use the back-button, it restarts the download. Not immediately, it has like a little delay of a couple seconds, etc.
Completely infuriating.
It's like design wise, they were going for the website Microsoft Windows used in 2002, for Windows Update, where you needed a special IE plugin.
Files of Chocobo1 and tmkk don't null. Regardless of audibility, is it normal that different compilers yield different files?
[edit] Never mind. Just found that x86 and x64 builds of tmkk don't null as well.
Here too, much faster: http://tmkk.undo.jp/lame/index_e.html
with this patch applied, i get an error when i try compile x86
./configure --host=i686-w64-mingw32 --enable-shared --enable-static
and then "make -j2" leads to a
gain_analysis.c: In Funktion »filterYule«:
gain_analysis.c:216:5: error: impossible constraint in 'asm'
__asm__ __volatile__ (
^
From the RareWares 64bit build:
(https://i.imgur.com/0yEbFdc.png)
(https://i.imgur.com/hErzMuk.png)
OK, thanks, I'll sort it out.
john33, perfect thanks, let me know when and I'll test right away.
Do we have listening tests yet?
Corrected compiles uploaded. 32 bit and 64 bit versions tested on system without the Intel libraries present and load and work fine. 'More haste, less speed' called for, methinks! ;)
Very good and almost as fast as tmkk (~55x vs ~60x), will test more tomorrow.
I don’t know how he compiled, is there any reason we shouldn’t use tmkk?
tmkk's binaries aren't just a different compile. They use replacement functions that are faster but also produce different results.
Sorry for the absence of compiles on Rarewares, but I have been away from home for the last 2 weeks and I don't return until the end of this week. I will post compiles as soon as I'm able. :)
Thanks John! Can you update the libmp3lame (x86 and x64) compiles too? I might be the only one using them, but I do use them!
Could you kindly check these compiles to see if they are OK before I post the links at Rarewares? TIA. :)
libmp3lame-3.100x86.zip (http://www.rarewares.org/files/mp3/libmp3lame-3.100x86.zip)
libmp3lame-3.100x64.zip (http://www.rarewares.org/files/mp3/libmp3lame-3.100x64.zip)
@john33: thank you for the updated flac and lame versions at rarewares. will there also be a latest ogg lancer build as well?
I see "LAME3.100".
I get additional special characters depending on the encoding mode. With CBR the encoder is said to be "LAME3.100Í" and when using VBR it says "LAME3.100Ý". With Lame 3.99.5 I don't have this "problem". I tested all encoders from this thread. Can someone confirm this?
@john33: thank you for the updated flac and lame versions at rarewares. will there also be a latest ogg lancer build as well?
You're welcome. :) I may get round to the Lancer builds, but I don't believe the code's been updated in a long while, so I'm not sure there will be any benefit.
d4k0: That's an innerent problem of old programs assuming that the tag was going to be 8 characters always. The problem is that LAME3.100 is now 9 characters, and in C, the strings are terminated will a null character (code 0). Due to this discrepancy, now the string is not being terminated at the correct position with programs that didn't get around this possibility.
I've not had any problems with this build.
https://github.com/Chocobo1/lame_win32-build/releases
@john33: thank you for the updated flac and lame versions at rarewares. will there also be a latest ogg lancer build as well?
You're welcome. :) I may get round to the Lancer builds, but I don't believe the code's been updated in a long while, so I'm not sure there will be any benefit.
hm, i think there have been some minor changes (not qualitywise though) to ogg lancer indeed. anyway, after flac & lame it would be great to see a lancer update, too :)
I don’t know how he compiled, is there any reason we shouldn’t use tmkk?
All builds sometimes create different files, even the x86 and x64 version from the same bundle. From the null test results I am unable to tell which particular build has more differences than the others, plus I can't ABX them. Therefore I am going to use tmkk's version for the speed.
I learnt about the term "non-deterministic" in x264 but I think the situation is a bit different, since individual lame.exe always create identical mp3 files.
I wonder will the same lame.exe create different mp3 files when using different processors, like Intel vs AMD? Who wants to try?
Among the attached files, Rarewares-x86.mp3 is the only file which is different from others. However, if the original audio files are longer, all files are more likely to be different.
Confirm Rarewares-x86.mp3 is the only different one with bit-compare.
I don’t know how he compiled, is there any reason we shouldn’t use tmkk?
All builds sometimes create different files, even the x86 and x64 version from the same bundle. From the null test results I am unable to tell which particular build has more differences than the others, plus I can't ABX them. Therefore I am going to use tmkk's version for the speed.
I learnt about the term "non-deterministic" in x264 but I think the situation is a bit different, since individual lame.exe always create identical mp3 files.
I wonder will the same lame.exe create different mp3 files when using different processors, like Intel vs AMD? Who wants to try?
It's been discussed in detail before, but basically floating point numbers have rounding error, so each of the many ways you can compile a mathematical operation may give slightly different results due to how the numbers round. If you need deterministic output, you're probably looking for a lossless codec.
Here too, much faster: http://tmkk.undo.jp/lame/index_e.html
with this patch applied, i get an error when i try compile x86
./configure --host=i686-w64-mingw32 --enable-shared --enable-static
and then "make -j2" leads to a
gain_analysis.c: In Funktion »filterYule«:
gain_analysis.c:216:5: error: impossible constraint in 'asm'
__asm__ __volatile__ (
^
sorry i was wrong, it does work, i simply made a silly mistake. :(
tmkk's binaries aren't just a different compile. They use replacement functions that are faster but also produce different results.
"Different results" as in different from all other builds, or ... ? What exactly are the replacement functions in question? Maybe I am just dense, but this thread has taken a turn toward the confusing. Or rather, I am confused! So which is the better choice? The tmkk Windows build or the flac-1.3.2-git-20171020-x64 build available at Rarewares? I am just trying to follow all of this and am obviously failing.
You're even more confused than you think. LAME != FLAC. One's an MP3 encoder, lossy by definition, the other one's a lossless codec.
You're even more confused than you think. LAME != FLAC. One's an MP3 encoder, lossy by definition, the other one's a lossless codec.
Aren't i an idiot?! Shows you what two hours of sleep will do! I meant to say the rarewares lame3.100-64 or the tmkk build.
Sorry about that!
Unless you need to encode a lot of music very quickly I would use the standard lame builds. The difference in speed is not that compelling on modern hardware.
Aren't i an idiot?! Shows you what two hours of sleep will do!
It is not difficult to sleep 2 hours a day. It's difficult not to sleep the other 22 hours :))
Nice one! Thanks a lot for all your hard work on rarewares,
@john33 Edit: added work (oh, my!)
I assume LAME v3.100.2.0 is the newest LAME build? ; I ask because that's whats included with the newest Encoders Pack for Foobar2000 which was updated on Oct 15th 2017.
I think john33 made a new version because there was an issue with some DLLs and I believe that's just the CLI/.exe version for him for reference, last version of LAME is still the one in the first post.
From libmp3lame\version.h:
# define LAME_MAJOR_VERSION 3 /* Major version number */
# define LAME_MINOR_VERSION 100 /* Minor version number */
# define LAME_TYPE_VERSION 2 /* 0:alpha 1:beta 2:release */
# define LAME_PATCH_VERSION 0 /* Patch level */
So 3.100.2.0 means "release version of 3.100.0"
I'm so mad I never got into programming, one new thing, thanks for that.
So 3.100.2.0 means "release version of 3.100.0"
I'd rather say:
3.100.2.0 means "first release version of
3.100" (since you've included the 0 at the patch level).
3.100.0 means it's the alpha of
3.100.
Technically the major number is being changed, when things get incompatible with the prior version, minor versions are: things are still compatible with one another, but internals have changed (these might be quite extensive, including a full rewrite, but as long as it's all the same to the user, eh).
Patch levels are pertaining to a specific version and are not really sub-minor versions, rather they signify a consecutive number of bugfixes, and are generally thought of as assets that are in some form finished and can become exposed to the userbase.
Alpha. Beta, and release are cycles usually used for each version, and usually each of those has their own set of patch levels.
In that regard, the structure of LAMEs version numbering makes sense, although I think using the word "alpha", "beta" or "a", "b", or - my favorite - "α" or "β" in the version number field is more desirable.
Version numbers should be skipped if development of an intermediate version has been dropped. For instance let's assume you have Software Program "X", currently at version 3.141.59-beta. Now the developers decide, even though the beta has been rolled out for a while, it makes no sense to finish this version as it is hated by the userbase and making that version into a release would be a waste of time. So instead they keep everything compatible, but basically quickly pivot their design ideas, rewrite large portions of the code, change the interface, here and there, and release 3.142.0-alpha, and ask the userbase for test reports. If they like it, that version will get an increasing number of bugfixes rolled out as patches (third number after the last dot), and will eventually be upgraded to beta, and after that, the release will drop "alpha" or "beta" and just use the version number on its own.
Version numbering is all about the userbase, not the developers. Developers use subversioning internally, which is an ever increasing number of code commits to some sort of version tracking system. Except if you're from the 60's then you probably use a crayon to mark the number on your batch of punched cards or fan-folded 1" paper tape…
Some software projects, mainly geared towards professional users, kinda push this a little further into basically a joke. LaTeX for instance approaches π, currently at version
3.14159265-2.6-1.40.17 (TeX Live 2016). Each time they release a new version they add another digit to the first number after the first dot.
You always include as many numbers as needed to be unambiguous, but as little as it is convenient, when referring to it.
For instance, when you're encoding MP3 with LAME (not how I didn't use any numbers here), it makes sense to put the entire version number into one of the ID3 tags.
I found that I had not been running the latest binary in my post earlier in this thread. Once I discovered the error I also found the binary would not run on the older machine/OS anyway.
Thanks to john33 I was able to run LAME 3.100 on the same machine. If it matters, the output MP3 (at setting -V2) from version 3.100 was identical to 3.995 except for the tag which displayed the version.
I still appreciate this project. Thanks goes to the LAME team and an additional thanks to john33 for his continued efforts towards providing consistent compiles. :)
Congratulations on the new release, Devs! It's beeb a long long while since I last visited HA, but I'm glad to see some old faces still hanging around.
d4k0: That's an innerent problem of old programs assuming that the tag was going to be 8 characters always. The problem is that LAME3.100 is now 9 characters, and in C, the strings are terminated will a null character (code 0). Due to this discrepancy, now the string is not being terminated at the correct position with programs that didn't get around this possibility.
Well, Lame 3.95.5 is reported as "LAME3.99r" which is also 9 characters long (I have some C/C++ knowledge so I know what a null-terminated string is). Or is the the second digit (= 100) the problem as it now contains 3 characters?
What I also noticed is that files that were encoded with Lame 3.95.5 also showed some encoding settings:
(https://i.imgur.com/eMuF4tD.png)
This is how Lame 3.100 looks:
(https://i.imgur.com/BMqkUce.png)
what tool are you using?
For the screenshots I used PotPlayer, but I get the same results with other media players like "Light Alloy" or "MPC-HC". I think they all use MediaInfo which could be the "culprit" (the stand-alone MediaInfo program has the same output). With AIMP2, Foobar2000 or MP3Tag I don't get any information about the encoder.
foobar2000 shows me the version.
(https://i.imgur.com/OLyHcpq.png)
I tested with the lame build published on the foobar2000 website as part of the free encoder pack and also the 64bit version from rarewares.
Ah, I somehow missed the details tab. I now get the same result. So this is probably an issue with MediaInfo?
The bug is in file MediaInfo/Audio/File_Mpega.cpp line 1408. It assumes it reads the very first version of the lame info, because it makes the wrong test. In its first draft the version text was up to 20 bytes.
https://sourceforge.net/p/mediainfo/code/HEAD/tree/MediaInfoLib/trunk/Source/MediaInfo/Audio/File_Mpega.cpp
Thanks robert, I created an issue on their github repository and linked your response there.
Thanks robert, I created an issue on their github repository and linked your response there.
Thanks for the report about this bug in MediaInfo.
Fixed (https://github.com/MediaArea/MediaInfoLib/pull/656), Windows snapshot (https://mediaarea.net/download/snapshots/binary/mediainfo-gui/20171101-2/MediaInfo_GUI_17.09.20171101_Windows.exe) available.
Note: this is an hot fix, there is a debate (https://sourceforge.net/p/mediainfo/bugs/1070/#656a) about how to detect new LAME versions and corresponding Info tag, discussion is not closed in case a better method for detecting new versions is found.
v3.100 compiled with msvc2005
v3.100 compiled with clang 5.0 with msvc2010 lib
v3.100 compiled with http://tmkk.undo.jp/lame/index_e.html patch + clang 5.0 + icl 15 + msvc2010 lib + icl 15 lib
Corrected compiles uploaded. 32 bit and 64 bit versions tested on system without the Intel libraries present and load and work fine. 'More haste, less speed' called for, methinks! ;)
i may be the sole user of lamedrop (xpd), but was wondering if you'd be able to update that too at some point?
also, i guess this question is for anyone using the rarewares encodes, i got checksums from the a set of files (with the same setting from the same wav), one created with the 32 bit version and one created with the 64 bit version and got different results for the checksums...
i was wondering if this was normal, like i'm assuming it's just because they have a different footprint in the file somehow, i was just worried after the initial errors with the 64 bit version that something could be wrong. it seems fine, but i would have thought the checksums would be identical.
Corrected compiles uploaded. 32 bit and 64 bit versions tested on system without the Intel libraries present and load and work fine. 'More haste, less speed' called for, methinks! ;)
i may be the sole user of lamedrop (xpd), but was wondering if you'd be able to update that too at some point?
also, i guess this question is for anyone using the rarewares encodes, i got checksums from the a set of files (with the same setting from the same wav), one created with the 32 bit version and one created with the 64 bit version and got different results for the checksums...
i was wondering if this was normal, like i'm assuming it's just because they have a different footprint in the file somehow, i was just worried after the initial errors with the 64 bit version that something could be wrong. it seems fine, but i would have thought the checksums would be identical.
Thanks for the 'nudge'! I was planning to get round to lamedropXpd, that'll give me the hurry up.
The only difference between the original compiles and the 'corrected' ones is that the first ones needed the Intel runtime libraries and the 'corrected' ones were compiled against the static libraries. I would not expect 32 bit and 64 bit encodes to be bit identical since, apart from anything else, the 32 bit compiles use 'nasm' code and the 64 bit compiles do not. I don't believe anyone has ever been able to hear any difference in the results, but you're welcome to try!! ;)
But i would have thought the checksums would be identical.
They won't be bit identical because of the architectures. Same happens with FLAC, sometimes you get different files if you use a Linux binary encoder than a Windows compiled encoder.
But i would have thought the checksums would be identical.
They won't be bit identical because of the architectures. Same happens with FLAC, sometimes you get different files if you use a Linux binary encoder than a Windows compiled encoder.
What?
But i would have thought the checksums would be identical.
They won't be bit identical because of the architectures. Same happens with FLAC, sometimes you get different files if you use a Linux binary encoder than a Windows compiled encoder.
Seems like that would be a problem for a codec that claims to be lossless ;) Lossy codecs, on the other hand, do all sorts of funky float arithmetic that gives different results on different architectures or hardware.
Why doesn't the same file compressed on different machines with the same options yield the same FLAC file? (https://xiph.org/flac/faq.html#tools__different_sizes)
FLAC uses floating point math to determine a best way to compress input audio. So, two different encoders can choose different ways to losslessly compress input audio.
It seems i found strange bug.
Take mp3 320 kbps (i tried files created with lame 3.99 and 3.100) encoded using foobar2000's converter with -S -cbr -b 320 -q 0 --noreplaygain - %d. Re-encode this file using lame 3.100 (i tried different builds - tmkk, foobar2000 free encoder pack and rarewares) and foobar2000's converter with -S -cbr --noreplaygain - %d, highest BPS supported 32. Resulted mp3 file is 2 times longer and sounds horribly distorted.
If i do the same re-encoding using lame 3.99 - no problem. 32 bit builds were used.
Your parameters are wrong. The right parameter for CBR is --cbr. The data gets treated as RAW PCM and it's assumed to be 16 bits.
I just did a little test with the most recent SVN code. It compiles smoothly and fast but the encoding speed is terribly low, about x7(default settings) vs x27 with lame 3.95.
Am I missing something?
Figured it out, gcc optimization flags are missing after recent compiler detection change. Latest lame cannot really be compiled with gcc.
LAME development is culminated. Last quality changes were made 6 years ago.
In the other hand LAME developers have squeezed all out of what MP3 can do.
Thank You for release.
:) life continues ...
Couldn't have said it better...
LAME development is culminated. Last quality changes were made 6 years ago.
In the other hand LAME developers have squeezed all out of what MP3 can do.
Thank You for release.
:) life continues ...
Couldn't have said it better...
Yeah, LAME has definitely reached its pinnacle ever since.
The finest MP3, as a format, will ever be.
LAME development is culminated. Last quality changes were made 6 years ago.
In the other hand LAME developers have squeezed all out of what MP3 can do.
Thank You for release.
:) life continues ...
Couldn't have said it better...
Yeah, LAME has definitely reached its pinnacle ever since.
The finest MP3, as a format, will ever be.
Not according to some ABX. Also, it's extremely slow.
I meant in terms of what LAME could milk, quality-wise, out of the MP3 format itself; as the problem samples detectable during ABX'ing seem to be inherent to that format.
hi everybody, anyone knows how can i pass the dB value computed with the --replaygain-accurate switch into the new --gain switch?
i may be the sole user of lamedrop (xpd), but was wondering if you'd be able to update that too at some point?
+1
You are not alone :)
hi everybody, anyone knows how can i pass the dB value computed with the --replaygain-accurate switch into the new --gain switch?
As an example, the output was
ReplayGain: -8.3dB then add
--gain -8.3 to your command line.
hi everybody, anyone knows how can i pass the dB value computed with the --replaygain-accurate switch into the new --gain switch?
As an example, the output was ReplayGain: -8.3dB then add --gain -8.3 to your command line.
yes that is simple and even i managed to realize it. :)
but there is a way to do something like
lame -V 0 -S --gain $(--replaygain-accurate ) inputfile outputfile
just to encode with the right volume in one passage ?
Well, you could use wavgain to calculate replaygain, though it doesn't take mp3 specifics into account, it may be good enough.
To give you some example, take a look at the following bash script:
https://sourceforge.net/p/lame/svn/HEAD/tree/trunk/lame/misc/mk_mp3.sh
i may be the sole user of lamedrop (xpd), but was wondering if you'd be able to update that too at some point?
+1
You are not alone :)
LamedropXPd updated compiles are now on Rarewares. Sorry for the delay. ;)
LamedropXPd updated compiles are now on Rarewares.
Thanks a lot! :)
A small glitch: even though the About window says "Using LAME 3.100.0" the Encoding Options window says "Using LAME 3.99.5 encoding engine".
Ooops!! That's only narrative, it was compiled using 3.100, but I'll make the change and upload again. Thanks for the 'heads up'. ;)
New LamedropXPd compiles uploaded with the narrative corrected. :)
New LamedropXPd compiles uploaded with the narrative corrected. :)
thanks!
Here my tests:
Chocobo1 (msvc2017, nasm 2.13.01)
32bit - 68x
64bit - 58x
Files produced: same
--
Descrates (all are 32bits)
tmkk patch + clang 5.0 + icl 15 + msvc2010 lib + icl 15 lib - 76x
clang 5.0 with msvc2010 lib - 65x
msvc2005 - 47x
Files produced: same for clang versions, msvc2005 different than clang
--
Tmkk (gcc-5.4/MinGW)
32bit - 79x
64bit - 79x
Files produced: same
--
Rarewares (Intel Compiler)
32bit - 60x
64bit - 75x
Files produced: different, comparing says one of them produces 3 clicks at the beggining. Otherwise they null.
--
Foobar2000 (no compiler info)
32bit - 64x
Looks like Rarewares build is fastest without patches. But the problem is 32bit & 64bit versions don't null and three pops appear in beggining of one of the files (when null compared). I have no idea why if they use same Intel Compiler.
Maybe it should be recompiled again?
If there is any assembly in a program, and you aren't disabling assembly, then the 32 and 64 bit versions won't be running the same code paths. For this reason you shouldn't expect the results to be identical.
L.A.M.E. v3.100
Built on December 12, 2017, GCC 7.2.0
http://lame.sourceforge.net
I've re-compiled and uploaded the lame bundles. The 32 bit version appears unchanged, but there is a difference with the 64 bit version. Personally, I can't hear a difference, but maybe someone can do a more exhaustive check. :)
Here too, much faster: http://tmkk.undo.jp/lame/index_e.html
with this patch applied, i get an error when i try compile x86
./configure --host=i686-w64-mingw32 --enable-shared --enable-static
and then "make -j2" leads to a
gain_analysis.c: In Funktion »filterYule«:
gain_analysis.c:216:5: error: impossible constraint in 'asm'
__asm__ __volatile__ (
^
sorry i was wrong, it does work, i simply made a silly mistake. :(
Hello, how your fix this error? Thank you in advance.
pretty easy... SSE2 (-msse2) is mandatory to compile this patched version.
pretty easy... SSE2 (-msse2) is mandatory to compile this patched version.
how will look the command for configuration and compilation?
tmkk patch + clang 6.0 + msvc2010 lib + icl 16 lib
Looks like Rarewares build is fastest without patches. But the problem is 32bit & 64bit versions don't null and three pops appear in beggining of one of the files (when null compared). I have no idea why if they use same Intel Compiler.
Maybe it should be recompiled again?
What program do you use for this comparison? Those pops are not audible for you?
I've re-compiled and uploaded the lame bundles. The 32 bit version appears unchanged, but there is a difference with the 64 bit version. Personally, I can't hear a difference, but maybe someone can do a more exhaustive check. :)
I have compared 4 files encoded with your 64-bit version compiled in October and in December. Binary comparator in foobar2000 says "no differences found".
BTW, I am converting using foobar2000 converter. Is it in any way important that I am inititating 64-bit LAME encoder from foobar2000 which is 32-bit program?
I've re-compiled and uploaded the lame bundles. The 32 bit version appears unchanged, but there is a difference with the 64 bit version. Personally, I can't hear a difference, but maybe someone can do a more exhaustive check. :)
I have compared 4 files encoded with your 64-bit version compiled in October and in December. Binary comparator in foobar2000 says "no differences found".
BTW, I am converting using foobar2000 converter. Is it in any way important that I am inititating 64-bit LAME encoder from foobar2000 which is 32-bit program?
I didn't expect there to be any difference between the Oct and Dec compiles, I just re-checked the compile options just to be sure that I hadn't missed something the first time round. ;) I also usually convert using Foobar as you specify and, no, that isn't an issue.
I didn't expect there to be any difference between the Oct and Dec compiles, I just re-checked the compile options just to be sure that I hadn't missed something the first time round. ;)
"Slivka" was saying that your "32bit & 64bit versions don't null and three pops appear in beggining of one of the files (when null compared)" so I thought you are recompiling to check if this is eliminated :) Are those "pops" even confirmed? As I understand 32-bit and 64-bit compiled versions can produce slightly different files in encoding, but I don't know what he meant by "three pops in the beginning". Three pops that can be heard or just three bits with different values?
tmkk patch + fastcrc patch + clang 8.0 snapshot (Full LTO) + msvc2010 lib
I may be the sole user of lamedrop (xpd) . . .
+1
You are not alone :)
Me too. LameDropXPd has been my "go-to" Lame frontend for a long time.
New LamedropXPd compiles uploaded with the narrative corrected. :)
Thanks John. And for all the work you do for making our music enjoyment better.
Artie
Why when compressing to V0 there's 20kHz lowpass on 3.100 when in LAME 3.99 that lowpass was removed? I know I should listen with my ears not eyes and I'm not saying 3.99 sounds better because of this, but I'm just curious why it was removed in 3.99 and then added again in 3.100. Thank you for help.
lame.exe -V0 test.wav
LAME 3.100 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
polyphase lowpass filter disabled
Encoding test.wav to test.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=0)
So no, there's no 20 kHz lowpass.
Maybe there's no lowpass filter, but comparing to 3.99r there's much less audio above 20kHz:
(https://i.imgur.com/elDPfZm.jpg)
I'm using LAME 3.100 64bit build from RareWares if that matters.
I'm using LAME 3.100 64bit build from RareWares if that matters.
Are you REALLY sure?
I just tested 3.100-2 (-2 being a distribution second edition, -1 would be the first release of that version).
Top is original, bottom is 3.100 -V0.
It seems that there is some bug in original build from tmkk. On some files when encoding with
-S --noreplaygain -V 0 encoder crashes with error and resulting mp3 file is corrupted.
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
LAME 3.100 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
polyphase lowpass filter disabled
Encoding D:\Music\I Love Disco Diamonds Collection\I Love Disco Diamonds Collection Vol. 14\02. Yeti.wav
to D:\Music\I Love Disco Diamonds Collection\I Love Disco Diamonds Collection Vol. 14\02. Yeti.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=0)
Assertion failed!
Program: D:\0__CODECS\Lossy\LAME\3.100\lame_tmkk.exe
File: ../../libmp3lame/vbrquantize.c, Line 948
Expression: vbrsf[sfb] >= vbrsfmin[sfb]
Windows 7 32 bit, core i3 3245
File is too long to share here, but if someone is interested, i can send link in PM. It is track #2 from CD #14 from compilation "I Love Disco Diamonds Collection"
tmkk already reported the bug and a fix is in SVN.
https://sourceforge.net/p/lame/bugs/496/
https://sourceforge.net/p/lame/svn/6438/tree//trunk/lame/libmp3lame/vector/xmm_quantize_sub.c?diff=59e1c885dab7b929b5817e2e:6437
Seems like you are running a debug version.
tmkk already reported the bug and a fix is in SVN.
https://sourceforge.net/p/lame/bugs/496/
https://sourceforge.net/p/lame/svn/6438/tree//trunk/lame/libmp3lame/vector/xmm_quantize_sub.c?diff=59e1c885dab7b929b5817e2e:6437
Seems like you are running a debug version.
Is compiled binary with fix available somewhere? I used binary from tmkk's site dated 2017.10.14
Binaries of LAME snapshot [r6438] https://sourceforge.net/p/lame/svn/HEAD/tree/trunk/lame/ with
https://tmkk.undo.jp/lame/lame-3.100-sse-20171014.diff and
https://freac.org/patches/lame-3.100-fastcrc.diff patch applied.
tmkk patch + fastcrc patch + clang-cl 9.0 snapshot (Full LTO, SSE2 (ASM used) forcing, AMD procie target) + msvc2013 lib (WinXP SP3)
btw unstable
tmkk patch + fastcrc patch + clang-cl 9.0 snapshot (Full LTO, SSE2 (ASM used) forcing, AMD procie target) + msvc2013 lib (WinXP SP3)
btw unstable
Hello friend, can you tell me how to compile Lame encoder?I like this small and easy-to-use coding scheme very much, so I want to delve into it.
Can you tell me?I look forward to your reply, best wishes.
:)
Perhaps,
You can also record a video the next time you make it.
English is not very good, I'm sorry :)
tmkk patch + fastcrc patch + clang-cl 9.0 snapshot (Full LTO, SSE2 (ASM used) forcing, AMD procie target) + msvc2013 lib (WinXP SP3)
btw unstable
Hello friend, can you tell me how to compile Lame encoder?I like this small and easy-to-use coding scheme very much, so I want to delve into it.
Can you tell me?I look forward to your reply, best wishes.
:)
compile lame via clang-cl?
in simplest (as example)
1st install msvc/visual studio 2017 x64
[or 2010/2013/2015 etc]
then...
1. download clang x64 snapshot or stable for windows
open with 7zip (keep default msvc's config)
(1) select file
1. clang-cl.exe
2. lld-link.exe
3. llvm-lib.exe
copy & paste into /bin/ in "VC folder" (/bin/HostX64/x64/)
[in visual studio folder]
rename llvm-lib.exe -> lib.exe
[1st backup msvc's lib.exe]
(2) select all folder in /lib/
copy & paste into /lib/ in "VC folder" (/lib/x64)
[in visual studio folder]
2. download nasm for windows
open with 7zip
select file -> nasm.exe
copy & paste into /bin/ in "VC folder"
[in visual studio folder]
rename nasm.exe -> nasmw.exe
3. edit makefile.msvc (in /lame-svn-?-trunk/lame/)
[in msvc config section]
replace string
cl -> clang-cl [flags]
link -> lld-link /force [flags]
link -> lld-link /force /DLL [flags] to combating lame_enc.dll
then save
4. select file -> lame.h "lame header file"
(in /lame-svn-?-trunk/lame/include/)
copy & paste into /include/ in "VC folder"
[in visual studio folder]
5. open visual c++ command prompt
cd /lame-svn-?-trunk/lame/
nmake -f makefile.msvc lame_enc.dll
cd output
6. if visual studio 2019 + clang-cl can create lame.exe
but "no speed" in Win10
(1) grab lib
grab libmmt.lib & libirc.lib from intel compiler lib
grab libucrtbase.a from mingw-w64 runtime 6.0
rename libucrtbase.a -> libucrt.lib
copy & paste into /lib/ in "VC folder"
[in visual studio folder]
[1st backup msvc's libucrt.lib]
(2) linking into libmmt.lib
edit /frontend/main.obj
replace string
libcmt.lib -> libmmt.lib
(3) _strnlen missing in parse.obj
open msvc's libucrt.lib with 7zip
search strnlen.obj
copy & paste into /lib/ in "VC folder"
[in visual studio folder]
convert strnlen.obj -> custom.lib
edit /frontend/parse.obj
replace string
libcmt.lib -> custom.lib
tmkk patch + clang 9.0 snapshot (Full LTO, Intel procie target) + msvc2013 lib + icl17 lib
no fastcrc patch (contra with icl17 lib)
tmkk patch + clang 10.0 snapshot (Full LTO, psymodel w/ -fveclib=SVML (SVML exp2 forcing), Intel procie target) + msvc2010 lib + svml 15 lib
-V0 & -V1 "higher" bitrate testing