HydrogenAudio

Hydrogenaudio Forum => Validated News => Topic started by: lvqcl on 2011-10-15 18:07:58

Title: LAME 3.99 is out
Post by: lvqcl on 2011-10-15 18:07:58
October 15 2011: 3.99 beta 1 becomes 3.99

Download: http://www.rarewares.org/mp3-lame-bundle.php (http://www.rarewares.org/mp3-lame-bundle.php)

Changelog: http://lame.cvs.sourceforge.net/viewvc/lam...ml/history.html (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html)
Title: LAME 3.99 is out
Post by: IgorC on 2011-10-16 08:36:31
Congratulations to developers of LAME with their new release 3.99.

Thank You for keeping the development of high quality  and open source MP3 encoder.

So what will be next? 3.100?
Title: LAME 3.99 is out
Post by: halb27 on 2011-10-16 13:34:32
Thanks a lot for the new version.

Tuning on VBR scale / resulting bitrate  is much appreciated, as there was a large gap between -V0 and -b 320 - those settings which are generally expected to yield the highest quality.

I'm curious about the tuning on PSY model.
Title: LAME 3.99 is out
Post by: no404error on 2011-10-16 14:59:35
x86 (lame3.99.zip)
LAME 3.99 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), SSE (ASM used), SSE2

x64 (lame3.99-64.zip)
LAME 3.99 64bits (http://lame.sf.net)
CPU features: , SSE (ASM used), SSE2
Title: LAME 3.99 is out
Post by: ShotCaller on 2011-10-16 18:49:43
So is the best plan to wait for a few more .1 revisions? I heard some complaints about artifacts and buggy psy model in 3.99 beta, have those been fixed? There's nothing in the changelog that would make one think so...
Title: LAME 3.99 is out
Post by: halb27 on 2011-10-16 18:54:54
For learning about 3.99's average bitrate for -Vx i encoded my usual test set of various pop music:

-V5:  3.98.4: 136 kbps  3.99: 126 kbps
-V4:  3.98.4: 152 kbps  3.99: 147 kbps
-V3:  3.98.4: 166 kbps  3.99: 167 kbps
-V2:  3.98.4: 188 kbps  3.99: 191 kbps
-V1:  3.98.4: 207 kbps  3.99: 224 kbps
-V0:  3.98.4: 233 kbps  3.99: 258 kbps

I like this behavior of 3.99.
For the many -V3 and -V2 users things don't really change.
From -V2 to -V0 it's adequate to increase the average bitrate steps from one quality level to the next because audible differences can only be expected with a higher amount of bitrate difference than in the range below -V2.
-V5 now matches pretty well 128 kbps, which is roughly the expected average bitrate for -V5. This is especially welcome for 128 kbps listening tests.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-10-16 19:35:52
My test set:

Code: [Select]
         3.98.4       3.99
-V6:     126 kbps     116 kbps
-V5:     139 kbps     131 kbps
-V4.999: 140 kbps     138 kbps
-V4:     155 kbps     151 kbps
-V3:     169 kbps     171 kbps
-V2.999: 179 kbps     182 kbps
-V2:     200 kbps     197 kbps
-V1:     222 kbps     232 kbps
-V0:     252 kbps     270 kbps

-V2 -Y:  181 kbps     185 kbps
-V1 -Y:  197 kbps     214 kbps
-V0 -Y:  220 kbps     242 kbps
Title: LAME 3.99 is out
Post by: lameboy on 2011-10-16 20:48:44
A big Thank You to the LAME devs for the important work they're doing! (as you can see by my username, I'm a big fan)

An open source, high-quality MP3 encoder continually developed is in my opinion very important, because it still is the de-facto standard for most people when it comes to music files, and it keeps users independent from commercial companies.

I want to donate some money to the LAME project, but I couldn't find a "donate"-button on the site. Does anyone know where it is (if there is one)?



Title: LAME 3.99 is out
Post by: halb27 on 2011-10-16 21:52:00
I did a short listening test comparing 3.99 against 3.98.4.

I chose samples which are real ugly with CBR 128 (better, but still very bad with -V5):

harp40_1 (harpsichord is a problem for mp3 - I concentrate on the chords around sec. 10.0)
lead-voice (a strong tremolo at sec. 0.0-2.0)
eig (strong pre-echo, with a special problem at around sec. 3.0)
herding_calls (at sec. 0.9-3.7 an artifact is audible)
trumpet (an artifact / an inaccuracy which sounds a bit like that in herding_calls)

The samples with all the encoded mp3 variants can be downloaded from here (http://dl.getdropbox.com/u/2681777/ProblemSamples/propblemSamples.zip).

I started comparing -V5.
The result can be summed up quickly: it's all bad, for none of the samples did I have a preference for one of the versions. From that the good message is: 3.99 behaves like 3.98.4, in spite of a somewhat lower average bitrate.

I continued with -V2 and found some differences.
The problem spot with eig at sec. 3.0 is more pronounced with 3.99. On the other hand herding_calls was harder to ABX with 3.99 than with 3.98.4. I was astonished about lead-voice and trumpet: lead-voice because it was so extremely easy to ABX (with both versions), and trumpet because it was rather hard (with both versions).

I finished with -V0.
eig is nearly fine for me as I'm not sensitive for pre-echo. It's just the spot at sec. 3.0 which has me ABX eig rather easily. Again the problem is more pronounced with 3.99. I am also very content with harp40_1 which wasn't easy to ABX (harder with 3.99). The difference with herding_calls was rather strong: With volume set up the right way for this sample (not too loud!) ABXing with 3.98.4 was rather easy, with 3.99 it was very noticeably harder. I ABXed lead-voice easily with both versions. trumpet was hard for me, and with the restricted time I allowed for the test, I could not get sufficiently good ABX results for 3.98.4. With 3.99 I succeeded, but it was very hard, and I consider the 3.99 result to be fine, too. I will redo trumpet tomorrow morning when I hopefully feel fresher than I just did.

As a result I see a certain progress with 3.99. The spot at sec. 3.0 of eig shouldn't be overestimated. For judging pre-echo behavior we hopefully get other listening test results from members who are more concerned about pre-echo problems than I am.
Title: LAME 3.99 is out
Post by: IgorC on 2011-10-16 22:46:38
Interesting report.

As a result I see a certain progress with 3.99. The spot at sec. 3.0 of eig shouldn't be overestimated.

I saw You have tested a short time (4 sec) of eig sample.  That's why You have found only one pulsive artifact. The artifacts are more clear on longer version of the sample because it's now the whole train of them.

I found that 3.99 does better than 3.98.4 for eig in my last report.


P.S. But if it was me you will probably saying "There must have gone something wrong"  . You see we are all different listeners, there is no "wrong".
Title: LAME 3.99 is out
Post by: halb27 on 2011-10-16 23:39:41
Sorry for having said "There must have gone something wrong" about your first report you gave on trumpet behavior. My remark was for the report as such, especially as I missed one result, and I was afraid that you mixed up your 3.97 result with that of a later version. It was not meant to be about your listening experience. When you explained this it's true I was astonished that you preferred 3.97 over 3.98. You're right, we're all different listeners, and our listening experience can vary under different circumstances.

As for eig probably everybody is more adequate to report on pre-echo behavior than I am. That's why I hoped I made it clear that I can only report differences about the spot at sec. 3.0. As for this spot though I'd be surprised if somebody would prefer 3.99. It is possible of course because as you said: we're all different listeners.

I'll have a look at the entire eig sample. I shortened it a long time ago because this allowed me to crank up volume. Later in the track the 'music' gets very loud which prevented me from listening very loud in the first 4 seconds, and with my extract I thought I had the important impulse part. I'll have a look into it.
Title: LAME 3.99 is out
Post by: IgorC on 2011-10-17 00:10:10
It's ok  , halb27. My sarcasm sometimes drives me crazy.

Now it makes me wonder what other people hear on eig sample.
Title: LAME 3.99 is out
Post by: Wombat on 2011-10-17 03:58:53
I didn´t really test anything because i don´t use mp3 much anymore. I encoded my old samples suite with V2 and found no regression on these.
I hear eig with 398.4 and V2 not worse in the whole sample, at least the 15second sample i have. The most obvious difference is the clear artifact at ~second 3 and 9 with 3.99 but me also isn´t to good on typical pre-echo samples.

Edit: Around second 9 both add some artifact that is louder to me with 3.99 also. Besides that i can´t listen such music for to long, so it doesn´t really matter
Title: LAME 3.99 is out
Post by: halb27 on 2011-10-17 08:07:27
I just retested trumpet, and this morning it was not extremely hard to ABX the 3.98.4 result. Today ABXing 3.99 was harder for me. The very effect you ran upon, IgorC.
As both results are so good to me that in practical listening situations with no reference to the original I really wouldn't complain, I'd call both results fine.

As for eig I tried the full sample, and became quickly aware again why I shortened the track for my purpose. The bass after sec. 4 is so strong that I can't hear any issue, not even at around sec. 9.
The discussion on eig made me one thing very clear: I will not report on pre-echo behavior again. I'm well aware now that I used eig in a kind of 'oh, me too can hear some pre-echo problem', but if I can only report about a specific spot within a track full of pre-echo prone impulses, I better am quiet. Guess I will still listen to that spot and possibly report about it, but in the sense of a specific artifact, not in the sense of pre-echo.
As for 3.99 V0's pre-echo behavior I expect it to be better than that of 3.98.4 because 3.99 uses a frame packaging strategy with the target of avoiding a large percentage of otherwise inaccurately encoded frames, and because 3.99 -V0 has higher accuracy demands than has 3.98.4 -V0.
Title: LAME 3.99 is out
Post by: TuNk77 on 2011-10-17 18:23:09
I don't know if this is the right place to ask this question, but I am wondering why LAME 3.99 32-bits and LAME 3.99 64-bits make mp3's that are different in size.
One example is this: an mp3 made with LAME 3.99 32-bits is 7,76 MB (8 138 854 bytes) in size, but the same song encoded with LAME 3.99 32-bits is 7,75 MB (8 137 291 bytes) in size.
The song was ripped with EAC 10. B3 and not modified in any way.
But, I am puzzled about that 1563 bytes in filesize difference

Edit: I forgot to mention that I used LAME 3.99 Bundle compiled with Intel Compiler 11.1. and LAME 3.99 64bit Bundle compiled with Intel Compiler 11.1. Downloaded from rarewares yesterday.
Title: LAME 3.99 is out
Post by: john33 on 2011-10-17 19:10:07
Quite simply, it's the fact that one is generating a compile for 32 bit using the internal 'nasm routines' whereas the 64 bit compile uses the compiler's internal processor optimisations. In this case the same compiler is used, but if compiles for the same target are created using different compilers, the encoded output will differ in size to a small extent because the internal math routines differ, amongst other things. I hasten to add that no one, to the best of my knowledge, has yet been able to discern any audible differences between any of the differing outputs generated by the encoders created with different compilers.
Title: LAME 3.99 is out
Post by: TuNk77 on 2011-10-17 19:21:47
Thank you for replying john33 and thanks for clarifying and explaining the filesize difference for me (and others)
Title: LAME 3.99 is out
Post by: inrobert on 2011-10-17 23:06:06
Hello. I have a problem with new version.
After upgrading to version 3.99 id3v2.3|id3v1 tags are automatically created during WAV encoding process, showing field <ENCODING SETTINGS> : LAME 32bits version 3.99 (http://lame.sf.net) in foobar2000 v1.1.8.
My LAME parameters in foobar2000 are: --silent --noreplaygain -V0 - %d. With EXACTLY the same parameters id3 tags are not created with LAME 3.98.4.
How to prevent LAME 3.99 from creating id3 tags? I was experimenting with parameters, reading LAME documentation, but couldn't find solution.
Title: LAME 3.99 is out
Post by: robert on 2011-10-18 01:06:06
Confirmed, fixed sources are available from SF.net.
Title: LAME 3.99 is out
Post by: ShotCaller on 2011-10-18 04:09:45
What is everyone's thoughts on -V 0 now using the full spectrum and no low pass filter? Is there really any reason to preserve frequencies above 20 kHz? Would manually applying a low pass filter be wise? I'm also wondering why CBR 320 encodes are not using full spectrum too considering it now uses the same psymodel as VBR.
Title: LAME 3.99 is out
Post by: halb27 on 2011-10-18 06:29:01
Thanks for the info.
I don't like having no or an extremely high low-pass. It's probably a concession towards those people who come up here occasionally demanding for the settings which allow for the 'full range'.

But it's not a problem as we can use --lowpass. Maybe it's not bad to find out for ourselves where to put the lowpass.
Title: LAME 3.99 is out
Post by: john33 on 2011-10-18 10:40:38
Confirmed, fixed sources are available from SF.net.

Fresh compiles from the amended sources are now at Rarewares.
Title: LAME 3.99 is out
Post by: Northpack on 2011-10-18 10:59:33
What is everyone's thoughts on -V 0 now using the full spectrum and no low pass filter? Is there really any reason to preserve frequencies above 20 kHz? Would manually applying a low pass filter be wise? I'm also wondering why CBR 320 encodes are not using full spectrum too considering it now uses the same psymodel as VBR.

Very good question. Any explanation for this kind of inconsistency? It seems completely illogical to me to have a lowpass at CBR 320 and no lowpass at -V0
Title: LAME 3.99 is out
Post by: robert on 2011-10-18 11:19:22
Tuning CBR/ABR is something I have planned to do in 3.100.
Title: LAME 3.99 is out
Post by: temp1 on 2011-10-18 11:36:40
Confirmed, fixed sources are available from SF.net.

Fresh compiles from the amended sources are now at Rarewares.

thank u, i love L.A.M.E 
my favorite
Title: LAME 3.99 is out
Post by: no404error on 2011-10-18 12:41:31
Confirmed, fixed sources are available from SF.net.

Fresh compiles from the amended sources are now at Rarewares.

And once again

x86
LAME 3.99 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), SSE (ASM used), SSE2

x64
LAME 3.99 64bits (http://lame.sf.net)
CPU features: , SSE (ASM used), SSE2

Title: LAME 3.99 is out
Post by: robert on 2011-10-18 13:20:42
That's actually not a bug for the x64 compile, only a glitch in the display routine, nothing to worry about.
Title: LAME 3.99 is out
Post by: markanini on 2011-10-18 14:14:11
Thanks for the info.
I don't like having no or an extremely high low-pass. It's probably a concession towards those people who come up here occasionally demanding for the settings which allow for the 'full range'.

But it's not a problem as we can use --lowpass. Maybe it's not bad to find out for ourselves where to put the lowpass.

Would this be recommended? My experiments with tones and filtered noise suggest I don't hear anything past 16kHz at sane levels. Which then bears the question: Should I use -Y switch or the lowpass switch?
Title: LAME 3.99 is out
Post by: no404error on 2011-10-18 15:22:02
That's actually not a bug for the x64 compile, only a glitch in the display routine, nothing to worry about.

Bug, glitch, feature... Never mind, but it's looks like too lame xD
Title: LAME 3.99 is out
Post by: halb27 on 2011-10-18 17:00:47
Thanks for the info.
I don't like having no or an extremely high low-pass. It's probably a concession towards those people who come up here occasionally demanding for the settings which allow for the 'full range'.

But it's not a problem as we can use --lowpass. Maybe it's not bad to find out for ourselves where to put the lowpass.
Would this be recommended? My experiments with tones and filtered noise suggest I don't hear anything past 16kHz at sane levels. Which then bears the question: Should I use -Y switch or the lowpass switch?

That's a question of taste. Both methods help. If you consider to use a high lowpass frequency > 17.5 kHz, -Y is expected to be more efficient. That's why it's automatically used internally with -V3 and below.
If you can allow for a lower limit frequency as it looks you can, I'd use a lowpass. I am very happy with using --lowpass 16.7.
Title: LAME 3.99 is out
Post by: inrobert on 2011-10-18 19:28:01
Confirmed, fixed sources are available from SF.net.

Fresh compiles from the amended sources are now at Rarewares.

Thanks! Works well now.
Title: LAME 3.99 is out
Post by: Agent69 on 2011-10-18 20:01:36
http://lame.cvs.sourceforge.net/viewvc/lam...ml/history.html (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html)

October 15 2011: 3.99 beta 1 becomes 3.99

And compiles are at Rarewares!!


I just wanted to say thanks for providing these compiles John.
Title: LAME 3.99 is out
Post by: punkrockdude on 2011-10-18 21:22:06
John33: do you know why the x64 version does not work in Reaper x64 when your x86 compile works in Reaper x86? maybe difficult for you to answer if it is a Reaper issue. I have made a thread over at Reaper's forum as well. http://forum.cockos.com/showthread.php?p=831811 (http://forum.cockos.com/showthread.php?p=831811) . Regards.
Title: LAME 3.99 is out
Post by: john33 on 2011-10-18 21:30:06
John33: do you know why the x64 version does not work in Reaper x64 when your x86 compile works in Reaper x86? maybe difficult for you to answer if it is a Reaper issue. I have made a thread over at Reaper's forum as well. http://forum.cockos.com/showthread.php?p=831811 (http://forum.cockos.com/showthread.php?p=831811) . Regards.

I'm afraid I have no idea as I don't even know what Reaper is!!
Title: LAME 3.99 is out
Post by: Steve Forte Rio on 2011-10-18 21:41:32
Question for the LAME developer: may I ask you, what was a reason of rising the lowpass value (actually disabling it) for VBR V0 to the inaudible range (22100 Hz)?
Title: LAME 3.99 is out
Post by: lvqcl on 2011-10-18 21:52:07
Apparently Reaper is a program that uses lame_enc.dll

The code from BladeMP3EncDLL:

Code: [Select]
typedef    unsigned long    HBE_STREAM;
typedef    HBE_STREAM    *PHBE_STREAM;
...
PHBE_STREAM phbeStream;
...
lame_global_flags* gfp = NULL;

// Init the global flags structure
gfp = lame_init();
*phbeStream = (HBE_STREAM)gfp;
...
lame_global_flags* gfp = (lame_global_flags*)hbeStream;


This code works only when sizeof (unsigned long) == sizeof(pointer).
(Or when the upper half of a pointer is 0. Maybe setting largeaddressaware=0 to Reaper executable should help)


This is in the change log of Reaper 3.35:
x64: now requires libmp3lame.dll or lame_enc64.dll (old x64 lame_enc.dll was broken)


IMHO  64-bit libmp3lame.dll is better than lame_encXX.
Title: LAME 3.99 is out
Post by: punkrockdude on 2011-10-18 22:23:06
lvqcl, thank you very much for the detailed reponse. DO you know where I can find the other dll using latest 3.99. I have only found lame_enc64.dll. Regards.
Title: LAME 3.99 is out
Post by: ShotCaller on 2011-10-19 16:59:58
Question for the LAME developer: may I ask you, what was a reason of rising the lowpass value (actually disabling it) for VBR V0 to the inaudible range (22100 Hz)?


I'd be interested in hearing what the developers have to say about this as well. Are these high frequencies truly inaudible? Can their presence have an effect on the audible range?
Title: LAME 3.99 is out
Post by: lameboy on 2011-10-20 15:19:47
For Mac-users there's a plugin available for XLD (scroll down to the download-section):

http://tmkk.pv.land.to/xld/index_e.html (http://tmkk.pv.land.to/xld/index_e.html)

Extract it to ~/Library/Application Support/XLD/PlugIns

Title: LAME 3.99 is out
Post by: kwanbis on 2011-10-22 01:31:41
Question for the LAME developer: may I ask you, what was a reason of rising the lowpass value (actually disabling it) for VBR V0 to the inaudible range (22100 Hz)?

I'll be interested on knowing too.
Title: LAME 3.99 is out
Post by: IgorC on 2011-10-22 09:00:54
++
My guess is that it's something to do with pre echo handling.
Title: LAME 3.99 is out
Post by: krafty on 2011-10-23 20:56:10
I too noticed that there is no lowpass using -V0.
Can this be to "compete" with iTunes which doesn't apply a lowpass with 256 kbps VBR setting anymore?
There may be people "feeling" more comfortable using AAC or OGG, than MP3 just because of this...

Any developer to explain this?
Title: LAME 3.99 is out
Post by: Gregory S. Chudov on 2011-10-24 20:53:25
I'm using lame_enc.dll in CUETools, and have some problems with it's BladeEnc interface, for example it cannot write LAME header to files with Unicode paths, because beWriteInfoTag uses ASCII string.

lame_enc.dll also exposes alternative lame_* interface, and i was considering using it, but the .def file wasn't updated for a long time, so many of the functions are not available. It seems that Audacity has the same problem, so they use their own version of lame_enc.dll (http://lame1.buanzo.com.ar/) which exposes more functions, but there's only a 32-bit version there, and they also don't expose some important functions, such as lame_get_lametag_frame() and lame_set_VBR_quality().

John, would it be possible to make lame_enc.dll expose the full LAME API (like libmp3lame.dll)?
Title: LAME 3.99 is out
Post by: lvqcl on 2011-10-24 21:07:51
Why do you want to use lame_enc.dll, but not libmp3lame.dll?

( both x32 and x64 DLLs for LAME 3.98.4 are available at http://lame.bakerweb.biz/ (http://lame.bakerweb.biz/)  )
Title: LAME 3.99 is out
Post by: Gregory S. Chudov on 2011-10-24 21:13:47
That would be the alternative, yes. But it still would be nice if people could use the builds from rarewares too. I wouldn't ask if blade_enc.dll was exposing _only_ BladeEnc API, but it does also expose some subset of LAME API, why not all of it? Such a .dll could probably work for all applications - EAC, Audacity, CUETools...
Title: LAME 3.99 is out
Post by: [JAZ] on 2011-10-25 19:01:12
That would be the alternative, yes. But it still would be nice if people could use the builds from rarewares too. I wouldn't ask if blade_enc.dll was exposing _only_ BladeEnc API, but it does also expose some subset of LAME API, why not all of it? Such a .dll could probably work for all applications - EAC, Audacity, CUETools...


I'd say the answer is around the lines of why to use .mkv or .mp4 instead of .avi.

Remember that the API of blade_enc was defined more than 10 years ago. There was not even the concept of 64bits. (Aside of some Alpha stations and other types of supercomputers )
Title: LAME 3.99 is out
Post by: Frankie on 2011-10-25 21:43:35
3.99 works fine but on my machine (Intel Dual Core E5300) runs ~12% slower then the latest 3.98 (both are from rarewares).
Title: LAME 3.99 is out
Post by: Destroid on 2011-10-26 11:28:31
I was about to post LAME 3.99 b1.2 test I ran compared to 3.98.4 that the newer LAME (at -V2) has better efficiency with tracks containing more mono data and that overall bit rate is the same if not more "flexible" for critical sounds. This was in light of my latest album release and wanted to analyze how lossy dealt with the tracks. I don't expect LAME 3.99 final to be too radically different.

Thanks LAME team and HA!
Title: LAME 3.99 is out
Post by: Alex B on 2011-10-26 13:19:08
A quad-core AMD Phenom II, XP Pro 32-bit, foobar2000, four simultaneous encoding processes, -S -V2 --noreplaygain - %d, source: 25 various wave tracks.

3.98.4 (the main bundle from Rarewares)
Total encoding time: 0:40.922, 134.34x realtime

The 'icc-patcher' compile (x86):
Total encoding time: 0:51.359, 107.04x realtime

3.99 (the main bundle from Rarewares)
Total encoding time: 0:48.500, 113.35x realtime

The 3.99 release compile is yet again slightly faster than the last beta compile was, but 3.98.4 is still almost 20% faster on my machine. (I did my best to reproduce the earlier test conditions, run the test several times and picked the middle result.)
Title: LAME 3.99 is out
Post by: lvqcl on 2011-10-26 16:56:16
Results of "lame -S -V2 --noreplaygain test.wav nul" on Intel Core2: encoding time in seconds

Rarewares compiles:
x32: 148 s
x64: 116 s

My compiles (MSVS 2010, fast math + SSE enabled):
x32 NASM: 125 s
x32 SSE2: 135 s
x64 SSE2: 119 s

Also, Rarewares Lame 3.98.4:
x32: 130 s
x64: 144 s
Title: LAME 3.99 is out
Post by: psycho on 2011-10-26 18:40:35
My results (samples taken from http://ff123.net/samples.html (http://ff123.net/samples.html)):

My CPU: AMD Athlon 64 X2 4000+ (Brisbane)
Endodes done with command line: -V 0

Rarewares 3.99 build:

LisztBMinor sample:
15.219x - 246.6 kbps

ATrain sample:
14.614x - 256.3 kbps

BachS1007 sample:
15.988x - 229.8 kbps

DaFunk sample:
14.185x - 287.6 kbps

ExitMusic sample:
15.921x - 250.4 kbps


My 3.99 build (MinGW 5.1.6 with MSYS-1.0.11 with yasm-1.1.0-win32.exe for nasm.exe):

LisztBMinor sample:
16.363x - 242.7 kbps

ATrain sample:
15.729x - 254.0 kbps

BachS1007 sample:
16.583x - 227.2 kbps

DaFunk sample:
15.520x - 285.6 kbps

ExitMusic sample:
15.909x - 250.1


It's curious to see how my build is faster and produces smaller mp3 files...
Title: LAME 3.99 is out
Post by: psycho on 2011-10-26 19:54:32
I forgot to mention:

OS: WinXP SP3 32-bit


Can't edit my previous post, so I will post my next test results here:

Here are the results with 3.98.4:

Rarewares 3.98.4 build:

LisztBMinor sample:
18.444x - 217.9 kbps

ExitMusic sample:
18.947x - 225.1 kbps


http://lame.bakerweb.biz/ (http://lame.bakerweb.biz/) 3.98.4 build:

LisztBMinor sample:
14.077x - 217.9 kbps

ExitMusic sample:
14.648x - 224.1 kbps


My 3.98.4 build (MinGW 5.1.6 with MSYS-1.0.11 with yasm-1.1.0-win32.exe for nasm.exe):

LisztBMinor sample:
15.770x - 217.9 kbps

ExitMusic sample:
16.742x - 224.6 kbps


Question for john33: I have Microsoft Visual C++ 6.0 - how can I compile lame with it?
Title: LAME 3.99 is out
Post by: Alex B on 2011-10-26 20:51:38
Rarewares 3.98.4 build:

LisztBMinor sample:
18.444x - 217.9 kbps

ExitMusic sample:
18.947x - 225.1 kbps

Which Rarewares build? The old "main" compile:
Quote
From: http://web.archive.org/web/20110722042821/...lame-bundle.php (http://web.archive.org/web/20110722042821/http://www.rarewares.org/mp3-lame-bundle.php)

LAME 3.98.4
2010-03-23

Bundle compiled with Intel Compiler 11.1.
Download (563kB)

... or the currently available "VC6/Intel Compiler 9.1" compile:
Quote
From: http://www.rarewares.org/mp3-lame-bundle.php (http://www.rarewares.org/mp3-lame-bundle.php)

LAME 3.98.4
2009-06-06

Bundle compiled with VC6/Intel Compiler 9.1 - intended for older Windows OSs.
Download (494kB)


I used the "Intel Compiler 11.1" version in my 3.98.4 test.
Title: LAME 3.99 is out
Post by: robert on 2011-10-26 21:21:15
Question for john33: I have Microsoft Visual C++ 6.0 - how can I compile lame with it?


With LAME sources comes a Makefile.MSVC, I used that to build LAME from the command line using VC6, back in the days.

Code: [Select]
lame v399: -V0 --noreplaygain LoveSexy.wav

m:ss    x    kbps    

2:06    21.3    260.8    gcc4.1.2    x86/makefile.unix CFG=RH_SSE

2:42    16.617    257.5    VC9 Express    x86/Release
2:02    22.099    259.8    VC9 Express    x86/ReleaseSSE

2:23    18.790    256.3    VC11 D-Prev    x86/Release
1:52    23.925    256.3    VC11 D-Prev    x86/ReleaseSSE

2:02    22.152    256.3    VC11 D-Prev    x64/Release
1:45    25.689    256.3    VC11 D-Prev    x64/ReleaseSSE

machine: Athlon 64x2 4000+ Brisbane @2.4GHz 8GB Win7 64bit / Suse 10.2 x86
Title: LAME 3.99 is out
Post by: psycho on 2011-10-26 21:28:20
Alex B, I used the "VC6/Intel Compiler 9.1" compile of Rarewares' 3.98.4.

john33, thanks, I'll try Makefile.MSVC.
Title: LAME 3.99 is out
Post by: Alex B on 2011-10-26 21:54:50
Alex B, I used the "VC6/Intel Compiler 9.1" compile of Rarewares' 3.98.4.

When I tested the 3.98.4 compiles in early October "VC6/Intel Compiler 9.1" was sligthly slower than "Intel Compiler 11.1" -- but perhaps not insignificantly because on average the speed difference was constantly reproducible (I ran the tests several times):
3.98.4 (the main bundle from Rarewares)
Total encoding time: 0:40.922, 134.34x realtime

3.98.4 (the VC6 compile from Rarewares)
Total encoding time: 0:41.625, 132.07x realtime

I really would not like to sacrifice any of the encoding speed just because of the new version is out. In the past a slightly improved encoding speed has often been a good reason to upgrade to the new version. 3.98.4 has been a fine LAME version and I may continue to use it (at least for now).
Title: LAME 3.99 is out
Post by: Alex B on 2011-10-26 22:08:18
Results of "lame -S -V2 --noreplaygain test.wav nul" on Intel Core2: encoding time in seconds

Rarewares compiles:
x32: 148 s

My compiles (MSVS 2010, fast math + SSE enabled):
x32 NASM: 125 s
x32 SSE2: 135 s

Also, Rarewares Lame 3.98.4:
x32: 130 s

Your 32-bit 3.99 compiles are interesting. The NASM compile is actually faster than the Rarewares 3.98.4 version. What does "NASM" mean in this case?
Title: LAME 3.99 is out
Post by: psycho on 2011-10-26 22:10:20
john33, I managed to compile lame.exe with VC6, however it doesn't encode.

If I just run lame.exe with no command line options, it displays the version info normally, however if I want to encode with it, I get an error:
Title: LAME 3.99 is out
Post by: robert on 2011-10-26 22:53:19
Your 32-bit 3.99 compiles are interesting. The NASM compile is actually faster than the Rarewares 3.98.4 version. What does "NASM" mean in this case?


NASM compile uses "Netwide Assembler" code for some routines. Btw., using the very same VC9 and compiling 3.99 and 3.98.4 (ReleaseNASM configuration), there is not much of an speed difference:

Code: [Select]
LAME 3.98.4 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding w:\cd\Prince\1988-Lovesexy\01 Songs are in a continous sequence.wav
      to x.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
103492/103492(100%)|    2:22/    2:22|    2:22/    2:22|   18.913x|    0:00
32 [     0]
40 [     1] %
48 [     0]
56 [     1] %
64 [     0]
80 [     4] *
96 [   115] *
112 [  1580] %**
128 [  7331] %************
160 [ 40039] %%%***************************************************************
192 [ 33304] %%%%%%%%%%%********************************************
224 [ 11836] %%%%%***************
256 [  5489] %%********
320 [  3792] %%*****
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  185.5       12.5  87.5        88.0   6.4   5.6
Writing LAME Tag...done

LAME 3.99 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding w:\cd\Prince\1988-Lovesexy\01 Songs are in a continous sequence.wav
      to x.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
103492/103492(100%)|    2:20/    2:20|    2:20/    2:20|   19.266x|    0:00
32 [     1] %
40 [     0]
48 [     0]
56 [     0]
64 [     0]
80 [     0]
96 [     2] %
112 [    81] %
128 [  5400] %********
160 [ 43295] %%%%%%************************************************************
192 [ 37019] %%%%%%%%%%%%%%%%%****************************************
224 [  8887] %%%%%*********
256 [  6608] %%%********
320 [  2199] %%**
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  184.8       19.1  80.9        88.0   6.4   5.6
Writing LAME Tag...done


Code: [Select]
LAME 3.98.4 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding w:\cd\Prince\1988-Lovesexy\01 Songs are in a continous sequence.wav
      to x.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
103492/103492(100%)|    3:17/    3:17|    3:17/    3:17|   13.677x|    0:00
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  128.0        7.8  92.2        92.9   4.1   2.9
Writing LAME Tag...done

LAME 3.99 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding w:\cd\Prince\1988-Lovesexy\01 Songs are in a continous sequence.wav
      to x.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
103492/103492(100%)|    2:58/    2:58|    2:58/    2:58|   15.177x|    0:00
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  128.0        8.5  91.5        92.6   4.1   3.3
Writing LAME Tag...done
Title: LAME 3.99 is out
Post by: krafty on 2011-10-29 18:11:10
No one is going to explain the lowpass thing?

Robert can you give any insight on that...
Title: LAME 3.99 is out
Post by: ShotCaller on 2011-10-30 17:32:30
Considering -V 0 now uses no lowpass filter, would it make sense to disable the lowpass filter for my CBR 320 encodes via the command "--lowpass -1"? Also, does anyone know if the "--buffer-constraint" command is still useful?
Title: LAME 3.99 is out
Post by: /mnt on 2011-10-30 22:41:46
As a result I see a certain progress with 3.99. The spot at sec. 3.0 of eig shouldn't be overestimated. For judging pre-echo behavior we hopefully get other listening test results from members who are more concerned about pre-echo problems than I am.


I have done a quick test with LAME 3.99 against 3.97 at 320kbps, since new tunings have been introduced on the CBR modes.

Everything Is Green - sounds worse on LAME 3.99, an easy to spot artifact appears at the start on the 3.99 encode, plus the pre-echo artifacts throughout the sample is more noticable to me.

Musique Non Stop - sounds worse on LAME 3.99, really bad disortion at the 0:04 mark.

That's What I Get - sounds better on LAME 3.99, less smearing on the synth.

Homecomputer
and Show Me You Spine - sounds both equally bad on both encodes.
Title: LAME 3.99 is out
Post by: chichazor on 2011-10-31 00:25:12
¿There is a regression in sound quality with -V2? A made a quick test with the album Soundchaser of Rage, and with the 3.99 the bitrates are 20-30 kbps lower than the 3.98.4 and I can abx without problems :S
Title: LAME 3.99 is out
Post by: DARcode on 2011-10-31 11:41:33
Is there a reson why the old "main" 2010-03-23 Intel Compiler 11.1 LAME 3.98.4 compile has been removed from RareWares please?
Title: LAME 3.99 is out
Post by: john33 on 2011-10-31 11:49:55
Is there a reson why the old "main" 2010-03-23 Intel Compiler 11.1 LAME 3.98.4 compile has been removed from RareWares please?

Yes!  I have always removed the previous released version when a new release becomes available.

If you require the older release, you can d/l it here:

http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4.zip)
Title: LAME 3.99 is out
Post by: DARcode on 2011-10-31 12:15:02
Thank you John, I was actually looking the the LAME 3.98.4 64bit 2010-06-08 build please, sorry for the confusion I quoted Alex B to be quicker.
EDIT 2: Got it modding your link, thanks.

Is version 3.99 (I know it's beta 1 renamed) the HA recommended one already?

Anyway, why leave the 3.98.4 VC6/Intel Compiler 9.1 compile instead of the Intel Compiler 11.1 one available on RW? More universally compatible?

EDIT 1: grammar.
Title: LAME 3.99 is out
Post by: john33 on 2011-10-31 12:20:32
http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4-64.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4-64.zip)

There you go!

I'm not sure whether the concensus is that 3.99 is better, or not, as yet!
Title: LAME 3.99 is out
Post by: halb27 on 2011-10-31 19:04:45
I have done a quick test with LAME 3.99 against 3.97 at 320kbps, since new tunings have been introduced on the CBR modes....

Since several Lame versions there are some question marks about improvements with CBR. Do you mind testing -V0?
Title: LAME 3.99 is out
Post by: john33 on 2011-11-01 18:37:12
New compiles at Rarewares reflecting id3 tagging changes, plus 64 bit libsndfile 1.0.25 compile added.
Title: LAME 3.99 is out
Post by: GeSomeone on 2011-11-01 20:16:55
Thanks John,
this seems to be 3.99.1 beta (or even before that)
One of the files has a release date of next week 
Title: LAME 3.99 is out
Post by: john33 on 2011-11-01 22:23:36
Thanks John,
this seems to be 3.99.1 beta (or even before that)

Why do you say that?
One of the files has a release date of next week 

Doh! Fixed with yet another id3 update!
Title: LAME 3.99 is out
Post by: sld on 2011-11-02 01:53:32
Has anybody tried to compile with the Open64 compiler?

http://www.open64.net/home.html (http://www.open64.net/home.html)
Title: LAME 3.99 is out
Post by: GeSomeone on 2011-11-02 12:23:12
Thanks John,
this seems to be 3.99.1 beta (or even before that)

Why do you say that?

I looked at the updated history.html, not meaning to cause confusion.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-02 12:55:54
Ah, OK, I thought it was perhaps something I had got wrong!!
Title: LAME 3.99 is out
Post by: john33 on 2011-11-02 14:13:04
So as to be sure that my compiles work on both Intel and AMD CPUs, I've changed my development system to a Phenom II X4 840 with 8GB of Corsair DDR3.

Checking the latest compiles, I also produced VC10 compiles for comparison. The Intel compiles, after running through icc_patch are between 5% and 10% faster on the above system than the VC10 versions.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-11-02 15:55:10
Has anybody tried to compile with the Open64 compiler?

Since it is Linux only, I doubt it.
Title: LAME 3.99 is out
Post by: no404error on 2011-11-02 16:53:26
So as to be sure that my compiles work on both Intel and AMD CPUs, I've changed my development system to a Phenom II X4 840 with 8GB of Corsair DDR3.

Checking the latest compiles, I also produced VC10 compiles for comparison. The Intel compiles, after running through icc_patch are between 5% and 10% faster on the above system than the VC10 versions.

Intel Pentium G630, DDRIII 533Mhz, Windows 7 Home Basic x64

lame -V0 test.wav nul

lame3.99-20111101-2
33.144x

lame3.99-64-20111101-2
41.422x

lame3.99-libsndfile-20111101-2
33.121x

lame3.99-libsndfile-64-20111101-2
41.348x
Title: LAME 3.99 is out
Post by: Alex B on 2011-11-02 18:07:54
Using the same test setup as before,

LAME 3.99 32-bit (the latest main bundle, Intel Compiler 11.1, 2011-11-01_2):
Total encoding time: 0:46.703, 117.71x realtime

LAME 3.98.4 (to make sure that my system has not changed significantly, I retested the 32-bit Intel compile from the old "3.98.4 main bundle")
Total encoding time: 0:40.875, 134.50x realtime
(my previous 3.98.4 result was: Total encoding time: 0:40.922, 134.34x realtime)
Title: LAME 3.99 is out
Post by: viktor on 2011-11-02 18:24:03
john, any chance for a 64 bit lamedropxpd build?
Title: LAME 3.99 is out
Post by: robert on 2011-11-02 19:11:28
@Alex
Just trying to figure out, what is so special on your report. Can you please run a single instance of LAME from the command line and see how encoding times compare there?

edit:
OK, I can confirm Alex's observation: John's older vc6-intel compiled version is 20% faster on my Athlon64X2, than the newer ic11.1 one. Though, my own VC9-NASM compiles are equally fast, but 11% slower than John's IC11.1 one.
Title: LAME 3.99 is out
Post by: Alex B on 2011-11-02 21:52:26
@Alex
Just trying to figure out, what is so special on your report. Can you please run a single instance of LAME from the command line and see how encoding times compare there?

I created a consolidated wave file from the same 25 wave tracks that I used in the previous tests and tested the encoders in a cmd window.

Apparently my quad-core Phenom II doesn't produce very repeatable results when it is not fully stressed. When a single encoder runs in a cmd window the results vary greatly. I have the Asus E-PU 4-Engine "power saving engine" running. It was set to "High Performance" during the tests, but either it or the power features that are enabled in BIOS make the results rather unreliable.

For example, I could now have posted these results and made 3.99 look even slower than it is:
3.99:  21.624x
3.84:  32.890x

-- but after running several test runs I think the following results are quite correct (they are about average from all runs):

LAME 3.99
Code: [Select]
C:\Soft\LAME\399>lame -V2 --noreplaygain "S:\Test\Testfile.wav" "F:\Test\HA\399s
peed\lame399.mp3"
LAME 3.99 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding S:\Test\Testfile.wav to F:\Test\HA\399speed\lame399.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
210463/210463(100%)|    3:33/    3:33|    3:33/    3:33|   25.715x|    0:00
32 [   862] %
40 [     9] %
48 [    20] %
56 [    29] %
64 [    78] %
80 [    84] %
96 [    71] %
112 [   219] %
128 [  3292] %**
160 [ 53858] %%%%%%%%%%****************************
192 [ 94613] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*********************************
224 [ 29853] %%%%%%%%%%%**********
256 [ 18511] %%%%%%%******
320 [  8964] %%%%%**
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  197.5       43.8  56.2        87.6   6.4   6.0
Writing LAME Tag...done

LAME 3.98.4
Code: [Select]
C:\Soft\LAME\3984>lame -V2 --noreplaygain "S:\Test\Testfile.wav" "F:\Test\HA\399
speed\lame3984.mp3"
LAME 3.98.4 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding S:\Test\Testfile.wav to F:\Test\HA\399speed\lame3984.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
210463/210463(100%)|    3:16/    3:16|    3:16/    3:16|   27.952x|    0:00
32 [   884] %
40 [     4] %
48 [     5] %
56 [    12] %
64 [    24] %
80 [    33] %
96 [   160] %
112 [   951] %
128 [  5223] %****
160 [ 53089] %%%%%%%%************************************
192 [ 80140] %%%%%%%%%%%%%%%%%%%%%%%*******************************************
224 [ 36470] %%%%%%%%%%*********************
256 [ 18169] %%%%%%*********
320 [ 15299] %%%%%%%******
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  201.6       29.5  70.5        87.6   6.4   6.0
Writing LAME Tag...done

A bit surprisingly 3.99 creates quite a bit more LR frames than 3.98.4. Is this an intended change?
Title: LAME 3.99 is out
Post by: john33 on 2011-11-02 22:32:25
john, any chance for a 64 bit lamedropxpd build?

I'm looking at it.
Title: LAME 3.99 is out
Post by: robert on 2011-11-02 22:41:04
A bit surprisingly 3.99 creates quite a bit more LR frames than 3.98.4. Is this an intended change?

That's a consequence of PSY model corrections in 3.99, so yes, it's intended.
Title: LAME 3.99 is out
Post by: Alex B on 2011-11-02 23:38:10
For comparison here is LAME 3.97. I have no idea about the compiler, but probably my archived encoder is from the past Rarewares "main bundle".

LAME 3.97
Code: [Select]
C:\Soft\LAME\397>lame -V2 --vbr-new --noreplaygain "S:\Test\Testfile.wav" "F:\Te
st\HA\399speed\lame397.mp3
LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding S:\Test\Testfile.wav to F:\Test\HA\399speed\lame397.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
210463/210463(100%)|    3:55/    3:55|    3:56/    3:56|   23.339x|    0:00
32 [   972] %
40 [    54] %
48 [    41] %
56 [    31] %
64 [    21] %
80 [   103] %
96 [   493] %
112 [  3200] %**
128 [  9556] %********
160 [ 54917] %%%%%%%********************************************
192 [ 71955] %%%%%%%%%%%%%%%%%%%%**********************************************
224 [ 40066] %%%%%%%%%%%%*************************
256 [ 21026] %%%%%%%*************
320 [  8028] %%%%****
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  195.8       24.8  75.2        91.5   4.8   3.8
Writing LAME Tag...done

The tendency seems to be to use more LR frames in each new version.

Regarding my speed results from running a single lame instance in a cmd window, perhaps you should ignore them. I ran a few additional tests and the results really vary too much from one run to another. When foobar2000 runs four simultaneous encoder instances, the results seem to be quite reproducible.
Title: LAME 3.99 is out
Post by: robert on 2011-11-03 00:27:07
So as to be sure that my compiles work on both Intel and AMD CPUs, I've changed my development system to a Phenom II X4 840 with 8GB of Corsair DDR3.

Checking the latest compiles, I also produced VC10 compiles for comparison. The Intel compiles, after running through icc_patch are between 5% and 10% faster on the above system than the VC10 versions.

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.
Title: LAME 3.99 is out
Post by: Fishman0919 on 2011-11-04 02:56:26
I did a quick test of VC 11 w/nasm 2.10rc8 and MinGW on a AMD Phenom 9950 X4

VC11... nmake -f Makefile.MSVC PREC=DOUBLE

(http://i467.photobucket.com/albums/rr37/fishman0919/VC11.png)

MinGW... ./configure

(http://i467.photobucket.com/albums/rr37/fishman0919/Msys.png)


noticeable difference in size and speed between the two
Title: LAME 3.99 is out
Post by: viktor on 2011-11-04 16:17:50
john, any chance for a 64 bit lamedropxpd build?

I'm looking at it.

thanks, eagerly waiting!
Title: LAME 3.99 is out
Post by: john33 on 2011-11-04 16:56:13
john, any chance for a 64 bit lamedropxpd build?

I'm looking at it.

thanks, eagerly waiting!

Don't hold your breath!!  I can get a clean compile, but it falls over when you drop a file onto it! Still working on it though.
Title: LAME 3.99 is out
Post by: viktor on 2011-11-04 16:57:00
Don't hold your breath!!  I can get a clean compile, but it falls over when you drop a file onto it! Still working on it though.


kk, thanks already!
Title: LAME 3.99 is out
Post by: krafty on 2011-11-05 20:42:36
Still not a word on the lowpass case for -V0  ???
Title: LAME 3.99 is out
Post by: ZinCh on 2011-11-05 21:51:08
LAME 3.99.1 released

lame-3.99.1.tar.gz (http://downloads.sourceforge.net/project/lame/lame/3.99/lame-3.99.1.tar.gz)

Quote
Fixes for several issues with ID3v2 unicode tags, using Big-Endian text encodings. Because of several other software (like Windows Media Player), LAME writes Little-Endian unicode tags only.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-06 11:53:14
Don't hold your breath!!  I can get a clean compile, but it falls over when you drop a file onto it! Still working on it though.


kk, thanks already!

OK, this is not exhaustively tested, but I think it's working - lamedropXPd 64 bits. It will co-exist in the same folder as the standard compile as it's called lamedropXPd.exe.

http://www.rarewares.org/files/mp3/lamedro...1-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.01-3.99.1-64.zip)

Built with 64bit FLAC libs and 64bit oggvorbis libs and will re-encode from both in addition to regular wav encoding.

Please report any problems here, thanks.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-11-06 11:57:08
BTW, 3.99.1 was released.
Title: LAME 3.99 is out
Post by: viktor on 2011-11-06 12:23:49
OK, this is not exhaustively tested, but I think it's working - lamedropXPd 64 bits. It will co-exist in the same folder as the standard compile as it's called lamedropXPd.exe.

http://www.rarewares.org/files/mp3/lamedro....01-3.99-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.01-3.99-64.zip)

Built with 64bit FLAC libs and 64bit oggvorbis libs and will re-encode from both in addition to regular wav encoding.

Please report any problems here, thanks.



many thanks!

btw. John, while you're at it, would you be so kind as to provide us with FLAC x64 ICC builds? i'd love to compare them with my MSVC builds (http://www.hydrogenaudio.org/forums/index.php?showtopic=91668).
Title: LAME 3.99 is out
Post by: john33 on 2011-11-06 14:57:34
BTW, 3.99.1 was released.

Good to know!

Full set of compiles now at Rarewares including the 64 bit LamedropXPd. The 64 bit libsndfile compile now works with FLAC files.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-06 14:58:19
OK, this is not exhaustively tested, but I think it's working - lamedropXPd 64 bits. It will co-exist in the same folder as the standard compile as it's called lamedropXPd.exe.

http://www.rarewares.org/files/mp3/lamedro....01-3.99-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.01-3.99-64.zip)

Built with 64bit FLAC libs and 64bit oggvorbis libs and will re-encode from both in addition to regular wav encoding.

Please report any problems here, thanks.



many thanks!

btw. John, while you're at it, would you be so kind as to provide us with FLAC x64 ICC builds? i'd love to compare them with my MSVC builds (http://www.hydrogenaudio.org/forums/index.php?showtopic=91668).

All in good time - probably!
Title: LAME 3.99 is out
Post by: Broadway on 2011-11-06 18:20:00
OK, this is not exhaustively tested, but I think it's working - lamedropXPd 64 bits. It will co-exist in the same folder as the standard compile as it's called lamedropXPd.exe.

http://www.rarewares.org/files/mp3/lamedro....01-3.99-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.01-3.99-64.zip)

Built with 64bit FLAC libs and 64bit oggvorbis libs and will re-encode from both in addition to regular wav encoding.

Please report any problems here, thanks.


John, 64bit-version of lamedropxpd based on lame 3.99.1 does not create lame tags, 32bit-version does.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-06 18:28:24
OK, this is not exhaustively tested, but I think it's working - lamedropXPd 64 bits. It will co-exist in the same folder as the standard compile as it's called lamedropXPd.exe.

http://www.rarewares.org/files/mp3/lamedro....01-3.99-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.01-3.99-64.zip)

Built with 64bit FLAC libs and 64bit oggvorbis libs and will re-encode from both in addition to regular wav encoding.

Please report any problems here, thanks.


John, 64bit-version of lamedropxpd based on lame 3.99.1 does not create lame tags, 32bit-version does.

Thanks for the  heads-up, I'll look into it.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-06 18:40:53
Having just checked, it appears to fine here. Anyone else have a problem?

Edit: When I say this it is because lametag.exe says so.
Title: LAME 3.99 is out
Post by: robert on 2011-11-06 21:32:48
Hm, yes.

Dumpzusammenfassung
-------------------
Dumpdatei:   WERCE17.tmp.mdmp : C:\Users\robert\AppData\Local\Temp\WERCE17.tmp.mdmp
Letzte Schreibzeit:   06.11.2011 22:24:06
Prozessname:   lamedropXPd.exe : T:\tmp\john\lamedropXPd.exe
Prozessarchitektur:   x64
Ausnahmecode:   0xC0000374
Ausnahmeinformationen:   
Heapinformationen:   Nicht vorhanden

Systeminformationen
-------------------
Betriebssystemversion:   6.1.7601


Edit: sorry, I've used an outdated link. Latest version does work here.
Title: LAME 3.99 is out
Post by: kwanbis on 2011-11-06 21:57:18
Still not a word on the lowpass case for -V0  ???

It seems LAME devs don't know either
Title: LAME 3.99 is out
Post by: C.R.Helmrich on 2011-11-06 23:52:50
Still not a word on the lowpass case for -V0  ???

It seems LAME devs don't know either

At least a partial reply is given in post 228 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79682&view=findpost&p=772529).

Sounds to me like the lowpass might also be dropped for 320 kbps in the near future. Then at least 320 CBR and -V 0 would be in sync again.

Conceptually it makes sense: maximum VBR mode => maximum bandwidth. I'd be considering the same when designing a very high-bitrate VBR mode. But it would be simply "cosmetic" (so that certain people watching spectrum analyzers would stop complaining), since I have yet to encounter someone able to ABX a 20-kHz lowpass on material other than sine-sweeps.

Chris
Title: LAME 3.99 is out
Post by: ShotCaller on 2011-11-07 01:51:00
I'd be considering the same when designing a very high-bitrate VBR mode. But it would be simply "cosmetic" (so that certain people watching spectrum analyzers would stop complaining), since I have yet to encounter someone able to ABX a 20-kHz lowpass on material other than sine-sweeps.

I think you are right that it is only cosmetic... I think LAME is trying to prove it can compete with AAC by including the whole spectrum
Title: LAME 3.99 is out
Post by: Broadway on 2011-11-07 09:22:42
Having just checked, it appears to fine here. Anyone else have a problem?

Edit: When I say this it is because lametag.exe says so.


This is strange, see:

LameTag - Reads the LAME tag from an mp3 file
Copyright © 2005 phwip
Release 0.4.1, compiled 2005-09-09

D:\RadioRecord\KalimbaV2_64.mp3
LAME tag not found.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-07 09:49:15
Are you sure you're using the version downloaded from Rarewares?

I just ran a test using the 64 bit version with this result:
Code: [Select]
Microsoft Windows [Version 6.1.7601]
Copyright © 2009 Microsoft Corporation.  All rights reserved.

C:\Users\John>f:

F:\>cd testdir

F:\testdir>lametag 14.mp3
LameTag - Reads the LAME tag from an mp3 file
Copyright © 2005 phwip
Release 0.4.1, compiled 2005-09-09

F:\testdir\14.mp3
Tag revision:   0
Encoder string: L3.9
Version string: 9r
Quality: 80 (V2 and q0)
Encoding method: vbr new / vbr mtrh
Lowpass: 18,500Hz
RG track peak:   <not stored>
RG track gain:   +0.0dB (determined automatically)
RG album gain:   <not stored>
nspsytune:   yes
nssafejoint: yes
nogap continued: no
nogap continuation: no
ATH type:   5
Bitrate: minimal (-b) bitrate 32
Encoder delay:   576 samples
Padded at end:   1,392 samples
Noise shaping:   1
Stereo mode: joint
Unwise settings: no
Source sample freq: 44.1kHz
MP3Gain change: <none>
Preset: V2: preset standard (fast mode)
Surround info:   none
Music length:   8,166,730 bytes
Music CRC:   050C
Actual Music CRC:  050C
Info tag CRC:   10E8
Actual InfoTag CRC: 10E8
Title: LAME 3.99 is out
Post by: Broadway on 2011-11-07 10:00:32
Are you sure you're using the version downloaded from Rarewares?

Yes I am, downloaded it again this morning from rarewares.
I did some tests this morning and found out that in one (!) case the Lame Tag was written, in all the other cases not.

Also I found out that the 64bit-version shuts down after converting without saving settings to the ini. This does not happen with the 32bit-version.

(I'm on Windows 7 X64 HP German)
Title: LAME 3.99 is out
Post by: john33 on 2011-11-07 10:21:53
OK, I'll do some more research and get back to you.
Title: LAME 3.99 is out
Post by: Broadway on 2011-11-07 10:28:14
OK, I'll do some more research and get back to you.

Thank you.

Just another point: I found out that changes of the settings are not written to the ini.
So it is maybe like this:  lamedropxpd (64) converts the wav to mp3 and shuts down before writing the lame tag and without saving to the ini.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-07 12:57:07
OK, would you be kind enough to try this one:

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.02-3.99.1-64.zip)

Hopefully, an improvement, certainly seems OK here.
Title: LAME 3.99 is out
Post by: Broadway on 2011-11-07 15:19:03
OK, would you be kind enough to try this one:

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.02-3.99.1-64.zip)

Hopefully, an improvement, certainly seems OK here.

I'm sorry, no improvement over here... Program finishes after creating the mp3 without writing the lame tag and saving settings to the ini.

I experimented a bit with running the program as admin... when running as admin it even does not convert....strange...
Title: LAME 3.99 is out
Post by: john33 on 2011-11-07 15:32:08
OK, would you be kind enough to try this one:

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.02-3.99.1-64.zip)

Hopefully, an improvement, certainly seems OK here.

I'm sorry, no improvement over here... Program finishes after creating the mp3 without writing the lame tag and saving settings to the ini.

I experimented a bit with running the program as admin... when running as admin it even does not convert....strange...

Very puzzling; it works flawlessly here. 

System 1: Phenom II X4 840 (@stock), 8GB DDR3, Windows 7 HP 64 bit
System 2: Phenom II X6 1075T (@3.6), 8GB DDR3, Windows 7 Pro 64 bit
System 3: i7 920 D0 (@3.6), 6GB DDR3, Windows 7 Ult 64 bit

Without seeing the problem myself, it's a little difficult to know where to go next. Anyone else seeing this or have any bright ideas?

EDIT: I take that back! I've just double checked on System 3 and the program failed part way through writing the Lame Tag. More work to do, I guess!
Title: LAME 3.99 is out
Post by: Broadway on 2011-11-07 16:03:08
System 3: i7 920 D0 (@3.6), 6GB DDR3, Windows 7 Ult 64 bit

...

EDIT: I take that back! I've just double checked on System 3 and the program failed part way through writing the Lame Tag. More work to do, I guess!

My Win 7 x64 is on a Core I3-System...
Title: LAME 3.99 is out
Post by: john33 on 2011-11-07 16:24:13
System 3: i7 920 D0 (@3.6), 6GB DDR3, Windows 7 Ult 64 bit

...

EDIT: I take that back! I've just double checked on System 3 and the program failed part way through writing the Lame Tag. More work to do, I guess!

My Win 7 x64 is on a Core I3-System...

Can you try downloading from the same link, again, please. There's a new compile there that runs on all systems OK, now.  If it runs OK, I'll tell you what it was!
Title: LAME 3.99 is out
Post by: krafty on 2011-11-07 16:28:46
At least a partial reply is given in post 228 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79682&view=findpost&p=772529).

Sounds to me like the lowpass might also be dropped for 320 kbps in the near future. Then at least 320 CBR and -V 0 would be in sync again.

Conceptually it makes sense: maximum VBR mode => maximum bandwidth. I'd be considering the same when designing a very high-bitrate VBR mode. But it would be simply "cosmetic" (so that certain people watching spectrum analyzers would stop complaining), since I have yet to encounter someone able to ABX a 20-kHz lowpass on material other than sine-sweeps.

Chris



That is what I thought too. Although "tuning" ABR/CBR says very little... I'd like a better confirmation.
But I eventually bump into forums and people are complaining why AAC 256 VBR mode has "full spectrum" while lame has a "cut". This could simmer down.
I myself was bothered by this when I noticed AAC going full spectrum. It's purely psychological.
Title: LAME 3.99 is out
Post by: Broadway on 2011-11-07 16:43:56
System 3: i7 920 D0 (@3.6), 6GB DDR3, Windows 7 Ult 64 bit

...

EDIT: I take that back! I've just double checked on System 3 and the program failed part way through writing the Lame Tag. More work to do, I guess!

My Win 7 x64 is on a Core I3-System...

Can you try downloading from the same link, again, please. There's a new compile there that runs on all systems OK, now.  If it runs OK, I'll tell you what it was!

Sorry, no changes here...
But I'm interested in your approach... maybe it helps locating the problem at my place.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-11-07 17:33:37
Oops... "Unhandled exception at 0x772a40f2 in lamedropXPd.exe: 0xC0000374: A heap has been corrupted."
Title: LAME 3.99 is out
Post by: john33 on 2011-11-07 18:16:43
Hmm, one more time.

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.02-3.99.1-64.zip)

This performs perfectly on my systems, so if there are any problems, I'm kind of lost!

EDIT: OK, forget this for the moment. There clearly is an issue on x64. Iworks on two systems and then fails on the third! Back to the drawing board for the time being!
Title: LAME 3.99 is out
Post by: Wombat on 2011-11-07 21:07:26
I use the lame_enc.dll for a while now and lame 3.98.4 and 3.99 showed "Variable Bit Rate -V X" under file details, 3.99.1 shows the actual bitrate. Is this on purpose?

Edit: wrong quote
Title: LAME 3.99 is out
Post by: john33 on 2011-11-08 10:43:53
Now this version has been tested fairly heavily on all three of my systems and has not failed, so far.

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.02-3.99.1-64.zip)

Some testing and feedback would be appreciated. TIA.
Title: LAME 3.99 is out
Post by: robert on 2011-11-08 11:23:08
So far, no problems on my machine.

Btw., target quality doesn't allow settings in the range ]9,10[ ?
Title: LAME 3.99 is out
Post by: john33 on 2011-11-08 11:34:47
So far, no problems on my machine.

Btw., target quality doesn't allow settings in the range ]9,10[ ?

Thanks for the testing, and I'll look into that.
Title: LAME 3.99 is out
Post by: viktor on 2011-11-08 11:43:19
Now this version has been tested fairly heavily on all three of my systems and has not failed, so far.

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.02-3.99.1-64.zip)

Some testing and feedback would be appreciated. TIA.


thanks!

speed comparison:
- x86: 245s
- x64: 179s

very nice improvement. but i have a few questions:

- why have such an odd default -V value (8.31) in lamedropxpd?
- why a different filename? i guess it's just an oversight
- why do the resulting mp3 files differ between 32 and 64 bit compiles? both lame and lamedropxpd, but at least the files are identical on the same architecture from the 2.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-08 12:38:21
Now this version has been tested fairly heavily on all three of my systems and has not failed, so far.

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.02-3.99.1-64.zip)

Some testing and feedback would be appreciated. TIA.


thanks!

speed comparison:
- x86: 245s
- x64: 179s

very nice improvement. but i have a few questions:

- why have such an odd default -V value (8.31) in lamedropxpd?
- why a different filename? i guess it's just an oversight
- why do the resulting mp3 files differ between 32 and 64 bit compiles? both lame and lamedropxpd, but at least the files are identical on the same architecture from the 2.

Thanks for the feedback.

1. I've changed the default now and thanks for telling me. That's a throwback to an older version and should have been changed a while ago!
2. I wanted to keep the name different so I could run them using the same .ini file. I'll probably change the .exe to have a '64' suffix when I'm reasonably sure it's OK to release.
3. The 32 bit compiles use 'nasm' assembler routines for cpu feature optimisations, the 64 bit compiles use the Intel intrinsics. The differences in the maths routines = differences in output. However, as had been said many times, although different compilers used result in differing outputs, no one has yet been able to abx any difference. So, just accept the difference and don't worry about.
Title: LAME 3.99 is out
Post by: viktor on 2011-11-08 12:43:46
Thanks for the feedback.

1. I've changed the default now and thanks for telling me. That's a throwback to an older version and should have been changed a while ago!
2. I wanted to keep the name different so I could run them using the same .ini file. I'll probably change the .exe to have a '64' suffix when I'm reasonably sure it's OK to release.
3. The 32 bit compiles use 'nasm' assembler routines for cpu feature optimisations, the 64 bit compiles use the Intel intrinsics. The differences in the maths routines = differences in output. However, as had been said many times, although different compilers used result in differing outputs, no one has yet been able to abx any difference. So, just accept the difference and don't worry about.


thanks for the clarification! as of point 2, it would be really helpful to change the program's title as well. i'm asking coz ATM it's really hard to distinguish the 2 when they run, there's no indication neither in the task bar nor anywhere else in the program (main window, encoding options, about screen, anything). lamedropXPd and lamedropXPd-64 (or sg like that) would be fine for me (both title and executable name).
Title: LAME 3.99 is out
Post by: john33 on 2011-11-08 14:54:56
So far, no problems on my machine.

Btw., target quality doesn't allow settings in the range ]9,10[ ?

Revised version which includes the extended VRB Quality range is here for testing, if those who are interested would be so kind.

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.02-3.99.1-64.zip)

On the 'About' page, I have added a note next to the compile date to indicate whether it is a 32 bit, or 64 bit compile.
Title: LAME 3.99 is out
Post by: Broadway on 2011-11-08 17:52:18
Revised version which includes the extended VRB Quality range is here for testing, if those who are interested would be so kind.

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.02-3.99.1-64.zip)

On the 'About' page, I have added a note next to the compile date to indicate whether it is a 32 bit, or 64 bit compile.


Runnig fine now - even on my system ;-)
No problems so far!

Thank you!
Title: LAME 3.99 is out
Post by: john33 on 2011-11-08 17:56:33
Revised version which includes the extended VRB Quality range is here for testing, if those who are interested would be so kind.

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip (http://www.rarewares.org/files/mp3/lamedropXPd3.02-3.99.1-64.zip)

On the 'About' page, I have added a note next to the compile date to indicate whether it is a 32 bit, or 64 bit compile.


Runnig fine now - even on my system ;-)
No problems so far!

Thank you!

Ah! Now that is good news. Let's hope it stays that way. If all is well over the next 24 hours, I'll put this and the new 32 bit compile up on Rarewares.

Thanks to all for your help.
Title: LAME 3.99 is out
Post by: Broadway on 2011-11-09 15:29:02
...
Let's hope it stays that way. If all is well over the next 24 hours, I'll put this and the new 32 bit compile up on Rarewares.
...

I tested several files abr, cbr and vbr...still working fine!
Title: LAME 3.99 is out
Post by: Anakunda on 2011-11-09 15:36:35
Hello I still think there's some tagging bug in L3.99.1.
Especially it concerns writting encoder metadata to Lame header.
Convert anything with Lame 3.99.1 and look to metadata by MediaInfo or another metadata viewer.
Seems to me the encoder field is kinda corrupted. I get various results for the latest Lame build from Rarewarez.
On my test encode I got this:

Writing library        : LAME3.99.1ŞŞŞŞŞŞŞŞŞŞ

This looks like the encoder doesnot zero terminate the encoder field properly, or even this value is written corrupted.
On another attempt the created mp3 even has no Lame version reported by MediaInfo.

In foobar I always get this value:

Tool : L3.99r

which is kinda nonstandard too. Please fix it.

(http://img543.imageshack.us/img543/8796/l3991.png)
Title: LAME 3.99 is out
Post by: lock67ca on 2011-11-09 15:52:19
With the latest build, the encoder setting in iTunes is listed as Unknown. Encspot has enccoder as Gogo(after 3.0). MediaInfo has 3.99.1 and Mr Questionman is 3.99, which I assume is normal. foobar is 3.99r, which is also correct.

Using the 32 bit version.
Title: LAME 3.99 is out
Post by: Anakunda on 2011-11-09 15:57:42
For me the string is as shown on the image above. Encoded with Lame 3.99.1 64bit from foobar. Using MediaInfo 0.7.50.
The nonsense characters behind the version string infer that there's something wrong with tagging in this version (or with MediaInfo?).
If I peek in metadata of random MP3 encoded by older version of Lame the version string looks correct (no trailing garbage chars).

Encoded raw WAV file from commandline. Now the version string reported by MediaInfo is

Writing library : LAMEŞŞqŞ“‘§dFĄĽ;óŇ

The WAV and resulting MP3 uploaded here:
Code: [Select]
http://www.mediafire.com/?ynz19sryizkrby9


Can anybody confirm the same problem?

// Yet another edit

This problem deals with 64 bit LAME backend from Rarewarez.
Tried to encode with 32bit CLI and the resulting MP3 version tag looks nice.
Please for recompile with fixed tagging.
Title: LAME 3.99 is out
Post by: Wombat on 2011-11-09 16:21:24
I reported the encoder settings value shown wrong in Post #319 already http://www.hydrogenaudio.org/forums/index....st&p=774849 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79682&view=findpost&p=774849)
The version string Windows 7 internal file details report is "3.99."

Title: LAME 3.99 is out
Post by: john33 on 2011-11-09 16:36:04
This post is basically directed at Robert, but anyone else is welcome to join in.

Relating to the comments about speeds of different compiles, I've been playing around with different options. I've come up with three compiles of the basic lame.exe which I've tested on my System 1 (the Phenom II x4 840) and System 3 (the i7 920). So the first one is firmly in the AMD camp and the second in the Intel camp.

The three compiles are:

lame-1, the standard nasm enabled 32 bit Intel compile (icc_patch run before testing on both systems);
lame-2, a 32 bit compile, without nasm support, but with the preprocessor directives HAVE_XMMINTRIN_H and MIN_ARCH_SSE specified (icc_patch run before testing on both systems); and
lame-64, the standard 64 bit compile.

On System 1:
lame-1 - 31.569x
lame-2 - 34.306x
lame-64 - 40.514x

On System 3:
lame-1 - 44.251x
lame-2 - 51.293x
lame-64 - 57.766x

So, the basic question would have to be, is it time to retire the nasm code from all builds? Is it reasonable to assume that MIN_ARCH_SSE compiles will run on all systems that the nasm builds run on? My feeling is yes to both questions, but I would welcome other input and opinions.
Title: LAME 3.99 is out
Post by: robert on 2011-11-09 16:51:41
The NASM compiles still run on older chips like AthlonXP or older Pentiums, the SSE compiles likely not. For 64-bit compiles, the NASM one is not needed anymore.

re media info: the lame info tag has a 9 bytes field for "Encoder short version string".
For versions with patch level > 0 we write: L<Major Version>.<Minor Version>[a,b or r]<Patch level>
else: LAME<Major Version>.<Minor Version>[a,b,r or blank]
In all cases, this string gets truncated after 9 bytes.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-11-09 16:56:40
john33, please compile NASM version with SSE enabled and fast FP (/arch:SSE /fp:fast). I suspect that it will be faster than now.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-09 17:19:53
john33, please compile NASM version with SSE enabled and fast FP (/arch:SSE /fp:fast). I suspect that it will be faster than now.

Exactly the same on both systems. /fp:fast was already set. In fact, the second compile without nasm support and with the preprocessor directives removed is still marginally faster on both systems!
Title: LAME 3.99 is out
Post by: nao on 2011-11-09 17:57:40
My test (@Sandy Bridge, gcc 4.2.1):

Code: [Select]
NASM build
fp math TAKEHIRO_IEEE754_HACK speed
_______ _____________________ _____
x87     yes                   59.7x
x87     no                    58.5x
SSE     yes                   62.1x
SSE     no                    67.7x

MIN_ARCH_SSE build
fp math TAKEHIRO_IEEE754_HACK speed
_______ _____________________ _____
SSE     yes                   55.1x
SSE     no                    56.3x

Here, NASM + SSE fp math + no TAKEHIRO_IEEE754_HACK build is the fastest. This is expected result because the nasm code is faster than the SSE intrinsics code used by MIN_ARCH_SSE definition. Maybe Intel Compiler does auto-vectorization pretty well.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-09 18:11:21
Interesting, thanks.
Title: LAME 3.99 is out
Post by: Anakunda on 2011-11-10 18:00:40
Hello,
I've tried out new(todays) compiles of lame and the 64 bit version bug with not writing the encoder settings + corrupted version string is still here.
Are the developers not reading bugs reported in this thread? Please fix it.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-10 18:22:52
Hello,
I've tried out new(todays) compiles of lame and the 64 bit version bug with not writing the encoder settings + corrupted version string is still here.
Are the developers not reading bugs reported in this thread? Please fix it.
While I am not a lame-dev, I'm not sure I understand your problem. The following is from today's lame bundles, 32 bit and 64 bit:
Code: [Select]
Microsoft Windows [Version 6.1.7601]
Copyright © 2009 Microsoft Corporation.  All rights reserved.

C:\Users\John>f:

F:\>cd testdir

F:\testdir>lame -V 2 14.wav 14.mp3
LAME 3.99.1 64bits (http://lame.sf.net)
CPU features: SSE (ASM used), SSE2 (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 14.wav to 14.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 14177/14177 (100%)|    0:09/    0:09|    0:09/    0:09|  39.989x|    0:00
 32 [    1] *
 40 [    0]
 48 [    0]
 56 [    0]
 64 [    5] %
 80 [  867] %%%%%%%%%%%%*
 96 [ 1930] %%%%%%%%%%%%%%%%%%%%%%%%%%%*
112 [  110] %%
128 [  268] %***
160 [ 3274] %%%%%%%%%%%%%%%%%%%***************************
192 [ 4781] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
224 [ 1110] %%%%%%%%%%%*****
256 [ 1158] %%%%%%%%%%%******
320 [  673] %%%%%%****
-------------------------------------------------------------------------------
  kbps        LR    MS  %    long switch short %
  176.6      63.4  36.6        85.4  7.9  6.7
Writing LAME Tag...done
ReplayGain: 0.0dB

F:\testdir>lametag 14.mp3
LameTag - Reads the LAME tag from an mp3 file
Copyright © 2005 phwip
Release 0.4.1, compiled 2005-09-09

F:\testdir\14.mp3
Tag revision:      0
Encoder string:    L3.9
Version string:    9r
Quality:            80 (V2 and q0)
Encoding method:    vbr new / vbr mtrh
Lowpass:            18,500Hz
RG track peak:      <not stored>
RG track gain:      +0.0dB (determined automatically)
RG album gain:      <not stored>
nspsytune:          yes
nssafejoint:        yes
nogap continued:    no
nogap continuation: no
ATH type:          5
Bitrate:            minimal (-b) bitrate 32
Encoder delay:      576 samples
Padded at end:      1,392 samples
Noise shaping:      1
Stereo mode:        joint
Unwise settings:    no
Source sample freq: 44.1kHz
MP3Gain change:    <none>
Preset:            V2: preset standard (fast mode)
Surround info:      none
Music length:      8,166,730 bytes
Music CRC:          050C
Actual Music CRC:  050C
Info tag CRC:      10E8
Actual InfoTag CRC: 10E8


F:\testdir>lame -V 2 14.wav 14.mp3
LAME 3.99.1 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 14.wav to 14.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 14177/14177 (100%)|    0:11/    0:11|    0:11/    0:11|  32.794x|    0:00
 32 [    1] *
 40 [    0]
 48 [    0]
 56 [    0]
 64 [    2] %
 80 [  335] %%%%%
 96 [ 2322] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*
112 [  249] %%%%
128 [  246] %***
160 [ 3240] %%%%%%%%%%%%%%%%%%****************************
192 [ 4798] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
224 [ 1147] %%%%%%%%%%%******
256 [ 1157] %%%%%%%%%%*******
320 [  680] %%%%%%%***
-------------------------------------------------------------------------------
  kbps        LR    MS  %    long switch short %
  177.7      63.4  36.6        85.4  7.9  6.7
Writing LAME Tag...done
ReplayGain: 0.0dB

F:\testdir>lametag 14.mp3
LameTag - Reads the LAME tag from an mp3 file
Copyright © 2005 phwip
Release 0.4.1, compiled 2005-09-09

F:\testdir\14.mp3
Tag revision:      0
Encoder string:    L3.9
Version string:    9r
Quality:            80 (V2 and q0)
Encoding method:    vbr new / vbr mtrh
Lowpass:            18,500Hz
RG track peak:      <not stored>
RG track gain:      +0.0dB (determined automatically)
RG album gain:      <not stored>
nspsytune:          yes
nssafejoint:        yes
nogap continued:    no
nogap continuation: no
ATH type:          5
Bitrate:            minimal (-b) bitrate 32
Encoder delay:      576 samples
Padded at end:      1,392 samples
Noise shaping:      1
Stereo mode:        joint
Unwise settings:    no
Source sample freq: 44.1kHz
MP3Gain change:    <none>
Preset:            V2: preset standard (fast mode)
Surround info:      none
Music length:      8,217,925 bytes
Music CRC:          0887
Actual Music CRC:  0887
Info tag CRC:      65E6
Actual InfoTag CRC: 65E6


F:\testdir>
The lame tag is essentially the same for both.
Title: LAME 3.99 is out
Post by: JoeSyr on 2011-11-10 18:28:31
Newbie question: what exactly do the libsndfile compiles offer that the others don't? I ask because I'd been using the normal compiles from rarewares to do FLAC->MP3 conversion in foobar2000 for a while, so seeing "This version of the libsndfile-1.dll provides FLAC and ogg vorbis (.ogg) input support." is confusing.

Is there any reason to not use the libsndfile version? And is it a feature of foobar that FLAC input is supported without it?
Title: LAME 3.99 is out
Post by: john33 on 2011-11-10 18:37:44
Newbie question: what exactly do the libsndfile compiles offer that the others don't? I ask because I'd been using the normal compiles from rarewares to do FLAC->MP3 conversion in foobar2000 for a while, so seeing "This version of the libsndfile-1.dll provides FLAC and ogg vorbis (.ogg) input support." is confusing.

Is there any reason to not use the libsndfile version? And is it a feature of foobar that FLAC input is supported without it?

If you are doing the conversion via foobar2000, then there is no reason to change. foobar is taking care of the FLAC decoding for you. However, if you were attempting the conversion from the command line, then the standard compile would not work as it does not have the ability to accept FLAC input whereas the libsndfile version uses that library to perform the FLAC decoding, passing the decoded data to the lame encoder internally. I hope that's clear!
Title: LAME 3.99 is out
Post by: Anakunda on 2011-11-10 18:38:18
Hello,
I've tried out new(todays) compiles of lame and the 64 bit version bug with not writing the encoder settings + corrupted version string is still here.
Are the developers not reading bugs reported in this thread? Please fix it.
While I am not a lame-dev, I'm not sure I understand your problem. The following is from today's lame bundles, 32 bit and 64 bit:
Code: [Select]
Microsoft Windows [Version 6.1.7601]
Copyright © 2009 Microsoft Corporation.  All rights reserved.

C:\Users\John>f:

F:\>cd testdir

F:\testdir>lame -V 2 14.wav 14.mp3
LAME 3.99.1 64bits (http://lame.sf.net)
CPU features: SSE (ASM used), SSE2 (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 14.wav to 14.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 14177/14177 (100%)|    0:09/    0:09|    0:09/    0:09|  39.989x|    0:00
 32 [    1] *
 40 [    0]
 48 [    0]
 56 [    0]
 64 [    5] %
 80 [  867] %%%%%%%%%%%%*
 96 [ 1930] %%%%%%%%%%%%%%%%%%%%%%%%%%%*
112 [  110] %%
128 [  268] %***
160 [ 3274] %%%%%%%%%%%%%%%%%%%***************************
192 [ 4781] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
224 [ 1110] %%%%%%%%%%%*****
256 [ 1158] %%%%%%%%%%%******
320 [  673] %%%%%%****
-------------------------------------------------------------------------------
  kbps        LR    MS  %    long switch short %
  176.6      63.4  36.6        85.4  7.9  6.7
Writing LAME Tag...done
ReplayGain: 0.0dB

F:\testdir>lametag 14.mp3
LameTag - Reads the LAME tag from an mp3 file
Copyright © 2005 phwip
Release 0.4.1, compiled 2005-09-09

F:\testdir\14.mp3
Tag revision:      0
Encoder string:    L3.9
Version string:    9r
Quality:            80 (V2 and q0)
Encoding method:    vbr new / vbr mtrh
Lowpass:            18,500Hz
RG track peak:      <not stored>
RG track gain:      +0.0dB (determined automatically)
RG album gain:      <not stored>
nspsytune:          yes
nssafejoint:        yes
nogap continued:    no
nogap continuation: no
ATH type:          5
Bitrate:            minimal (-b) bitrate 32
Encoder delay:      576 samples
Padded at end:      1,392 samples
Noise shaping:      1
Stereo mode:        joint
Unwise settings:    no
Source sample freq: 44.1kHz
MP3Gain change:    <none>
Preset:            V2: preset standard (fast mode)
Surround info:      none
Music length:      8,166,730 bytes
Music CRC:          050C
Actual Music CRC:  050C
Info tag CRC:      10E8
Actual InfoTag CRC: 10E8


F:\testdir>lame -V 2 14.wav 14.mp3
LAME 3.99.1 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 14.wav to 14.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 14177/14177 (100%)|    0:11/    0:11|    0:11/    0:11|  32.794x|    0:00
 32 [    1] *
 40 [    0]
 48 [    0]
 56 [    0]
 64 [    2] %
 80 [  335] %%%%%
 96 [ 2322] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*
112 [  249] %%%%
128 [  246] %***
160 [ 3240] %%%%%%%%%%%%%%%%%%****************************
192 [ 4798] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
224 [ 1147] %%%%%%%%%%%******
256 [ 1157] %%%%%%%%%%*******
320 [  680] %%%%%%%***
-------------------------------------------------------------------------------
  kbps        LR    MS  %    long switch short %
  177.7      63.4  36.6        85.4  7.9  6.7
Writing LAME Tag...done
ReplayGain: 0.0dB

F:\testdir>lametag 14.mp3
LameTag - Reads the LAME tag from an mp3 file
Copyright © 2005 phwip
Release 0.4.1, compiled 2005-09-09

F:\testdir\14.mp3
Tag revision:      0
Encoder string:    L3.9
Version string:    9r
Quality:            80 (V2 and q0)
Encoding method:    vbr new / vbr mtrh
Lowpass:            18,500Hz
RG track peak:      <not stored>
RG track gain:      +0.0dB (determined automatically)
RG album gain:      <not stored>
nspsytune:          yes
nssafejoint:        yes
nogap continued:    no
nogap continuation: no
ATH type:          5
Bitrate:            minimal (-b) bitrate 32
Encoder delay:      576 samples
Padded at end:      1,392 samples
Noise shaping:      1
Stereo mode:        joint
Unwise settings:    no
Source sample freq: 44.1kHz
MP3Gain change:    <none>
Preset:            V2: preset standard (fast mode)
Surround info:      none
Music length:      8,217,925 bytes
Music CRC:          0887
Actual Music CRC:  0887
Info tag CRC:      65E6
Actual InfoTag CRC: 65E6


F:\testdir>
The lame tag is essentially the same for both.


It's the metadata problem I reported yesterday. Look at the screenshot in Post #129 (http://www.hydrogenaudio.org/forums/index.php?showtopic=91372&view=findpost&p=775060).

Console dump with the corrupted metadata shown by MediaInfo here:

Code: [Select]
E:\xfer\download\music>lame --version
LAME 64bits version 3.99.1 (http://lame.sf.net)

Copyright (c) 1999-2011 by The LAME Project
Copyright (c) 1999,2000,2001 by Mark Taylor
Copyright (c) 1998 by Michael Cheng
Copyright (c) 1995,1996,1997 by Michael Hipp: mpglib

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with this program. If not, see
<http://www.gnu.org/licenses/>.

E:\xfer\download\music>lame -V 2 Show_Me_Your_Spine__Sample_.wav
LAME 3.99.1 64bits (http://lame.sf.net)
CPU features: SSE (ASM used), SSE2 (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Show_Me_Your_Spine__Sample_.wav to Show_Me_Your_Spine__Sample_.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  1142/1142  (100%)|    0:02/    0:02|    0:02/    0:02|   13.824x|    0:00
 32 [   0]
 40 [   0]
 48 [   0]
 56 [   0]
 64 [   0]
 80 [   1] %
 96 [   4] %
112 [   3] %
128 [   6] *
160 [ 451] %%%%%%**************************************************************
192 [ 344] %%%%%%**********************************************
224 [  79] %%%*********
256 [ 165] %%%%%%%******************
320 [  89] %%%%%*********
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  199.8       14.8  85.2        68.1  17.4  14.4
Writing LAME Tag...done
ReplayGain: -4.3dB

E:\xfer\download\music>mediainfo Show_Me_Your_Spine__Sample_.mp3
General
Complete name                            : Show_Me_Your_Spine__Sample_.mp3
Format                                   : MPEG Audio
File size                                : 727 KiB
Duration                                 : 29s 831ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 200 Kbps
Writing library                          : LAME3.99.1ŞŞŞŞŞŞŞŞŞŞ

Audio
Format                                   : MPEG Audio
Format version                           : Version 1
Format profile                           : Layer 3
Mode                                     : Joint stereo
Mode extension                           : MS Stereo
Duration                                 : 29s 831ms
Bit rate mode                            : Variable
Bit rate                                 : 200 Kbps
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 KHz
Compression mode                         : Lossy
Stream size                              : 727 KiB (100%)
Writing library                          : LAME3.99.1ŞŞŞŞŞŞŞŞŞŞ


E:\xfer\download\music>
Title: LAME 3.99 is out
Post by: robert on 2011-11-10 18:38:18
Ok, I guess my other reply didn't make it clear.

Hello I still think there's some tagging bug in L3.99.1.
Especially it concerns writting encoder metadata to Lame header.
Convert anything with Lame 3.99.1 and look to metadata by MediaInfo or another metadata viewer.
Seems to me the encoder field is kinda corrupted. I get various results for the latest Lame build from Rarewarez.
On my test encode I got this:

Writing library        : LAME3.99.1??????????

This looks like the encoder doesnot zero terminate the encoder field properly, or even this value is written corrupted.
On another attempt the created mp3 even has no Lame version reported by MediaInfo.

This looks like a problem within MediaInfo. The field consists of 9 characters, no Zero termination required.

Quote
In foobar I always get this value:

Tool : L3.99r

which is kinda nonstandard too. Please fix it.

This is a correct value of the "encoder short version" field, but it should be ending with a patch level number after the "r".
Title: LAME 3.99 is out
Post by: Anakunda on 2011-11-10 18:41:29
This looks like a problem within MediaInfo. The field consists of 9 characters, no Zero termination required.


I'm using MediaInfo 0.7.50 official build. I wonder if that's MediaInfo problem as it shows version and encoder settings for all mp3s encoded with Lame 3.98.4 or older correctly.
Title: LAME 3.99 is out
Post by: nao on 2011-11-10 18:45:01
This is a correct value of the "encoder short version" field, but it should be ending with a patch level number after the "r".

Due to a small error in version.c, the patch level number is truncated in the release versions.
Code: [Select]
#define P "r";
should be
Code: [Select]
#define P "r"
to fix the issue.
Title: LAME 3.99 is out
Post by: robert on 2011-11-10 18:48:36
Thanks, nao. Fix committed to CVS main branch.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-10 19:07:44
Ho hum!!

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.

Always best to have things right, of course.
Title: LAME 3.99 is out
Post by: JoeSyr on 2011-11-10 20:12:28
Newbie question: what exactly do the libsndfile compiles offer that the others don't? I ask because I'd been using the normal compiles from rarewares to do FLAC->MP3 conversion in foobar2000 for a while, so seeing "This version of the libsndfile-1.dll provides FLAC and ogg vorbis (.ogg) input support." is confusing.

Is there any reason to not use the libsndfile version? And is it a feature of foobar that FLAC input is supported without it?

If you are doing the conversion via foobar2000, then there is no reason to change. foobar is taking care of the FLAC decoding for you. However, if you were attempting the conversion from the command line, then the standard compile would not work as it does not have the ability to accept FLAC input whereas the libsndfile version uses that library to perform the FLAC decoding, passing the decoded data to the lame encoder internally. I hope that's clear!


Crystal, thanks for clearing that up.
Title: LAME 3.99 is out
Post by: DARcode on 2011-11-11 09:34:12
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?
Title: LAME 3.99 is out
Post by: john33 on 2011-11-11 09:43:07
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.
Title: LAME 3.99 is out
Post by: nao on 2011-11-11 09:50:04
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: [Select]
            if (Lame || Lib==_T("LAME") || Lib==_T("GOGO"))
                Header_Encoders_Lame();
Title: LAME 3.99 is out
Post by: john33 on 2011-11-11 11:27:29
New compiles now available.
Title: LAME 3.99 is out
Post by: DARcode on 2011-11-11 12:20:53
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.
Title: LAME 3.99 is out
Post by: Anakunda on 2011-11-11 14:27:57
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.
Title: LAME 3.99 is out
Post by: DARcode on 2011-11-11 14:30:42
[...]Mediainfo only accepts version strings beginning with "LAME" or "GOGO".
Quote from mediainfo's File_Mpega.cpp, line 1204
Code: [Select]
            if (Lame || Lib==_T("LAME") || Lib==_T("GOGO"))
                Header_Encoders_Lame();

Title: LAME 3.99 is out
Post by: john33 on 2011-11-11 14:37:35
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.
Title: LAME 3.99 is out
Post by: Anakunda on 2011-11-11 14:38:32
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?
Title: LAME 3.99 is out
Post by: DARcode on 2011-11-11 14:52:12
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.
Title: LAME 3.99 is out
Post by: GeSomeone on 2011-11-11 15:19:58
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.
Title: LAME 3.99 is out
Post by: nao on 2011-11-11 15:21:53
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".
Title: LAME 3.99 is out
Post by: Anakunda on 2011-11-11 15:56:37
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.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-11 16:49:15
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.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-11-11 17:22:51
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 (http://www.multiupload.com/ROM5UG0RW5)
Title: LAME 3.99 is out
Post by: psycho on 2011-11-11 19:07:43
I have made my compile available for anyone interrested to test it:

LAME - psycho build (http://www.4shared.com/file/r47b3jbq/lame.html)

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.
Title: LAME 3.99 is out
Post by: psycho on 2011-11-11 20:26:30
My previous build is 3.99, so here's the new one:

LAME 3.99.1 - psycho build (http://www.4shared.com/file/ghxh-xYX/lame-3991.html)
Title: LAME 3.99 is out
Post by: robert on 2011-11-11 21:31:31
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 (http://www.4shared.com/file/ghxh-xYX/lame-3991.html)

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)
Title: LAME 3.99 is out
Post by: hidn on 2011-11-12 09:40:44
it is possible to see how used cpu extensions
http://www.cpuid.com/softwares/perfmonitor.html (http://www.cpuid.com/softwares/perfmonitor.html)

(http://dl.dropbox.com/u/17244829/temp/shot-20111112T133700.png)
(on ss working gogo 3.13)
Title: LAME 3.99 is out
Post by: robert on 2011-11-12 11:08:36
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 [attachment=6751:psycho.png] B [attachment=6749:john.32_bit.png] C [attachment=6750:john.64_bit.png] D [attachment=6752:robert.v...m_32_bit.png] E [attachment=6753:robert.v...2_32_bit.png] F [attachment=6754:robert.vc11_64_bit.png]
Title: LAME 3.99 is out
Post by: ijskonijn on 2011-11-12 15:44:51
Is it correct that in the latest build of Lame from 2011-11-11 ( http://www.rarewares.org/mp3-lame-bundle.php (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 (http://forum.dbpoweramp.com/showthread.php?24741-Lame-3.99-release-today-10-16-2011&p=116335&viewfull=1#post116335) )?

Because i saw an error in dBpoweramp ( http://forum.dbpoweramp.com/showthread.php...ll=1#post116339 (http://forum.dbpoweramp.com/showthread.php?24741-Lame-3.99-release-today-10-16-2011&p=116339&viewfull=1#post116339) ) and they say that this was the problem?
Title: LAME 3.99 is out
Post by: lock67ca on 2011-11-12 16:38:18
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???
Title: LAME 3.99 is out
Post by: robert on 2011-11-12 17:04:41
@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.
Title: LAME 3.99 is out
Post by: Zenitram on 2011-11-15 21:16:55
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 (http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.51%2B/MediaInfo_GUI_20111115_Windows_i386_WithoutInstaller.7z/download) (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 (http://gabriel.mp3-tech.org/mp3infotag.html) (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.
Title: LAME 3.99 is out
Post by: viktor on 2011-11-15 22:09:29
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"
Title: LAME 3.99 is out
Post by: apodtele on 2011-11-16 03:38:40
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.
Title: LAME 3.99 is out
Post by: kwanbis on 2011-11-16 06:24:31
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.

Agree 100%.
Title: LAME 3.99 is out
Post by: spoon on 2011-11-16 09:39:58
Just testing the latest 3.99.1 from Rarewares, there seems to be changes to the Lame header written, previously it was written LAME3.98  now (very quick glance) it seems to be 'L3.99r1' that is why no programs are picking up the lame header now.

Old Lame (after an info chunk):

(http://www.dbpoweramp.com/misc/lameold.png)

New Lame

(http://www.dbpoweramp.com/misc/lamenew.png)
Title: LAME 3.99 is out
Post by: john33 on 2011-11-16 10:17:18
Just by way of explanation, the problem relates to the desire to indicate that the release version is 3.99.1 as opposed to 3.99.

Under the old scheme it was not possible to indicate in the tag that it was 3.99 release, patch version 1, it was simply 'LAME3.99r', where 'r' indicated that it is a release version at a patch verion above '0', but the patch version number is not shown. If the release version was never at a patch version greater than '0', this was not an issue and the tag would read 'LAME3.99 ', but the change was to allow for the specification of what the patch version was above '0'.

Code: [Select]
const char *
get_lame_very_short_version(void)
{
    /* adding date and time to version string makes it harder for output
       validation */
#if   LAME_ALPHA_VERSION
#define P "a"
#elif LAME_BETA_VERSION
#define P "b"
#elif LAME_RELEASE_VERSION && (LAME_PATCH_VERSION > 0)
#define P "r"
#else
#define P " "
#endif
    static /*@observer@ */ const char *const str =
#if (LAME_PATCH_VERSION > 0)
      "L" STR(LAME_MAJOR_VERSION) "." STR(LAME_MINOR_VERSION) P STR(LAME_PATCH_VERSION)
#else
      "LAME" STR(LAME_MAJOR_VERSION) "." STR(LAME_MINOR_VERSION) P
#endif
     ;
    return str;
}

Above is the code that does the work.

So, as you can see, if the patch version is at '0', then the tag will read 'LAME3.99 ', as before, but if it is greater than '0' then it will read 'L3.99rn', where 'r' indicates that it is indeed a release version and 'n' = the patch version number.

Whether there may be a better way to do this is not for me to say, but knowing the patch version and, therefore, knowing if you are using the latest version must be of benefit.
Title: LAME 3.99 is out
Post by: spoon on 2011-11-16 10:25:14
Programs can update to this new standard, but who knows any program which reads a lame header (even iTunes?) might be broken, and updates might not be forthcoming for all programs.
Title: LAME 3.99 is out
Post by: DARcode on 2011-11-16 10:36:13
I second spoon's concerns, improved standards should always be introduced with some measure of backward compatibility at least for a transition phase.
Title: LAME 3.99 is out
Post by: spoon on 2011-11-16 10:40:27
Simple fix why not write:

LAME3.991

instead of L3.99r1

Keep to the LAME3.99a for point releases

Also I echo the concern about dropping the LAME branding, having encoded by: L3.99r1  is confusing.
Title: LAME 3.99 is out
Post by: Zenitram on 2011-11-16 10:42:25
but knowing the patch version and, therefore, knowing if you are using the latest version must be of benefit.

Is this rule be "forever"? Is it good to remove "LAME" brand from the the "vendor" tag? Sorting is fun too (3.99r1, then 3.99a2, than 3.99b2, then 3.99r2, then 3.99a3... This is not trivial to sort, compared to L3.99.1r, L3.99.2a...). How someone who has never seen a LAME tag (this can happen!) can find that "L" or "L3.99" is the hint for "Lame" encoder? "Lame encoder" on Google redirects to http://lame.sourceforge.net (http://lame.sourceforge.net), "L encoder" will never do it. I would have imagined something like "LAME3.99s" or "LAME4.00r"... (Why using .99 if you don't plan to rename it to .00 at some point? After 3.99.9, will the next one be 3.99.9.1?)
Title: LAME 3.99 is out
Post by: john33 on 2011-11-16 11:16:57
The problem is that the LAME tag currently allows 9 bytes for the Version info. Without changing the size of this and causing more external software issues, no doubt, there has to be a compromise if the Patch Version Number is to be written. Previously, it wasn't written, so it wasn't an issue.

So, it really depends on whether people want the patch version number written into the LAME tag, or not.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-16 11:18:03
but knowing the patch version and, therefore, knowing if you are using the latest version must be of benefit.

Is this rule be "forever"? Is it good to remove "LAME" brand from the the "vendor" tag? Sorting is fun too (3.99r1, then 3.99a2, than 3.99b2, then 3.99r2, then 3.99a3... This is not trivial to sort, compared to L3.99.1r, L3.99.2a...). How someone who has never seen a LAME tag (this can happen!) can find that "L" or "L3.99" is the hint for "Lame" encoder? "Lame encoder" on Google redirects to http://lame.sourceforge.net (http://lame.sourceforge.net), "L encoder" will never do it. I would have imagined something like "LAME3.99s" or "LAME4.00r"... (Why using .99 if you don't plan to rename it to .00 at some point? After 3.99.9, will the next one be 3.99.9.1?)

The next version is already designated as '3.100' which will cause a further problem!!
Title: LAME 3.99 is out
Post by: RobertoDomenico on 2011-11-16 12:32:04
Don't know if this is any help. When converting some FLAC to MP3 Lame 3.99.1 with XLD on OS X Lion and then playing them back with iTunes  under get info iTunes reports  "Encoded with LAME 32bits version 3.99.1 (http://lame.sf.net)"

The files play back gapless perfectly.
Title: LAME 3.99 is out
Post by: lameboy on 2011-11-16 14:35:03
The next version is already designated as '3.100' which will cause a further problem!!


Indeed. Since the maximum number of characters is 9 (9 bytes), for the next major version with a patch (LAME 3.100.1) one has the following options:

LAME31001
or
L3.100r1

Or something else in 9 characters.



Title: LAME 3.99 is out
Post by: apodtele on 2011-11-16 15:33:28
Indeed. Since the maximum number of characters is 9 (9 bytes), for the next major version with a patch (LAME 3.100.1) one has the following options:

LAME31001
or
L3.100r1

Or something else in 9 characters.


Obviously, this is about priorities. Many people here including myself think that 'LAME' brand is way way way more important than squeezing in '.1'.

In addition there won't be 3.100 until it is released. It is not late to stop this silliness and reset the counter. Why not 4.0 already? Why not 5.0 if 4.0
is taken? Indeed dropping periods is much more harmless

LAME5000
LAME5001
LAME5101

Title: LAME 3.99 is out
Post by: bilbo on 2011-11-16 15:38:02
Why not just use a letter designation for now such as:

3.99a
3.99b
...
...
3.99z

This will give us 25 more revisions to fight about it!
Title: LAME 3.99 is out
Post by: john33 on 2011-11-16 18:05:51
Why not just use a letter designation for now such as:

3.99a
3.99b
...
...
3.99z

This will give us 25 more revisions to fight about it!

The 'a' and 'b' are already in use for 'alpha' and 'beta' versions.
Title: LAME 3.99 is out
Post by: GeSomeone on 2011-11-16 19:49:33
r,s,t,u,v,w,x,y,z seems vaguely familiar somehow, gives just 9 "revisions", the new scheme leaves one char extra.
At least foobar2000 has no problems displaying the new version tag.
Title: LAME 3.99 is out
Post by: Alex B on 2011-11-16 22:22:49
Please change the LAME header back to the old more compatible format. Many SW & HW players can now read the LAME tag and play files gaplessly, but apparently the changed header does not work with every player.

For example, here is how JRiver Media Center sees the 3.98.4 and 3.99.1 headers:

LAME 3.98.4
Code: [Select]
MPEG-1 Layer 3
236 Kbit VBR
44.1 Khz Joint stereo

Copyrighted: No
Original: Yes
Protected by CRC: No
Encoder: LAME
Gapless: Yes (576 start, 828 end)


LAME 3.99.1
Code: [Select]
MPEG-1 Layer 3
273 Kbit VBR
44.1 Khz Joint stereo

Copyrighted: No
Original: Yes
Protected by CRC: No
Encoder: L3.9
Gapless: No


I'd request to label the current version as 3.99r and then do the 5.0 release. (4.0 must be skipped because of known reasons.)

Then the LAME developes can create up to 5 x 99 versions before the encountering the next problem - 10.0.
i.e. 5.00, 5.01, 5.02 ... 5.99, 6.00, 6.01 ... and so on.

IMHO, this a very important thing and even if the 5.00 release does not contain any other significant changes, fixing this header problem justifies the new version number.
Title: LAME 3.99 is out
Post by: halb27 on 2011-11-16 22:59:08
I second Alex B's proposal.
Title: LAME 3.99 is out
Post by: Alex B on 2011-11-16 23:05:41
... And as already reported EncSpot Pro is one of the programs that do not recognize the new header. Encspot Pro is a sacred relic from the past, but I still use it almost every day.
Title: LAME 3.99 is out
Post by: lock67ca on 2011-11-16 23:16:17
So that would also explain the trouble I'm having with gapless playback in iTunes and my Ipod?

3.98.4 plays perfectly.
Title: LAME 3.99 is out
Post by: Alex B on 2011-11-16 23:42:57
I just tried the current Winamp build. It can be added to the list of victims. It does not recognize the encoder delay and padding values from the LAME v.3.99.1 header.
Title: LAME 3.99 is out
Post by: timcupery on 2011-11-17 04:54:32
Simple fix why not write LAME3.991 instead of L3.99r1
...
Also I echo the concern about dropping the LAME branding, having encoded by: L3.99r1  is confusing.

I proposed this awhile back, on a thread wishing that Lame 3.98.4 could be distinguished from 3.98.2 in the header info (as it was, both versions are denoted in the header as LAME3.98r).
Similarly, Lame 3.90.3 just shows up as LAME3.90.  with nothing after the decimal.
I think for now, dropping the decimal and making it LAME3.991 is the best solution, to keep the header consistent with previous versions.
Title: LAME 3.99 is out
Post by: RobertoDomenico on 2011-11-17 06:26:53
So that would also explain the trouble I'm having with gapless playback in iTunes and my Ipod?

3.98.4 plays perfectly.


I can't say for the iPod but with iTunes 10.5.1 on OS X MP3's created with XLD using LAME 3.99.1 play back perfectly gapless and play back perfectly gapless on the Apple TV 2
Title: LAME 3.99 is out
Post by: Aleron Ives on 2011-11-17 07:28:28
I think for now, dropping the decimal and making it LAME3.991 is the best solution, to keep the header consistent with previous versions.

It's also worth noting that this is only an option as long as the plans for the next version number are changed. Since 1999, the sub-version numbers have always been limited to a maximum of two digits (LAME 3.01, 3.22, 3.96.1, etc.), and since that is the case, removing the period before the final number works, as it's understood that the sub-version can only be two digits. If 3.100 is released, it will forever eliminate the possibility of removing the final decimal point, as it won't be clear whether the sub-version is two or three digits in any given future release without looking at the ChangeLog.

If the developers are still opposed to moving beyond LAME 3.x releases, they could always switch to numbering the releases in hexadecimal. They could then release LAME 3.9A - 3.FF (while still using lowercase letters "a" and "b" for alpha/beta) before having to deprecate the 3.x series.  (Yes, this is said in jest, but the sad thing is it would probably be less disruptive to software compatibility than removing the "LAME" string from the version identifier field.) I agree with those who have said that it's preferable to remove a decimal point to fit in full version numbers than to shorten the "LAME" name to "L", so I hope the developers can find a solution which satisfies their desire for version specificity while preserving software compatibility.
Title: LAME 3.99 is out
Post by: db1989 on 2011-11-17 10:24:36
The problem is that the LAME tag currently allows 9 bytes for the Version info. Without changing the size of this and causing more external software issues, no doubt, there has to be a compromise if the Patch Version Number is to be written. Previously, it wasn't written, so it wasn't an issue.

So, it really depends on whether people want the patch version number written into the LAME tag, or not.

And yet, two posts earlier?

Simple fix why not write:

LAME3.991

instead of L3.99r1

Keep to the LAME3.99a for point releases

Also I echo the concern about dropping the LAME branding, having encoded by: L3.99r1  is confusing.

Then use LAME3100x for 3.100 (assuming version 3 lasts forever!). Something tells me that the one-, three-, and one-digit limits for major version, minor version, and revision numbers aren’t going to be exhausted any time soon.

Really, with how simple this seems, I don’t understand the amount of discussion that has come out of it!
Title: LAME 3.99 is out
Post by: Alex B on 2011-11-17 10:29:11
Everyone must keep in mind that we are speaking about a well hidden code that resides inside the LAME header. It has very little importance to the users. It does not necessarily need to be exactly identical to the actual LAME revision number. The most important thing is to keep the LAME header compatible with the existing player implementations. Thanks to LAME, gapless MP3 playback is now possible with many SW and HW players. There is no reason to make that anyhow more difficult.

However, it would not harm to use a string that indicates the actual version number if the code is 100% compatible.

In my opinion the idea to use 3.991, 3.992, etc or include additional letters like 3.99C would cause confusion and the road would dead end at 3.1000 or 3.100C. As already said, a sensible thing to do would be to proudly start a new numbering scheme from 5.0. Then the LAME developers could decide later if they want to simply use the numbers chronologically like 5.00...5.99, 6.00...6.99 and so on -- or continue releasing minor "point" versions like 5.0.1, 5.1.3, 6.2.5, etc

For comparison, the Firefox version number has quickly advanced from 3.6.xx to 8.0 in less than one year after the developers changed the numbering logic.
Title: LAME 3.99 is out
Post by: robert on 2011-11-17 10:30:56
but knowing the patch version and, therefore, knowing if you are using the latest version must be of benefit.

Is this rule be "forever"? Is it good to remove "LAME" brand from the the "vendor" tag? Sorting is fun too (3.99r1, then 3.99a2, than 3.99b2, then 3.99r2, then 3.99a3... This is not trivial to sort, compared to L3.99.1r, L3.99.2a...). How someone who has never seen a LAME tag (this can happen!) can find that "L" or "L3.99" is the hint for "Lame" encoder? "Lame encoder" on Google redirects to http://lame.sourceforge.net (http://lame.sourceforge.net), "L encoder" will never do it. I would have imagined something like "LAME3.99s" or "LAME4.00r"... (Why using .99 if you don't plan to rename it to .00 at some point? After 3.99.9, will the next one be 3.99.9.1?)

If 3rd party software recognizes the extra info only, when the short version string starts with LAME, then other encoders will have to fake a LAME version info here too, if they want their files to be handled equally well. As a consequence, you can't trust the version info anymore and this hurts the "brand" even more. I don't get your sorting problem. The letters stand for a-lpha, b-eta and r-elease versions. The corresponding file version info in the executable are 3.99.n.1 with n = 0 (alpha), 1 (beta), 2 (release). With the old scheme and upcoming versions, you can't differentiate between a/b/r versions anymore.

To sum it up, I'll think about a compromise.
Title: LAME 3.99 is out
Post by: Zenitram on 2011-11-17 10:46:21
I don't get your sorting problem. The letters stand for a-lpha, b-eta and r-elease versions. The corresponding file version info in the executable are 3.99.n.1 with n = 0 (alpha), 1 (beta), 2 (release). With the old scheme and upcoming versions, you can't differentiate between a/b/r versions anymore.

Sorting issue ("3.99a2"<"3.99r1", weird) is a detail (very few developers will try to sort, but a "compromise" could be "3991r", even if the dot is hardcoded in specs, I think this is not used as a "trigger" for LAME decoder detection)
The major, very important issue, you can see it in the comments, is the 4th first letters "LAME". Lot of programs (and hardware!) rely on theses 4 letters, because... It was written in the "specs", this is a method to detect LAME encoder, this is "logical".

"LAME" letters are very important for legacy.
Title: LAME 3.99 is out
Post by: Alex B on 2011-11-17 10:52:43
Robert, since you posted almost the same time as I, please check also my last reply in the previous page if you did not already notice it. Thanks.
Title: LAME 3.99 is out
Post by: robert on 2011-11-17 11:18:41
I don't get your sorting problem. The letters stand for a-lpha, b-eta and r-elease versions. The corresponding file version info in the executable are 3.99.n.1 with n = 0 (alpha), 1 (beta), 2 (release). With the old scheme and upcoming versions, you can't differentiate between a/b/r versions anymore.

Sorting issue ("3.99a2"<"3.99r1", weird) is a detail (very few developers will try to sort, but a "compromise" could be "3991r", even if the dot is hardcoded in specs, I think this is not used as a "trigger" for LAME decoder detection)
The major, very important issue, you can see it in the comments, is the 4th first letters "LAME". Lot of programs (and hardware!) rely on theses 4 letters, because... It was written in the "specs", this is a method to detect LAME encoder, this is "logical".

"LAME" letters are very important for legacy.

The "spec" gives two examples for Encoder short VersionString (btw the spec has a miscounted starting point there), but that doesn't make any of these examples mandatory.

Code: [Select]
9 characters 

examples:
"LAME3.90a" : LAME version 3.90 alpha
"GOGO3.02b" : GOGO version 3.02 beta


Robert, since you posted almost the same time as I, please check also my last reply in the previous page if you did not already notice it. Thanks.

I've read your post.
Title: LAME 3.99 is out
Post by: Zenitram on 2011-11-17 11:47:46
The "spec" gives two examples for Encoder short VersionString (btw the spec has a miscounted starting point there), but that doesn't make any of these examples mandatory.

Specs are not logical, yes... That's a pity that there is no correction and "official" definition of the tag.
Take the other part of the spec: 00h 00h 00h $9B "L" "A" "M" "E" $A0 "." $A2 $A3 $A4.

Anyway, that does not change the fact that some tools/hardware have problems without "LAME" magic value. This is a mess, but I see no big reason to break such tools (and this part of the specs), there are other solutions, from my point of view.
Title: LAME 3.99 is out
Post by: robert on 2011-11-17 11:50:47
You know what an example is, yes?
Title: LAME 3.99 is out
Post by: Zenitram on 2011-11-17 12:26:09
I know to read a spec, I read dozens of them for my job. When $9C is replaced by 'L' somewhere in a hex dump with links to the definition of each not hard coded parts, this used to be something mandatory (normative). Examples use to be "not normative" = if you have a doubt, trust the normative part.

Anyway, mood, discussion on bad specs is not the main issue. The main issue is that you break compatibility. Specs have often corrections, but when a spec is corrected, authors try not to break the past when they can (e.g. on the same page, it is said not to use "Info" tag for VBR, but to continue to use "Xing" tag even if "Info" tag is valid for VBR, the goal is to keep compatibility, legacy), and I am sure you can do better. If the goal is to break compatibilty with software/hardware, why not, if the goal is to spread the LAME tag, the idea is not good.

And I am not the only one to say that "L" magic value for Lame encoder is not very appropriate. User may not see the problem directly, but they see that the tool they use don't support anymore some features because another developer has made the same error than me.

At the end, my tool is not a problem, I'll adapt my code and my user base is so tiny that nearly nobody will see it (except some people asking why Lame software is no more well detected, very few people). I only warn you on potential problem you can face later when most users will not be able to use correctly their hardware/software (more spread than mine). I am only an small alert of the potential future.
Title: LAME 3.99 is out
Post by: fromsilenceandanything on 2011-11-18 02:32:20
Could some kind soul please mirror/link the 3.99 32bit libsnd bundle for Windows 7? Spent an hour googling and snooping around the Rarewares site, but it's apparently been deleted already. My iPhone cannot handle the new 3.99.1 headers and thus doesn't play the files gaplessly... That's too irritating for me. 
Title: LAME 3.99 is out
Post by: lock67ca on 2011-11-18 02:39:47
That's the same problem I'm having with iTunes and my Ipod. They either cannot read the LAME header, or cannot read it properly, and as a result, gapless playback is now screwed up. My concern isn't so much about how the version of the encoder is displayed, but how the header is handled by certain hardware and software. There's clearly a problem here.
Title: LAME 3.99 is out
Post by: RobertoDomenico on 2011-11-18 02:58:28
I just tried my brothers iPhone 4s this morning and it plays back Lame 3.99.1 files perfectly gapless along with iTunes. I convert ALAC files with XLD on OS X Lion to Mp3.
Title: LAME 3.99 is out
Post by: fromsilenceandanything on 2011-11-18 03:35:30
I just tried my brothers iPhone 4s this morning and it plays back Lame 3.99.1 files perfectly gapless along with iTunes. I convert ALAC files with XLD on OS X Lion to Mp3.
Mine is 3 series (or something, I got it for free and wouldn't pay a penny for it if I had to lol), so apparently these old gen models can't read them properly.
Title: LAME 3.99 is out
Post by: lock67ca on 2011-11-18 03:42:57
That's probably it. Mine is a 120GB Ipod Classic. Three years old. Sounds like the newest models are not having a problem with the header. Apple isn't updating the firmware on the older models, so they won't deal with the problem.
Title: LAME 3.99 is out
Post by: RobertoDomenico on 2011-11-18 03:45:14
Could it be the way the XLD developer implemented theLAME encoder. UNder get info in iTunes it does show "ENCODED WITTH Lame 32bits 3.99.1
Title: LAME 3.99 is out
Post by: lock67ca on 2011-11-18 03:55:24
My 3.99.1 encodes are still showing up as Encoded by: Unknown in iTunes. Odd. I used foobar2000, EAC and dBpoweramp to encode, and it makes no difference which one is used, they all show up as Unknown. It's definitely not reading the header correctly. XLD is for Apple computers, right? Perhaps that's why it's working properly for you? Just a guess on my part.
Title: LAME 3.99 is out
Post by: RobertoDomenico on 2011-11-18 06:06:42
I just booted into Windows and used dbpoweramp and iTunes does show it as unknown. The XLD developer must of changed something somewhere as Lame 3.99.1 encoded with XLD show in iTunes as Lame 32bits 3.99.1 and play gapless everywhere i have tried.

This might explain http://tmkk.pv.land.to/lame/index_e.html (http://tmkk.pv.land.to/lame/index_e.html)
Title: LAME 3.99 is out
Post by: john33 on 2011-11-18 09:06:52
Could some kind soul please mirror/link the 3.99 32bit libsnd bundle for Windows 7? Spent an hour googling and snooping around the Rarewares site, but it's apparently been deleted already. My iPhone cannot handle the new 3.99.1 headers and thus doesn't play the files gaplessly... That's too irritating for me. 

http://homepage.ntlworld.com/jfe1205/LAME/...-20111101-2.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.99-libsndfile-20111101-2.zip)
There you go.
Title: LAME 3.99 is out
Post by: robert on 2011-11-18 10:01:00
I just booted into Windows and used dbpoweramp and iTunes does show it as unknown. The XLD developer must of changed something somewhere as Lame 3.99.1 encoded with XLD show in iTunes as Lame 32bits 3.99.1 and play gapless everywhere i have tried.

This might explain http://tmkk.pv.land.to/lame/index_e.html (http://tmkk.pv.land.to/lame/index_e.html)

What you are seeing is some ID3v2 tag, LAME adds it when you use its tagging options. I don't know if iTunes does react on such a tag.
Title: LAME 3.99 is out
Post by: RobertoDomenico on 2011-11-18 10:02:52
Then why are Lame mp3 created with dbpoweramp non gapless and Lame mp3s created with XLD on OSX gapless.
Title: LAME 3.99 is out
Post by: robert on 2011-11-18 10:07:17
To my knowledge, dBpoweramp doesn't use LAME's id3 tag writing options, it does it on its own. Maybe try to copy the ID3v2 TSSE frame to one file encoded with dBpoweramp. See if that makes any difference for iTunes.

Edit: forgot to mention, XLD seems to be using LAME's id3v2 tagging options.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-18 12:12:29
LAME 3.99.2 compiles on the way featuring a reversal to the old LAME tag scheme.
Title: LAME 3.99 is out
Post by: Zenitram on 2011-11-18 12:18:08
LAME 3.99.2 compiles on the way featuring a reversal to the old LAME tag scheme.

Thank you.
How will the version be after this one? (3.100? 5.00?). I am working on a "human readable" decoder name + decoder version based on this string, so if I can anticipate any change in the version string policy, it would be great.
Title: LAME 3.99 is out
Post by: fromsilenceandanything on 2011-11-18 12:36:22
Could some kind soul please mirror/link the 3.99 32bit libsnd bundle for Windows 7? Spent an hour googling and snooping around the Rarewares site, but it's apparently been deleted already. My iPhone cannot handle the new 3.99.1 headers and thus doesn't play the files gaplessly... That's too irritating for me. 

http://homepage.ntlworld.com/jfe1205/LAME/...-20111101-2.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.99-libsndfile-20111101-2.zip)
There you go.
Thanks, you just made my day.

P.S.
Quote
LAME 3.99.2 compiles on the way featuring a reversal to the old LAME tag scheme.
Does this only go for how the tool is written or gap information?
Title: LAME 3.99 is out
Post by: john33 on 2011-11-18 12:58:43
3.99.2 compiles are now at Rarewares.

Questions regarding future numbering schemes are really for Robert and not me as he is the currently active lame-dev and I am not one at all!
Title: LAME 3.99 is out
Post by: DARcode on 2011-11-18 13:22:51
How will the version be after this one? (3.100? 5.00?). I am working on a "human readable" decoder name + decoder version based on this string, so if I can anticipate any change in the version string policy, it would be great.

From: http://lame.cvs.sourceforge.net/viewvc/lam...l?revision=HEAD (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=HEAD)
Quote
LAME 3.100  not yet released.
Title: LAME 3.99 is out
Post by: apodtele on 2011-11-18 16:20:53
This is some history

LAME3.97a
LAME3.97b
LAME3.97r
LAME3.98a
LAME3.98b
LAME3.98r    3.98-3.98.4
LAME3.98a
LAME3.98b
LAME3.99r    3.99
L3.99r1        3.99.1 (aka insane)
LAME3.99r    3.99.2 (back to sanity)

and future

LAME3.993  3.99.3  (kill the 'r')
LAME3100a            (kill the dot)
LAME3100b
LAME31000  3.100 release
LAME31001  3.100.1
LAME31024  3.102.4
LAME50579  5.57.9
...

My point is that 9 characters is plenty.


Title: LAME 3.99 is out
Post by: fromsilenceandanything on 2011-11-18 18:24:25
Can we expect any sort of backward-compatibility with the new gapless headers in the future?
Title: LAME 3.99 is out
Post by: lock67ca on 2011-11-18 20:13:13
Can we expect any sort of backward-compatibility with the new gapless headers in the future?



Still having problems?
Title: LAME 3.99 is out
Post by: fromsilenceandanything on 2011-11-19 02:42:27
Can we expect any sort of backward-compatibility with the new gapless headers in the future?



Still having problems?
Hm, was this fixed in the new revision? I didn't even bother to try it out.
Title: LAME 3.99 is out
Post by: apodtele on 2011-11-19 03:18:22
Hm, was this fixed in the new revision? I didn't even bother to try it out.


Well, I tried it and I know, but I am not going to bother to tell you.
Title: LAME 3.99 is out
Post by: fromsilenceandanything on 2011-11-19 03:38:18
Hm, was this fixed in the new revision? I didn't even bother to try it out.


Well, I tried it and I know, but I am not going to bother to tell you.
I don't think I'm too wrong here if I state it's too much work switching between different encoders, converting FLAC into mp3 and transferring those transcodes into an iPod (which is not simply drag&drop) + doing it again with old lame if it *doesn't* work..

But, yeah, what Rarewares only mentions is that it changes how the tool is written. How would I know?
Title: LAME 3.99 is out
Post by: john33 on 2011-11-19 08:56:30
What I actually wrote at Rarewares was:
Quote
Reverts how the version information is written to the LAME tag to the previous scheme.
So, yes, it's fixed at the moment.

I believe that Robert is re-considering what may happen in the future.
Title: LAME 3.99 is out
Post by: Rio on 2011-11-19 15:33:43
even at -V8 it didn't use lowpass filtering, but surely resampling it to 24kHz automatically filters the encode to 12kHz. still sounds good on my portable, comparable with -V8 using 3.97. wouldn't complain against the lack of that filter =)

edit: grammar
Title: LAME 3.99 is out
Post by: raceviper13 on 2011-11-21 16:45:06
I use LAME primarily for encoding voice.  The switch from 3.98 and 3.99 is incorrigible for my needs.  I have used -V9.9999 on 3.98.4 as it produced the smallest file size and it sounded great in the car with voice recordings.  Now with 3.99.2, I can't get an equivalent sound quality.  When LAME downsamples, the quality/filesize dramatically changes.  From -V7.9 to -V8 it switches from 32kHz to 22kHz and the file size dramatically drops.  Why was this path chosen?  Is this useful to anyone?

I checked a music file and did an impromtu test.  I got both files at the same file size and 3.99.2 did not sound as good as 3.98.4.  I wont be able to use the new version.  Why did this change happen?  Did anyone not notice these problems?  Was this update to LAME only for music?  Who's using LAME for music anymore?  AAC is way better.
Title: LAME 3.99 is out
Post by: db1989 on 2011-11-21 16:58:54
I’ll leave others to sort through that more thoroughly if they wish, but a couple of things.

From -V7.9 to -V8 it switches from 32kHz to 22kHz and the file size dramatically drops.  Why was this path chosen?  Is this useful to anyone?
It is logical to reduce the range of frequencies that are conserved, in order to increase the fidelity with which the remainder are encoded. I imagine that many people find this feature useful. It is rather rudimentary as far as lossy encoding goes.

Quote
I checked a music file and did an impromtu test. I got both files at the same file size and 3.99.2 did not sound as good as 3.98.4.
I assume that your yardstick for “sound[ing] good” here is frequency range. In any case, expecting transparency at such low quality settings is unrealistic. Frequency range and fidelity must be weighed against each other, as noted above, and neither is likely to escape unscathed at a bitrate this low.

Quote
I wont be able to use the new version.
Not even by reading the guide to the command-line options and disabling the resampling as detailed therein?

Quote
Who's using LAME for music anymore?  AAC is way better.
This is almost rude in its presumptiveness, particularly as you appear to be projecting your preference onto everyone else. Many users continue to use MP3 for various reasons, e.g. compatibility, without being concerned that AAC has performed better in some listening tests at lower bitrates.
Title: LAME 3.99 is out
Post by: apodtele on 2011-11-21 17:10:01
I use LAME primarily for encoding voice.  The switch from 3.98 and 3.99 is incorrigible for my needs.  I have used -V9.9999 on 3.98.4 as it produced the smallest file size and it sounded great in the car with voice recordings.  Now with 3.99.2, I can't get an equivalent sound quality.  When LAME downsamples, the quality/filesize dramatically changes.  From -V7.9 to -V8 it switches from 32kHz to 22kHz and the file size dramatically drops.  Why was this path chosen?  Is this useful to anyone?

I checked a music file and did an impromtu test.  I got both files at the same file size and 3.99.2 did not sound as good as 3.98.4.  I wont be able to use the new version.  Why did this change happen?  Did anyone not notice these problems?  Was this update to LAME only for music?  Who's using LAME for music anymore?  AAC is way better.


The target bitrates for the V scale did change a lot. As a result you may be getting much lower bitrates with you old magic -V9.9999.
This is not a bug however, because the target bitrates were never mandatory. Your report is too sketchy on details.
Please provide more information of the actual resulting bitrates and file sizes.

For example,  your voice files:
1) 3.98.4 -V9.9999, size and bitrate
2) 3.99.2 -V9.9999, size and bitrate
3) 3.99.2 -V"whatever-you-now-consider acceptable", size and bitrate




Title: LAME 3.99 is out
Post by: raceviper13 on 2011-11-21 17:35:53
Quote
Not even by reading the guide to the command-line options and disabling the resampling as detailed therein?


I looked in the lame.exe --longhelp and at http://wiki.hydrogenaudio.org/index.php?title=LAME (http://wiki.hydrogenaudio.org/index.php?title=LAME).  I looked but did not find such an option.  If one does exist, it would completely change my opinion of 3.99.2.
Title: LAME 3.99 is out
Post by: db1989 on 2011-11-21 17:39:52
http://lame.cvs.sourceforge.net/viewvc/lam...d.html#resample (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#resample)
Title: LAME 3.99 is out
Post by: raceviper13 on 2011-11-21 18:00:10
http://lame.cvs.sourceforge.net/viewvc/lam...d.html#resample (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#resample)


I think 3.99.2 is not for me.  It must be for everyone else but me.  I can get it to do what I want now, but not without a bunch of work.  3.98.4 will do what I want every time, and I don't have to wonder if it'll be what I am looking for.
Title: LAME 3.99 is out
Post by: viktor on 2011-11-21 18:29:27
4.0 must be skipped because of known reasons.

such as?
Title: LAME 3.99 is out
Post by: apodtele on 2011-11-21 18:33:48
http://lame.cvs.sourceforge.net/viewvc/lam...d.html#resample (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#resample)


I think 3.99.2 is not for me.  It must be for everyone else but me.  I can get it to do what I want now, but not without a bunch of work.  3.98.4 will do what I want every time, and I don't have to wonder if it'll be what I am looking for.


In a nutshell, your problem is that changing your habitual -V9.9999 is too much for you to take. In other words, your are completely change-avert. Stick to 3.98.4 by all means. I am surprised that you even tried 3.99.2. That was a really bad idea in your world where no change is permitted.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-21 18:47:34
4.0 must be skipped because of known reasons.

such as?

LAME 4.0 was a totally experimental branch being worked on exclusively by Takehiro Tominaga and involved a major re-write of much of LAME. Takehiro has not worked on this now for some years as he is, I believe, 'getting on with life'!!
Title: LAME 3.99 is out
Post by: viktor on 2011-11-21 18:51:32
4.0 must be skipped because of known reasons.

such as?

LAME 4.0 was a totally experimental branch being worked on exclusively by Takehiro Tominaga and involved a major re-write of much of LAME. Takehiro has not worked on this now for some years as he is, I believe, 'getting on with life'!!

that doesn't give us a reason to call the next release lame 5. everyone would keep asking, "where's lame 4?", and their question would be perfectly legit. put Takehiro's code aside, and keep working on lame 4. you can call it internally whatever you want, it doesn't matter from a user point of view. it's VC'ed, so no information is lost. simple.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-11-21 19:03:13
everyone would keep asking, "where's lame 4?", and their question would be perfectly legit.


Where is Winamp 4? 
Title: LAME 3.99 is out
Post by: viktor on 2011-11-21 19:03:56
everyone would keep asking, "where's lame 4?", and their question would be perfectly legit.


Where is Winamp 4? 

yeah, others are stupid, so we should be, too
Title: LAME 3.99 is out
Post by: lvqcl on 2011-11-21 19:19:36
I think 3.99.2 is not for me.  It must be for everyone else but me.  I can get it to do what I want now, but not without a bunch of work.  3.98.4 will do what I want every time, and I don't have to wonder if it'll be what I am looking for.


Some people even prefer 3.97 over 3.98 (http://www.hydrogenaudio.org/forums/index.php?showtopic=67041), so... Just use a version (encoder/format/...) that suits your needs better.
Title: LAME 3.99 is out
Post by: decapattack on 2011-11-22 01:08:45
Hi guys!

I'm new here but i've been looking for information here for a long time but this is my fisrt post.

So, i tried the new lame 3.99.2. I was converting some soundtracks ( basically Megadrive - Genesis soundtrack) and some of them sounded terrible with 3.99.2, even with V 0. Seem like the codec always tries to low the bitrate of the music. It sounded muffled and kinda "metallic".

When i used the old 3.98.4, it sounded OK.

There are the options that I used to convert the files, the same for both codecs:

lame.exe --vbr-new -V 0 -b -B -m j -q 0 --noreplaygain --id3v1-only --lowpass 14000 --resample $(SampleRate) "$(SourceFile)" "$(DestFileAudio)"

Does anyone experienced this?

Thanks a lot!
Title: LAME 3.99 is out
Post by: kwanbis on 2011-11-22 02:08:30
lame.exe --vbr-new -V 0 -b -B -m j -q 0 --noreplaygain --id3v1-only --lowpass 14000 --resample $(SampleRate) "$(SourceFile)" "$(DestFileAudio)"

Are you serious?

lame -V 0

Is the only thing you need.
Title: LAME 3.99 is out
Post by: Aleron Ives on 2011-11-22 06:23:30
The "muffled" sound could likely be attributed to the lowpass you used, seeing as it is much lower than what V 0 would use by default (3.99's V 0 doesn't even have a lowpass). You should also take note of TOS #8 (http://www.hydrogenaudio.org/forums/index.php?showtopic=3974#entry149481), which requires you to perform double-blind listening tests to substantiate quality claims.
Title: LAME 3.99 is out
Post by: DARcode on 2011-11-22 09:14:47
Some people even prefer 3.97 over 3.98 (http://www.hydrogenaudio.org/forums/index.php?showtopic=67041), so... Just use a version (encoder/format/...) that suits your needs better.
Since HA has chosen to recommend the latest stable version of the LAME compile for optimal quality unless noted otherwise (http://wiki.hydrogenaudio.org/index.php?title=LAME#Recommended_encoder_compiles_and_source_code), 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?
Title: LAME 3.99 is out
Post by: decapattack on 2011-11-22 09:22:36
Interesting. I changed the lowpass to 20k and the metallic sound went away.

About the lowpass, my ears are already damaged so i can't hear frequencies above 16k. So, after tons os tests, i decided that setting the lowpass to 14000, for me and for music in general, was ok. The loss of quality was minimal and the filesize was small enough with V 5.

Anyway. Thanks a lot for the tip!
Title: LAME 3.99 is out
Post by: db1989 on 2011-11-22 10:52:24
http://lame.cvs.sourceforge.net/viewvc/lam...d.html#resample (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.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.

Quote
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.
Title: LAME 3.99 is out
Post by: DARcode on 2011-11-23 11:41:56
Since HA has chosen to recommend the latest stable version of the LAME compile for optimal quality unless noted otherwise (http://wiki.hydrogenaudio.org/index.php?title=LAME#Recommended_encoder_compiles_and_source_code), 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?
Title: LAME 3.99 is out
Post by: halb27 on 2011-11-23 13:44:30
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.
Title: LAME 3.99 is out
Post by: apodtele on 2011-11-23 15:10:36
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.
Title: LAME 3.99 is out
Post by: DARcode on 2011-11-23 15:33:46
I've gone thru pages 7 and 8 of the "ame 3.98.4, 3.99 alpha, 32- and 64-bit builds (http://www.hydrogenaudio.org/forums/index.php?showtopic=79682&st=150)" 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 (http://en.wikipedia.org/wiki/Livin%27_in_Exile_(Album)), 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.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-11-23 15:36:23
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)
Title: LAME 3.99 is out
Post by: zipr on 2011-11-23 16:28:34
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...
Title: LAME 3.99 is out
Post by: zipr on 2011-11-23 17:39:56
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....
Title: LAME 3.99 is out
Post by: ZinCh on 2011-11-28 08:02:12
LAME 3.99.3  November 26 2011

Robert Hegemann
Fix for tracker item [ 3441349 ] --tg does not handle genre number when adding unicode tag
Title: LAME 3.99 is out
Post by: john33 on 2011-11-28 08:49:16
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.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-28 16:10:17
As some people have already discovered, the compiles are there now - MSVC10/ICL12.1 compiles.
Title: LAME 3.99 is out
Post by: psycho on 2011-11-28 18:16:47
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?
Title: LAME 3.99 is out
Post by: john33 on 2011-11-28 18:29:29
I'd love to help, but you need someone who's familiar with that environment and I'm afraid that isn't me!
Title: LAME 3.99 is out
Post by: zipr on 2011-11-29 02:56:34
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
Title: LAME 3.99 is out
Post by: bilbo on 2011-11-29 14:54:39
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: [Select]
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.
Title: LAME 3.99 is out
Post by: robert on 2011-11-29 15:05:28
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?
Title: LAME 3.99 is out
Post by: zipr on 2011-11-29 15:41:06
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.
Title: LAME 3.99 is out
Post by: bilbo on 2011-11-29 19:13:07
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!
Title: LAME 3.99 is out
Post by: Frankie on 2011-11-29 20:48:36
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). 

Title: LAME 3.99 is out
Post by: zipr on 2011-11-30 03:39:56
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!
Title: LAME 3.99 is out
Post by: psycho on 2011-11-30 16:39:28
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.
Title: LAME 3.99 is out
Post by: Jebus on 2011-11-30 20:55:32
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.
Title: LAME 3.99 is out
Post by: john33 on 2011-11-30 21:35:57
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.
Title: LAME 3.99 is out
Post by: Mr. Odd on 2011-12-04 03:16:56
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!

Title: LAME 3.99 is out
Post by: robert on 2011-12-04 09:10:07
What version of MP3Gain are you using?
Can you call "check integrity" from foobar's utilities for those files?
Title: LAME 3.99 is out
Post by: robert on 2011-12-04 09:28:05
@Jebus

Albert Faber originally wrote the code for the DLL for his CDex project.
For new programs, do use the libmp3lame.dll instead.

Do you want to replace RG by r128 ?
Title: LAME 3.99 is out
Post by: Jebus on 2011-12-05 17:41:03
ah, I didn't realize - thought it was the preferred public API. I'm using my own native C# RG implementation; I may also implement r128 at a later date.

Could someone add libmp3lame.dll be to the Rarewares Lame bundles? I need both 32-bit and 64-bit versions, and don't have access to ICL. It would be muchly appreciated!
Title: LAME 3.99 is out
Post by: john33 on 2011-12-05 18:00:02
Will do, over the next 24 hours.  I'll add them separately.
Title: LAME 3.99 is out
Post by: JJZolx on 2011-12-05 19:55:17
So, what's the verdict? Is 3.99.3 going to be it for a while? There have been a slew of releases in very short order. Could we see a 3.99.4 soon to fix more bugs? I'm hesitant to encode anything with 3.99.3 after the missteps with 3.99 and 3.99.1 and 3.99.2.
Title: LAME 3.99 is out
Post by: halb27 on 2011-12-05 20:15:42
You don't have to re-encode when a new subversion comes out. As  far as I can see  the new subversion were only a.bout special tagging issues.
Title: LAME 3.99 is out
Post by: zipr on 2011-12-06 03:25:21
Robert and Mr. Odd:

I'm using mp3gain v1.25

When I did run "check integrity," it told me that there were minor problems and that there were multiple id3v2 tags encountered.

So I checked my EAC settings. I had LAME set up to tag the file:
-V2 --add-id3v2 --pad-id3v2 --ta "%artist%" --tl "%albumtitle%" --tt "%title%" --tn "%tracknr%" --tg "%genre%" --ty "%year%" %source% %dest%

And also on the EAC compression tab I had 'Add ID3 tag' checked as well. So I think that there were actually two sets of tags being written. If I unchecked the box and tested, I was still getting id3v2 tags, but no errors in foobar or in mp3gain.

So I think the problem is solved for me. I'm still curious as to why this caused problems in 3.99 but not in 3.98?

Title: LAME 3.99 is out
Post by: apodtele on 2011-12-06 14:35:25
When I did run "check integrity," it told me that there were minor problems and that there were multiple id3v2 tags encountered.


... as was suggested in post #266.

Nonetheless, LAME should have replaced the old tag instead of piling on. It is a bug in LAME.
Title: LAME 3.99 is out
Post by: john33 on 2011-12-06 14:43:06
.....
Could someone add libmp3lame.dll be to the Rarewares Lame bundles? I need both 32-bit and 64-bit versions, and don't have access to ICL. It would be muchly appreciated!

Compiles of the dll with exports and libs (ICL 12.1), x86 and x64, now at Rarewares on the lame-libs page.
Title: LAME 3.99 is out
Post by: robert on 2011-12-06 15:05:05
Nonetheless, LAME should have replaced the old tag instead of piling on. It is a bug in LAME.

LAME creates the file, there is nothing to replace. Sorry, no bug in LAME.
Title: LAME 3.99 is out
Post by: Jebus on 2011-12-06 15:19:15
.....
Could someone add libmp3lame.dll be to the Rarewares Lame bundles? I need both 32-bit and 64-bit versions, and don't have access to ICL. It would be muchly appreciated!

Compiles of the dll with exports and libs (ICL 12.1), x86 and x64, now at Rarewares on the lame-libs page. 


Thanks so much - you rule!
Title: LAME 3.99 is out
Post by: bilbo on 2011-12-07 18:53:03
The program must protect itself from idiots. Or, security holes would be user errors too. It is an EAC bug, because it should check
if the file contains the tag already before writing its own.


First of all, the program is listed as a beta version.

Second, you have a choice of beginner mode or advanced mode. Beginner is default. Do you think it needs a stupid mode?
Title: LAME 3.99 is out
Post by: zipr on 2011-12-08 03:38:59
Whether or not it was idiotic of me to leave the 'write id3 tag' box checked, I still am curious as to why it's only an issue using 3.99, and something I've never encountered with all of the other versions of LAME I've used (back to 3.96.1)...

Regardless, it's no longer an issue for me, and I learned a bit more about EAC in the process.
Title: LAME 3.99 is out
Post by: bilbo on 2011-12-08 21:45:03

Not meant for you!
Title: LAME 3.99 is out
Post by: greynol on 2011-12-08 22:31:47

Not meant for you!

I split away the useless off-topic argument but wanted to keep zipr's post since it relates back to differences between the current version of Lame and previous versions.  Your post was kept in order to preserve some context and it links back to the binned side-discussion.  Sorry for any confusion.
Title: LAME 3.99 is out
Post by: dxiv on 2011-12-13 05:03:26
Compiles of the dll with exports and libs (ICL 12.1), x86 and x64, now at Rarewares on the lame-libs page.

If that's not too much trouble, could you please add a modified lame_enc.dll to use .ini settings as well? Thanks.
Title: LAME 3.99 is out
Post by: robert on 2011-12-13 09:08:54
I still am curious as to why it's only an issue using 3.99, and something I've never encountered with all of the other versions of LAME I've used (back to 3.96.1)...


As of v3.99, LAME writes unicode tags by default (and when compiled with unicode support). The byte order marker (BOM) look like sync bits. Seeing your location, you eventually can live with Latin-1 text encoding, add --id3v2-latin1 in front of the other tagging options to avoid unicode tags.
Title: LAME 3.99 is out
Post by: john33 on 2011-12-13 10:00:09
Compiles of the dll with exports and libs (ICL 12.1), x86 and x64, now at Rarewares on the lame-libs page.

If that's not too much trouble, could you please add a modified lame_enc.dll to use .ini settings as well? Thanks.

Yes, sorry, I meant to look at these variations but they slipped my mind!  I'll try to get them done in the next day, or so.
Title: LAME 3.99 is out
Post by: john33 on 2011-12-14 16:10:08
...
If that's not too much trouble, could you please add a modified lame_enc.dll to use .ini settings as well? Thanks.

Available at Rarewares now in the same place as before.
Title: LAME 3.99 is out
Post by: apodtele on 2011-12-14 20:14:39
...
If that's not too much trouble, could you please add a modified lame_enc.dll to use .ini settings as well? Thanks.

Available at Rarewares now in the same place as before.


Would ini file settings have a precedence over other settings?
I do not like Winamps mp3 encoder set up that is very outdated.
Can I use this to overwrite Winamp plugin?
Title: LAME 3.99 is out
Post by: db1989 on 2011-12-14 21:19:31
Yes, that is basically the entire purpose of that particular DLL.

Edit: Well, sort of
Quote
This dll uses an '.ini' file to set up the encoder. This is designed for use with applications that use the dll but do not provide full preset support.
Title: LAME 3.99 is out
Post by: dxiv on 2011-12-14 22:17:55
(lamedll_mod3.99.3) Available at Rarewares now in the same place as before.

Thanks again, much obliged.
Title: LAME 3.99 is out
Post by: apodtele on 2011-12-14 23:29:22
Yes, that is basically the entire purpose of that particular DLL.

Edit: Well, sort of
Quote
http://www.rarewares.org/mp3-lame-libraries.php (http://www.rarewares.org/mp3-lame-libraries.php)[/url] ]This dll uses an '.ini' file to set up the encoder. This is designed for use with applications that use the dll but do not provide full preset support.



Sort of the other way around
This implies that the ini file has lower precedence, but this is not clear or explicit.
Title: LAME 3.99 is out
Post by: john33 on 2011-12-15 09:57:03
...
Sort of the other way around
This implies that the ini file has lower precedence, but this is not clear or explicit.

The code for the dll has been modified so that it ignores all parameters from the 'host' application that are specified in the .ini file.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-12-15 14:49:54
I cannot see why such DLL is better for Winamp users. 
Title: LAME 3.99 is out
Post by: DoctorO on 2011-12-15 15:39:11
likewise.

yes the Winamp mp3 encoder settings dialog isn't great / needs to be updated to whatever the suggested guidelines are now, but it otherwise works.

-daz
Title: LAME 3.99 is out
Post by: apodtele on 2011-12-15 16:59:27
yes the Winamp mp3 encoder settings dialog isn't great / needs to be updated to whatever the suggested guidelines are now, but it otherwise works.


DrO,

Take a look at http://wiki.hydrogenaudio.org/index.php?title=LAME (http://wiki.hydrogenaudio.org/index.php?title=LAME)  for the guidelines

In comparison to Winamp mp3 plugin, the modern LAME recommendations
-- do not even mention -q
-- do not dwell on bitrates
-- instead settle on --vbr-new by making it default
-- instead explain a lot about -V for VBR that are not offered by Winamp

That is how much Winamp mp3 plugin is behind.

A.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-12-15 17:34:55
-- instead explain a lot about -V for VBR that are not offered by Winamp


Yes they are:

(http://img196.imageshack.us/img196/2433/clipboard01zq.png)
Title: LAME 3.99 is out
Post by: apodtele on 2011-12-15 17:57:42
That is -q rather than -V, it never changes from 2 with any --preset or quality setting,
Title: LAME 3.99 is out
Post by: lvqcl on 2011-12-15 19:24:20
-q is "Quality" when it is equal to Low / Normal / High / Very High. And then "VBR Q" is -V switch.
Title: LAME 3.99 is out
Post by: apodtele on 2011-12-15 20:48:10
-q is "Quality" when it is equal to Low / Normal / High / Very High. And then "VBR Q" is -V switch.


When I read this http://lame.cvs.sourceforge.net/viewvc/lame/lame/USAGE (http://lame.cvs.sourceforge.net/viewvc/lame/lame/USAGE)
I expect -q to be either numeric or Fast / Slow / ... as an algorithm speed rating
and -V is either numeric or High / Low / ... as in quality/kbps or whatever.

Do you see my confusion while lacking Winamp documentation?
The layout is also confusing because VBR Q appears to be the least important (bottom) setting.

What you said and what I see simply does not chime with the Lame documentation.
The only thing that rings the correct bells is "--preset fast standard" and this is what I use.
Title: LAME 3.99 is out
Post by: DoctorO on 2011-12-15 23:30:41
apodtele: the link you've directed at me doesn't seem to be the one i remember seeing some time back on what is meant to be done in a UI for controlling lame. which was http://lame.sourceforge.net/lame_ui_example.php (http://lame.sourceforge.net/lame_ui_example.php) and as i've not followed things closely, my comment was worded as such to cater for things having changed with those suggested guidelines (though looks like i remember it being).

either way, no one is disagreeing that Winamp's mp3 encoder config needs to be overhauled, but trying to base what is currently there against documentation which has most likely changed since the encoder's ui was created (which if i remember correctly goes back to the original Winamp dev team) is never going to match up. also without checking, i was under the impression that the encoder's defaults have changed over time time to better fit with more of the 'preferred' options even if it's still based on the -preset method.

then again if you don't like it, you don't have to use it and just use whatever actually fits with what you want to use / get the results you deem important  (plus i'm pretty sure the mp3 encoder is only available if you're a pro user...).

-daz
Title: LAME 3.99 is out
Post by: krafty on 2011-12-16 00:18:14
Is it a good time to encode with 3.99 or should I stick with 3.98...
Audibly both doesn't matter, but in matter of bugs and the new -V0 lowpass extended, does it make any sense?
Title: LAME 3.99 is out
Post by: dxiv on 2011-12-16 07:35:51
I cannot see why such DLL is better for Winamp users. 

The INI-driven DLL wasn't invented just for Winamp users. Other rippers/encoders used to offer less than satisfactory control over LAME's options, older PlexTools for one.
Title: LAME 3.99 is out
Post by: john33 on 2011-12-16 09:33:42
I cannot see why such DLL is better for Winamp users. 

The INI-driven DLL wasn't invented just for Winamp users. Other rippers/encoders used to offer less than satisfactory control over LAME's options, older PlexTools for one.

Actually, I did it originally for older versions of CDex, but any software that uses the old .dll can take advantage of it.
Title: LAME 3.99 is out
Post by: Mercuryc on 2011-12-18 12:25:27
Hi,

not sure where to post this. I just encoded a 32000Hz wav file with foobar and LAME 3.99.3 64bit (from rarewares) with the setting "-V 5". For the result mp3 file Foobar says: Codec Profile: MP3 VBR V3 (132kbps)

I didn't make any more tests.

Something is wrong here, I guess.
Title: LAME 3.99 is out
Post by: halb27 on 2011-12-18 13:11:34
I ran upon this phenomenon while working on 3.99.3x.
-V level is remapped when using 32 kHz sampling frequency. It's a feature.
It would be better of cause if the user demanded -V level would be used to compute the quality item within the Lame tags which tools like foobar use for recalculating the -V level (the -V level isn't stored directly in the mp3 file).

If this is something that bothers you, you can use 3.99.3x (http://www.hydrogenaudio.org/forums/index.php?showtopic=92226&view=findpost&p=778153) where I fixed this. When using 3.99.3x with the usual -V n 3.99.3x works exactly like 3.99.3 does.
Title: LAME 3.99 is out
Post by: lvqcl on 2011-12-18 13:28:40
test32.wav is a 32kHz test file;

lame.exe -V 5 test32.wav => 118.6 kbps

lame.exe --resample 32 -V 5 test32.wav => 102.4 kbps


There is no difference between "-V 5" and "-V 5 --resample 44" for files with 44 kHz samplerate.
Title: LAME 3.99 is out
Post by: exx on 2011-12-18 23:30:35
Posted in the old 3.98 topic; might as well post here again.


Was using dbPowerAmp (which uses LAME) to convert some FLAC for my ipod and noticed it wasn't using my CPU to its full potential.

http://i.imgur.com/Kv9bR.png (http://i.imgur.com/Kv9bR.png)

Only goes up to ~15% per process (max would be 25%). Total encoding speed was around 120-130x, which is much slower than normal. I was doing the same thing yesterday and all 4 cores were maxed. I don't have anything running in the background. Could it be a HD speed issue? The input and output paths were on the same drive, but it's a WD Black so it's not terribly slow, and I didn't hear any drive noise.
Update: have since tried writing to a RAM disk as well as a different drive than the source; it goes a bit faster, but I still can't reliably max out each core. I feel as if there is wasted potential here. The CPU will often be maxed at the start of the batch, but drop off soon after.

Any ideas?
Title: LAME 3.99 is out
Post by: d_headshot on 2011-12-21 03:15:29
What's the deal with the lowpass filter? Is it on both v3.98 and 3.99? Has anyone viewed the frequency spectrum of two files at the same quality setting?
Title: LAME 3.99 is out
Post by: antman on 2012-01-02 03:29:39
My observations:

1.  My library with 3.98 V0 clocked in at 35GB, with 3.99 V0 it's at 36.8GB.

2.  Usually something NIN or metal is highest encoded song in my collection, with 3.99, it's Nirvana - From the Muddy Banks of the Wishkah - 08 - Sliver @ 307kbps (?!).

3.  In Windows Explorer (WinXP) when I highlight over that song, and all 3.99 encodes for that matter, the bitrate comes up at 656kbps.
Title: LAME 3.99 is out
Post by: DARcode on 2012-01-03 10:59:14
As mentioned a bitrate increase is to be expected, and I subscribe to shadowking's take on the matter here http://www.hydrogenaudio.org/forums/index....st&p=769219 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79682&view=findpost&p=769219).
Title: LAME 3.99 is out
Post by: apodtele on 2012-01-03 16:11:46
As mentioned a bitrate increase is to be expected, and I subscribe to shadowking's take on the matter here http://www.hydrogenaudio.org/forums/index....st&p=769219 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79682&view=findpost&p=769219).


I did not get this. If you equate VBR V3 from 2011 and CBR 256kbps from 2000, that's a big big progress. Just compare the file sizes and bitrates.

To V0 people: If you are so paranoid about the quality, stop complaining about the size.
Title: LAME 3.99 is out
Post by: greynol on 2012-01-03 16:20:26
What's the deal with the lowpass filter? Is it on both v3.98 and 3.99? Has anyone viewed the frequency spectrum of two files at the same quality setting?

Are you suggesting that there is a difference that you can actually hear and it has gotten worse with the new version?

If not then I fail to see why this matters!
Title: LAME 3.99 is out
Post by: d_headshot on 2012-01-03 21:41:31
What's the deal with the lowpass filter? Is it on both v3.98 and 3.99? Has anyone viewed the frequency spectrum of two files at the same quality setting?

Are you suggesting that there is a difference that you can actually hear and it has gotten worse with the new version?

If not then I fail to see why this matters!


By George of course I'm not 

All versions of lame are transparent to me so I'm not concerned about any difference in sound. I'm just curious about it because I'm in engineering and people like me are interested in stuff like that lol.
Title: LAME 3.99 is out
Post by: instaud on 2012-01-08 13:11:35
If not then I fail to see why this matters!

As a reader who finds valuable information on this great board I have to say that the only posts distracting from the flow of information are your regular attempts to shove in reminders about TOS #8, even if it was not the typical "320kbps rulez" kind of post.

If you own thousands of CDs you try to inform yourself thoroughly before switching your encoder and reencode. Technical background information and details about the developer's motivation to change things in the code helps with that decision.
Title: LAME 3.99 is out
Post by: naturfreak on 2012-01-25 21:40:53
Update to Version 3.99.4 (http://sourceforge.net/projects/lame/files/lame/3.99/) a few hours ago...

Quote
Changelog:
LAME 3.99.4  January 25 2012

    * Robert Hegemann
          o Fix for tracker item [ 3475581 ] lame crashes at .w64 input file
          o Addressing things brought to attention by tracker item [ 3463197 ] 3.99.x problem WFED and PCST frames
                + WFED and PCST frames can now be added, to tag podcasts iTunes recognizes
                + USER frames are now supported
                + COMM frames can now have a description, when passed via --tv "COMM=description=full text"
                + possible divide-by-zero exception should be fixed
                + adding malformed user-defined-frames could result in abnormal program termination, fixed
Title: LAME 3.99 is out
Post by: john33 on 2012-01-25 22:31:24
I have all the new compiles ready to go, but I am currently unable to access Rarewares FTP to update the site!! I have emailed Roberto to find out what's up and am awaiting a response.

Temporarily, they can be downloaded from here:

EDIT: Link removed - see below.

but please don't pass the link around otherwise my ISP will hit on me for too much traffic!! 

I'll get them up on Rarewares as soon as I'm able.
Title: LAME 3.99 is out
Post by: john33 on 2012-01-27 12:58:13
All compiles now available on Rarewares so the above link is removed.
Title: LAME 3.99 is out
Post by: bbrabant on 2012-01-28 09:53:59
All compiles now available on Rarewares so the above link is removed.


Thanks for the new Lame compiles but on my windows xp pc (32bit) I am unable to run these compiles. I had no problem running the previous compiles of  Lame.
Do I need to install additional libraries ?

Greetz,

Ben
Title: LAME 3.99 is out
Post by: john33 on 2012-01-28 09:59:13
I don't believe there are any dependencies. These (32 bit compiles) were tested on Win 2000 Pro and worked fine. The compiler is unchanged. What error message do you get, if any?

I won't be able to reply further until Monday as I'm away now until then.
Title: LAME 3.99 is out
Post by: bbrabant on 2012-01-28 12:11:06
What error message do you get, if any?


Immediately after running lame a windows dialog box comes up "Application Failure lame.exe 3.99.2.4 in lame.exe 3.99.2.4 at offset 0001afa6"
Title: LAME 3.99 is out
Post by: biomega on 2012-01-28 13:55:07
Thanks for the new Lame compiles but on my windows xp pc (32bit) I am unable to run these compiles. I had no problem running the previous compiles of  Lame.


Same problem here. NO error messages. Nothings happens (in the command-line window it simply jumps to a new line).

I've only encountered a similar behavior with programs that require a CPU with SSE2 support. (using an AthlonXP without SSE2)
Could that may be the case for this new release (LAME 3.99.4)?
Title: LAME 3.99 is out
Post by: Alex B on 2012-01-28 16:41:06
I've only encountered a similar behavior with programs that require a CPU with SSE2 support. (using an AthlonXP without SSE2)
Could that may be the case for this new release (LAME 3.99.4)?

You may be right. I just tried AMD Athlon XP 3200+ on Win 7 (32-bit). LAME 3.99.4 did not work when using the same foobar2000 settings that work fine with 3.99.3.

foobar2000 reported:

Conversion failed: The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters
Title: LAME 3.99 is out
Post by: bbrabant on 2012-01-28 20:32:38
I've only encountered a similar behavior with programs that require a CPU with SSE2 support. (using an AthlonXP without SSE2)


I am using a AMD Athlon XP 2200 also without SSE2 support
Title: LAME 3.99 is out
Post by: R3D on 2012-02-03 11:32:10
Hey, I've got a question and I hope you can help me. (I hope it's the right topic)

I would like to convert my CD's new. For the last nearly 2 years I used Rarewares Lame bundle 3.98.4 64-Bit all the time. But deleted it by mistake.
The problem is that I can't find the Rarewares 3.98.4 64-Bit version on their website anymore. Just the 32-Bit version of 3.98.4.

And I don't know if I can trust Lame 3.99.4 because I read about artifacts.


So, my question is... does someone know where I can find the Rarewares 64-Bit version of Lame 3.98.4?

Thanks.
Title: LAME 3.99 is out
Post by: john33 on 2012-02-03 12:08:41
Here you go:

http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4-64.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4-64.zip)
Title: LAME 3.99 is out
Post by: R3D on 2012-02-03 17:49:49
Thx for your quick help! 
Title: LAME 3.99 is out
Post by: db1989 on 2012-02-07 13:48:35
Split: LAME: different compilers producing significantly different bitstreams (http://www.hydrogenaudio.org/forums/index.php?showtopic=93308)
Title: LAME 3.99 is out
Post by: Steve Forte Rio on 2012-02-25 09:12:56
Hi all. I wonder when we will see regular (non-test) LAME 3.99.5 32- and 64-bit compiles at RareWares?
Title: LAME 3.99 is out
Post by: ZinCh on 2012-02-28 19:57:48
LAME 3.99.5 final version released today (  February 28 2012 )
Title: LAME 3.99 is out
Post by: john33 on 2012-02-28 22:38:03
A full set of 3.99.5 compiles is now at Rarewares.

For anyone who may have used the most recent test compile; there are no code changes in the release version so there is no need to re-encode anything.
Title: LAME 3.99 is out
Post by: eahm on 2012-02-28 23:48:30
Good birthday present thank you
Title: LAME 3.99 is out
Post by: apodtele on 2012-03-01 18:40:25
I run Windows 7 64-bit, however...

32-bit Winamp uses lame_enc.dll. Do I have to take 32-bit build?
32-bit foobar2000 uses lame.exe. Can I take 64-bit build?

See how confused I am?

Unfortunately, those players do not come in 64-bit form to bring me peace.
Title: LAME 3.99 is out
Post by: Jebus on 2012-03-01 19:12:45
Appologies and thanks in advance, because I know this increases the work for you every time a new release is made, but any chance we could get those libmp3lame downloads updated to the latest as well?
Title: LAME 3.99 is out
Post by: john33 on 2012-03-01 22:28:27
Appologies and thanks in advance, because I know this increases the work for you every time a new release is made, but any chance we could get those libmp3lame downloads updated to the latest as well?

Done.
Title: LAME 3.99 is out
Post by: DoctorO on 2012-03-01 22:56:08
32-bit Winamp uses lame_enc.dll. Do I have to take 32-bit build?
you need to use the 32-bit compile of lame_enc.dll as Winamp cannot load / use the 64-bit version.

-daz
Title: LAME 3.99 is out
Post by: yakuman on 2012-03-01 23:30:21
32-bit foobar2000 uses lame.exe. Can I take 64-bit build?

See how confused I am?

Unfortunately, those players do not come in 64-bit form to bring me peace.

I've been there too.  foobar2000 can encode with 64-bit LAME.  This is what I've been doing ever since I recently discovered the 64-bit version.  I don't know if there's any quality or size difference in the result of MP3 files, though.
Title: LAME 3.99 is out
Post by: Fishman0919 on 2012-03-02 16:42:24
I'm getting an error when trying to compile with "nmake -f Makefile.MSVC MSVCVER=8.0 PREC=DOUBLE"

Code: [Select]
Setting environment for using Microsoft Visual Studio 2010 x86 tools.

C:\Program Files\Microsoft Visual Studio 10.0\VC>cd lame

C:\Program Files\Microsoft Visual Studio 10.0\VC\lame>nmake -f Makefile.MSVC MSV
CVER=8.0 PREC=DOUBLE

Microsoft ® Program Maintenance Utility Version 10.00.30319.01
Copyright © Microsoft Corporation.  All rights reserved.

----------------------------------------------------------------------
building LAME featuring RH
+ ASM
+ MMX
+ using MSVC 8.0 32-Bit Compiler
+ optimizing for Pentium II/III
----------------------------------------------------------------------
Pass GTK=YES to build the frame analyzer. (requires installed GTK)


--- LAME MP3 ENCODING LIBRARY UPTODATE ---


--- HIP DECODING LIBRARY UPTODATE ---


--=* .\output\libmp3lame-static.lib ready *=--


--- COMMON FRONTEND STUFF UPTODATE ---

Microsoft ® Windows ® Resource Compiler Version 6.1.7600.16385
Copyright © Microsoft Corporation.  All rights reserved.

libmp3lame-static.lib(psymodel.obj) : error LNK2001: unresolved external symbol
_static_assert_tab_mask_add_delta
.\output\lame.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 10.0\VC\BI
N\link.EXE"' : return code '0x460'
Stop.

C:\Program Files\Microsoft Visual Studio 10.0\VC\lame>
Title: LAME 3.99 is out
Post by: robert on 2012-03-02 20:23:27
You'll have to remove the /GL compiler option in Makefile.MSVC line 209.
The _static_assert_tab_mask_add_delta symbol is there to do some compile-time assertions, there should be no such symbol actually compiled into the object files. I don't know, why the linker thinks it should find such a thing, when using /GL for whole program optimization.

some variations on static asserts (http://www.pixelbeat.org/programming/gcc/static_assert.html)
Title: LAME 3.99 is out
Post by: ZinCh on 2012-03-02 20:32:58
Can someone post LAME 3.99.5 builds using MS VC 11 (beta) ?
Title: LAME 3.99 is out
Post by: Fishman0919 on 2012-03-03 04:21:11
You'll have to remove the /GL compiler option in Makefile.MSVC line 209.
The _static_assert_tab_mask_add_delta symbol is there to do some compile-time assertions, there should be no such symbol actually compiled into the object files. I don't know, why the linker thinks it should find such a thing, when using /GL for whole program optimization.

some variations on static asserts (http://www.pixelbeat.org/programming/gcc/static_assert.html)


Thank You
Title: LAME 3.99 is out
Post by: Kilu on 2012-03-09 14:13:04
Wonderful, wonderful.
Title: LAME 3.99 is out
Post by: alexz721 on 2012-03-24 03:03:55
Here you go:

http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4-64.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4-64.zip)

Hi, was wondering if you could re-up this as the link is dead.
Title: LAME 3.99 is out
Post by: john33 on 2012-03-24 18:54:30
Here you go:

http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4-64.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4-64.zip)

Hi, was wondering if you could re-up this as the link is dead.

And again: http://www.john1205.webspace.virginmedia.c...me3.98.4-64.zip (http://www.john1205.webspace.virginmedia.com/LAME/lame3.98.4-64.zip)

Title: LAME 3.99 is out
Post by: alexz721 on 2012-03-25 18:17:44
Here you go:

http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4-64.zip (http://homepage.ntlworld.com/jfe1205/LAME/lame3.98.4-64.zip)

Hi, was wondering if you could re-up this as the link is dead.

And again: http://www.john1205.webspace.virginmedia.c...me3.98.4-64.zip (http://www.john1205.webspace.virginmedia.com/LAME/lame3.98.4-64.zip)



Much thanks, sir.
Title: LAME 3.99 is out
Post by: vinnie97 on 2012-03-28 21:53:57
'Cuse the ignorance/possible forgetfulness (and I thought I'd previously heard that 4.0 was being developed concurrently with all these 3.x releases), but will there ever be a fanfare for 4.0 beta?  I realize some alphas have been released in the past 6 years...
Title: LAME 3.99 is out
Post by: john33 on 2012-03-28 22:07:57
'Cuse the ignorance/possible forgetfulness (and I thought I'd previously heard that 4.0 was being developed concurrently with all these 3.x releases), but will there ever be a fanfare for 4.0 beta?  I realize some alphas have been released in the past 6 years...

4.0 was the personal project of Takehiro who 'retired' from the scene several years ago, sadly. It was a total rewrite of the LAME project but, unfortunately, is never likely to see the light of day.
Title: LAME 3.99 is out
Post by: vinnie97 on 2012-03-28 22:47:08
Thanks!  Wow, that's a pity...what will become of LAME version numbering after 3.99 is exhausted?  Any roadmaps detailing the plan or will fine tuning likely continue into perpetuity of the current branch?
Title: LAME 3.99 is out
Post by: john33 on 2012-03-28 22:50:50
Thanks!  Wow, that's a pity...what will become of LAME version numbering after 3.99 is exhausted?  Any roadmaps detailing the plan or will fine tuning likely continue into perpetuity of the current branch?

3.100 already exists as an alpha.
Title: LAME 3.99 is out
Post by: JJZolx on 2012-03-28 22:52:43
I'm curious about how it got to 3.99. Surely there weren't 99 3.xx versions before this one.
Title: LAME 3.99 is out
Post by: vinnie97 on 2012-03-28 22:53:09
Thanks!  Wow, that's a pity...what will become of LAME version numbering after 3.99 is exhausted?  Any roadmaps detailing the plan or will fine tuning likely continue into perpetuity of the current branch?

3.100 already exists as an alpha.

Oh, sure enough, I see it at Rarewares down there at the bottom...apologies for the oversight.
Title: LAME 3.99 is out
Post by: rohangc on 2012-03-29 03:39:17
I've only encountered a similar behavior with programs that require a CPU with SSE2 support. (using an AthlonXP without SSE2)
Could that may be the case for this new release (LAME 3.99.4)?

You may be right. I just tried AMD Athlon XP 3200+ on Win 7 (32-bit). LAME 3.99.4 did not work when using the same foobar2000 settings that work fine with 3.99.3.

foobar2000 reported:

Conversion failed: The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters


I see the exact same behavior on my machine running Windows 7 64-bit and with an AMD Phenom II X6 processor (that does support SSE2 instructions). I see the crash on both LAME 3.99.4 and 3.99.5.

Can someone please tell me how I can resolve this issue?

Thanks!
Title: LAME 3.99 is out
Post by: john33 on 2012-03-29 08:46:25
I see the exact same behavior on my machine running Windows 7 64-bit and with an AMD Phenom II X6 processor (that does support SSE2 instructions). I see the crash on both LAME 3.99.4 and 3.99.5.

Can someone please tell me how I can resolve this issue?

Thanks!

3.99.5 (all versions) were built and tested on a Phenom II X6 1075T with Windows 7 Home Premium 64 bit. I just checked all versions and they run without issue. Also tested on an Intel i7 2600K/Win 7 Pro 64 bit and an Intel i7 920/Win 7 Pro 64 bit. 32 bit versions also tested on Win2k Pro.

Anyone else with any issues?
Title: LAME 3.99 is out
Post by: apodtele on 2012-03-29 14:37:49
You may be right. I just tried AMD Athlon XP 3200+ on Win 7 (32-bit). LAME 3.99.4 did not work when using the same foobar2000 settings that work fine with 3.99.3.

foobar2000 reported:

Conversion failed: The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters


Please post the parameters that cause the crash. That would be swell.
Title: LAME 3.99 is out
Post by: Alex B on 2012-03-30 19:52:46
I see the exact same behavior on my machine running Windows 7 64-bit and with an AMD Phenom II X6 processor (that does support SSE2 instructions). I see the crash on both LAME 3.99.4 and 3.99.5.
Please post the parameters that cause the crash. That would be swell.
3.99.5 fixed this problem for me. (on Athlon XP 3200+ / 32-bit Win 7)

I just retested 3.99.3, 3.99.4 and 3.99.5. Here are the foobar2000 console logs:

3.99.3
Code: [Select]
CLI encoder: C:\Soft\Lame\3993\lame.exe
Destination file: F:\Rip\Jam & Spoon\1997 - Kaleidoscope\02 - Kaleidoscope Skies.mp3
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Soft\Lame\3993\lame.exe" -S --noreplaygain -V 1 - "02 - Kaleidoscope Skies.mp3"
Working folder: F:\Rip\Jam & Spoon\1997 - Kaleidoscope\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Track converted successfully.
Total encoding time: 0:16.125, 12.85x realtime
3.99.4
Code: [Select]
CLI encoder: C:\Soft\Lame\3994\lame.exe
Destination file: F:\Rip\Jam & Spoon\1997 - Kaleidoscope\02 - Kaleidoscope Skies.mp3
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Soft\Lame\3994\lame.exe" -S --noreplaygain -V 1 - "02 - Kaleidoscope Skies.mp3"
Working folder: F:\Rip\Jam & Spoon\1997 - Kaleidoscope\
An error occurred while writing to file (The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters) : "F:\Rip\Jam & Spoon\1997 - Kaleidoscope\02 - Kaleidoscope Skies.mp3"
Additional information:
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Soft\Lame\3994\lame.exe" -S --noreplaygain -V 1 - "02 - Kaleidoscope Skies.mp3"
Working folder: F:\Rip\Jam & Spoon\1997 - Kaleidoscope\
Conversion failed: The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters
could not enumerate tracks (Object not found) on:
F:\Rip\Jam & Spoon\1997 - Kaleidoscope\02 - Kaleidoscope Skies.mp3
Total encoding time: 0:08.657, 0.04x realtime
3.99.5
Code: [Select]
CLI encoder: C:\Soft\Lame\3995\lame.exe
Destination file: F:\Rip\Jam & Spoon\1997 - Kaleidoscope\02 - Kaleidoscope Skies.mp3
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Soft\Lame\3995\lame.exe" -S --noreplaygain -V 1 - "02 - Kaleidoscope Skies.mp3"
Working folder: F:\Rip\Jam & Spoon\1997 - Kaleidoscope\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Track converted successfully.
Total encoding time: 0:16.484, 12.57x realtime
Title: LAME 3.99 is out
Post by: alter4 on 2012-03-31 14:34:13
Hi Guys!
I encoded the same file with lame 3.99.5 using -V0 and -b320.
There are a few questions here.
-V0
Code: [Select]
LAME 3.99.5 64bits (http://lame.sf.net)
CPU features: SSE (ASM used), SSE2 (ASM used)
polyphase lowpass filter disabled
Encoding 1.wav to 1.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=0)

misc:

scaling: 1
ch0 (left) scaling: 1
ch1 (right) scaling: 1
huffman search: best (outside loop)
experimental Y=0
...

stream format:

MPEG-1 Layer 3
2 channel - joint stereo
padding: all
variable bitrate - VBR mtrh (default)
using LAME Tag
...

psychoacoustic:

using short blocks: channel coupled
subblock gain: 1
adjust masking: -6.8 dB
adjust masking short: -6.8 dB
quantization comparison: 9
^ comparison short blocks: 9
noise shaping: 1
^ amplification: 2
^ stopping: 1
ATH: using
^ type: 5
^ shape: 1 (only for type 4)
^ level adjustement: -7.1 dB
^ adjust type: 3
^ adjust sensitivity power: 1.000000
experimental psy tunings by Naoki Shibata
  adjust masking bass=-0.5 dB, alto=-0.25 dB, treble=-0.025 dB, sfb21=8.25 dB
using temporal masking effect: no
interchannel masking ratio: 0
...
-b320
Code: [Select]
LAME 3.99.5 64bits (http://lame.sf.net)
CPU features: SSE (ASM used), SSE2 (ASM used)
Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz
Encoding 1.wav to 1.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (4.4x) 320 kbps qval=3

misc:

scaling: 1
ch0 (left) scaling: 1
ch1 (right) scaling: 1
huffman search: best (outside loop)
experimental Y=0
...

stream format:

MPEG-1 Layer 3
2 channel - joint stereo
padding: off
constant bitrate - CBR
using LAME Tag
...

psychoacoustic:

using short blocks: channel coupled
subblock gain: 1
adjust masking: -10 dB
adjust masking short: -11 dB
quantization comparison: 9
^ comparison short blocks: 9
noise shaping: 1
^ amplification: 1
^ stopping: 1
ATH: using
^ type: 4
^ shape: 0 (only for type 4)
^ level adjustement: -12 dB
^ adjust type: 3
^ adjust sensitivity power: 1.000000
experimental psy tunings by Naoki Shibata
  adjust masking bass=-0.5 dB, alto=-0.25 dB, treble=-0.025 dB, sfb21=0.5 dB
using temporal masking effect: yes
interchannel masking ratio: 0
...

-b320 on HA wiki considered as "best quality settings", but what is my concern
1) -V0 doesn't use polyphase lowpass filter but -b320 does
2) q value is 0 for V0 but q=3 for -b320
3) ATH setting looks more cautious for V0.

Is -b320 always best in compare with -V0? I am not sure looking into this dump or may be I miss something?


Title: LAME 3.99 is out
Post by: [JAZ] on 2012-03-31 16:41:15
First, don't try to see more than what it is in there anyway.

the "q" you see next to the VBR text is the VBR range (-V0 = q0). The "q" you see in CBR is really the "-q" setting, which defaults to q3 in both VBR and CBR. In VBR there is no difference from q 3 to q 0. in CBR, there is a difference, but lower than q 3 just controls how strong it tries to encode, which may or may not give a better quality (I mean it literally).

Next, not using a filter, with the MP3 format never means a better file. (It does not necessarily mean a worse file either).

I am not knowledgeable enough to give my oppinion on the values relative to the ATH (Things are only comparable when they use the same algorithm, and here there are clearly different options)

Now, VBR vs CBR:

The 3.99.x versions have had tweakings on both, the CBR and VBR modes. CBR is using some tools from VBR, and the higher VBR levels (like V0) have been made stronger (using more bitrate).

The general consensus is still he one mentioned, (by definition, VBR can only use up to 320kbps anyway) but the different ways to pack those 320kbps might give one or the other an edge. I guess only user tests and information from the developers can answer that, but it can not change drastically.
Title: LAME 3.99 is out
Post by: ggunnell on 2012-04-07 17:36:43
Are there other download sites for compiled Lame 3.99.5 other than Rarewares?  My Norton 2012 is currently blocking Rarewares downloads, reporting w32.leave.worm and fake AV redirect 31.
Title: LAME 3.99 is out
Post by: tpijag on 2012-04-07 18:23:30
That is a false positive. Either ignore or you could use these Google search on "compiled lame 3.99.5" (https://www.google.com/search?rlz=1C1GGLS_en-USUS291US302&sourceid=chrome&ie=UTF-8&q=compiled+Lame+3.99.5)
Title: LAME 3.99 is out
Post by: lvqcl on 2012-04-07 18:26:04
Link from previous page: http://www.john1205.webspace.virginmedia.com/LAME/ (http://www.john1205.webspace.virginmedia.com/LAME/)
Title: LAME 3.99 is out
Post by: Thundik81 on 2012-04-07 19:07:16
Are there other download sites for compiled Lame 3.99.5 other than Rarewares?  My Norton 2012 is currently blocking Rarewares downloads, reporting w32.leave.worm and fake AV redirect 31.


Few bad links remains on Rarewares :
http://www.rarewares.org/files/ogg/angelineoconnor.php (http://www.rarewares.org/files/ogg/angelineoconnor.php)
http://www.rarewares.org/files/mp3/galoiscepheus.php (http://www.rarewares.org/files/mp3/galoiscepheus.php)
Title: LAME 3.99 is out
Post by: ggunnell on 2012-04-07 22:49:40
Link from previous page: http://www.john1205.webspace.virginmedia.com/LAME/ (http://www.john1205.webspace.virginmedia.com/LAME/)

Thanks -- got it!
It may be a false positive, but clicking on the Rarewares download link for 3.99.5 64-bit bundle triggered the anti-intrusion on my firewall -- something I have learned the hard way not to bypass.
Title: LAME 3.99 is out
Post by: john33 on 2012-04-08 09:34:55
I'm not home right now, but can those who have had a problem accessing Rarewares confirm whether they were using IE? Other browsers do not exhibit the same problem, or so I have thought from one previous notification.
Title: LAME 3.99 is out
Post by: Ferongr on 2012-05-10 19:34:24
Hey John, is the lame_enc.dll build that uses an .ini file for the settings built using your own patches? Is it possible to update it to the latest release?

BTW, I'm using this version successfully with SAM Broadcaster to stream 200kbps ABR audio through Shoutcast DNAS V1. The reason 192kbps CBR was not transparent was because of many transcoding artifacts from lossy originals, especially extreme smearing of high frequencies at certain tracks. Using ABR at 200kbps reduced the artifacts dramatically.
Title: LAME 3.99 is out
Post by: john33 on 2012-05-10 19:38:47
Hey John, is the lame_enc.dll build that uses an .ini file for the settings built using your own patches? Is it possible to update it to the latest release?

BTW, I'm using this version successfully with SAM Broadcaster to stream 200kbps ABR audio through Shoutcast DNAS V1. The reason 192kbps CBR was not transparent was because of many transcoding artifacts from lossy originals, especially extreme smearing of high frequencies at certain tracks. Using ABR at 200kbps reduced the artifacts dramatically.

I'll try to get this done this evening.  I'll post again when it's available.
Title: LAME 3.99 is out
Post by: john33 on 2012-05-10 21:26:13
New build - 3.99.5 - of the modified dll is now at Rarewares.
Title: LAME 3.99 is out
Post by: Ferongr on 2012-05-10 22:13:57
New build - 3.99.5 - of the modified dll is now at Rarewares.


Excellent. Thank you very much!

Edit: Just a small question: Per LAME documentation, the "q" switch accepts values from 0 to 9, yet in the bundled .ini it's set at -1. Does that set it to use the default (5?) setting?
Title: LAME 3.99 is out
Post by: john33 on 2012-05-10 22:25:10
New build - 3.99.5 - of the modified dll is now at Rarewares.


Excellent. Thank you very much!

Edit: Just a small question: Per LAME documentation, the "q" switch accepts values from 0 to 9, yet in the bundled .ini it's set at -1. Does that set it to use the default (5?) setting?

When set to '-1', it uses whatever is the default value for the Lame Preset selected.
Title: LAME 3.99 is out
Post by: Emiliano55 on 2012-05-27 00:14:29
Guys, I have just upgraded to a 64bit Windows (i've always used 32bits systems). Do you guys recommend me to use the 64bit version of this new Lame, or should I still be using the 32bit version even though I'm on a x64 Windows now ?

What are the differences between both on a x64 Windows platform ?

Thanks!
Title: LAME 3.99 is out
Post by: antman on 2012-05-27 20:54:06
Speed.  Use x64 and shave some time off your transcoding.
Title: LAME 3.99 is out
Post by: Emiliano55 on 2012-05-28 00:48:43
Thanks! If speed is the only difference then I will use the x64. I asked that because i noticed many people are still using the 32bit version... I guess I will have to assume they all have 32bit systems ?
Title: LAME 3.99 is out
Post by: rohangc on 2012-05-30 03:55:35
I see the exact same behavior on my machine running Windows 7 64-bit and with an AMD Phenom II X6 processor (that does support SSE2 instructions). I see the crash on both LAME 3.99.4 and 3.99.5.

Please post the parameters that cause the crash. That would be swell.

3.99.5 fixed this problem for me. (on Athlon XP 3200+ / 32-bit Win 7)


Hi Alex. I confirm that 3.99.5 has fixed the problem on my machine too (I upgraded Foobar2000 to 1.1.12a for good measure).
Last night I transcoded all my FLAC files using LAME 3.99.5 and all went well without any hitches.

Thanks!
Title: LAME 3.99 is out
Post by: IgorC on 2012-09-29 21:44:05
Some speed test for  LAME 3.99.5 V 5 on Atom N2600 (http://ark.intel.com/products/58916/Intel-Atom-Processor-N2600-1M-Cache-1_6-GHz).

foobar converter (5 threads)

rarewares'es build - 21.5x
gcc 4.6/MinGW build - 30.3x http://tmkk.pv.land.to/lame/index_e.html (http://tmkk.pv.land.to/lame/index_e.html)


AFAIK Atom CPU is a paticular case. Some binaries might actually run slower on it.
Wonder if there are any optimized binaries for Atom. Still pretty impressed with 30x speed for this little monster with TDP just 3.5 Watts. 
Title: LAME 3.99 is out
Post by: eahm on 2012-09-29 22:14:38
30x is impressive for the Atom!

i7-2700k (http://ark.intel.com/products/61275/Intel-Core-i7-2700K-Processor-8M-Cache-up-to-3_90-GHz)
RareWares: 252.63x
gcc 4.6/MinGW compiled binary for Windows: 271.76x
Title: LAME 3.99 is out
Post by: NewQuestions on 2012-10-05 14:16:31
Important diff. between lame3.98.4.exe and lame3.99.5.exe: "unrecognized option --ns-treble" - The automation in arts reduces quality and the possibility to create new things
Title: LAME 3.99 is out
Post by: ManekiNeko on 2013-04-16 02:47:40
30x is impressive for the Atom!

i7-2700k (http://ark.intel.com/products/61275/Intel-Core-i7-2700K-Processor-8M-Cache-up-to-3_90-GHz)
RareWares: 252.63x
gcc 4.6/MinGW compiled binary for Windows: 271.76x


I just tested that build (64 bit version). Damn, that's fast! (Core i5 2500k). To your knowledge, is it the fastest encoding lame 3.99.5 build?

Also, the page states: "64-bit version is not verified to work". I've only tested a few albums which worked fine and the mp3 files seem identical to the ones encoded with the  rarewares x64 build. Have you experienced any issues with it?