lame3995o is based on the fact that the lame3995n -Q1.7 quality is excellent to my ears and for all the music I tried except for the harp40_1 sample.
So it was a promising strategy for me to use the -Q1.7 quality parameters as a basis and optimize them for harp40_1 at -Q1.
I did that, created a new version lame3995o, and arrived at the following ABC/HR results:
- lame3995n -Q1: 4.3
- lame3995o -Q1: 4.5
- lame3995o -Q0.5: 4.7
Compared to lame3995n lame3995o's different bahavior concerns the -Q values above 1.7. The main effect is between -Q1 and -Q0.5, The differences stop at -Q0.
You can download lame3995o from here (http://www.horst-albrecht.de/misc/lame3995o.zip).
Hi halb27. I've been using -Q1 on my standard playlist for the past month, and have not noticed any quality issues under normal listening conditions. As I get more time later in the summer, I will try a few ABC/HR tests on a few select tracks from my collection. As a bonus, -Q1 uses less bitrate than standard LAME -V 1 does for my playlist. Thanks again for your continuing attention and refinement to your fork of LAME.
Best Regards,
LedHed8
Thank you for testing lame3995o. I'm looking forward to your ABC/HR results.
Horst
I've noticed an audio distortion with lame3995o.
I ripped Billy Joel's song "Piano Man" and in the line "Sing us a song you're the piano man" the 'S' in sing distorts.
I'm using -Q0 setting in foobar. The CD is Billy Joel - The Essential Billy Joel 3.0
[...] in the line "Sing us a song you're the piano man" the 'S' in sing distorts.
A little reminder:
Publishing your ABX tests's results (and if anyone would be interested, uploading a small sample of that passage) would be, as you'll probably recall, more in agreement with some of this community's TOS's - more specifically, TOS 8 (https://hydrogenaud.io/index.php/topic,3974.html#post_tos8).
@soundping:
I also welcome if you could send a sound snippet of the critical spot so that I can have a look what's going wrong.
How to use lame3995o in foobar2000 ?
You create a commandline encoder setting like this:
(http://dl.getdropbox.com/u/2681777/Lame3995o/foobar_lame3995o.jpg)
thanks :)
i will convert my files today with Q0.
With this bitrate (317-318 kps), it's better than cbr320 ?
I guess for 99.99 percent of the music everything will be perfect no matter your choice.
I haven't tried recently but I guess the critical spot at sec. ~3 of problem sample eig is in favor of lame3995o - Qx (it doesn't take - Q0).
Maybe there's a difference also for problem samples lead_voice or harp40_1. You can find out yourself. After all it's your ears that count.
I've noticed an audio distortion with lame3995o.
I ripped Billy Joel's song "Piano Man" and in the line "Sing us a song you're the piano man" the 'S' in sing distorts.
I'm using -Q0 setting in foobar. The CD is Billy Joel - The Essential Billy Joel 3.0
@soundping. Is the distortion you are hearing on the 1st chorus at about the 1:26.7 mark? If so, I'm not able to hear a difference. I have the same version from the 3.0 edition. I've tried to abx on lower quality settings of 3995o, 3.99.5, and 3.98.4 versions down to V5 with no success. In the past, I've been pretty sensitive to sibilant S distortions, so perhaps my hearing has worsened. Then again, I hear an identical slight distortion in the 'S' in the FLAC and MP3 encodes.
Best regards, LedHed8
I've noticed an audio distortion with lame3995o.
I ripped Billy Joel's song "Piano Man" and in the line "Sing us a song you're the piano man" the 'S' in sing distorts.
I'm using -Q0 setting in foobar. The CD is Billy Joel - The Essential Billy Joel 3.0
@soundping:
I also welcome if you could send a sound snippet of the critical spot so that I can have a look what's going wrong.
After all these days, will you kindly finally pass the baton of burden of proof,
@soundping , please?
EDIT:
To the admins/mods: I've just realized that neither halb27 nor me couldn't actually refer to soundping (member=96900) in our posts, since whenever we both typed "@soundping" in our replies, the editor has interpreted it as 'sound' (member=57038) - who is a totally different member - even when I at least, confirmed it by clicking on the right name in the drop-down list that pops out.
PS: Though it may be us doing something wrong, as @LedHed8 managed to do it properly. :-\
EDIT:
To the admins/mods: I've just realized that neither halb27 nor me couldn't actually refer to soundping (member=96900) in our posts, since whenever we both typed "@soundping" in our replies, the editor has interpreted it as 'sound' (member=57038) - who is a totally different member - even when I at least, confirmed it by clicking on the right name in the drop-down list that pops out.
PS: Though it may be us doing something wrong, as @LedHed8 managed to do it properly. :-\
You may mention members manually using the member=id# BBCode tag. For an example, quote the posts. It's a pain, but it works. I'll report this to ElkArte forum as a bug, or misfeature.
I'm back online.
Tonight I'll make samples and post them.
The original file is gone now. I re-ripped the track and the "S" distortion sound isn't there now.
The original file is gone now. I re-ripped the track and the "S" distortion sound isn't there now.
Well, I'll be damned...
I made some test audio samples from 3995o.
The 30s source file is from a burn-in track sample.
https://mega.nz/#F!aEE3GQaa!kdDsaq5Pn4ycccPsZLBUwA
The source file is there and copies from settings -Q0, -Q0.5 and -Q1.
I compared the flac with the -Q1 file and didn't notice a difference.
Is there an issue with one of the encoded files?
I didn't notice any problems. I was hoping someone else would test them out.
I didn't notice any problems. I was hoping someone else would test them out.
Why bother if, as you were plain honest to admit, you couldn't detect anything wrong with said sample the second time around?
In my view, that was a simple case of claiming you'd found a problematic sample and then disproving it with (I hope) blind testing, afterwards.
Anyway, thanks for clarifying that.
The cutoff frequencies are not the same with Vx and Qx ?
No they aren't. cutoff of -Qx is somewhat lower than that of -Vx.
The background for this is as follows:
-Vx internally uses a number of parameters controlling the accuracy of lossy encoding.
Lame has no real idea what a setting of these parameters has to be chosen in a specific situation for the music to be transparent. That's why these parameters are static.
Sure these static parameters are carefully chosen so that usually music is fine even with -V5.
A higher quality -Vx setting means these parameters are chosen more restrictive so hat the deviation from the original is lower. This way the probability of getting a transparent result increases. This is kind of a brute force quality management.
My -Qx quality setting works a bit different.
-Q1 for instance internally uses the accuracy parameters of -V3 as a quality basis. This gives the headroom for a dynamic quality management. For the known issues of very tonal problem samples as well as harpsichord music I derived criteria where audio quality is increased in a musical situation when lame3995o thinks this is necessary. This is a more selective approach than that of -Vx. (But don't think it is a very intelligent mechanism. In order to have a strong effect on various problem samples I still had to do things in a pretty much brute force way).
I don't touch the lowpass anymore which is a function of -Vx, in case of -Q1 that of the underlying basic -V3.
If you prefer another lowpass, use the --lowpass setting.
average kps of Q0 is 317 ...
So, better is -Q0 or CBR 320 ?
Probability is close to zero that you would notice any difference.
Problem sample lead-voice is a promising candidate for finding a difference, maybe also harp40_1.
Better late than never!! ;)
64bit Intel compile: www.rarewares.org/files/mp3/lame3995o-x64.rar (http://www.rarewares.org/files/mp3/lame3995o-x64.rar)
Thanks a lot, John.
Long time no see.
Great news from
@john33.
@halb27, where i can get your source?
I want to try build it with vs-2015 or gcc 6.2.
I think there is some math in your source.
Maybe I can build it with sse 4 caps.
The changes towards original Lame are in my download file (http://dl.getdropbox.com/u/2681777/Lame3995o/lame3995o.zip).
I got the original Lame source from here (http://lame.cvs.sourceforge.net/viewvc/lame/lame/?view=tar).
I forgot to check your zip.
I though it only contain binaries.
Thanks.
Love this Lame mod fixes few artifacts i that say at 320k. I can walk with my stuff at V2 or Q2.
Can anyone help how to build this mod on Linux? With which IDE or build-system?
Bug?
(http://i.imgur.com/UVOVmof.png)
Impossible to say without knowing about test.wav. Can you provide it?
How does original Lame3.99.5 behave? Using -V6 (not the target quality of lame3995o) lame3995o should behave more or less like original Lame.
Do you have mp3packer.exe in the folder of lame3995o.exe?
test.wav is just a normal audio wav file, ripped from a cd.
Lame 3.99.5 encodes test.wav to a vbr mp3 file, somewhere in the range of 112 kbps, as expected.
I don't have mp3packer.exe at all, do I need it?
One of the lame3995o features is to keep the bit reservoir at maximum in order to locally allow for the highest bitrates when necessary. This can result in a lot of 320 kbps frames which are not necessarily filled with audio data. mp3packer squeezes the 'air' out of the mp3 file. So I do recommend to use it. It is used from within lame3995o automatically if you put mp3packer.exe into the folder where lame3995o.exe is.
In a few days there won't be public folders any more in DropBox for easy distribution of files.
That's why I have moved lame3995o to my own webspace (which I had to put up last year because DropBox couldn't be used for web content any more).
So you can download lame3995o now from http://www.horst-albrecht.de/misc/lame3995o.zip (http://www.horst-albrecht.de/misc/lame3995o.zip)
(https://jfgvsw-sn3302.files.1drv.com/y4pDWUrms5ewK5MncXUUvdyPraURRthMLaJDzuk5AdnSrX_NyY5Mzc9J3o7LvyfhnYleh1xf1GbHUY9HRLQAdzfmbQr4zJDADH_htdsrGJJgi2ZCHdHbwF7i1wtyEsgAqR1beZiTpL6EsuOQiota_3m-P5SinzZOib5xQvrQPocCvV2jOYn0nQ3ucDsro_mXlgIur1ytvZ89iC0BZCHVTwXZA/Bug.png?psid=1)
Need help with this. I've encoded a flac file using lame3995o and find something strange. The file is somewhat larger than expected.
The reported codec profile is V1 which means you probably used either -V1 or -Q1.
With this 215 kbps is normal, for lame3995o as well as for standard Lame 3.99.5.
In case your filename means you encoded using - Q1.7 215 kbps is more than the average ~200 kbps bitrate of - Q1.7. But that's what VBR is meant to do. If you encode say 20 tracks of various pop music, you should get an average bitrate of ~200 kbps. But every single track will deviate from that more or less.
You create a commandline encoder setting like this:
(http://dl.getdropbox.com/u/2681777/Lame3995o/foobar_lame3995o.jpg)
Hi ! How to create a commandline for lame 3995o into foobar2000?
Is necessary to add "-mj" joint stereo information for "-q0 ir -q1" settings?
Thanks and Regards !
Dallaed
You create a commandline encoder setting like this:
(http://www.horst-albrecht.de/misc/foobarCLI.jpg)
I have no experience with -q or -m and personally wouldn't touch the defaults.
Hi !!! Halb27 thank you for your clarification !!!
Regards !!!
Hi, halb27!
I'm trying to build with gcc on Linux and would like to find out what a difference if compile lame3995o with no changes to files:
frontend/lame_main.c
frontend/main.c
frontend/main.h
The question at issue is that the compilation finishes well if these files keeps unchanged, otherwise it fails apparently due to Windows related code.
Thanks! (sorry, my English not so well)
I'm not sure whether I understand you correctly.
Is this true?:
a) If you compile with all my modified files (21 files), your compilation fails.
b) If you use the original lame_main.c, main.c, main.h, but all of the other 18 files according to my modifications, your compilation is successful.
As for a) what does 'compilation fails' exactly mean?
Hi, halb27
a) Yes, it is. Compilation fails because of use windows related header files
make[2]: Entering directory `/tmp/lame/lame-3.99.5o/frontend'
gcc -DHAVE_CONFIG_H -I. -I.. -I../libmp3lame -I../include -I.. -O3 -fomit-frame-pointer -ffast-math -maccumulate-outgoing-args -Wall -pipe -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
main.c:77:18: warning: extra tokens at end of #include directive [enabled by default]
#include "main.h"z
^
main.c:78:21: fatal error: process.h: No such file or directory
#include "process.h"
^
compilation terminated.
When I add if condition:
#if defined(_WIN32)
#include "process.h"
#include "windows.h"
#include <ShellAPI.h>
#endif
compilation fails with error:
Making all in frontend
make[2]: Entering directory `/tmp/lame/lame-3.99.5o/frontend'
gcc -DHAVE_CONFIG_H -I. -I.. -I../libmp3lame -I../include -I.. -O3 -fomit-frame-pointer -ffast-math -maccumulate-outgoing-args -Wall -pipe -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
gcc -DHAVE_CONFIG_H -I. -I.. -I../libmp3lame -I../include -I.. -O3 -fomit-frame-pointer -ffast-math -maccumulate-outgoing-args -Wall -pipe -MT timestatus.o -MD -MP -MF .deps/timestatus.Tpo -c -o timestatus.o timestatus.c
main.c: In function 'c_main':
main.c:461:2: error: unknown type name 'DWORD'
DWORD fileAtt;
^
main.c:506:5: warning: implicit declaration of function 'utf8ToUnicode' [-Wimplicit-function-declaration]
wMp3packerPath = utf8ToUnicode(mp3packerPath);
^
main.c:506:20: warning: assignment makes pointer from integer without a cast [enabled by default]
wMp3packerPath = utf8ToUnicode(mp3packerPath);
^
main.c:508:3: warning: implicit declaration of function 'GetFileAttributesW' [-Wimplicit-function-declaration]
fileAtt = GetFileAttributesW(wMp3packerPath);
^
main.c:511:3: warning: implicit declaration of function 'GetFileAttributesA' [-Wimplicit-function-declaration]
fileAtt = GetFileAttributesA(mp3packerPath);
^
main.c:513:17: error: 'INVALID_FILE_ATTRIBUTES' undeclared (first use in this function)
if (fileAtt == INVALID_FILE_ATTRIBUTES) { /* if mp3packer.exe not in Lame folder */
^
main.c:513:17: note: each undeclared identifier is reported only once for each function it appears in
main.c:520:14: warning: assignment makes pointer from integer without a cast [enabled by default]
wCmdline = utf8ToUnicode(cmdline);
^
main.c:522:3: warning: implicit declaration of function 'ShellExecuteW' [-Wimplicit-function-declaration]
ShellExecuteW(NULL, NULL, wMp3packerPath, wCmdline, NULL, 0);
^
main.c:525:3: warning: implicit declaration of function 'ShellExecuteA' [-Wimplicit-function-declaration]
ShellExecuteA(NULL, NULL, mp3packerPath, cmdline, NULL, 0);
^
main.c:540:15: warning: assignment makes pointer from integer without a cast [enabled by default]
wFileName = utf8ToUnicode(filename);
^
main.c:541:16: warning: assignment makes pointer from integer without a cast [enabled by default]
wFileName2 = utf8ToUnicode(filename2);
^
main.c:543:3: warning: implicit declaration of function '_sleep' [-Wimplicit-function-declaration]
_sleep(100);
^
main.c:545:4: warning: implicit declaration of function 'MoveFileW' [-Wimplicit-function-declaration]
r = MoveFileW( (LPCWSTR) wFileName2, (LPCWSTR) wFileName);
^
main.c:545:20: error: 'LPCWSTR' undeclared (first use in this function)
r = MoveFileW( (LPCWSTR) wFileName2, (LPCWSTR) wFileName);
^
main.c:545:29: error: expected ')' before 'wFileName2'
r = MoveFileW( (LPCWSTR) wFileName2, (LPCWSTR) wFileName);
^
main.c:548:4: warning: implicit declaration of function 'MoveFileA' [-Wimplicit-function-declaration]
r = MoveFileA( (LPCSTR) wFileName2, (LPCSTR) wFileName);
^
main.c:548:20: error: 'LPCSTR' undeclared (first use in this function)
r = MoveFileA( (LPCSTR) wFileName2, (LPCSTR) wFileName);
^
main.c:548:28: error: expected ')' before 'wFileName2'
r = MoveFileA( (LPCSTR) wFileName2, (LPCSTR) wFileName);
^
make[2]: *** [main.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f .deps/timestatus.Tpo .deps/timestatus.Po
make[2]: Leaving directory `/tmp/lame/lame-3.99.5o/frontend'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/lame/lame-3.99.5o'
make: *** [all] Error 2
b) Yes, in this case compilation finishes well and resulting lame binary works. I would like to know is there a difference if use this binary (18 modified files only)?
I've checked the source code, and you will be missing two things:
One is the option to define the parameters on a shell variable ( xxx = a; export xxx ). The other is the automatic execution of mp3packer at the end.
The effect of not executing mp3packer is that the files will be bigger than needed. One of the features of this fork of LAME is that it works in a way that tries to maximize at all times the amount of space that is available to the encoder, and if it wasn't needed, mp3packer just strips it off.
The code at the end of main.c is what would need to be implemented in a posix way in order to compile in linux, and also you would need mp3packer. Probably it's easier to build a shell script that executes mp3packer after LAME.
[JAZ] did it first, but I've also looked up the source files and can only confirm what [JAZ] said.
If you don't use my main.c, main.h, lame_main.c you don't call mp3packer at the end. And yes, this part is windows-specific and certainly not well-implemented from a developer's point of view.
I'm sorry but you have to do the mp3packer part on your own. If that's a problem you can use mp3packer on its own. Before I integrated it into my Lame variants I always used m3packer after encoding all my tracks (one step for all the files in a folder).
Depending on your lame3995o usage it may also be the case that mp3packer isn't much of an advantage. But I'd definitely compare with/without mp3packer usage,
If I understand correctly, the changes in lame_main.c, main.c, main.h files are only for mp3packer usage. If I don't use mp3packer I can leave these files unchanged. Thanks for your answers.
The original download link for lame3995o.zip is dead now.
Please re-upload. Thanks in advance.
halb27, another question.
Are these 64-bit builds by john33 are identical to yours in terms of quality of sound?
Because the 64-bit code uses the SSE2 vector instruction set by default and may handle the floating point operations differently.
I gave the updated link in reply #36.
I'll try to have the mods let me update my original post.
It's a pity that different development environtments lead to different encoders. I was troubled by this when I started doing Lame development. The then active Lame developer, robert (haven't heard of him for years unfortunately), helped me a lot doing my first compilations (I wasn't used to C programming environments). He used VC++, and so did I. First thing I noticed was that using the original Lame source the VC++ compiled encoder produced other results than the Rarewares encoder which used the same source. I computed the difference signal, and the difference wasn't even very small. robert convinced me that I don't have to care.
As long as you don't have any evidence for audible differences I think you don't have to worry. And if you do want to use exactly the encoder I tested just use my exe.
Thank you.
I've noticed that files encoded with your lame3995o have a higher lowpass. Or no lowpass at all?
Here's my encoding settings. And the same file that was encoded with your old lame3100m. Click on thumbnails to enlarge.
(http://www.pictureshack.net/images/46348_0001.png) (http://www.pictureshack.net/images/42530_0002.png)
(http://www.pictureshack.net/images/2490_0004.png) (http://www.pictureshack.net/images/86592_0003.png)
(http://www.pictureshack.net/images/70734_0006.png) (http://www.pictureshack.net/images/11184_0005.png)
Is this normal? I think the lowpass value of 22.1 kHz (-Q0) is not good.
With lame3995o and each -Q level there is an underlying basic -V level. The encoding parameters of my machinery have a value at least that of this basic -V level. This goes also for the lowpass value (though not really a quality parameter).
The basic -V level for -Q0 is -V0, so -Q0 uses the lowpass value of original Lame's -V0. I have no reason not to trust in original Lame's lowpass value (though it's true I was more conservative with former versions of my variant).
If you prefer another lowpass just use the lowpass option.
Thank you again.
What do you think? Is it still okay to use lame3100m? Because I'm quite satisfied with quality it produces.
Also I think having lowpass at 18.2 kHz will result in more data in bit reservoir, thus making overall better sound quality than 3995o with no lowpass at all (-Q0). Correct me if I wrong.
The MP3 format has difficulty storing content above 16 KHz without sacrificing quality and increasing the bitrate requirements of the lower frequency bands.
So, the lowpass at 22.1 kHz (3995o -Q0) is an overkill. We cannot hear such high frequencies, anyway.
The MP3 format has a technical limitation that forces a trade-off: the more accurately the highest frequency band (16 KHz and up, normally) is encoded, the greater the space required to encode the lower frequency bands with similar quality. In other words, if the highest frequencies are preserved well, the quality of the much-more audible lower frequencies is sacrificed, and the bitrate has to be increased significantly to compensate, and it might not always be possible to fully compensate because of the 320 kbps limit on bitrate.
About lame 3.100...
From URL (https://sourceforge.net/p/lame/mailman/message/35974173/)
I think the main issue is that after the 3.99.5 release the main SVN
branch (trunk) has been (mis-)used a a feature branch for some
improvements to the psycho-acoustic model. However, these improvements
never really took off, the changes were rather considered as
regressions and after the main developer lost time (and/ot interest?),
nobody really dared to touch that code.
Then came the first patches and fixes addressed at the 3.99.5 release
and were applied on top of the current development state, but nobody
dared to do the overdue point release because of all the other changes
to the code [1]. As such, the code wasn't touched at all anymore,
because it couldn't get released as is and no preparations were ever
made to do a point release with minimal changes to the previous one.
This is at least how I perceived what has happened. However, this
doesn't mean that it really was like this.
Said that, that talk has spuried some changes (security related mostly) that are being done over 3.100.
What do you think? Is it still okay to use lame3100m?
IMO lame3995n was a major step forward compared to former versions (and lame3995o is different only for -Q values of 1 or similar).
However as you use the highest VBR bitrate setting this probably doesn't mean any audible difference.
But if it is only the lowpass you care about maybe I can bring some relief to you by mentioning that Lame3.99.5 (original as well as my variants) demands only for a very limited precision in the 16+ kHz range compared to the more audible ranges. I guess that's why the lowpass value is that high when using -V0. So it can't happen that a lot of bits are 'wasted' eventually.
But there's also no reason not to simply use the --lowpass 18.2 switch in case you prefer this.
If you care a lot about the bit reservoir it may be wiser to use a somewhat lower -Q value like -Q1 or similar. I use -Q1, but after having tried opus I would even go lower. With opus as well as lame3995o it is only harpsichord music which requires an (otherwise inadequate) very high bitrate setting. Everything else is perfectly encoded when using lame3995o -Q1.7, and there is even a certain safety margin with this. I do not struggle any more for a general encoder setting which gives perfect results for any kind of music. I can easily do so as harpsichord music isn't exactly my favorite genre. Moreover even the worst harpsichord sample I know is well acceptable when using -Q1.7, and I guess -Q1.7 is perfect for many a harpsichord music. And I can always use -Q0 for the few tracks with dominating harpsichord music I have. I don't have a reason to reencode my collection, but if I had to I'd use -Q1.7 (200 kbps on average for pop music).
I was allowed to update the link to lame3995o in the OP.
Done.
I downloaded an installed lame3995o only for Norton to automatically delete it as it was apparently a risk. Has anyone else had such a problem?
Many thanks
I'm sorry you have this problem.
I have no idea why Norton behaves like this. I just had virustotal check lame3995o online using 64 antivirus tools and none of these had a complaint. Norton unfortunately is not among these 64 tools.
Strangely, on VirusTotal, Symantec says it's clean. Submit a false positive to them?
I gave up using Norton many years ago because of frequent false positive issues.
Now a (stable) Lame 3.100 has been released (https://hydrogenaud.io/index.php/topic,114777.0.html), would it make sence to create a new lame3100x ? (just backport the fixes of LAME3.100 I guess).
BTW AFAIK there were no quality changes, but some security and buffer issues.
ATM I have very serious health problems.
So this may be a question to me later next year.
Sorry to hear that. May I wish you a speedy and full recovery.
Sorry to hear that. May I wish you a speedy and full recovery.
Same, hope you get better soon.
Thanks a lot.
Get well soon. Wishing you a speedy recovery!
@halb27 , hope that everything is alright and you are in good health. Your lame version is still the best out there!
Thank you very much. TheQwertiest, for your good wishes and your appreciation of lame3995o.
My cancer is slowly growing, but I'm fine most of the time. I'm thankful that I am able to do everything I want to do, just not at any time.
Of course normal life events drop in. Last week a dog ran into my bike. This brought me down with four broken ribs. Pretty much pain and I have to take care that the ribs don't get into my lung. But it's getting better.
Hava a nice christmas!
Best wishes
Horst
@halb27 , I'm so sorry to hear that =(
Was hoping that your health problems were on a lighter side... Hopefully your ribs will heal up quickly so as to not bring additional problems.
PS: I will try to build (and post) a 3.100 lame with your patch applied, should be pretty straight-forward, since 3.100 seems to produce the bit-exact result as 3.99.5.
@TheQwertiest, have you managed to build LAME 3.100 with halb27's patches?
Also, I'm curious how to make lame3995o use mp3packer when encoding via Foobar2000. Both utils are located in some folder mentioned in PATH variable under Windows and work as expected in the bare command line, but for some reason mp3packer is not used by lame3995o when encoding via Foobar2000. Any help here would be appreciated.