Skip to main content

Topic: lame3995o (Read 13820 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • john33
  • [*][*][*][*][*]
  • Developer
Re: lame3995o
Reply #25
Better late than never!! ;)

64bit Intel compile: www.rarewares.org/files/mp3/lame3995o-x64.rar
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

  • halb27
  • [*][*][*][*][*]
  • Developer
Re: lame3995o
Reply #26
Thanks a lot, John.
lame3995o -Q1.7
opus --bitrate 140

  • KinG-KanG
  • [*]
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.

  • halb27
  • [*][*][*][*][*]
  • Developer
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
opus --bitrate 140

  • KinG-KanG
  • [*]
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. 



  • SPV82
  • [*]
Re: lame3995o
Reply #31
Can anyone help how to build this mod on Linux? With which IDE or build-system?
  • Last Edit: 12 February, 2017, 01:51:03 AM by SPV82

  • nastea
  • [*][*][*]
Re: lame3995o
Reply #32
Bug?


  • halb27
  • [*][*][*][*][*]
  • Developer
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?
  • Last Edit: 12 February, 2017, 04:12:19 PM by halb27
lame3995o -Q1.7
opus --bitrate 140

  • nastea
  • [*][*][*]
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?

  • halb27
  • [*][*][*][*][*]
  • Developer
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
opus --bitrate 140

  • halb27
  • [*][*][*][*][*]
  • Developer
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
opus --bitrate 140

  • halo001
  • [*]
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.

  • halb27
  • [*][*][*][*][*]
  • Developer
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.
  • Last Edit: 17 April, 2017, 04:07:51 AM by halb27
lame3995o -Q1.7
opus --bitrate 140

Re: lame3995o
Reply #39
You create a commandline encoder setting like this:



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

  • halb27
  • [*][*][*][*][*]
  • Developer
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
opus --bitrate 140

Re: lame3995o
Reply #41
Hi !!! Halb27 thank you for your clarification !!!

Regards !!!

  • SPV82
  • [*]
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)

  • halb27
  • [*][*][*][*][*]
  • Developer
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
opus --bitrate 140

  • SPV82
  • [*]
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)?
  • Last Edit: 02 June, 2017, 10:52:34 AM by SPV82

  • [JAZ]
  • [*][*][*][*][*]
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.

  • halb27
  • [*][*][*][*][*]
  • Developer
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
opus --bitrate 140

  • SPV82
  • [*]
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.
  • Last Edit: 03 June, 2017, 01:28:02 AM by SPV82

  • SubV
  • [*]
Re: lame3995o
Reply #48
The original download link for lame3995o.zip is dead now.

Please re-upload. Thanks in advance.

  • SubV
  • [*]
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.