Hydrogenaudio Forums

Lossy Audio Compression => MP3 => MP3 - General => Topic started by: apastuszak on 2017-10-14 17:00:14

Title: Lame 3.100 has been released
Post by: apastuszak on 2017-10-14 17:00:14
Release notes:

http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=HEAD

Quote
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

Title: Re: Lame 3.100 has been released
Post by: o-l-a-v on 2017-10-14 19:03:59
Windows binaries by Chocobo1 at GitHub
https://github.com/Chocobo1/lame_win32-build/releases/tag/2017.10.15
Title: Re: Lame 3.100 has been released
Post by: eahm on 2017-10-14 19:26:15
Here too, much faster: http://tmkk.undo.jp/lame/index_e.html
Title: Re: Lame 3.100 has been released
Post by: o-l-a-v on 2017-10-14 19:43:16
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.
Title: Re: Lame 3.100 has been released
Post by: Kamedo2 on 2017-10-15 10:56:43
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.
Quote
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



Title: Re: Lame 3.100 has been released
Post by: IgorC on 2017-10-15 14:35:00
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 ...
Title: Re: Lame 3.100 has been released
Post by: Destroid on 2017-10-15 19:21:08
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?
Title: Re: Lame 3.100 has been released
Post by: eahm on 2017-10-15 19:50:49
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".
Title: Re: Lame 3.100 has been released
Post by: saratoga on 2017-10-16 16:52:59
Here too, much faster: http://tmkk.undo.jp/lame/index_e.html

Curious why the SSE stuff wasn't merged?  Is there some downside?
Title: Re: Lame 3.100 has been released
Post by: john33 on 2017-10-16 20:22:59
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. :)
Title: Re: Lame 3.100 has been released
Post by: 145dBSPL on 2017-10-17 08:42:42
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.
Title: Re: Lame 3.100 has been released
Post by: eahm on 2017-10-17 08:44:36
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.
Title: Re: Lame 3.100 has been released
Post by: rizukitomi on 2017-10-17 08:51:15
Thanks for the update, finally i can remove the "3.100 alpha2" from my laptop :)
Title: Re: Lame 3.100 has been released
Post by: 145dBSPL on 2017-10-17 09:29:24
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...
Title: Re: Lame 3.100 has been released
Post by: xanadu6291 on 2017-10-17 23:21:33
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!!!
Title: Re: Lame 3.100 has been released
Post by: lazka on 2017-10-19 10:58:30
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
Title: Re: Lame 3.100 has been released
Post by: xanadu6291 on 2017-10-19 11:30:37
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...  ;(
Title: Re: Lame 3.100 has been released
Post by: lazka on 2017-10-19 12:30:14
No idea then, sorry :/
Title: Re: Lame 3.100 has been released
Post by: robert on 2017-10-19 14:15:32
Remove the line containing 'lame_init_old' from the file 'include/libmp3lame.sym'
Title: Re: Lame 3.100 has been released
Post by: xanadu6291 on 2017-10-19 14:47:22
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?
Title: Re: Lame 3.100 has been released
Post by: Jebus on 2017-10-19 18:56:22
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!
Title: Re: Lame 3.100 has been released
Post by: polemon on 2017-10-19 23:28:15
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...
Title: Re: Lame 3.100 has been released
Post by: robert on 2017-10-20 07:50:16
maybe start with lame.sf.net and click get lame and folllow the link to source tarballs?
Title: Re: Lame 3.100 has been released
Post by: polemon on 2017-10-20 09:50:00
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.
Title: Re: Lame 3.100 has been released
Post by: bennetng on 2017-10-20 13:08:23
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.
Title: Re: Lame 3.100 has been released
Post by: madmax on 2017-10-20 18:18:52
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
Quote
gain_analysis.c: In Funktion »filterYule«:
gain_analysis.c:216:5: error: impossible constraint in 'asm'
     __asm__ __volatile__ (
     ^
Title: Re: Lame 3.100 has been released
Post by: eahm on 2017-10-21 17:50:52
From the RareWares 64bit build:

(https://i.imgur.com/0yEbFdc.png)

(https://i.imgur.com/hErzMuk.png)
Title: Re: Lame 3.100 has been released
Post by: john33 on 2017-10-21 18:05:21
OK, thanks, I'll sort it out.
Title: Re: Lame 3.100 has been released
Post by: eahm on 2017-10-21 22:08:53
john33, perfect thanks, let me know when and I'll test right away.
Title: Re: Lame 3.100 has been released
Post by: polemon on 2017-10-22 10:21:35
Do we have listening tests yet?
Title: Re: Lame 3.100 has been released
Post by: john33 on 2017-10-22 11:07:59
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! ;)
Title: Re: Lame 3.100 has been released
Post by: eahm on 2017-10-22 11:57:45
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?
Title: Re: Lame 3.100 has been released
Post by: Case on 2017-10-22 13:03:13
tmkk's binaries aren't just a different compile. They use replacement functions that are faster but also produce different results.
Title: Re: Lame 3.100 has been released
Post by: john33 on 2017-10-22 13:15:33
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)
Title: Re: Lame 3.100 has been released
Post by: sanskrit44 on 2017-10-22 15:52:46
@john33: thank you for the updated flac and lame versions at rarewares. will there also be a latest ogg lancer build as well?
Title: Re: Lame 3.100 has been released
Post by: d4k0 on 2017-10-22 16:01:08
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?
Title: Re: Lame 3.100 has been released
Post by: john33 on 2017-10-22 16:28:53
@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.
Title: Re: Lame 3.100 has been released
Post by: [JAZ] on 2017-10-22 17:15:05
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.
Title: Re: Lame 3.100 has been released
Post by: soundping on 2017-10-22 18:37:31
I've not had any problems with this build.
https://github.com/Chocobo1/lame_win32-build/releases
Title: Re: Lame 3.100 has been released
Post by: sanskrit44 on 2017-10-22 18:46:37
@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 :)
Title: Re: Lame 3.100 has been released
Post by: bennetng on 2017-10-22 20:03:55
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.

Title: Re: Lame 3.100 has been released
Post by: eahm on 2017-10-22 20:10:15
Confirm Rarewares-x86.mp3 is the only different one with bit-compare.
Title: Re: Lame 3.100 has been released
Post by: saratoga on 2017-10-22 20:23:40
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.
Title: Re: Lame 3.100 has been released
Post by: madmax on 2017-10-22 22:36:18
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
Quote
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. :(
Title: Re: Lame 3.100 has been released
Post by: Pepzhez on 2017-10-24 00:34:47
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.
Title: Re: Lame 3.100 has been released
Post by: kode54 on 2017-10-24 01:40:42
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.
Title: Re: Lame 3.100 has been released
Post by: Pepzhez on 2017-10-24 02:07:09
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!
Title: Re: Lame 3.100 has been released
Post by: saratoga on 2017-10-24 04:35:58
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.
Title: Re: Lame 3.100 has been released
Post by: mpuzirew on 2017-10-24 13:53:30
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 :))
Title: Re: Lame 3.100 has been released
Post by: includemeout on 2017-10-24 14:19:56
Nice one! Thanks a lot for all your hard work on rarewares, @john33

Edit: added work (oh, my!)
Title: Re: Lame 3.100 has been released
Post by: ThaCrip on 2017-10-28 08:47:37
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.
Title: Re: Lame 3.100 has been released
Post by: eahm on 2017-10-28 09:29:28
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.
Title: Re: Lame 3.100 has been released
Post by: lvqcl on 2017-10-28 09:50:34
From libmp3lame\version.h:
Code: [Select]
# 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"
Title: Re: Lame 3.100 has been released
Post by: eahm on 2017-10-28 09:55:39
I'm so mad I never got into programming, one new thing, thanks for that.
Title: Re: Lame 3.100 has been released
Post by: polemon on 2017-10-29 11:37:28
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.
Title: Re: Lame 3.100 has been released
Post by: Destroid on 2017-10-29 15:12:04
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. :)
Title: Re: Lame 3.100 has been released
Post by: LoFiYo on 2017-10-31 04:17:58
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.
Title: Re: Lame 3.100 has been released
Post by: d4k0 on 2017-10-31 15:54:55
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)
Title: Re: Lame 3.100 has been released
Post by: robert on 2017-10-31 16:11:42
what tool are you using?
Title: Re: Lame 3.100 has been released
Post by: d4k0 on 2017-10-31 16:35:35
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.
Title: Re: Lame 3.100 has been released
Post by: marc2003 on 2017-10-31 16:45:20
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.



Title: Re: Lame 3.100 has been released
Post by: d4k0 on 2017-10-31 16:57:51
Ah, I somehow missed the details tab. I now get the same result. So this is probably an issue with MediaInfo?
Title: Re: Lame 3.100 has been released
Post by: robert on 2017-10-31 17:07:02
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
Title: Re: Lame 3.100 has been released
Post by: d4k0 on 2017-10-31 17:33:25
Thanks robert, I created an issue on their github repository and linked your response there.
Title: Re: Lame 3.100 has been released
Post by: Zenitram on 2017-11-01 12:53:46
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.
Title: Re: Lame 3.100 has been released
Post by: descrates on 2017-11-09 23:30:51
v3.100 compiled with msvc2005
Title: Re: Lame 3.100 has been released
Post by: descrates on 2017-11-14 00:35:39
v3.100 compiled with clang 5.0 with msvc2010 lib
Title: Re: Lame 3.100 has been released
Post by: descrates on 2017-11-14 05:34:27
v3.100 compiled with http://tmkk.undo.jp/lame/index_e.html patch + clang 5.0 + icl 15 + msvc2010 lib + icl 15 lib
Title: Re: Lame 3.100 has been released
Post by: izmo on 2017-11-14 05:52:41
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.
Title: Re: Lame 3.100 has been released
Post by: john33 on 2017-11-14 07:50:55
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!! ;)
Title: Re: Lame 3.100 has been released
Post by: krafty on 2017-11-14 17:19:02
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.
Title: Re: Lame 3.100 has been released
Post by: eahm on 2017-11-14 17:37:11
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?
Title: Re: Lame 3.100 has been released
Post by: lithopsian on 2017-11-14 20:25:49
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.
Title: Re: Lame 3.100 has been released
Post by: lvqcl on 2017-11-14 20:32:31
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.
Title: Re: Lame 3.100 has been released
Post by: Rollin on 2017-11-15 18:36:06
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.
Title: Re: Lame 3.100 has been released
Post by: Case on 2017-11-15 19:52:44
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.
Title: Re: Lame 3.100 has been released
Post by: knik on 2017-11-16 09:58:24
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?
Title: Re: Lame 3.100 has been released
Post by: knik on 2017-11-17 11:32:55
Figured it out, gcc optimization flags are missing after recent compiler detection change. Latest lame cannot really be compiled with gcc.
Title: Re: Lame 3.100 has been released
Post by: ajfoucault on 2017-11-21 19:21:17
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...
Title: Re: Lame 3.100 has been released
Post by: includemeout on 2017-11-21 21:14:47
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.
Title: Re: Lame 3.100 has been released
Post by: Funkstar De Luxe on 2017-11-23 09:43:16
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.
Title: Re: Lame 3.100 has been released
Post by: includemeout on 2017-11-23 11:17:32
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.
Title: Re: Lame 3.100 has been released
Post by: tuxnowar on 2017-11-27 19:52:05
hi everybody, anyone knows how can i pass the dB value computed with the --replaygain-accurate switch into the new --gain switch?
Title: Re: Lame 3.100 has been released
Post by: Brazil2 on 2017-11-28 10:14:15
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 :)
Title: Re: Lame 3.100 has been released
Post by: robert on 2017-11-28 12:51:22
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.
Title: Re: Lame 3.100 has been released
Post by: tuxnowar on 2017-11-28 16:35:46
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 ?
Title: Re: Lame 3.100 has been released
Post by: robert on 2017-11-28 17:13:07
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
Title: Re: Lame 3.100 has been released
Post by: john33 on 2017-11-28 19:30:32
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. ;)
Title: Re: Lame 3.100 has been released
Post by: Brazil2 on 2017-11-29 16:30:41
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".
Title: Re: Lame 3.100 has been released
Post by: john33 on 2017-11-29 16:55:20
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'. ;)
Title: Re: Lame 3.100 has been released
Post by: john33 on 2017-11-29 21:11:56
New LamedropXPd compiles uploaded with the narrative corrected. :)
Title: Re: Lame 3.100 has been released
Post by: izmo on 2017-12-05 23:01:34
New LamedropXPd compiles uploaded with the narrative corrected. :)

thanks!
Title: Re: Lame 3.100 has been released
Post by: Slivka on 2017-12-09 12:41:01
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?
Title: Re: Lame 3.100 has been released
Post by: saratoga on 2017-12-09 16:07:35
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.
Title: Re: Lame 3.100 has been released
Post by: NetRanger on 2017-12-12 11:28:05
L.A.M.E. v3.100
Built on December 12, 2017, GCC 7.2.0
http://lame.sourceforge.net
Title: Re: Lame 3.100 has been released
Post by: john33 on 2017-12-12 22:05:50
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. :)
Title: Re: Lame 3.100 has been released
Post by: faladun on 2017-12-21 04:40:15
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
Quote
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.
Title: Re: Lame 3.100 has been released
Post by: madmax on 2017-12-21 14:52:37
pretty easy... SSE2 (-msse2) is mandatory to compile this patched version.
Title: Re: Lame 3.100 has been released
Post by: faladun on 2017-12-21 17:12:22
pretty easy... SSE2 (-msse2) is mandatory to compile this patched version.
how will look the command for configuration and compilation?
Title: Re: Lame 3.100 has been released
Post by: descrates on 2017-12-28 03:44:34
tmkk patch + clang 6.0 + msvc2010 lib + icl 16 lib
Title: Re: Lame 3.100 has been released
Post by: inrobert on 2018-01-14 00:11:23
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?
Title: Re: Lame 3.100 has been released
Post by: john33 on 2018-01-14 08:22:51
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.
Title: Re: Lame 3.100 has been released
Post by: inrobert on 2018-01-14 13:37:42
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?
SimplePortal 1.0.0 RC1 © 2008-2018