Skip to main content ↑ ↓

Notice

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

LAME 3.98 Final

Reply #100 –
@Bad Monkey

Using Visual C++ Express Edition with the Microsoft Platform SDK

Nmake is one of the executables in PSDK bin directory.

To setup build environment from the command line, call the batch files vcvarsall.bat from Visual Studio and SetEnv.cmd from PSDK. They will set PATH, INCLUDE and LIB environment variables for you.

LAME 3.98 Final

Reply #101 –
Quote from: Wombat on
Cool thing! Finaly
Waiting for the first complaints about inreased bitrate at V2. My noise samples seem fine but higher in bitrate than older 3.98 betas i tested. Much higher than 3.97 for sure.


See if the lowpass filter is filtering higher frequencies than before. This may be one of the reasons for the bitrate inflation.

I for one, am perfectly happy with lame 3.98 and "-V 5" (or even lower than that, as I already mentioned that I can't abx "--resample 44100 -V 7" from the original). I guess that I don't have the golden ears that you guys have.

I'm using the misc/abx tool that I fixed. Oh, and I started committing some cosmetic changes to the repository. In particular, I will take care of some of the expopt=full things, but I don't have access to a MacOS X running Leopard.

My iBook G3 (yes, G3) can only run MacOS X Tiger and I'm switching to Debian (goodbye, Apple) as soon as I can finally debug the rt2500usb driver for PowerPC.


Regards, Rogério Brito.

P.S.: I don't know if this is still the case, or if I am dreaming, but if I pass "--resample 44100" to a "-V 7" encoding process, then the lowpass filter allows higher frequencies to be encoded... I will have to check our sources.

LAME 3.98 Final

Reply #102 –
Quote from: john33 on
Quote from: Jebus on

Quote from: Canar on
My congratulations to the LAME team on another awesome release!

I suppose now we're just one update away from 4.0? Or will the LAME team be humorous and release 3.100 instead? Find out next time on Hydrogenaudio!



I don't believe there is much (if any) activity on 4.0 anymore... at least there wasn't the last time I checked.

There's been no activity for about 2 and a half years. I imagine Takehiro's life has gone in a different direction.


Indeed, it seems that the development will be on the 3.x front for some time. But who cares? Version numbers are not decimal numbers (or numbers in any other base  ) in general, at least. 

Anyway, we haven't seen messages from Takehiro for the past 6 months or so. A pity, since I planned on doing things with him (as he is a Debian user like me).

And doing a benchmark regarding his hack (like the guy from Intel asked us) on other platforms than Windows would be a good thing... I think that I will have to make things systematic here with many compilations and GCC options.

(BTW, if any Debian/Ubuntu user feels that lame should be a bit faster and you have a recent CPU, I would recommend that you base your own compilations on the switches that I've put on Makefile.unix from the recent CVS trunk---it will quite possibly have some improvements related to what you get if you compile with expopt=full).

Oh, you should have GCC 4.3, as we were discussing on lame-dev that versions from Red Hat may not work correctly with the -ffast-math switch (Robert found a funny case of miscompilation).

Regards, Rogério Brito.


Quote from: krmathis on
Great news!
Lame 3.98 for Mac OS X (universal binary) available on my website.


How did you compile it? With the macosx directory present on the sources? I guess that some ia32 code could be improved, depending on the options you've used.

Regards, Rogério Brito.

P.S.: I have not checked your .dmg file since I am on Ubuntu, but do you provide dynamic libraries also? It would be a good thing for those that use audacity to export their files...

Quote from: .halverhahn on
Free Beer for all developers!     


A used/old (traditional, not extreme) Apple Airport card for G3 iBooks would be much appreciated.  I have problems drinking and coding.


Regards, Rogério Brito.

P.S.: Actually, I'm moderately serious here: if anybody in the US or Europe can get one such a card and send me as a "gift" (so that I don't have problems with customs, like I did for ordering a US$9 "The Gathering" DVD from amazon, when I ordered books on Abstract Algebra), I would be quite grateful.

We can see how I can pay back for the card and shipping (most probably, places like Otherworld computing or www.smalldog.com would have such a card).

LAME 3.98 Final

Reply #103 –
Quote from: rbrito on
How did you compile it? With the macosx directory present on the sources? I guess that some ia32 code could be improved, depending on the options you've used.

Regards, Rogério Brito.

P.S.: I have not checked your .dmg file since I am on Ubuntu, but do you provide dynamic libraries also? It would be a good thing for those that use audacity to export their files...

I (cross)compiled static binaries in three stages (one for each architecture), which I later merged to one universal binary with 'lipo'.
Just a plain "./configure [flags here] && make" in the source directory. No magic...

Would be interested in improvements which would make it more effective. 

Edit: Think I used GCC 4.2.1. Have GCC 4.0.1 installed as well, hence why I am not 100% sure.

LAME 3.98 Final

Reply #104 –
Quote from: k.eight.a on
Quote from: garym on

What' the difference between using the "LAME 3.98 using libsndfile 1.0.17" versus the other bundle of LAME 3.98.  I don't recall this option before. I simply use LAME encoder as called by EAC or fb2k. Thanks for any insight on this.
I'd love to know it either. 

Anyway many thanks to the developers for the new version and a step forward.


libsndfile allows lame to take much more input formats than "bare" lame.

Version 1 of the library (as opposed to version 0, which was available earlier, in lame 3.97 and previous versions) still allow one to grab input from the standard input, while allowing one to take a FLAC file directly as input (just to name one popular format that I know that works) and (this one is particularly important to me, since I record my classes) to take "wav" audio in IMA ADPCM (like those generated by the very popular S1MP3 recorders/players), all without many gymnastics.

The libsndfile1 ability of lame came directly from Erik de Castro Lopo's (the upstream author of libsndfile). That is, from the horse's mouth.

Hope this clarifies a bit, Rogério Brito.

LAME 3.98 Final

Reply #105 –
Quote from: krmathis on
Quote from: rbrito on
How did you compile it? With the macosx directory present on the sources? I guess that some ia32 code could be improved, depending on the options you've used.

Regards, Rogério Brito.

P.S.: I have not checked your .dmg file since I am on Ubuntu, but do you provide dynamic libraries also? It would be a good thing for those that use audacity to export their files...

I (cross)compiled static binaries in three stages (one for each architecture), which I later merged to one universal binary with 'lipo'.
Just a plain "./configure [flags here] && make" in the source directory. No magic...

Would be interested in improvements which would make it more effective. 

Edit: Think I used GCC 4.2.1. Have GCC 4.0.1 installed as well, hence why I am not 100% sure.


Apple ships their own "instrumented" GCC 4.0.1, which makes it hard to detect the features based on the version alone (grrr...). Anyway, you could try to compile things with (Apple's) options --arch, like "--arch powerpc --arch i386 --arch ppc64". Pass it, in the configure step, as:

CFLAGS="--arch powerpc --arch i386 --arch ppc64" ./configure && make

It should work. If not, please, file a bugreport on our tracker. But using "lipo" is fine also. Just thought you would like to know about an easier method.

You might want to see what I posted here: My (outdated) diary/blog.

Anyway, it would be worth it to grab the sources from the FSF of GCC 4.3.1 (and of two libraries that are required now) to benefit from some newer features and fixes. Just enable C, if you have a slow machine or if you are impatient.

BTW, I've been crosscompiling kernels for PowerPC with a x86-64 machine, generating a .deb package and everything with a similar recipe.


Regards, Rogério Brito.

LAME 3.98 Final

Reply #106 –
Quote from: IgorC on
Quote from: DARcode on

I've surely missed something in the MP3 forums, but what's the reason behind Gabriel's limited involvement with this release please?

He's doing well on x264 project.


Ah, this explains why he mentioned lately that there was a lack of manpower in the lame project (citing that once that the core people working on lame hasn't changed in the last 8--10 years, with Robert doing a lot of work), while he mentioned that some people were getting paid on other Open Source projects like x264... Hummm...

But, actually, he is correct. Lame is next to its limits (Robert can prove me wrong here  ), as I see it, while other progeny from the newer MPEG specifications should be improved. And his work on x264 is greatly appreciated (actually, the projects developed/communicated/hosted at mplayerhq.hu are so welcome that I can't even start thanking them). One has got to love the ffmpeg project, for instance.

Regards, Rogério Brito.

LAME 3.98 Final

Reply #107 –
Quote from: Synthetic Soul on
This option was present with 3.97 also (and presumably previous versions).  Lame with libsndfile allows you to encode from numerous additional formats, including AIFF, SND, VOC, and FLAC.  Check the site for the full list.


Yes, but it only had libsndfile0, while, now, lame has support for libsndfile1, which includes flac files and IMA ADPCM files to be used as input.

The patch was sent by Erik himself about the time of lame 3.98 beta 1, according to our changelog.

Regards, Rogério Brito.

LAME 3.98 Final

Reply #108 –
Quote from: Rain on
BTW, I'm not sure if anyone's noticed but many of the pages on the official LAME sourceforge website are not valid XHTML 1.0 Transitional.


The changelog is valid HTML 4.01 Transitional, soon to be XHTML 1.0 Transitional.


Regards, Rogério.

LAME 3.98 Final

Reply #109 –
Quote from: rbrito on
Apple ships their own "instrumented" GCC 4.0.1, which makes it hard to detect the features based on the version alone (grrr...). Anyway, you could try to compile things with (Apple's) options --arch, like "--arch powerpc --arch i386 --arch ppc64". Pass it, in the configure step, as:

CFLAGS="--arch powerpc --arch i386 --arch ppc64" ./configure && make

It should work. If not, please, file a bugreport on our tracker. But using "lipo" is fine also. Just thought you would like to know about an easier method.

Thats basically what I did. Add "--arch powerpc" etc. But one architecture at a time, since I had to cross-compile and thought that were the only way. Works like a treat, so guess I stick with it. After all it end up identical...

Quote
You might want to see what I posted here: My (outdated) diary/blog
Will head over to take a look.

Quote
Anyway, it would be worth it to grab the sources from the FSF of GCC 4.3.1 (and of two libraries that are required now) to benefit from some newer features and fixes. Just enable C, if you have a slow machine or if you are impatient.

BTW, I've been crosscompiling kernels for PowerPC with a x86-64 machine, generating a .deb package and everything with a similar recipe.


Regards, Rogério Brito.
Well, I just installed Xcode 3.1 today. With two compilers installed already I stay clear of installing a third one. Its a shame that Apple lay so far behind with their GCC version, but guess they have their reason...

LAME 3.98 Final

Reply #110 –
Quote from: robert on
@Bad Monkey

Using Visual C++ Express Edition with the Microsoft Platform SDK

Nmake is one of the executables in PSDK bin directory.

To setup build environment from the command line, call the batch files vcvarsall.bat from Visual Studio and SetEnv.cmd from PSDK. They will set PATH, INCLUDE and LIB environment variables for you.

Thanks Robert, that got me along a bit. It's built some libraries, but now failed with an error along the lines of x86 when x64 is needed.

Backing up a bit, in my VC/bin/ dir, there is only a "vcvars32.bat". Running "vcvarsall.bat x64" (as I understand I need to) fails, configuration data unavailable. None of the 64-bit bats exist.
A bit of a look later, and I see this: http://msdn.microsoft.com/en-us/library/hs24szh9.aspx
Does this mean VS Express is incompatible with ICL 64-bit?
Or am I doing something stupid again.

LAME 3.98 Final

Reply #111 –
Quote from: rbrito on
(BTW, if any Debian/Ubuntu user feels that lame should be a bit faster and you have a recent CPU, I would recommend that you base your own compilations on the switches that I've put on Makefile.unix from the recent CVS trunk---it will quite possibly have some improvements related to what you get if you compile with expopt=full).

I took a look at the version in the CVS Head (dated 12 July) and have a couple of comments for you:
Quote
135 # Suggested for GCC 4.* & machines with sse+sse2+sse3: -Os might reduce
  136 # the use of the instruction cache and, thus, get better performance,
  137 # but this should be experimented by the user. Customize at your own
  138 # convenience.
  139 #
  140 #CC_OPTS = -pipe -O3 \
  141 #   -Wall -Wextra -pedantic \
  142 #   -Wmissing-declarations -Wfloat-equal -Wshadow \
  143 #   -Wcast-qual -Wcast-align -Wdisabled-optimization \
  144 #   -ffast-math -ftree-vectorize -ftree-vect-loop-version \
  145 #   -mtune=nocona -march=nocona -mfpmath=sse -msse -msse2 -msse3 \
  146 #   -malign-double -maccumulate-outgoing-args


-ftree-vectorize-version is the default, and might or might not make faster code. It makes some of my code slower, but I couldn't get a significant result either way with LAME.
-mtune=nocona is not needed because -march= implies -mtune
-march=nocona could probably be replaced with -march=native, which would be better for a wider range of people

On x86_64 you can drop -malign-double and -mfpmath=sse because these are default.

Thanks again for the development effort, and good luck with future releases.

LAME 3.98 Final

Reply #113 –
Quote from: niask on
Quote from: twostar on
Thanks so much to the LAME devs!

Maybe it's time to update the recommended version here at HA as well.
Yeah, why in the Hydrogenaudio Knowledgebase the currently recommended LAME version is still 3.97?


Because we should verify first that 3.98 is superior generally and shows no serious regressions over 3.97. What use is the recommendation if it always just indicates the latest stable version? I don't doubt the ability of the devs here, but everyones ears are different, and testing the new recommended version and settings against the old ones in a public listening test is important to ensure it really sounds better for most people.

LAME 3.98 Final

Reply #114 –
Quote from: niask on
Quote from: twostar on
Thanks so much to the LAME devs!

Maybe it's time to update the recommended version here at HA as well.
Yeah, why in the Hydrogenaudio Knowledgebase the currently recommended LAME version is still 3.97?


Lame 3.97 is still the recommended version as 3.98 hasn't been through any public listening tests (or multiple individual tests).  People are setting up a public listening test right now.  They have narrowed down the list of encoders and settings to use (mainly 128kbps VBR with a variety of mp3 encoders including Lame 3.98) and are now working on the samples that will be used.

Edit: MedO beat me to it.

LAME 3.98 Final

Reply #115 –
I remember this discussion when 3.97 was new...

3.98 should be Hydrogenaudio's new recommended MP3 encoder. Every "stable" version should be automatically recommended. Why? Over two years there were many beta versions... all of which were (or at least should have been) tested for improvement and/or regression. A listening test now is nothing more than just a formality. I don't believe that 3.98 would turn out worse than 3.97... and if it did, it could mean just two things: either the developers didn't do a good job (which is of course extremely unlikely), or the community feedback wasn't good enough in those two years in which case any "Hydrogenaudio recommendation" would lose its authority completely.

LAME 3.98 Final

Reply #116 –
Quote from: Raiden on
I remember this discussion when 3.97 was new...

3.98 should be Hydrogenaudio's new recommended MP3 encoder. Every "stable" version should be automatically recommended. Why? Over two years there were many beta versions... all of which were (or at least should have been) tested for improvement and/or regression. A listening test now is nothing more than just a formality. I don't believe that 3.98 would turn out worse than 3.97... and if it did, it could mean just two things: either the developers didn't do a good job (which is of course extremely unlikely), or the community feedback wasn't good enough in those two years in which case any "Hydrogenaudio recommendation" would lose its authority completely.

While the public listening tests are useful, on balance, I have to agree with Raiden. It is certainly true to say that considerable testing has been done via this board over the development period. The 'golden ears' have already done their job!

LAME 3.98 Final

Reply #117 –
Quote from: Raiden on
... 3.98 should be Hydrogenaudio's new recommended MP3 encoder. Every "stable" version should be automatically recommended. ...

I totally agree, but in the end this means that there's no use in recommending a Lame version. The latest verison always is considered best. We never know something for sure, especially as we can't have encoder experience with the universe of music, but as long as there's no experience of serious regression (which hopefully would trigger further Lame improvement) just using the latest version is the most promising strategy.
lame3995o -Q1.7 --lowpass 17

LAME 3.98 Final

Reply #118 –
For me, i use 3.98 betas since beta 3 if i´m right. From there on the added noise i disliked from version 3.97 was much improved or gone at high bitrate V values.
One thing is that most 3.98 testing i read over here was done at relative high bitrates. I don´t know how 3.98 behaves on low bitrates. This may be the main unknown atm.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

LAME 3.98 Final

Reply #119 –
maybe it is time for some changes
a. i wouldn't recommend any particular version
b. just update the thread with recommended usage command line(s)/switches when there is a decently different/newer version out there
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

LAME 3.98 Final

Reply #120 –
I found a track that LAME 3.98 seems to perform better then 3.97 at V2.

Code: [Select]
foo_abx 1.3.3 report
foobar2000 v0.9.5.4
2008/07/17 11:22:55

File A: C:\Temp\2 Run To The Hills.wav
File B: C:\Music\Albums\Iron Maiden - The Number Of The Beast\06. Run To The Hills.mp3

11:22:55 : Test started.
11:23:45 : 01/01  50.0%
11:23:50 : 02/02  25.0%
11:23:59 : 03/03  12.5%
11:24:49 : 03/04  31.3%
11:25:15 : 04/05  18.8%
11:25:20 : 05/06  10.9%
11:25:26 : 06/07  6.3%
11:25:36 : 07/08  3.5%
11:25:45 : 08/09  2.0%
11:25:57 : 09/10  1.1%
11:26:29 : 10/11  0.6%
11:26:48 : 11/12  0.3%
11:27:07 : 12/13  0.2%
11:27:19 : 13/14  0.1%
11:27:37 : Test finished.

 ---------- 
Total: 13/14 (0.1%)

At around 0:47 - 0:48, there is a nasty smear on the drums. The track's bitrate is at 237kbps and its still not transparent, and my V0 encode was at 293 and managed to get a 8/10.

I have tested it on 3.98 at V2 (7/10), but sometimes I could hear a "psst" (precho) sound at the same area, but it was harder to notice unlike the 3.97 encode. The bitrate on the 3.98 encode was a tad lower at 234kbps (-3).

This track is a bad example of the sfb21 issue, such as being bloated and not transparent, and one of the main reasons I do not use V0.
"I never thought I'd see this much candy in one mission!"

LAME 3.98 Final

Reply #122 –
Hi
Could someone advise whether to get the very best mp3 quality I should be using -b 320 or v0 with Lame 3.98. Storage space is not an issue for me so the increased file size with CBR is fine, but I want the best quality.

TIA

LAME 3.98 Final

Reply #123 –
Quote from: gsa999 on
Could someone advise whether to get the very best mp3 quality I should be using -b 320 or v0 with Lame 3.98. Storage space is not an issue for me so the increased file size with CBR is fine, but I want the best quality.
If space is not an issue, I would recommend going with lossless (FLAC, or similar). That way you can be sure you have no audible artifacts, and you can transcode (for an iPod, for example) at will. I'm not an MP3 hater, but lossy compression only makes sense in situations where space is an issue. Do you have any reason to prefer very large MP3s to lossless?

LAME 3.98 Final

Reply #124 –
Quote from: smok3 on
maybe it is time for some changes
a. i wouldn't recommend any particular version
b. just update the thread with recommended usage command line(s)/switches when there is a decently different/newer version out there

Why not use a blacklist instead of a whitelist? That is, do not "recommend" a specific version, but instead "unrecommend" significantly suboptimal verions.
I am arrogant and I can afford it because I deliver.