Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: lame3995o (Read 40355 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: lame3995o

Reply #26
Thanks a lot, John.
lame3995o -Q1.7 --lowpass 17

Re: lame3995o

Reply #27
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.

Re: lame3995o

Reply #28
The changes towards original Lame are in my download file.
I got the original Lame source from here.
lame3995o -Q1.7 --lowpass 17

Re: lame3995o

Reply #29
I forgot to check your zip.
I though it only contain binaries.

Thanks.

Re: lame3995o

Reply #30
Love this Lame mod fixes few artifacts i that say at 320k. I can walk with my stuff at V2 or Q2. 



Re: lame3995o

Reply #31
Can anyone help how to build this mod on Linux? With which IDE or build-system?

Re: lame3995o

Reply #32
Bug?


Re: lame3995o

Reply #33
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?
lame3995o -Q1.7 --lowpass 17

Re: lame3995o

Reply #34
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?

Re: lame3995o

Reply #35
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.
lame3995o -Q1.7 --lowpass 17

Re: lame3995o

Reply #36
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
lame3995o -Q1.7 --lowpass 17

Re: lame3995o

Reply #37


Need help with this. I've encoded a flac file using lame3995o and find something strange. The file is somewhat larger than expected.

Re: lame3995o

Reply #38
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.
lame3995o -Q1.7 --lowpass 17


Re: lame3995o

Reply #40
You create a commandline encoder setting like this:



I have no experience with -q or -m and personally wouldn't touch the defaults.
lame3995o -Q1.7 --lowpass 17

Re: lame3995o

Reply #41
Hi !!! Halb27 thank you for your clarification !!!

Regards !!!

Re: lame3995o

Reply #42
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:
Code: [Select]
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)

Re: lame3995o

Reply #43
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?
lame3995o -Q1.7 --lowpass 17

Re: lame3995o

Reply #44
Hi, halb27

a) Yes, it is. Compilation fails because of use windows related header files
 Spoiler (click to show/hide)
When I add if condition:
Code: [Select]
#if defined(_WIN32)
#include "process.h"
#include "windows.h"
#include <ShellAPI.h>
#endif
compilation fails with error:
Spoiler (click to show/hide)

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)?

Re: lame3995o

Reply #45
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.

Re: lame3995o

Reply #46
[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,
lame3995o -Q1.7 --lowpass 17

Re: lame3995o

Reply #47
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.

Re: lame3995o

Reply #48
The original download link for lame3995o.zip is dead now.

Please re-upload. Thanks in advance.

Re: lame3995o

Reply #49
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.