LAME 3.99 is out, 2012-02-28: version 3.99.5 has been released Options

[john33]

Ok, I guess my other reply didn't make it clear.
[...]
This looks like a problem within MediaInfo. The field consists of 9 characters, no Zero termination required.

Not arguing, simply trying to understand: why the issue manifests itself with 3.99.1 and not 3.98.4 please?

[...]
I'll produce a new set of compiles with this fix, but it will likely not be until tomorrow now. Technically, it was a problem although I would imagine most are unconcerned by this, IMHO.

Which compiler settings then please? Is it not best you devs/coders first agree on the most compatible and hopefully best performing ones?

This was two tiny and inconsequential coding errors in version.c that affected the insertion of the lame version into the LAME tag, nothing to do with compiler settings.

[nao]

Not arguing, simply trying to understand: why the issue manifests itself with 3.99.1 and not 3.98.4 please?

3.98.4 says "LAME3.98r", and 3.99.1 says "L3.99r". Mediainfo only accepts version strings beginning with "LAME" or "GOGO".
Quote from mediainfo's File_Mpega.cpp, line 1204

CODE

            if (Lame || Lib==_T("LAME") || Lib==_T("GOGO"))
                Header_Encoders_Lame();

[john33]

New compiles now available.

[DARcode]

This was two tiny and inconsequential coding errors in version.c that affected the insertion of the lame version into the LAME tag, nothing to do with compiler settings.

What I meant is: since you were about to produce new compiles, why not sort our the compiler switches doubts first.

[Anakunda]

Tried to view last build's (11/11) metadata with MediaInfo 0.7.50, encode settings are not shown at all, version information not shown at all on both 32bit and 64bit build. Foobar however reports L3.99r1 correctly.

[DARcode]

[...]Mediainfo only accepts version strings beginning with "LAME" or "GOGO".
Quote from mediainfo's File_Mpega.cpp, line 1204

CODE

            if (Lame || Lib==_T("LAME") || Lib==_T("GOGO"))
                Header_Encoders_Lame();

[john33]

This was two tiny and inconsequential coding errors in version.c that affected the insertion of the lame version into the LAME tag, nothing to do with compiler settings.

What I meant is: since you were about to produce new compiles, why not sort our the compiler switches doubts first.

In truth, the basic optimisation settings have changed very little over the last several years, it's more a case of trying the odd tweak to see if it makes any difference.

[Anakunda]

Does it mean the new LAME version doesnot begin with LAME but L only? I wished Mediainfo could show LAME version again, and why is not shown encode time settings anymore? Does it something to do with required LAME version string too?

[DARcode]

In truth, the basic optimisation settings have changed very little over the last several years, it's more a case of trying the odd tweak to see if it makes any difference.

I don't wanna hijack or spam this thread, so I'll make one last try at explaining myself: I'm referring to the different compiles' performance you've been discussing with Alex B, lvqcl and psycho.

[GeSomeone]

Still not a word on the lowpass case for -V0 ?

Nothing genius, but if you like to mimic the old behaviour one of the possibilities is to use -V 0.5. This is the highest setting that uses a lowpass, although it is a rather high one.

[nao]

Does it something to do with required LAME version string too?

Mediainfo assumes that LAME tag is not written unless the version string begins with "LAME" or "GOGO".

[Anakunda]

Does it something to do with required LAME version string too?

Mediainfo assumes that LAME tag is not written unless the version string begins with "LAME" or "GOGO".

If the problem is on MediaInfos side then consider this issue solved.
MediaInfo 0.7.51 was released today but doesnot reflect the latest Lame version tagging changes
Anyway I'd like to Lame continues identify itself as LAME henceforward.

[john33]

In truth, the basic optimisation settings have changed very little over the last several years, it's more a case of trying the odd tweak to see if it makes any difference.

I don't wanna hijack or spam this thread, so I'll make one last try at explaining myself: I'm referring to the different compiles' performance you've been discussing with Alex B, lvqcl and psycho.

From my own testing on AMD and Intel based systems, I believe that the compiles now on Rarewares represent the fastest compiles that I can produce with the tools I have available. Don't forget that no one involved in any of this actually makes any money out of it, in fact probably the reverse. We do what we do from interest and, I guess, because it provides a diversion from other things in life.

Don't take that to mean that we don't welcome constructive criticism, but we do this in our spare time and, more importantly, when it suits us.

[lvqcl]

I'm referring to the different compiles' performance you've been discussing with Alex B, lvqcl and psycho.

If you want to compare, you can download MSVS2010 compiles here: http://www.multiupload.com/ROM5UG0RW5

[psycho]

I have made my compile available for anyone interrested to test it:

LAME - psycho build

Be kind and report your results.


My results with MSVS2010 compiles, lvqcl provided (machinae_supremacy-fighters_from_ninne flac used as source from their website):

My LAME build:
16.200x 277.7 kbps

ReleaseNASM:
18.095x 277.4 kbps

ReleaseSSE2 x32:
16.437x 277.4 kbps

Rarewares build:
17.214x 278.0 kbps


Don't have 64- OS installed to test the ReleaseSSE2 x64.


So - for me, the ReleaseNASM is the fastest way to go.

This post has been edited by psycho: Nov 11 2011, 20:22

[psycho]

My previous build is 3.99, so here's the new one:

LAME 3.99.1 - psycho build

[robert]

Running some test with my above ~45 min track:

Rarewares compiles:
3.98.4 : 1:46
3.99.0 : 2:08

My own VC9 compiles :
3.98.4 : 2:24 (Release NASM)
3.99.0 : 2:24 (Release NASM)
3.99.0 : 2:01 (Release SSE2)

My own VC11 compile:
3.99.0 : 2:10 (Release)
3.99.0 : 1:46 (Release SSE2)
3.99.0 : 1:38 (Release SSE2, 64-bit)

It looks like John's IC11.1 compile isn't using optimized code paths, or at least no SSE2 optimizations.

My previous build is 3.99, so here's the new one:

LAME 3.99.1 - psycho build

Same test as above, with psycho's build:
3.99.1 : 2:08 (Release NASM, VC10 32-bit)

So, it's faster than my own VC9 NASM build, but not as fast as my Release SSE2 VC9 32-bit one.

Update on John's 11-11 compiles:
3.99.1 : 2:01 (Intel Compiler 11.1 32-bit)
3.99.1 : 1:43 (Intel Compiler 11.1 64-bit)

This post has been edited by robert: Nov 11 2011, 23:23

[hidn]

it is possible to see how used cpu extensions
http://www.cpuid.com/softwares/perfmonitor.html


(on ss working gogo 3.13)

This post has been edited by hidn: Nov 12 2011, 10:41

[robert]

Here are some perfmon snapshots using psycho's (A), john's 32-bit (B) and 64-bit ©, my VC9-NASM-32-bit (D), VC9-SSE2-32-bit (E) and VC11-SSE2-64-bit (F) compiles.

A B C
D E F

This post has been edited by robert: Nov 12 2011, 12:39

[ijskonijn]

Is it correct that in the latest build of Lame from 2011-11-11 ( http://www.rarewares.org/mp3-lame-bundle.php ) the error still exist where Lame writes the lame header ( http://forum.dbpoweramp.com/showthread.php...ll=1#post116335 )?

Because i saw an error in dBpoweramp ( http://forum.dbpoweramp.com/showthread.php...ll=1#post116339 ) and they say that this was the problem?

[lock67ca]

EncSpot is showing the Xing tag but isn't showing the Lame tag (which it usually does), as if it is unable to read it or it hasn't been written. iTunes still shows the encoder as Unknown. Odd???

[robert]

@ijskonijn

The rarewares builds look fine. When dMC still shows "3.98.4", then it seems you haven't replaced the correct file(s). IIRC, you'll have to use the CLI encoder from dMC, if you want to use LAME.exe.

[Zenitram]

Not arguing, simply trying to understand: why the issue manifests itself with 3.99.1 and not 3.98.4 please?

3.98.4 says "LAME3.98r", and 3.99.1 says "L3.99r". Mediainfo only accepts version strings beginning with "LAME" or "GOGO".

MediaInfo has been updated (Windows development snapshot, for Linux you need to update from SVN) in a "quick and dirty" way (actually, the whole Lame tag code is quick and dirty ).
For the future, I'll implement a better code and I'll detect LAME tag from the CRC-16 instead of "magic value" = "LAME", but if you don't plan to obey the "specifications" described on this page (saying that $9C is 'L', $9D is 'A', $9E is 'M', $9F is 'E'), do you have a page describing the updated specifications (especially the rule for the version number for previous, present and future versions, I would like to be able to separe library name and library version in the future)?

Is there any specific reason to break the "LAME3.99a" (a, b, c, d...) versioning method?

Jérôme, developer of MediaInfo.

[viktor]

Is there any specific reason to break the "LAME3.99a" (a, b, c, d...) versioning method?

i've been wondering about this as well, and i couldn't find any particular reason other than "just cause"

[apodtele]

Dropping LAME is a bad idea from branding standpoint. L is not a brand name, LAME is. This is way more important than any minor version.