After 2 years of development and 8 beta versions LAME 3.98 has been released. Highlights from changelog:
- LAME now has its own psy model, a derivation from NSPSY
- LAME now accepts a floating point value in the range [0,...,10[ as VBR quality setting, like -V5.678
- Ability to set user-defined ID3v2.3 frame and include albumArt in ID3v2.3 tag
- The newer VBR code is now LAME's default VBR routine
More - changelog (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html)
Source - lame-398.tar.gz (http://downloads.sourceforge.net/lame/lame-398.tar.gz)
Website - www.mp3dev.org (http://lame.sourceforge.net/)
Binaries - windows (http://www.rarewares.org/mp3-lame-bundle.php), debian (http://debian-multimedia.org/pool/main/l/lame/), osx (http://homepage.mac.com/krmathis/)
Great news!
Lame 3.98 for Mac OS X (universal binary) available on my website (http://homepage.mac.com/krmathis/).
Thank you.
Great news!
Lame 3.98 for Mac OS X (universal binary) available on my website (http://homepage.mac.com/krmathis/).
Uploaded to Rarewares.
- LAME now accepts a floating point value in the range [0,...,10] as VBR quality setting, like -V5.678
To what end?
*cheers*
- LAME now accepts a floating point value in the range [0,...,10] as VBR quality setting, like -V5.678
To what end?
Whatever end you want
Some spelling/grammar fixed, pm me if I miss something
Oops... "LAME 3.98 using libsndfile 1.0.17" @rarewares -- invalid link:
http://www.rarewares.org/files/mp3/lame3.98b8-libsndfile.zip
Oops... "LAME 3.98 using libsndfile 1.0.17" @rarewares -- invalid link:
http://www.rarewares.org/files/mp3/lame3.98b8-libsndfile.zip
Fixed, thanks!
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!
Free Beer for all developers!
Thankyou SO much!
Cheers, Slipstreem.
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.
Thanks so much to the LAME devs!
Maybe it's time to update the recommended version here at HA as well.
Out of curiosity, are floating point V settings stored in the lame header, or just the integer part?
Out of curiosity, are floating point V settings stored in the lame header, or just the integer part?
From what I could tell looking at the code, it isn't stored in the header, but can be inferred from the lowpass value. I don't know if it can be inferred reliably though, and I'm not even sure if the integer value is reliable now due to the fact that it just truncates the floating point number (making -V2.999 have an integer value of 2).
I asked about this in another thread but didn't get a reply. I'd really like to know as well, so I can update Dnuos.
Just great.
Thank you
Thanks to all the developers!
Also krmathis's OSX port, when will LAMEdrop have OSX version ?
- LAME now accepts a floating point value in the range [0,...,10] as VBR quality setting, like -V5.678
One tiny correction: valid range is [0 ... 10[ . That is, it excludes 10 from the range.
(exact range is [0 ... 9.999] )
My thanks to the LAME developers for their hard work and effort.
Excellent!
Thank you for all the hard work and improvements made.
Congrats and thanks to all involved. You truely ROCK!!
Many thanks - I use LAME quite a lot and love it.
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.
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.
Many thanks an excellent new build devs, appreciated!
I've surely missed something in the MP3 forums, but what's the reason behind Gabriel's limited involvement with this release please?
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.
V5 as well. Now it isn't anymore 130-135 kbits but more close to 140 and higher.
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.
I made a fast ABC/HR test 3.97 vs 3.98 V5
I was enough compulsive but lame 3.97 benefits in most of the case. I don't pretend to anything. It is only personal and fast test.
(http://img387.imageshack.us/img387/4716/397vs398fo7.png)
Some observations:
3.98 has only 1 sample with score lower than 4.0 while 3.97 has 5 of such samples. 3.98 has more constant quality (less desviation)
There was some audible issue with 3.98 aplaud sample while 3.97 makes it better. http://ff123.net/samples/applaud00.flac (http://ff123.net/samples/applaud00.flac)
do you use --vbr-new with lame 3.97 or the old vbr mode ?
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.
Thanks LAME guys, will do some testing tonight, after I watch DR Who of course
do you use --vbr-new with lame 3.97 or the old vbr mode ?
--vbr-new
...3.98 has only 1 sample with score lower than 4.0 while 3.97 has 5 of such samples. 3.98 has more constant quality (less desviation) ...
That's real progress IMO though your score differences aren't dramatic.
There's been no activity for about 2 and a half years. I imagine Takehiro's life has gone in a different direction.
Whoa. Shows how in-touch I keep these days...
I just finished my first listening test.
With this I wanted to use a moderate bitrate where mp3 should be fine except for problem samples.
I will do a very high bitrate test later.
As a high quality moderate bitrate setting -V4, -V3 or -V2 are interesting settings and I decided to use -V3.
My most important test samples for such a setting are those which aren't specifically problematic, but with which I wasn't totally satisfied on occasion even with high bitrate mp3.
The samples I used:
- Sandrine Kiberlain: La godiche
- Camille: Là où je suis née
- Smokie: Oh Carol
To make it short: I couldn't find any problem using -V3.
I continued with samples which I know they are a bit problematic for mp3, but of which I would expect of an mp3 encoder at such a quality setting to yield only a minor issue.
- Wombat's sample Birds
- herding_calls
- trumpet
- trumpet_myPrince
I abxed Birds 9/10, herding_calls 10/10, trumpet 10/10, trumpet_myPrince 8/10 - more or less as expected.
trumpet_myPrince is a minor issue, absolutely negligible. Not so clear to say so however for the other samples though the issues aren't very obvious.
I finished with samples where major issues have to be expected (and accepted) with a setting of -V3 due to mp3-intrinsic restricted temporal resolution:
I abxed castanets 7/10, no need to abx harp and eig.
I'm personally totally satisfied with castanets, and to me eig too is encoded fine with this setting keeping in mind the extreme nature of this sample.
harp40_1 is the worst encoding among this group to me, the only sample among all I've tested I'd call really annoying. A non-subtle issue is to be expected though, harpsichord music can't be encoded with mp3, moderate bitrate, and high quality expectations.
For a comparison I also tested --abr 170 with part of the samples (Birds, castanets, eig, harp40_1, herding_calls, trumpet).
The result for Birds is clearly inferior to -V3.
I abxed castanets 10/10 though to me the quality is very good.
The eig result also is more obviously non-transparent than when using -V3 though it's still remarkable quality with respect to this sample.
The harp40_1 problem is very obvious though it's clearly better than -V3 to me.
Very bad is the ABR result of herding_calls: at second ~3.8 there's a gross error in the encoding which makes me wonder whether there is a real encoder bug when using ABR. With this result I didn't want to continue testing ABR.
I just tried trumpet for finishing up as this is a sample of special meaning to me. I abxed it 9/10, it's the same quality level to me as the -V3 result.
So for a moderate bitrate setting like -V3 it's better to use VBR than ABR, but I really wonder whether there's a real bug with ABR.
-V3 however works as expected: very good results for usual tracks, with more or less slight restrictions for tracks which are problematic to Lame (and other mp3 encoders).
I made a fast ABC/HR test 3.97 vs 3.98 V5
I was enough compulsive but lame 3.97 benefits in most of the case. I don't pretend to anything. It is only personal and fast test.
(http://img387.imageshack.us/img387/4716/397vs398fo7.png)
Some observations:
3.98 has only 1 sample with score lower than 4.0 while 3.97 has 5 of such samples. 3.98 has more constant quality (less desviation)
There was some audible issue with 3.98 aplaud sample while 3.97 makes it better. http://ff123.net/samples/applaud00.flac (http://ff123.net/samples/applaud00.flac)
Is the samples "Replica FF" and "HK FF" are from Fear Factory by any chance?
I know for some reason LAME can have trouble on their songs such as Linchpin, Replica, Back The F**k Up and am just wondering if there was a problem on HK aswell.
Yep, FF stands for Fear Factroy.
Yep, FF stands for Fear Factroy.
I see, thanks for the response.
Am been wondering for a while, if I could hear a artifact on HK on my -V2 rip, but have not done a ABX test on it though atm and thought it was a placebo.
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.
I know for some reason LAME can have trouble on their songs such as Linchpin, Replica, Back The F**k Up and am just wondering if there was a problem on HK aswell.
Particular reason to test on Fear Factory's cds that it's loud metal music with well recorded instruments especially drums (clicking double pedal, very clear and loud snare drum,hi-hat and cymbals as in HK ).
Thanks to all the developers!
Also krmathis's OSX port, when will LAMEdrop have OSX version ?
LAMEdrop have OSX version is right after the version that supports FLAC images with cue.
On the whole, the bitrate-increase from V3.97 to 3.98 isn't that dramatic at all - at least with the most popular encoder-setting -V2 --vbr-new. The MP3-files are with V3.98 on average only about 4 % larger.
V3.97: 191 kbps
V3.98: 199 kbps = + 4,18 %.
Source:
Transcoded 6,893 FLAC-files (all kind of music, but mostly Rock + Pop) to LAME-MP3. Measured with MPEG-Audio-Collection V2.93.
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.
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 (http://www.mega-nerd.com/libsndfile/) for the full list.
It seems that there is something wrong with the current compiles with libsndfile. A few testruns with .flac files as input produced mp3 files with only noise in them.
Just a plain
LAME.EXE -V 3 "TRACK01.FLAC"
libsndfile-1.dll was in the workig directory of course
Could somebody confirm this please ?
I added Lame 3.98 (-V5) to SE 128 kbit/s group. My first impressions in comparison with 3.97b2 (-V5) that is also in the group:
- Increased resulting bit rate on nine SE sound samples – 131.3 kbit/s vs. 112.7 kbit/s
- The only two SE samples with obviously audible artifacts are harpsichord and lo-fi tape recording. All others could be roughly and preliminarily estimated as “around 5”. Version 3.97b2 also produced obviously audible artifacts on the above samples plus glockenspiel and castanets. Though, this quality comparison has not much sense as the bit rate increased significantly. Just notes.
- The character of artifacts in SE samples (revealed by artifact amplification) is pretty much the same except preserving more high frequencies by 3.98.
So summing all of these factors I can predict slightly better results of Lame 3.98 over 3.97b2 in SE 128 kbit/s group which is not too informative due to increased bit rate. Comparison with other contenders will be more interesting as the competition is fairer now.
It seems that there is something wrong with the current compiles with libsndfile. A few testruns with .flac files as input produced mp3 files with only noise in them.
Just a plain
LAME.EXE -V 3 "TRACK01.FLAC"
libsndfile-1.dll was in the workig directory of course
Could somebody confirm this please ?
I also have this problem. I am assuming that the precompiled libsndfile-1.dll that is provided with the libsndfile download was not compiled with FLAC support. I don't know this for a fact and, although I've hunted high and low, I can't find any definitive answer to this, but it certainly does not have any FLAC dll dependency. When I have the opportunity, I will try compiling with FLAC support.
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.
A reduced and different allocation of my spare time. (btw, x264 is not part of my spare time)
I added Lame 3.98 (-V5) to SE 128 kbit/s group. ...
Increased resulting bit rate on nine SE sound samples – 131.3 kbit/s vs. 112.7 kbit/s ...
So summing all of these factors I can predict slightly better results of Lame 3.98 over 3.97b2 in SE 128 kbit/s group which is not too informative due to increased bit rate.
LAME 3.98 allows intermediate quality settings. The old "-V5" has obviously changed. The bitrate increase may be partly caused by the now used higher low pass frequency:
3.98 -V5 "transition band: 16538 Hz - 17071 Hz"
3.98 -V5.7 "transition band: 15826 Hz - 16360 Hz"
3.97 -V5 --vbr new "transition band: 15826 Hz - 16360 Hz"
With my usual test sample set 3.98 -V 5.7 appears to be comparable with LAME 3.97 -V5 --vbr-new (3.98: 133.6 kbps vs. 3.97: 133.8 kbps)
Do you guys recommend -V5.7 to be used in my test?
It seems that there is something wrong with the current compiles with libsndfile. A few testruns with .flac files as input produced mp3 files with only noise in them.
Just a plain
LAME.EXE -V 3 "TRACK01.FLAC"
libsndfile-1.dll was in the workig directory of course
Could somebody confirm this please ?
I also have this problem. I am assuming that the precompiled libsndfile-1.dll that is provided with the libsndfile download was not compiled with FLAC support. I don't know this for a fact and, although I've hunted high and low, I can't find any definitive answer to this, but it certainly does not have any FLAC dll dependency. When I have the opportunity, I will try compiling with FLAC support.
This LAME build will work with official pre versions of libsndfile 1.0.18 with FLAC support:
http://www.mega-nerd.com/tmp/?M=D (http://www.mega-nerd.com/tmp/?M=D)
Direct links - libsndfile-1-0-18pre22a-setup.exe (http://www.mega-nerd.com/tmp/libsndfile-1-0-18pre22a-setup.exe) (installer), libsndfile-1.dll (http://www.duplium.com/canada_upload/uploaded/libsndfile-1.zip) (extracted)
Thanks ZinCh!
The strange part of this is the fact that FLAC support is explicitly mentioned in the table
http://www.mega-nerd.com/libsndfile/ (http://www.mega-nerd.com/libsndfile/)
Do you guys recommend -V5.7 to be used in my test?
I think NO coz there is no possibility to make all participating coders to produce equal resulting bit rates. So the use of real-life settings (resulting in acceptable bit rates) seems to be a reasonable compromise.
It seems that there is something wrong with the current compiles with libsndfile. A few testruns with .flac files as input produced mp3 files with only noise in them.
Just a plain
LAME.EXE -V 3 "TRACK01.FLAC"
libsndfile-1.dll was in the workig directory of course
Could somebody confirm this please ?
I also have this problem. I am assuming that the precompiled libsndfile-1.dll that is provided with the libsndfile download was not compiled with FLAC support. I don't know this for a fact and, although I've hunted high and low, I can't find any definitive answer to this, but it certainly does not have any FLAC dll dependency. When I have the opportunity, I will try compiling with FLAC support.
This LAME build will work with official pre versions of libsndfile 1.0.18 with FLAC support:
http://www.mega-nerd.com/tmp/?M=D (http://www.mega-nerd.com/tmp/?M=D)
Direct links - libsndfile-1-0-18pre22a-setup.exe (http://www.mega-nerd.com/tmp/libsndfile-1-0-18pre22a-setup.exe) (installer), libsndfile-1.dll (http://www.duplium.com/canada_upload/uploaded/libsndfile-1.zip) (extracted)
Brilliant, thanks. I'll add this to the Rarewares download. I'll do this momentarily as I'm just about to do a lamedropXPd build that should work with this too, but I'll let you know.
OK, I've updated the lame.exe download now compiled to use the libsndfile 1.0.18pre22a dll and I've also added a build of lamedropXPd that works with the same dll and both now accept FLAC files as input and process accordingly.
(Both builds include the new dll.)
OK, I've updated the lame.exe download now compiled to use the libsndfile 1.0.18pre22a dll and I've also added a build of lamedropXPd that works with the same dll and both now accept FLAC files as input and process accordingly.
(Both builds include the new dll.)
Whoa! I've been waiting 3 years for this day! Whoo hoo!
Just downloaded and tested. Finally can drop a FLAC and get a MP3.
One note: On the Encoding Options screen is showing "Using L.A.M.E. v3.98 beta 8 encoding engine"....is this a typo, or is this still using beta 8 and not the final version?
Also - is the Variable Bitrate Mode relevant anymore? Doesn't 3.98 use --vbr-new as default? Wasn't that what this setting changed, the old vs. new VBR mode? I'm assuming Standard is now --vbr-new. Can you clarify?
Lastly - is there anyway to show the -V settings along the slider so we know where along the scale we're locked in on say -V2 -V3 -V4 -V5, etc. I'm finding it impossible to tell where -V4 is so I can compare LameDrop files with the output of foobar. If this can't be done, don't sweat it.
Anyway, thank you so much for getting LameDropXPd to work with FLAC.
OK, I've updated the lame.exe download now compiled to use the libsndfile 1.0.18pre22a dll and I've also added a build of lamedropXPd that works with the same dll and both now accept FLAC files as input and process accordingly.
(Both builds include the new dll.)
Whoa! I've been waiting 3 years for this day! Whoo hoo!
Just downloaded and tested. Finally can drop a FLAC and get a MP3.
One note: On the Encoding Options screen is showing "Using L.A.M.E. v3.98 beta 8 encoding engine"....is this a typo, or is this still using beta 8 and not the final version?
Also - is the Variable Bitrate Mode relevant anymore? Doesn't 3.98 use --vbr-new as default? Wasn't that what this setting changed, the old vs. new VBR mode? I'm assuming Standard is now --vbr-new. Can you clarify?
Lastly - is there anyway to show the -V settings along the slider so we know where along the scale we're locked in on say -V2 -V3 -V4 -V5, etc. I'm finding it impossible to tell where -V4 is so I can compare LameDrop files with the output of foobar. If this can't be done, don't sweat it.
Anyway, thank you so much for getting LameDropXPd to work with FLAC.
Your right, it was a typo! I've fixed that and uploaded again. This version does not accept ogg files for input as it uses libsndfile exclusively for input purposes. If you want to drop ogg files as well, you'll need both versions, but they can share the same ini file and co-exist quite happily.
OK, I've updated the lame.exe download now compiled to use the libsndfile 1.0.18pre22a dll and I've also added a build of lamedropXPd that works with the same dll and both now accept FLAC files as input and process accordingly.
(Both builds include the new dll.)
Whoa! I've been waiting 3 years for this day! Whoo hoo!
Just downloaded and tested. Finally can drop a FLAC and get a MP3.
One note: On the Encoding Options screen is showing "Using L.A.M.E. v3.98 beta 8 encoding engine"....is this a typo, or is this still using beta 8 and not the final version?
Also - is the Variable Bitrate Mode relevant anymore? Doesn't 3.98 use --vbr-new as default? Wasn't that what this setting changed, the old vs. new VBR mode? I'm assuming Standard is now --vbr-new. Can you clarify?
Lastly - is there anyway to show the -V settings along the slider so we know where along the scale we're locked in on say -V2 -V3 -V4 -V5, etc. I'm finding it impossible to tell where -V4 is so I can compare LameDrop files with the output of foobar. If this can't be done, don't sweat it.
Anyway, thank you so much for getting LameDropXPd to work with FLAC.
Your right, it was a typo! I've fixed that and uploaded again. This version does not accept ogg files for input as it uses libsndfile exclusively for input purposes. If you want to drop ogg files as well, you'll need both versions, but they can share the same ini file and co-exist quite happily.
OK, looks like we still need to toggle "Fast" on Variable Bitrate Mode to get --vbr-new. Is the old vbr mode still an option in 3.98 because it looks like the "Standard" setting is still using the old mode. I thought I read that --vbr-new is now the default.
OK, I've updated the lame.exe download now compiled to use the libsndfile 1.0.18pre22a dll and I've also added a build of lamedropXPd that works with the same dll and both now accept FLAC files as input and process accordingly.
Hi John, thanks for the release with flac support.
OK, looks like we still need to toggle "Fast" on Variable Bitrate Mode to get --vbr-new. Is the old vbr mode still an option in 3.98 because it looks like the "Standard" setting is still using the old mode. I thought I read that --vbr-new is now the default.
You're right, with "Standard" setting lamedrop uses the old mode. I converted few flacs to mp3's and encspot shows in Lame Tag: "VBR Method - vbr-old / vbr-rh". If i encode wav's with normal 3.98 lame, encspot shows in Lame Tag: "VBR Method - vbr mtrh".
Also, LamedropXPd doesn't copy tags from flacs to mp3 like oggdropXPd does. But i guess this is because of libsndfile...
You're right, I forgot to change the default on the Method. I've changed it for subsequent compiles, but it's probably not worth uploading again.
And, Kim_C, you're also right, as the FLAC routines are courtesy of libsndfile, tag copying is not catered for, but still a step in the right direction, I think.
OK, I've updated the lame.exe download now compiled to use the libsndfile 1.0.18pre22a dll and I've also added a build of lamedropXPd that works with the same dll and both now accept FLAC files as input and process accordingly.
(Both builds include the new dll.)
Wow
As always, thanks !
Do you guys recommend -V5.7 to be used in my test?
I want to see a comparison of different encoders in mostly equal bitrate ranges. So if -V 5 now produces ~150kbps in a 128kbps test ist's not ok in my opinion. I also would like to see lame 3.98 and 3.97; so we may get a new recommended encoder + setting with lame 3.98 after the test.
Thanks to the Lame devs for the new version and many thanks to John33 for finally including FLAC support into LamedropXPd
I have seem to have ripped a NES video game music sample that LAME 3.97 sounds worse then 3.98 at -V5.
LAME 3.97 -V 5 --vbr-newfoo_abx 1.3.3 report
foobar2000 v0.9.5.3
2008/07/06 23:54:31
File A: C:\Temp\Metal Gear NFS Rip Preview\NES_MetalGearBGM LAME3.97 V5.mp3
File B: C:\Temp\Metal Gear NFS Rip Preview\NES_MetalGearBGM.flac
23:54:31 : Test started.
23:54:51 : 01/01 50.0%
23:55:00 : 02/02 25.0%
23:55:28 : 03/03 12.5%
23:55:44 : 04/04 6.3%
23:55:58 : 05/05 3.1%
23:56:04 : 06/06 1.6%
23:56:13 : 07/07 0.8%
23:56:27 : 08/08 0.4%
23:56:33 : 09/09 0.2%
23:56:44 : 10/10 0.1%
23:56:46 : Test finished.
----------
Total: 10/10 (0.1%)
LAME 3.98 -V 5foo_abx 1.3.3 report
foobar2000 v0.9.5.3
2008/07/06 23:57:43
File A: C:\Temp\Metal Gear NFS Rip Preview\NES_MetalGearBGM LAME3.98 V5.mp3
File B: C:\Temp\Metal Gear NFS Rip Preview\NES_MetalGearBGM.flac
23:57:43 : Test started.
23:58:13 : 01/01 50.0%
23:58:24 : 02/02 25.0%
23:59:19 : 03/03 12.5%
23:59:39 : 04/04 6.3%
23:59:46 : 05/05 3.1%
00:00:23 : 06/06 1.6%
00:00:40 : 07/07 0.8%
00:00:47 : 07/08 3.5%
00:01:05 : 08/09 2.0%
00:01:46 : 08/10 5.5%
00:01:50 : Test finished.
----------
Total: 8/10 (5.5%)
I have to seem to have more trouble doing a ABX on the 3.98 encode. At the moment am having trouble doing any tests, since I can not barely hear much at of my right ear, which is likely to be a bad ear wax build up hopefully.
The sample was a 30 sec preview, produced on foobar2000 with the Game Emu music plugin. from a NSF file of a NES and MSX game called Metal Gear. The source was a FLAC preview trancode with the Mono to Stero DSP plugin enabled.
EDIT:
I have uploaded the sample (http://www.hydrogenaudio.org/forums/index.php?act=Attach&type=post&id=4582)
Thanks, another great release
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.
john33, a big thank you for the LAME 3.98 compile(s) on Rarewares! Many thanks brother.
Is there a 64 bit compile available from anyone yet?
I know that there are 64bit versions of LAME out there for Unix, such as the version that I run on my x64 Arch Linux box, but I can't recall ever seeing one for Windows. Is a 64 bit version possible for Windows?
There's an old one out there, apparently it was slightly faster, in the order on 10%, in 64-bit. I'm hoping someone has or will do a binary for 3.98.
Is there a 64 bit compile available from anyone yet?
My LAME binary contain 64-bit code.
http://www.rarewares.org/files/mp3/Lame%203.98.dmg (http://www.rarewares.org/files/mp3/Lame%203.98.dmg)
My LAME binary contain 64-bit code.
http://www.rarewares.org/files/mp3/Lame%203.98.dmg (http://www.rarewares.org/files/mp3/Lame%203.98.dmg)
Is that a Mac binary? Why DMG?
I see it is. Very funny. Do a 64-bit version for the OS that most people use and I'll be your best friend.
My LAME binary contain 64-bit code.
http://www.rarewares.org/files/mp3/Lame%203.98.dmg (http://www.rarewares.org/files/mp3/Lame%203.98.dmg)
Is that a Mac binary? Why DMG?
Disk images are the standard way of distributing programs in the Mac world (or at least it was when I sold my Mac and bought a PC in 2006). Sadly, in Windows almost every app maker seems to think you need an installer when a simply zip file would suffice.
But back on topic, I gave 3.98 a try and it seems very nice. I embedded cover art into a test file and Foobar and iTunes both picked it up fine. I also noticed in the command help that you can now supply not just the track number but also total tracks of the album. All in all, a nice update I'd say.
I can't wait to update my apps.
I am a alt preset extreme kind of sort . I guess this is still V0?
Has this improved any over the early 3.98 betas?
Thanks!
Since the "newer VBR code is now LAME's default VBR routine", does that mean that
-V0 --vbr-new
now simply becomes
-V0
Yes.
That's simply wonderful!
Disk images are the standard way of distributing programs in the Mac world (or at least it was when I sold my Mac and bought a PC in 2006). Sadly, in Windows almost every app maker seems to think you need an installer when a simply zip file would suffice.
But back on topic, I gave 3.98 a try and it seems very nice. I embedded cover art into a test file and Foobar and iTunes both picked it up fine. I also noticed in the command help that you can now supply not just the track number but also total tracks of the album. All in all, a nice update I'd say.
Yeah I get it. Just want a 64 bit binary for Windows
Doesn't 64-bit not allow you some ASM features? ie. MMX/SSE? And I seem to recall encoding was actually slower due to that. Seems like a novelty with no real benifit.
There is some info on this here:
http://www.hydrogenaudio.org/forums/index....showtopic=47244 (http://www.hydrogenaudio.org/forums/index.php?showtopic=47244)
...actually one of the reasons I'm asking.
I am no expert, the LAME devs can shoot me down if they want, I just like the sound of ~15% improvement. Whenever I use a LAME compile, it's usually to generate a CD full of MP3s and I tend to end up waiting on it, so any improvement in performance is important to me for one.
I tried the x64 build by Gabriel (http://gabriel.mp3-tech.org/lame/x64/) in the above thread, which is dated 09-Aug-2006. On my Q6600 it's actually considerably slower than 32-bit 3.98 from rarewares.org, but I'm putting that down to the version, and hoping that a similar x64 build of 3.98 will be quicker.
http://gabriel.mp3-tech.org/lame/x64/ (http://gabriel.mp3-tech.org/lame/x64/)
Compiled with VC8
http://gabriel.mp3-tech.org/lame/x64/ (http://gabriel.mp3-tech.org/lame/x64/)
Compiled with VC8
Thanks Gabriel, I take it that's 3.98 as there's no version info anywhere.
I just did a few tests with that plus the 32-bit rarewares version. I got very inconsistent results with smaller tracks, I imagine on account of Foobar waiting on the HDD, so I did a second round with much longer tracks. However on these settings at least, the 32 bit version is consistently faster.
==========================
FLAC to MP3 via Foobar2000 on Intel Core 2 Quad 6600-S --noreplaygain -V 2 --vbr-new - %d33 radio length tracks:Gabriel's LAME x641st run - 1m 57s
2nd run - 1m 45s
3rd run - 1m 56s
(total 338s)
rarewares LAME 321st run - 1m 39s
2nd run - 1m 43s
3rd run - 1m 41s
(total 303s)
x64 is
9.9% slower
4 half album length tracks:Gabriel's LAME x641st run - 1m 09s
2nd run - 1m 12s
3rd run - 1m 09s
(total 210s)
rarewares LAME 321st run - 1m 03s
2nd run - 1m 03s
3rd run - 1m 03s
(total 189s)
x64 is
11.1% slower
==========================
Gabriel, are these results to be expected? Would any different command parameters give a different result? Any comments at all?
I would guess the rarewares compiles are made with Intel compiler and Gabriel uses Microsoft VC8.
As pointed by Robert, you only tested that the x86 version from Rarewares is faster than the x64 vc8 version, so you can't draw any x86 vs x64 conclusion from this.
You have to make comparisons with the same compiler being used (which is why I also provided an x86 version)
Well like most users I am only interested in real world results. If the 64-bit version is slower than the fastest available 32-bit version, it is a bit pointless, no?
Is it possible to compile an x64 exe optimized for Intel?
Well like most users I am only interested in real world results. If the 64-bit version is slower than the fastest available 32-bit version, it is a bit pointless, no?
I thought that you were interested to know if it could be faster in x64 vs x86. In this case, it would not have been pointless to report speed tests done on your computer, comparing x86 vs x64 binaries produced by the same compiler (it might even have been helpful).
If you are only interested in the fastest binary available, then you will have to wait for someone else to report test results, so we could start gathering data about it.
It would probably be possible to compile an x64 version with vc8 or icc 10.x, but I don't have any of those compilers.
note:
On my k8, the x64 vc8 version is faster than the x86 vc8 version.
I benchmarked 32 bit lame 3.98 with nasm versus 64 bit lame on a Q6600 (Intel Core 2 Quad Q6600, 6GB DDR2) running stock Ubuntu 8.04 (not that it should make a big difference). Both were compiled with gcc 4.2.3 with the flags given by the ./configure. The results are the average of four runs, discarding to the first run to make sure the file was in cache.
Flags: --noreplaygain -V2
File: Ravel's Bolero, 16:10
32bit: 57.8 seconds
64bit: 50.61 seconds
This puts the 64bit compile in the lead by about 14%. It's probably due to better register allocation (x86_64 has more registers) more than the 64bit-ness of the platform.
Congrats to the Lame devs for putting out a new release.
I benchmarked 32 bit lame 3.98 with nasm versus 64 bit lame on a Q6600 (Intel Core 2 Quad Q6600, 6GB DDR2) running stock Ubuntu 8.04 (not that it should make a big difference). Both were compiled with gcc 4.2.3 with the flags given by the ./configure. The results are the average of four runs, discarding to the first run to make sure the file was in cache.
Flags: --noreplaygain -V2
File: Ravel's Bolero, 16:10
32bit: 57.8 seconds
64bit: 50.61 seconds
This puts the 64bit compile in the lead by about 14%. It's probably due to better register allocation (x86_64 has more registers) more than the 64bit-ness of the platform.
Congrats to the Lame devs for putting out a new release.
Eeeeek damn you all gimme an optimized win 64 compile already
lol
Yeah, I'd at least be interesting in testing 3.98 for Win64 compiled with ICL 10.
From your comment, can I assume that the Intel compiler is more optimized than Microsoft's is?
From your comment, can I assume that the Intel compiler is more optimized than Microsoft's is?
Yes, for many programs ICL generates faster executables than wither MSVC or gcc. Most of the time these differences are pretty small - and the changes are on the order of a couple of percent. Unless you are converting large batches, these won't matter - but can becomes significant over a long batch job.
Last night I did a very high bitrate listening test with my usual problem samples.
I used -V0 as it's the best VBR quality setting, as well as ABR 270 and CBR 320.
I don't care about the bitrate differences: if the philosophy behind VBR and ABR works well, the quality of these settings should be identical. I wanted to find out if the philosophies are right, or whether it makes sense qualitywise to pay some bitrate and go the brute force way using CBR 320 in the extreme case.
I started with my moderate problems herding_calls, Birds, trumpet, trumpet_myPrince. With these very high quality settings these problems were expected to be transparent to me.
Well, they are to me with last night's ABXing, with all the settings, though there is sime suspicion that herding_calls and trumpet_myPrince aren't perfect. With herding_calls I started quite well and arrived at 5/6 resp. 4/5 (depending on encoding setting) before I failed and ended up 6/10 resp. 7/10.
With trumpet_myPrince I arrived at 8/10 (-V0) to 5/10 (--abr 270).
If at all the isssues are very subtle though, and I can't really differentiate the quality of the various settings.
With the serious problems castanets, eig, and harp40_1 I can't differentiate the quality of the various settings either. This time I had no problem abxing castanets clearly, and eig of course is easy to abx.
But to me quality of the encodings is very good, with any of the settings.
harp40_1 was hard to abx, and it was only with ABR 270 that I got a decent result of 9/10 (7/10 with the other settings). But I don't think ABR 270 is worse - as with the other test samples with subtle issues if at all there's some randomness in my ABX results). Which shows of course that quality is very high.
So in the end quality is identical to me with my samples tested, no matter whether -V0, --abr 270, or -b320 is used. Quality is very high, remarkably high with very bad problem eig.
So according to this test -V0 is the most attractive way to go, and taking it together with my last -V3 test, everything is fine from -V3 to -V0 depending on personal quality demand.
BTW the strong error of herding_calls at sec. ~3.8 is so strong just with --abr 170. With --abr 175 it's a lot better, and it disappears for me when using --abr 180 (though herding_calls as an entire track is not transparent using --abr 180).
So summing all of these factors I can predict slightly better results of Lame 3.98 over 3.97b2 in SE 128 kbit/s group which is not too informative due to increased bit rate. Comparison with other contenders will be more interesting as the competition is fairer now.
That sounds like a surprisingly old flaw in thinking. Practically relevant isn't the bitrate of the TEST-SAMPLES, but the average bitrate of MUSIC COLLECTIONS. If an encoder is "smart" enough, to increase bitrate for a difficult sample, then thats a good sign, not something which needs to be "handicapped". While from current observations, 3.98 average bitrate on collections seems to be a bit higher, it isn't as high as test-samples would make one asume. So to summarize: Test should be calibrated to average bitrates of music collections, not to the average bitrate of the test-samples.
3.98 V5 has higher bitrate on average (whole collection).
So summing all of these factors I can predict slightly better results of Lame 3.98 over 3.97b2 in SE 128 kbit/s group which is not too informative due to increased bit rate. Comparison with other contenders will be more interesting as the competition is fairer now.
That sounds like a surprisingly old flaw in thinking. Practically relevant isn't the bitrate of the TEST-SAMPLES, but the average bitrate of MUSIC COLLECTIONS. If an encoder is "smart" enough, to increase bitrate for a difficult sample, then thats a good sign, not something which needs to be "handicapped". While from current observations, 3.98 average bitrate on collections seems to be a bit higher, it isn't as high as test-samples would make one asume. So to summarize: Test should be calibrated to average bitrates of music collections, not to the average bitrate of the test-samples.
Unfortunately there is no any best way of listening test "calibration" for VBR encoders. So different approaches are possible. SoundExpert has its own (quoted text refers to SE tests). This was discussed to death at HA forums.
Is that a Mac binary? Why DMG?
I see it is. Very funny. Do a 64-bit version for the OS that most people use and I'll be your best friend.
Yes, it is a Mac OS X binary.
Sorry if its not for you. But you did not mention which OS you run, hence why I responded.
Hint. Next time mention which OS you want the binary to run on.
Hint. Next time mention which OS you want the binary to run on.
Now come on, nobody actually uses Macs these days. What sort of weird creature are you? If you'd linked to some x64 *nix binary you'd have a point.
I actually wasted several hours of my life monkeying around with MS VS Express and the evaluation Intel compiler, but ICL won't recognize the Visual Studio install (even though it's supposed to) and all the LAME C code fails on trying to compile, unable to find its includes etc. Maybe somebody above my level of proficiency (complete moron) will eventually try. C'mon haxors, bet you can't do it.
What about the chimps that did the RareWares x86 compiles, don't they realize that the 64-bit world is here now and ain't going away?
Having said that, the makefile.msvc wasn't prepared for modern CPUs either, ICL kept failing with some strange /QaxK or /QxK switches being passed to it (with CPU=P3 or not, respectively). No such switches according to icl /help - the one I wanted was /Qax
T, which apparently is optimizations for Core 2, so I had to mod the makefile myself. So it seems strange that the LAME devs release source code that won't compile out-of-the-box for native execution on half of today's processors. Obviously nobody cares, I shudda stuck with my 32-bit WinXP on my old Athlon. Sob.
If you are trying to build native Windows applications with VS Express, you need to install a recent Microsoft Platform SDK too.
If you are trying to build native Windows applications with VS Express, you need to install a recent Microsoft Platform SDK too.
Yeah I have. I got Windows SDK 6.1. First time I installed VS with a modified install directory, and ICL kept failing when called from nmake, unable to find all the includes. Then I tried reinstalling to default dir, and the ICL component for VS integration now fails upon trying to reinstall, saying that VS can't be found.
By the way, even the first time, from the Intel C++ Build Environment, the system didn't know where nmake was - I had to add the dir to PATH. In retrospect I'm guessing that's not normal.
Now come on, nobody actually uses Macs these days. What sort of weird creature are you? If you'd linked to some x64 *nix binary you'd have a point
Let me tell you. A LOT of people use Mac's these days, including me. So don't even go there...
I linked to an x64 *nix binary. Mac OS X is UNIX, GNU/Linux is not.
Oh well!
@Bad Monkey
Using Visual C++ Express Edition with the Microsoft Platform SDK (http://www.microsoft.com/express/2005/platformsdk/default.aspx)
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.
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.
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.
Great news!
Lame 3.98 for Mac OS X (universal binary) available on my website (http://homepage.mac.com/krmathis/).
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...
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).
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.
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.
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 (http://www.ime.usp.br/~rbrito/diary/2008.xhtml).
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.
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.
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 (http://www.mega-nerd.com/libsndfile/) 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.
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.
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...
You might want to see what I posted here: My (outdated) diary/blog (http://www.ime.usp.br/~rbrito/diary/2008.xhtml)
Will head over to take a look.
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...
@Bad Monkey
Using Visual C++ Express Edition with the Microsoft Platform SDK (http://www.microsoft.com/express/2005/platformsdk/default.aspx)
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 (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.
(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:
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.
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 (http://wiki.hydrogenaudio.org/index.php?title=Lame) the currently recommended LAME version is still 3.97?
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 (http://wiki.hydrogenaudio.org/index.php?title=Lame) 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.
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 (http://wiki.hydrogenaudio.org/index.php?title=Lame) 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.
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.
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!
... 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.
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.
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
I found a track that LAME 3.98 seems to perform better then 3.97 at V2.
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.
http://gabriel.mp3-tech.org/lame/x64/ (http://gabriel.mp3-tech.org/lame/x64/)
Compiled with VC8
Hey Gabriel,
thanks for the x64 build!
Best,
Stevie
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
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?
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.
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?
Yes, sorry I did not make that clear in my initial post. I want to use the mp3's for my iPod. I already use flac to stream music within the home, but lossless files (flac or aac) are going to limit the amount of music I can get on the iPod.
Rgds
Yes, sorry I did not make that clear in my initial post. I want to use the mp3's for my iPod. I already use flac to stream music within the home, but lossless files (flac or aac) are going to limit the amount of music I can get on the iPod.
Rgds
AAC is not lossless, you mean ALAC.
That said, if it's just for the iPod and you don't need the better general compatibility of MP3s, use AAC instead of MP3; for the same quality the files are smaller. Only drawback is the encoder is half the speed of LAME.
Thanks
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
This is a good idea, i thought about that as well. I updated the Wiki accordingly.
OK, I've updated the lame.exe download now compiled to use the libsndfile 1.0.18pre22a dll and I've also added a build of lamedropXPd that works with the same dll and both now accept FLAC files as input and process accordingly.
(Both builds include the new dll.)
Hi John,
Whenever you get around to updating the "lame_enc.dll modified to use INI File" for 3.98, is there any way you can add more options to what you can specify in the INI file? for example, Mono/JStereo switch, CBR/ABR switch, CBR/ABR bitrate value (and these would be ignored when a LamePreset is used)? I think these additional switches would make the binary more useful to more people. I would appreciate it if you could consider implementing some or all of these switches. Thanks
I have uploaded a sample, that both LAME 3.97 and 3.98 struggle at -V3 and -V2. I got 10/10 with 3.97, since there's a smear at 0:13. The smear seems to have gone on 3.98, but there is a warbling noise on the distorted guitar riff at the start of the track.
Linchpin Sample (http://www.hydrogenaudio.org/forums/index.php?act=Attach&type=post&id=4632)
foo_abx 1.3.3 report
foobar2000 v0.9.5.5
2008/08/09 17:55:53
File A: C:\Temp\Linchpin3.98V2.mp3
File B: C:\Temp\Listen Tests\Linchpin.wav
17:55:53 : Test started.
17:56:12 : 01/01 50.0%
17:56:17 : 02/02 25.0%
17:56:33 : 03/03 12.5%
17:57:08 : 04/04 6.3%
17:57:31 : 05/05 3.1%
17:57:38 : 06/06 1.6%
17:58:05 : 07/07 0.8%
17:58:30 : 08/08 0.4%
17:58:36 : 09/09 0.2%
17:58:42 : 10/10 0.1%
17:58:50 : 11/11 0.0%
17:59:29 : 12/12 0.0%
17:59:31 : Test finished.
----------
Total: 12/12 (0.0%)
OK, I've updated the lame.exe download now compiled to use the libsndfile 1.0.18pre22a dll and I've also added a build of lamedropXPd that works with the same dll and both now accept FLAC files as input and process accordingly.
(Both builds include the new dll.)
Hi John,
Whenever you get around to updating the "lame_enc.dll modified to use INI File" for 3.98, is there any way you can add more options to what you can specify in the INI file? for example, Mono/JStereo switch, CBR/ABR switch, CBR/ABR bitrate value (and these would be ignored when a LamePreset is used)? I think these additional switches would make the binary more useful to more people. I would appreciate it if you could consider implementing some or all of these switches. Thanks
Sorry, I've not been ignoring this but I was away when you posted it! I plan to take a look at this over the next week, or so.
There is new version of the modified dll now at the Lame Libraries page at Rarewares. This is a 3.98 ICL10.1 compile and contains much more flexibility than previously. From the new .ini file:
[lame_enc]
LamePreset=V2.00
Stereo=JS
Scale=0.0
ExperimentalY=0
REM LamePreset is specified as follows:
REM For VBR settings V0.00 to V9.00, specify LamePreset=Vn.nnn.
REM The specified value will be chacked and defaulted to V2.0 if invalid.
REM
REM For ABR settings, specify LamePreset=ABRnnn, where nnn = desired bitrate.
REM The specified value will be checked and limited to within 8 - 320.
REM
REM Similarly, for CBR, specify LamePreset=CBRnnn, where nnn = desired bitrate.
REM For CBR, the indicated bitrate will be checked and will be adjusted to
REM the nearest valid CBR bitrate.
REM
REM If the 'LamePreset' line is invalid, it will default to 128kbps CBR, as normal.
REM
REM To specify Mono, specify Stereo=Mono
REM Please Note: In order for downmixing to Mono to work correctly, you will
REM need to select a setting on the CDex Settings page that allows you to
REM select Mono. Failure to do this will result in incorrect encoding.
REM To specify Joint Stereo, specify Stereo=JS
REM The default is Joint Stereo.
REM
REM Scale can be used to apply the ReplayGain factor to scale the samples
REM as floating point numbers within LAME before encoding.
REM Valid values are > 0.0 and less than 1.0, default = 0.0.
REM
REM ExperimentalY is used to toggle the switch ON or OFF. Set to 1 if you want
REM it changed to ON or OFF, depending whether it is already set.
REM If set to anything other than 1,it will be ignored.
REM
REM NOTE: ONLY the FIRST 5 lines of this file are read and used.
@ john33: Thanks a million!
OK, I've updated the lame.exe download now compiled to use the libsndfile 1.0.18pre22a dll and I've also added a build of lamedropXPd that works with the same dll and both now accept FLAC files as input and process accordingly.
(Both builds include the new dll.)
Hi John,
Whenever you get around to updating the "lame_enc.dll modified to use INI File" for 3.98, is there any way you can add more options to what you can specify in the INI file? for example, Mono/JStereo switch, CBR/ABR switch, CBR/ABR bitrate value (and these would be ignored when a LamePreset is used)? I think these additional switches would make the binary more useful to more people. I would appreciate it if you could consider implementing some or all of these switches. Thanks
Sorry, I've not been ignoring this but I was away when you posted it! I plan to take a look at this over the next week, or so.
Thank you very much, John! I was away for a while also, and when I visited HA today, I was amazed how much work you have done for my request! Thank you again!!
Great news!
Lame 3.98 for Mac OS X (universal binary) available on my website (http://homepage.mac.com/krmathis/).
I've compiled it long time ago on my G5 myself, but I just tried your universal binary: I get a bus error on my iMac G5 Maybe it's not realy "universal"?
I'm a Linux newbie.
Where and how I can get Lame 3.98 for Ubuntu Linux 8.04 LTS ?
Now it's too early to puzzle with compiling my own stuff from the source code...
You will have to :
- wait for a hardy backport
- wait for intrepid release
- use win32 binary through WINE
- backport source from intrepid , then build a .deb for your release.
- download build-essential & compile the old way ./configure [options] && make && sudo make install
You will have to :
- wait for a hardy backport
- wait for intrepid release
- use win32 binary through WINE
- backport source from intrepid , then build a .deb for your release.
- download build-essential & compile the old way ./configure [options] && make && sudo make install
Friend of mine has suggested me to add a custom repository. I've added those mentioned there (http://www.rarewares.org/debian-info-apt.php) and there was Lame 3.98 available.
Unfortunately I don't have any idea if I would brake something by that or cause any problems...
You will have to :
- wait for a hardy backport
- wait for intrepid release
- use win32 binary through WINE
- backport source from intrepid , then build a .deb for your release.
- download build-essential & compile the old way ./configure [options] && make && sudo make install
Friend of mine has suggested me to add a custom repository. I've added those mentioned there (http://www.rarewares.org/debian-info-apt.php) and there was Lame 3.98 available.
Unfortunately I don't have any idea if I would brake something by that or cause any problems...
Thats the debian repo i use but its not for ubuntu. I think the lame package is okay for you since it won't pull in harmfull stuff - if you want to be safe download the .deb only .
For the benefit of those who have been after a 64 bit compile, I've just tested a 64 bit Intel compile against the standard 32 bit version, as posted on Rarewares. It is important to remember that the 64 bit compile is NOT using the nasm routines as they are incompatible, at least currently. This test was run under WindowsXP Pro x64, the system comprising: e6700 @ 3.2GHz, 4GB OCZ Reaper PC2 6400, Asus P5W-DH De Luxe.
F:\Testdir>lame -V 2 01.wav 01.mp3
LAME 3.98 64bits (http://www.mp3dev.org/)
CPU features: , SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 01.wav to 01.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
9211/9211 (100%)| 0:06/ 0:06| 0:06/ 0:06| 37.467x| 0:00
32 [ 76] %*
40 [ 1] %
48 [ 0]
56 [ 0]
64 [ 3] %
80 [ 4] %
96 [ 11] %
112 [ 17] %
128 [ 46] %
160 [2183] %%%%%%%%%%%%%%%*****************
192 [4756] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
224 [1159] %%%%%%%**********
256 [ 412] %%%***
320 [ 543] %%%%%***
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
196.8 53.7 46.3 88.9 6.2 4.9
Writing LAME Tag...done
ReplayGain: -1.8dB
F:\Testdir>lame -V 2 01.wav 01.mp3
LAME 3.98 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 01.wav to 01.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
9211/9211 (100%)| 0:06/ 0:06| 0:06/ 0:06| 39.896x| 0:00
32 [ 76] %*
40 [ 1] %
48 [ 0]
56 [ 0]
64 [ 3] %
80 [ 4] %
96 [ 11] %
112 [ 16] %
128 [ 47] %
160 [2188] %%%%%%%%%%%%%%%*****************
192 [4748] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
224 [1161] %%%%%%%**********
256 [ 413] %%%***
320 [ 543] %%%%%***
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
196.8 53.7 46.3 88.9 6.2 4.9
Writing LAME Tag...done
ReplayGain: -1.8dB
F:\Testdir>
As you can see, although the 64 bit compile comes close, the standard 32 bit compile is still faster. The small encoding discrepancies are inaudible, to my ears at least!
It's also important to bear in mind that the 64 bit compile is using compiler optimisations alone, no code changes have been made other than to exclude the nasm routines from the build.
LAME 3.98.2 source are available (http://downloads.sourceforge.net/lame/lame-398-2.tar.gz) on SF.net, dated 2008-09-22.
The following notes are attached to the release:
The 3.98.2 release is a maintenance release over 3.98.
Changes do not affect audio quality, but operational bug fixes only:
- build system related: some fixes for mp3rtp and abx tools
- encoder padding values were not correct when resampling was involved
- frequency filtering API was broken; in case you want to use your own higher quality filtering method, it is now possible again to disable LAME buildin filters
- ID3 tagging:
--id3v1-only switch did not work anymore, fixed
--tg <genre> improved, now it matches more often one of the ID3v1 genres, even when small spelling errors are involved
--add-id3v2-size <n> is a new switch, it allows to define your own padding of n bytes.
NOTE: Version 3.98.1 contains a bug that will let it crash when encoding CBR/ABR or with old VBR at setting q0, q1 or q2!
LAME 3.98.2 source are available (http://downloads.sourceforge.net/lame/lame-398-2.tar.gz) on SF.net, dated 2008-09-22.
.....
I've not been at home since late Friday, and I will not be back until later this evening so, sorry about the absence of new builds on Rarewares, but I'll attend to it on my return either later tonight, or tomorrow.
Thank you for your consistent dedication, John. It is much appreciated
A full set of compiles is now on Rarewares.
Thanks
Thnx for the new complies john33
Thank you Mr. John33
Good news!
But history.html (http://lame.cvs.sourceforge.net/*checkout*...RELEASE__3_98_2 (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html?pathrev=RELEASE__3_98_2)) still says "LAME 3.98.1 not yet released"
and 3.98.2 is somehow broken. It doesn't compile on OS X. Neither with gcc 3.3 nor with 4.0.1 :
(cd .libs/libmp3lame.lax/libmpgdecoder.a && ar x /Users/frankseyen/Desktop/Lame 3.98.2/lame-398-2/libmp3lame/../mpglib/.libs/libmpgdecoder.a)
ar: /Users/frankseyen/Desktop/Lame: Inappropriate file type or format
make[3]: *** [libmp3lame.la] Error 1
Where does that blank come frome in "Lame 3.98.2" ?
@vpa:
You'll have to rename the directory you created. Make doesn't like paths containing blanks.
Where does that blank come frome in "Lame 3.98.2" ?
@vpa:
You'll have to rename the directory you created. Make doesn't like paths containing blanks.
Thanks. It still doesn't work with gcc 3.3, but at least 4.0.1 compiles it now.
I have just been doing some testing with V0 --vbr-new on LAME 3.97 and found a track that was not transparent to me at that setting and almost also on 3.98.2.
LAME 3.97 -V0 --vbr-newfoo_abx 1.3.3 report
foobar2000 v0.9.5.5
2008/09/28 00:18:38
File A: C:\Temp\LAME V0\White Zombie - Astro-Creep 2000\05. Electric Head, Pt. 2 (The Ecstasy).mp3
File B: C:\Rips\White Zombie - Astro-Creep 2000\05. Electric Head, Pt. 2 (The Ecstasy).flac
00:18:38 : Test started.
00:19:25 : 01/01 50.0%
00:19:31 : 02/02 25.0%
00:19:38 : 03/03 12.5%
00:19:44 : 04/04 6.3%
00:19:52 : 04/05 18.8%
00:19:55 : 05/06 10.9%
00:20:01 : 06/07 6.3%
00:20:06 : 07/08 3.5%
00:20:12 : 08/09 2.0%
00:20:16 : 08/10 5.5%
00:20:20 : 09/11 3.3%
00:20:24 : 10/12 1.9%
00:20:31 : 11/13 1.1%
00:20:39 : 12/14 0.6%
00:20:58 : 13/15 0.4%
00:21:08 : 14/16 0.2%
00:21:14 : 15/17 0.1%
00:21:18 : 16/18 0.1%
00:21:28 : 16/19 0.2%
00:21:34 : 17/20 0.1%
00:21:47 : 17/21 0.4%
00:21:57 : 18/22 0.2%
00:22:03 : 19/23 0.1%
00:22:12 : 20/24 0.1%
00:22:19 : 21/25 0.0%
00:22:24 : Test finished.
----------
Total: 21/25 (0.0%)
Drum smearing at 0:06, or could be a stereo collapse artifact or a noise on the left channel.
LAME 3.98.2 -V0foo_abx 1.3.3 report
foobar2000 v0.9.5.5
2008/09/28 00:38:44
File A: C:\Rips\White Zombie - Astro-Creep 2000\05. Electric Head, Pt. 2 (The Ecstasy).flac
File B: C:\Temp\Transcodes\Mp3\Electric Head, Pt. 2 (The Ecstasy) LAME 3.98.2.mp3
00:38:44 : Test started.
00:39:14 : 01/01 50.0%
00:39:37 : 02/02 25.0%
00:39:48 : 02/03 50.0%
00:39:54 : 03/04 31.3%
00:40:06 : 04/05 18.8%
00:40:12 : 05/06 10.9%
00:40:22 : 05/07 22.7%
00:40:29 : 06/08 14.5%
00:40:36 : 07/09 9.0%
00:40:50 : 07/10 17.2%
00:40:57 : 07/11 27.4%
00:41:08 : 08/12 19.4%
00:41:15 : 09/13 13.3%
00:41:26 : 10/14 9.0%
00:41:40 : 11/15 5.9%
00:41:47 : 12/16 3.8%
00:42:02 : 13/17 2.5%
00:42:07 : 13/18 4.8%
00:42:16 : 14/19 3.2%
00:42:27 : 15/20 2.1%
00:42:32 : 16/21 1.3%
00:42:37 : 17/22 0.8%
00:42:51 : 18/23 0.5%
00:42:59 : 19/24 0.3%
00:43:06 : 20/25 0.2%
00:43:14 : 21/26 0.1%
00:43:29 : 22/27 0.1%
00:43:40 : Test finished.
----------
Total: 22/27 (0.1%)
The artifact at 0:06 is gone, but at 0:27 something sounds odd, which could be smearing.
I have uploaded a sample (http://www.sendspace.com/file/2a2ejt) of the track.
I've compiled it long time ago on my G5 myself, but I just tried your universal binary: I get a bus error on my iMac G5 Maybe it's not realy "universal"?
"Universal" point to the fact that its both PPC and Intel code in the same binary.
Perhaps you don't run Mac OS 10.5, which is what I used to compile this...
Perhaps you don't run Mac OS 10.5, which is what I used to compile this...
Yes indeed. I'm still running 10.4
Does anyone know why I cannot download lame_enc.dll from LAME's site and instead have to go to RareWares?
Because the LAME site does not offer binaries at all due to patent restrictions (distributing sources does not require patent fees to be paid, distributing binaries does AFAIK).
Because the LAME site does not offer binaries at all due to patent restrictions (distributing sources does not require patent fees to be paid, distributing binaries does AFAIK).
Perhaps I am mistaken, but I think a few versions back that was possible.
Thank you for the reply.
Where does that blank come frome in "Lame 3.98.2" ?
@vpa:
You'll have to rename the directory you created. Make doesn't like paths containing blanks.
Thanks. It still doesn't work with gcc 3.3, but at least 4.0.1 compiles it now.
What is the problem with gcc 3.3? At what point will the build process fail?
What is the problem with gcc 3.3? At what point will the build process fail?
3.3 was labeled sometimes as a buggy version of gcc.
I have tried using version 3.4.5 in mingw (windows) and with it compiles just fine. Of course, it may be using different #define paths.
I'll give it a try again this evening and post the error log.
i have update lame to 3.98
but this version 3.98.2 is different i can't find the history about the 3.98.
2i mean in rarewares i can find 3.98.2
where can i find info about the improvement about 3.98.2 vs 3.98
in the history i can find this ,
nothing about the 3.98.2LAME 3.98.1 not yet released
* Rogério Brito:
o More fixes for the abx tool for Unix systems:
+ Plugged a memory leak.
+ Fixed an endianness problem: users of big-endian machines can now do abx tests.
o Fixed history's HTML doctype
o Fixed history so that it finally validates at W3's validator
o Fixed compilation of frontend mp3rtp.c. Thanks to Kris Karas. Bugtracker item [ 2015432 ] mp3rtp missing uint16_t in lame 3.98
* Robert Hegemann:
o Fix for Bugtracker item [ 2031704 ] --id3v1-only didnt work in 3.98-final
o Fix for Bugtracker item [ 2022035 ] encoder_padding value and resampling
o Fix for Bugtracker item [ 2029282 ] Frequency filtering API broken in 3.98
o Fix for Bugtracker item [ 2039648 ] potential memory leak in parse_args() function in parse.c
o Fix for some tagging issues:
+ Made search for ID3v1 genres more sloppy, abbrevations may match more often as some simple typos. Examples:
# --tg "Alt. Rock" matches genre "Alternate Rock"
# --tg "acapela" matches genre "A Cappella"
+ New switch --pad-id3v2-size "n": adds ID3v2 tag with n padding bytes.
LAME 3.98 July 4 2008
* Anton Sergunov:
o Frontend DirectShow: enabling LAME dshow filter to connect to "File Writer Filter".
* Rogério Brito:
o Updates to the Debian Packaging
o Fixes to the abx tool for Unix systems (so that more people can evaluate LAME's compression against the original files)
* Alexander Leidinger:
o explicitely link the math lib to the lame lib
o add switch to disable the use of the compaq optimized math lib
3.98.2 has a fix for a bug introduced in 3.98.1:
- [ 2123206 ] lame 3.98.1 segfaults with -h
Well, I freshly depacked the source and now it also works with gcc3.3
Something must have been messed up that worse that even a make clean didn't fix it.
and 3.98.2 is somehow broken. It doesn't compile on OS X. Neither with gcc 3.3 nor with 4.0.1 :
(cd .libs/libmp3lame.lax/libmpgdecoder.a && ar x /Users/frankseyen/Desktop/Lame 3.98.2/lame-398-2/libmp3lame/../mpglib/.libs/libmpgdecoder.a)
ar: /Users/frankseyen/Desktop/Lame: Inappropriate file type or format
make[3]: *** [libmp3lame.la] Error 1
I am having one hell of a time trying to figure out how to make the new Lame release work with EAC as it has no .exe file in the zip download! All the code stuff is so far over my head. I need simple answer as to how to get high rate VBR working with the new LAME release! (A command line code would be great once it is working!)
I realize there are many different command codes ( I have seen far too many! ) but don't know how to decide on what is best for a highest rate VBR encode in EAC.
Thanks in advance for any help.
Get the latest LAME bundle here (http://www.rarewares.org/dancer/dancer.php?f=226) (3.98.2)
Then, follow the wiki (http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame) for EAC + LAME
Forget about --vbr-new since it's by default in 3.98.2
--> -V0 %s %d
V0 is the best quality VBR setting
BUT:
Since the recent release of lame 3.98.2, I've read a lot of forum posts. Most of people who used V2 by the past now prefer V3 and even lower because of the constant development and improvement of the codec.
http://www.hydrogenaudio.org/forums/index....showtopic=65101 (http://www.hydrogenaudio.org/forums/index.php?showtopic=65101)
I'm 23, have a pretty good hearing and use V5.5 for portable. You'd be surprised the amazing quality you'll get.
My experience with embedding album art:
foobar2000 shows it. My hardware player doesn't.
If i embed an albumart from the same source file with mp3tag, both f2k and my hardware player show it.
What i found out: Mp3tag embeds the albumart as "front cover", but an albumart embedded with the lame encoder is called "other".
Is there a way to tell the encoder to embed the albumart as "front cover"? Or would you call it worth a change for one of the next versions?
Has anyone compiled 398.2 for os x. If you have can you please point me to it. Thanks
Has anyone compiled 398.2 for os x. If you have can you please point me to it. Thanks
If you are using a PowerPC Mac, then try Lame for OSX PPC (http://rapidshare.com/files/172954635/LAME-PPC.zip.html)
It contains a gcc 3.3 compile, a gcc 4.01 compile and a fresh cvs checkout (3.99 a1) compiled with gcc 4.01. I hope it's helpfull for you.
How about a version for the Intel side of OS X?
Thanks in advance.
Has anyone compiled 398.2 for os x. If you have can you please point me to it. Thanks
If you are using a PowerPC Mac, then try Lame for OSX PPC (http://rapidshare.com/files/172954635/LAME-PPC.zip.html)
It contains a gcc 3.3 compile, a gcc 4.01 compile and a fresh cvs checkout (3.99 a1) compiled with gcc 4.01. I hope it's helpfull for you.
Has anyone compiled 398.2 for os x. If you have can you please point me to it. Thanks
Thanks for the reply, Sorry I didn't respond quicker I was gone for the holiday.
I am not using PPC. Intel Imac 2g Core Duo with 10.5.6.
Just out of curiosity, why hasn't LAME v3.98.2 become the recommended version here at HA? Just about every music group (on "the scene") uses 3.97, prolly 'cuz it's HA-recommended. Me myself, I'm trying to figure out if there are any known disadvantages on 3.98 apart from 3.97? Known stability bugs? Compatibility bugs?? Anything(!) that would have you prefer 3.97 > 3.98.2? I've done lots of research, trying to fetch this answer someplace else, but there's not much to go on. And since I'm no audio pro, I'm kinda lost in a maze here..
Thankfor for all answers~
Just out of curiosity, why hasn't LAME v3.98.2 become the recommended version here at HA?....
Why do you say that? The Wiki clearly recommends 3.98.2.
Just out of curiosity, why hasn't LAME v3.98.2 become the recommended version here at HA? Just about every music group (on "the scene") uses 3.97, prolly 'cuz it's HA-recommended. Me myself, I'm trying to figure out if there are any known disadvantages on 3.98 apart from 3.97? Known stability bugs? Compatibility bugs?? Anything(!) that would have you prefer 3.97 > 3.98.2? I've done lots of research, trying to fetch this answer someplace else, but there's not much to go on. And since I'm no audio pro, I'm kinda lost in a maze here..
Thankfor for all answers~
"The Scene" appears to be slow to adopt new standards.
Why do you say that? The Wiki clearly recommends 3.98.2.
Maybe I am blind, but the wiki recommends the latest stable version, and the same page states that the latest stable version is 3.9
8.
not 3.98.2. I just fixed this in the wiki.