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

[db1989]

http://lame.cvs.sourceforge.net/viewvc/lam...d.html#resample

I think 3.99.2 is not for me.…I can get it to do what I want now, but not without a bunch of work.

Sorry I bothered! If adding one parameter to the command line is really too much work.

It must be for everyone else but me.

No need to play the victim. No one ever said you were completely alone in, or otherwise abnormal for, preferring an older version. In fact, there has been some discussion from other users on reasons why they are not upgrading right away. My point, rather, is that 3.99 deserves a little more consideration than summary dismissal on the basis of newly altered default settings that are nonetheless totally revertible.

[DARcode]

Since HA has chosen to recommend the latest stable version of the LAME compile for optimal quality unless noted otherwise, can the reasons for switching to 3.99.2 from 3.98.4 be clearly stated by anyone as opposed to simply pointing to the changelog and beta threads or suggesting to ABX and decide for yourself please?

Could anyone please indulge me?

[halb27]

With former Lame versions we had public testing and discussion of the alpha versions here on HA.
This gave us an idea about what was going on. We did not have this with 3.99, unfortunately.

Some testing was published here, especially by IgorC who told about the improvements here. I did so too on a small scale, and I like the new version too.

As for the general attitude towards a new Lame version I agree with the HA recommendation: as long as no issue is found specific to the new version the new version should be preferred. It should be assumed that the Lame developer(s) implemented improvements. Of cause this does not necessarily mean re-encoding in case a user is totally content with the previous version.

[apodtele]

Most of complaints come from people who tuned the previous version for their needs with crazy options like

"-V9.9999" or "--vbr-new -V 0 -b -B -m j -q 0 --noreplaygain --id3v1-only --lowpass 14000 --resample"

These people spent years tweaking old versions for their needs, often to work around some old and now-fixed bugs. They consider themselves experts in lame, even though their expertise is outdated. Of course, they are unhappy if things change even when they change for the better.

Basically 3.99.2 is a good version, but it is not the same as 3.98.4. With plain and simple "-V2" it sounds super.

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

[DARcode]

I've gone thru pages 7 and 8 of the "ame 3.98.4, 3.99 alpha, 32- and 64-bit builds" thread again, IgorC's and your (halb27) posts mainly, and if that's all there is on HA about quality improvements in LAME 3.99.2 I'm a bit disappointed, also I definitely agree with shadowking's post #176 there.

My ears are FUBAR, more'n 25 years of live hardcore punk, thrash metal and 70's hard rock have taken their toll, so right now I stick to my own problem samples in order to be able to evaluate the quality of encodes, the most telling being the title track to Blood For Blood's 1999 release Living' In Exile, to be precise the "I'm" part of all the "I'm in exile" lines after "There’s gotta be something more than this, There’s gotta be something that I missed": with all Lame versions at V2 they produce what I call the "water drop blip" effect on the vowl, 3.99.2 with the default VBR mode is no different, therefore since I'm not interested in V0 I'll stick to 3.98.4 for now (when I can't use qaac -V 100 M4A's due to hardware limitations).

This weekend I'll prolly test a couple more personal killer samples, anyone else into my or similar music genres can share their experiences?

EDIT: Links.

This post has been edited by DARcode: Nov 23 2011, 16:47

[lvqcl]

I compared 3.98.4 and 3.99.2, ABR and VBR, at ~96 kbps. The settings: --abr 96 and -V 8 for 3.98.4, --abr 96 and -V 7.7 for 3.99.2.

3.98 ABR and 3.99 VBR have more or less the same quality; 3.98 VBR suffer from noticeable lowpass filtering; 3.99 ABR has more noticeable encoding artifacts.

(of course, this doesn't mean that e.g. 320kbps 3.99 is worse than 320kbps 3.98)

[zipr]

I thought I'd give 3.99 a try. Seems like it works well, but when I run mp3s through mp3gain, it gives me the following error:

Let There Be Horns.mp3 is an MPEG Layer I file, not a layer III file

Any ideas why this is happening?

I'm using EAC, and here is my compression command line:
-V 2 --add-id3v2 --pad-id3v2 --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d

The LAME version I'm using is the x64 one from rarewares...

[zipr]

Also tried the 32 bit version of LAME 3.99.2, and had the same problem.

If I enable the "No check for layer I or II" setting in MP3Gain, I don't get an error (no surprise!), but I'd like to be sure that there's nothing else amiss before I scan in more CDs....

[ZinCh]

LAME 3.99.3 November 26 2011

Robert Hegemann
Fix for tracker item [ 3441349 ] --tg does not handle genre number when adding unicode tag

[john33]

LAME 3.99.3 November 26 2011

Robert Hegemann
Fix for tracker item [ 3441349 ] --tg does not handle genre number when adding unicode tag

Sorry, hadn't seen this, been away for the weekend. I'll get some compiles up a little later.

[john33]

As some people have already discovered, the compiles are there now - MSVC10/ICL12.1 compiles.

[psycho]

I am in need of assistance with compiling lame. I have been doing some testing and have come to the conclusion that nasm doesn't work on my compiles. Why do I say so? Because I have tried encoding with --noasm mmx --noasm 3dnow --noasm sse commands and have found that the encoding speed is exactly the same as without those commands with my lame compile (that's 16× realtime); I have just compiled 3.99.3 and also tested my older compiles - results are the same... my ASM functions obviously don't work, even though lame output says "CPU features: MMX (ASM used), 3DNow! (ASM used), SSE, SSE2". I have then also tried the latest 3.99.3 rarewares lame compile and have found that with those commands I achieve the exact same encoding speed - 16×, whereas I achieve higher encoding speed without those commands (as expected) - 18×.

I compile lame using MinGW+MSYS+nasm.exe and I configure the compile with "./configure --prefix=/mingw --enable-nasm --enable-expopt=full" and then I finish with simple "make".

What am I doing wrong?

[john33]

I'd love to help, but you need someone who's familiar with that environment and I'm afraid that isn't me!

This post has been edited by db1989: Nov 29 2011, 13:12

Reason for edit: removing unnecessary full quote of above post

[zipr]

Tried mp3gain on files I created from 3.99.3, and am still getting errors.

I found that if I use EAC and rip to wav files, and then compress those wav files into mp3, I don't get the "is an MPEG Layer I file, not a layer III file" error in mp3gain.

So there must be an issue in the tags that EAC is writing when I choose the "Test & copy selected tracks - compressed" option. Anyone else run into that?

Is there something in my command line?

-V 2 --add-id3v2 --pad-id3v2 --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d

[bilbo]

Tried mp3gain on files I created from 3.99.3, and am still getting errors.

I found that if I use EAC and rip to wav files, and then compress those wav files into mp3, I don't get the "is an MPEG Layer I file, not a layer III file" error in mp3gain.

So there must be an issue in the tags that EAC is writing when I choose the "Test & copy selected tracks - compressed" option. Anyone else run into that?

Is there something in my command line?

-V 2 --add-id3v2 --pad-id3v2 --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d

Starting with EAC 1.0 beta 2 and on, placeholder names have changed. From the EAC website:

CODE

Which flags can I use in the external compression scheme “User Defined MP3 Encoder”?

In the field “Additional command line options” you could use replacements for the selectable options :

For versions before 1.0 beta 2

%s – Source filename
%d – Destination filename
%h…%h – Text “…” only when “High quality” selected
%l…%l -Text “…” only when “Low quality” selected
%c…%c – Text “…” only when “CRC checksum” selected
%j…%j – Text “…” only when storing cd cover is enabled
%i – Filename of CD cover image
%r – Bitrate (“32″..”320″)
%e – Comment
%a – Track artist
%t – Track title
%v – CD artist
%g – CD title
%y – Year
%n – Track number
%x – Number of tracks on album
%m – MP3 music genre
%o – Original filename (without temporary renaming)
%e – Comment (as selected in EAC)
%b – CRC of extracted track
%f – freedb ID

So a command line would look like (for l3enc)

%s %d -br %r000 %h-hq%h %c-crc%c

For versions from 1.0 beta 2 on (some placeholders might only be available in the latest version!)

%source% – Source filename
%dest% – Destination filename
%original% – Original filename (without temporary renaming)

%ishigh%…%ishigh% – Text “…” only when “High quality” selected
%islow%…%islow% -Text “…” only when “Low quality” selected
%haslyrics%…%haslyrics% – Text “…” only when lyrics exist
%hascover%…%hascover% – Text “…” only when storing cd cover is enabled and cover exists
%crcenabled%…%crcenabled% – Text “…” only when “CRC checksum” selected

%title% – Track title
%genre% – MP3 music genre
%year% – Year
%cddbid% – freedb ID
%artist% – Track artist
%lyrics% – Lyrics
%lyricsfile% – Filename of lyrics text file (ANSI)
%bitrate% – Bitrate (“32″..”320″)
%comment% – Comment (as selected in EAC)
%tracknr% – Track number (same as %tracknr2%)
%tracknr1% – Track number (at least 1 digit)
%tracknr2% – Track number (at least 2 digits)
%tracknr3% – Track number (at least 3 digits)
%totalcds% – Total number of CDs in the given CD set
%cdnumber% – Number of the CD
%composer% – Track performer
%trackcrc% – CRC of extracted track
%coverfile% – Filename of CD cover image
%numtracks% – Number of tracks on album
%albumtitle% – CD title
%albumartist% – CD artist
%albumcomposer% – CD composer
%albuminterpret% – CD performer

%% – The ‘%’ character

So a command line would look like (for l3enc)

%source% %dest% -br %bitrate%000 %ishigh%-hq%ishigh% %crcenabled%-crc%crcenabled%

The extension can also be selected within these settings.

[robert]

Tried mp3gain on files I created from 3.99.3, and am still getting errors.

I found that if I use EAC and rip to wav files, and then compress those wav files into mp3, I don't get the "is an MPEG Layer I file, not a layer III file" error in mp3gain.

Maybe you end up with more than one ID3v2 tag? I'm quite sure mp3gain skips over the first ID3v2 tag, but what happens when there are more than one?

[zipr]

Thanks Robert and bilbo. I'll take a look at my settings when I get the chance. The strange thing about it for me is that I haven't changed any EAC settings for this -- and if I slip in 3.98 it works fine.

[bilbo]

Thanks Robert and bilbo. The strange thing about it for me is that I haven't changed any EAC settings for this -- and if I slip in 3.98 it works fine.

That is the problem!! EAC has changed the settings!

[Frankie]

As some people have already discovered, the compiles are there now - MSVC10/ICL12.1 compiles.

Whooha, the speed is coming back! 3.99.3 is almost as fast as 3.98.4 on my system (48 secs compared to 46 secs for encoding a 55 minute album, that's ~ 5% while the first 3.99 was ~ 12% slower).

[zipr]

That is the problem!! EAC has changed the settings!

I was actually using .99 prebeta 4, so it still uses the old settings. I upgraded to the latest version of EAC and updated the command line to -V2 --add-id3v2 --pad-id3v2 --ta "%artist%" --tl "%albumtitle%" --tt "%title%" --tn "%tracknr%" --tg "%genre%" --ty "%year%" %source% %dest%
but it still gives me the error.

This is probably a bit off-topic, though, and since it doesn't seem that others are running into this problem, I'll take it offline and see if I can figure something out. I'll report back if I solve the problem!

[psycho]

As some people have already discovered, the compiles are there now - MSVC10/ICL12.1 compiles.

Whooha, the speed is coming back! 3.99.3 is almost as fast as 3.98.4 on my system (48 secs compared to 46 secs for encoding a 55 minute album, that's ~ 5% while the first 3.99 was ~ 12% slower).

For me this is also true. Rareware's 3.99.3 is almost as fast as 3.98.4; practically the same. Seems like ICL12.1 compiler is better? Or maybe john33 used some different settings to compile this time.

[Jebus]

I have 2 DLL-related questions/comments:

1) Is there a good explaination for why beWriteVBRHeader() and beWriteInfoTag() throw up a Win32 dialog box on failure? This is really irritating behavior for a command-line implementation, especially since the function returns an error code anyhow. Sometimes the file can't be opened for whatever reason, and I want to handle the error myself.

2) Is there any way to get beWriteVBRHeader() to fill in the replaygain section? Assuming I did the analysis externally. Right now it just leaves those bytes blank.

Given the above 2 issues, I might just have to implement my own Lame Tag function and/or submit a patch upstream, if the Lame devs are open to this.

[john33]

As some people have already discovered, the compiles are there now - MSVC10/ICL12.1 compiles.

Whooha, the speed is coming back! 3.99.3 is almost as fast as 3.98.4 on my system (48 secs compared to 46 secs for encoding a 55 minute album, that's ~ 5% while the first 3.99 was ~ 12% slower).

For me this is also true. Rareware's 3.99.3 is almost as fast as 3.98.4; practically the same. Seems like ICL12.1 compiler is better? Or maybe john33 used some different settings to compile this time.

Nope! It's all down to the compiler, not me.

[Mr. Odd]

I am having the EXACT same problem, with the same setup. I've toggled the layer checking off in MP3Gain but I agree, it'd be better if this wasn't the case.

That is the problem!! EAC has changed the settings!

I was actually using .99 prebeta 4, so it still uses the old settings. I upgraded to the latest version of EAC and updated the command line to -V2 --add-id3v2 --pad-id3v2 --ta "%artist%" --tl "%albumtitle%" --tt "%title%" --tn "%tracknr%" --tg "%genre%" --ty "%year%" %source% %dest%
but it still gives me the error.

This is probably a bit off-topic, though, and since it doesn't seem that others are running into this problem, I'll take it offline and see if I can figure something out. I'll report back if I solve the problem!

[robert]

What version of MP3Gain are you using?
Can you call "check integrity" from foobar's utilities for those files?