Hi people,
Just wondering if LAME is still in development. There seems to be a lot less activity in LAMe now and I was wondering if 3.93.1 is going to be the definitive in "best" quality for recording in .mp3 format.
There used to be a lot more activity in relases and forum discussion/testing and seing as though Car stereos still don't include the.ogg format the next choice is .wma.
Is this what we can expect or is LAME still comparable and under development.
Half the links to developent discussions don't even work any more.
I was wondering if 3.93.1 is going to be the definitive in "best" quality for recording in .mp3 format.
[a href="index.php?act=findpost&pid=255421"][{POST_SNAPBACK}][/a]
Where did you get that from? The recommended version is still 3.90.3 or the latest 3.96.1
3.96.1 came out in july i believe, that's pretty recent.
Right, but version 3.93.1 is pretty old
Right, but version 3.93.1 is pretty old
[a href="index.php?act=findpost&pid=255542"][{POST_SNAPBACK}][/a]
...yes, and you shouldn't use it either...
Right, but version 3.93.1 is pretty old
[a href="index.php?act=findpost&pid=255542"][{POST_SNAPBACK}][/a]
...yes, and you shouldn't use it either...
[a href="index.php?act=findpost&pid=255721"][{POST_SNAPBACK}][/a]
woops, I meant 3.90.3
3.90.3 is also very old. I understand it's supposed to be the best sounding. It is why I was asking if LAME was at the end of it's development as no movement (sorry I mean movement as in quality getting better with newer versions, ie: this is the best version) has been seen from 3.90.3 for a long time now and although there are more resent versions, releases seem more and more infrequent and still not recomended over ther 3.90.3 version.
Just after opinions as to if the .mp3 format is dead, I mean dead as in people are more interested in "other" formats now and so concentrate less on LAME.
(...) releases seem more and more infrequent (...)
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=256102\")
It's a joke?
[a href=\"http://cvs.sourceforge.net/viewcvs.py/lame/lame/doc/html/history.html?rev=1.70]http://cvs.sourceforge.net/viewcvs.py/lame...y.html?rev=1.70[/url]
3.95 - 3.95.1 - 3.96 - 3.96.1 - 3.97 alpha 1-> 4 were released this year, which was a very productive one.
and still not recomended over ther 3.90.3 version.
Generally speaking, lame 3.90.3 recommandations are done by people which can't ABX 3.90.3 over 3.96 (fortunately, there are exceptions). I wouldn't trust 95% of these
parrots people.
I prefer LAME 3.96.1 over LAME 3.90.3
I prefer LAME 3.96.1 over LAME 3.90.3
[a href="index.php?act=findpost&pid=256140"][{POST_SNAPBACK}][/a]
3.96.1 should be especially appealing for car stereos given the improvements it offers at lower bitrates, not to mention encoding is competitvely fast, and i haven't been able to abx the fast presets from the normal ones despite the filesizes are a bit smaller. whatever samples people have found regression in are more than made up for in improvements at portable-friendly bitrates since so many have them. getting more transparent(esp. with road noise) onto a disc faster can only be a good thing.
LAME 3.96 is 2X faster than 3.90.3 especialy with "preset"
an abvious advantage of 3.96 over 3.90
You're all also forgetting Takehiro's work on LAME4.0. This is currently at Alpha 11.
Last time I did this, I got into trouble , but here goes - you can d/l an exe of the latest 4.0 alpha 11 build from: http://homepage.ntlworld.com/jfe1205/lame4.0a11.zip (http://homepage.ntlworld.com/jfe1205/lame4.0a11.zip). But please remember this is an alpha build for testing only. This is purely for people to see how things are going. This is not to be used for archival, nor do I believe Takehiro is particulalry interested in detailed feedback at this time. When he's ready for this, he'll request it.
You're all also forgetting Takehiro's work on LAME4.0. This is currently at Alpha 11.
Last time I did this, I got into trouble , but here goes - you can d/l an exe of the latest 4.0 alpha 11 build from:
[a href="index.php?act=findpost&pid=256157"][{POST_SNAPBACK}][/a]
I agree, you shouldn't post this since there is no point in using it (unless you are bored)...it's even more dangerous than the 3x alpha releases...
any info on when lame 4 is going to "air"?
You're all also forgetting Takehiro's work on LAME4.0. This is currently at Alpha 11.
Last time I did this, I got into trouble , but here goes - you can d/l an exe of the latest 4.0 alpha 11 build from: http://homepage.ntlworld.com/jfe1205/lame4.0a11.zip (http://homepage.ntlworld.com/jfe1205/lame4.0a11.zip). But please remember this is an alpha build for testing only. This is purely for people to see how things are going. This is not to be used for archival, nor do I believe Takehiro is particulalry interested in detailed feedback at this time. When he's ready for this, he'll request it.
[a href="index.php?act=findpost&pid=256157"][{POST_SNAPBACK}][/a]
Do you know what the goals for 4.0 are? Will it be significantly different from 3x?
Do you know what the goals for 4.0 are? Will it be significantly different from 3x?[a href="index.php?act=findpost&pid=257188"][{POST_SNAPBACK}][/a]
LAME4 is now in the late-alpha stage. One of its final goal is to define the goal
Current LAME4's Main goal is "destory all the obstacles to improve the quality/speed, which is made by OLD code".
"Improving quality" itself is not current goal, but "to lay the foundations for it" is the goal.
Maybe after archiving this goal, I will do the next goal (improving quality by tuning the parameters). That will be beta stages' work, after Christmas or the new year.
edit: tag is not closed. oops.
Do you know what the goals for 4.0 are? Will it be significantly different from 3x?[a href="index.php?act=findpost&pid=257188"][{POST_SNAPBACK}][/a]
LAME4 is now in the late-alpha stage. One of its final goal is to define the goal
Current LAME4's Main goal is "destory all the obstacles to improve the quality/speed, which is made by OLD code".
"Improving quality" itself is not current goal, but "to lay the foundations for it" is the goal.
Maybe after archiving this goal, I will do the next goal (improving quality by tuning the parameters). That will be beta stages' work, after Christmas or the new year.
edit: tag is not closed. oops.
[a href="index.php?act=findpost&pid=257995"][{POST_SNAPBACK}][/a]
i must suppose that by "improving the quality/speed" you mean to improve the speed but maintain the lame 3.9x quality, right?
Do you know what the goals for 4.0 are? Will it be significantly different from 3x?[a href="index.php?act=findpost&pid=257188"][{POST_SNAPBACK}][/a]
LAME4 is now in the late-alpha stage. One of its final goal is to define the goal
Current LAME4's Main goal is "destory all the obstacles to improve the quality/speed, which is made by OLD code".
"Improving quality" itself is not current goal, but "to lay the foundations for it" is the goal.
Maybe after archiving this goal, I will do the next goal (improving quality by tuning the parameters). That will be beta stages' work, after Christmas or the new year.
edit: tag is not closed. oops.
[a href="index.php?act=findpost&pid=257995"][{POST_SNAPBACK}][/a]
i must suppose that by "improving the quality/speed" you mean to improve the speed but maintain the lame 3.9x quality, right?
[a href="index.php?act=findpost&pid=258044"][{POST_SNAPBACK}][/a]
...and hopefully get rid of 'Stereo' (and use JS instead), unsafe JS, CBR-Encoding and stupid command lines that either bloat filesize and don't achive anything in terms of quality - or making a file sound worse at a bitrate were better sound could be achived
Well, if someone wants to take over the frontends for v4, the position is open.
We will use v4 to clean some features of the frontends, but Takehiro's time is more usefull inside the encoder.
Sorry, if I missed this, but is Intensity Stereo planned for LAME 4.0?
Would it be possible to have mp3gain in Lame 4.0 ?
Sorry, if I missed this, but is Intensity Stereo planned for LAME 4.0?
Yes
Would it be possible to have mp3gain in Lame 4.0 ?
This is possible with ANY mp3 encoder.
Would it be possible to have mp3gain in Lame 4.0 ?
[a href="index.php?act=findpost&pid=258097"][{POST_SNAPBACK}][/a]
LAME 3.96.1 already writes ReplayGain information to the LAME header. However, there is no application supporting this AFAIK.
Well, if someone wants to take over the frontends for v4, the position is open.
We will use v4 to clean some features of the frontends, but Takehiro's time is more usefull inside the encoder.
[a href="index.php?act=findpost&pid=258077"][{POST_SNAPBACK}][/a]
what you mean by frontend?
what you mean by frontend?
The frontends are lame.exe, lame.dll, acm codec, directshow filter.
This is possible with ANY mp3 encoder.
LAME 3.96.1 already writes ReplayGain information to the LAME header. However, there is no application supporting this AFAIK.
(Apologizes in advanced I new to this )
On my portables the replaygain does not do seem to do anything. I think the
hardware just skips this. Mp3 gain changes the a value about loudness in the
frames ?
I think it would be realy cool if lame could take a second pass if say --mp3gain
was enabled to change the files gain to avoid the clipping.
Also is the q 0 switch fixed. I have no real regard for encoding time. But like
to know the huffman coding is making the files small. (or have i got this wrong )
But like to know the huffman coding is making the files small. (or have i got this wrong )
[a href="index.php?act=findpost&pid=258117"][{POST_SNAPBACK}][/a]
Not sure if I got you right here... The Huffman coding kicks at the end of the encoding process after most of the "squeezing" took place.
The Huffman Coding
At the end of the perceptual coding process, a second compression process is run. However, this second round is not a perceptual coding, but rather a more traditional compression of all the bits in the file, taken together as a whole. To use a loose analogy, you might think of this second run, called the " Huffman coding," as being similar to zip or other standard compression mechanisms (in other words, the Huffman run is completely lossless, unlike the perceptual coding techniques). Huffman coding is extremely fast, as it utilizes a look-up table for spotting possible bit substitutions. In other words, it doesn't have to "figure anything out" in order to do its job.
The chief benefit of the Huffman compression run is that it compensates for those areas where the perceptual masking is less efficient. For example, a passage of music that contains many sounds happening at once (i.e., a " polyphonous" passage) will benefit greatly from the masking filter. However, a musical phrase consisting only of a single, sustained note will not. However, this passage can be compressed very efficiently with more traditional means, due to its high level of redundancy. On average, an additional 20% of the total file size can be shaved during the Huffman coding.
The Huffman coding:
The MP3 also uses the classic technique of the Huffman algorithm. It acts at the end of the compression to code information, and this is not therefore itself a compression algorithm but rather a coding method.
This coding creates variable length codes on a whole number of bits. Higher probability symbols have shorter codes. Huffman codes have the property to have a unique prefix, they can therefore be decoded correctly in spite of their variable length. The decoding step is very fast (via a correspondence table). This kind of coding allows to save on the average a bit less than 20% of space.
It is an ideal complement of the perceptual coding: During big polyphonies, the perceptual coding is very efficient because many sounds are masked or lessened, but little information is identical, so the Huffmann algorithm is very seldom efficient. During "pure" sounds there are few masking effects, but Huffman is then very efficient because digitalized sound contains many repetitive bytes, that will then be replaced by shorter codes.
Ah cool thanks, Does Lame do huffman coding with the presets ?
I think it would be realy cool if lame could take a second pass if say --mp3gain
was enabled to change the files gain to avoid the clipping.
Also is the q 0 switch fixed. I have no real regard for encoding time. But like
to know the huffman coding is making the files small. (or have i got this wrong )
[a href="index.php?act=findpost&pid=258117"][{POST_SNAPBACK}][/a]
That's a feature I'm dreaming about all the time, because now I can only do MP3Gain modification which is lowering the volume too much from the original.
Or I can use --scale 0.9X but I could never know if the result will be without clipping. That's too much pain to achieve my goal
I the other hand that's true that HW players ignore ReplayGain informations, the only thing how to avoid clipping is MP3Gain modification AFAIK...
Yes, the fixed -q 0 switch would be nice...
I still don't have a clue why there are the options of -q 0 and -q 1, when they are not safe and flawless...
That's a feature I'm dreaming about all the time, because now I can only do MP3Gain modification which is lowering the volume too much from the original.
Or I can use --scale 0.9X but I could never know if the result will be without clipping. That's too much pain to achieve my goal
I the other hand that's true that HW players ignore ReplayGain informations, the only thing how to avoid clipping is MP3Gain modification AFAIK...
Yes, the fixed -q 0 switch would be nice...
I still don't have a clue why there are the options of -q 0 and -q 1, when they are not safe and flawless...
I see i never thought of using --scale. Thanks. Does scale time each samples
value by 0.n making less chance of a sample over 32768 ?
I see i never thought of using --scale. Thanks. Does scale time each samples
value by 0.n making less chance of a sample over 32768 ?
[a href="index.php?act=findpost&pid=258150"][{POST_SNAPBACK}][/a]
Yes, I think it's quite obvious, but you can never guess if it is enough to avoid clipping or if it isn't too much...
Edit: So you have to encode with some --scale setting and then verify it by MP3Gain if it is clipping free... And so on...
I see i never thought of using --scale. Thanks. Does scale time each samples
value by 0.n making less chance of a sample over 32768 ?
[a href="index.php?act=findpost&pid=258150"][{POST_SNAPBACK}][/a]
Yes, I think it's quite obvious, but you can never guess if it is enough to avoid clipping or if it isn't too much...
Edit: So you have to encode with some --scale setting and then verify it by MP3Gain if it is clipping free... And so on...
[a href="index.php?act=findpost&pid=258151"][{POST_SNAPBACK}][/a]
I will test it out this week end. I do not mind the odd sample. But encoding
"All becuase of you" from U2 gives terrible clipping at 98db. I do not undestand
why newer cd are masterd so loud.
Just like to say great work with lame. I can not wait to test the beta of 4.0
when it hapens
Yes, the fixed -q 0 switch would be nice...
I still don't have a clue why there are the options of -q 0 and -q 1, when they are not safe and flawless...
They are fixed in current alpha version.
Well, if someone wants to take over the frontends for v4, the position is open.
[a href="index.php?act=findpost&pid=258077"][{POST_SNAPBACK}][/a]
great! So LAME will finally come with a GUI!
Sorry, if I missed this, but is Intensity Stereo planned for LAME 4.0?
Yes
[a href="index.php?act=findpost&pid=258105"][{POST_SNAPBACK}][/a]
I just learned that Intensity Stereo is lossy...what would be the use for that? Doesn't Joint-Stereo work good enough already?
Well, if someone wants to take over the frontends for v4, the position is open.
[a href="index.php?act=findpost&pid=258077"][{POST_SNAPBACK}][/a]
great! So LAME will finally come with a GUI!
[a href="index.php?act=findpost&pid=258160"][{POST_SNAPBACK}][/a]
frontend != GUI
what you mean by frontend?
The frontends are lame.exe, lame.dll, acm codec, directshow filter.
[a href="index.php?act=findpost&pid=258116"][{POST_SNAPBACK}][/a]
great! So LAME will finally come with a GUI!
No
Well...Lame 4.0 alpha 11 seems to be very good with APS...
Gabriel,can u tell me why qval is locked with vbr?
I just learned that Intensity Stereo is lossy...what would be the use for that? Doesn't Joint-Stereo work good enough already?
Intensity Stereo should be better than Mid-Side Stereo for low bitrates.
By Joint Stereo I assume you mean Lames Mid-Side stereo implementation. Both Mid-Side Stereo and Intensity Stereo are Joint Stereo.
You're all also forgetting Takehiro's work on LAME4.0. This is currently at Alpha 11.
Last time I did this, I got into trouble , but here goes - you can d/l an exe of the latest 4.0 alpha 11 build from: http://homepage.ntlworld.com/jfe1205/lame4.0a11.zip (http://homepage.ntlworld.com/jfe1205/lame4.0a11.zip). But please remember this is an alpha build for testing only. This is purely for people to see how things are going. This is not to be used for archival, nor do I believe Takehiro is particulalry interested in detailed feedback at this time. When he's ready for this, he'll request it.
[a href="index.php?act=findpost&pid=256157"][{POST_SNAPBACK}][/a]
Wow that Lame4 alpha is a blindingly fast encoder. About 4 times as fast as 3.96.1 and nearly 8 times as fast as 3.90.3 on my system. I'll be watching for that to become beta or release.
You're all also forgetting Takehiro's work on LAME4.0. This is currently at Alpha 11.
Last time I did this, I got into trouble , but here goes - you can d/l an exe of the latest 4.0 alpha 11 build from: http://homepage.ntlworld.com/jfe1205/lame4.0a11.zip (http://homepage.ntlworld.com/jfe1205/lame4.0a11.zip). But please remember this is an alpha build for testing only. This is purely for people to see how things are going. This is not to be used for archival, nor do I believe Takehiro is particulalry interested in detailed feedback at this time. When he's ready for this, he'll request it.
[a href="index.php?act=findpost&pid=256157"][{POST_SNAPBACK}][/a]
Wow that Lame4 alpha is a blindingly fast encoder. About 4 times as fast as 3.96.1 and nearly 8 times as fast as 3.90.3 on my system. I'll be watching for that to become beta or release.
[a href="index.php?act=findpost&pid=263128"][{POST_SNAPBACK}][/a]
Holy Cow!
It took only 17 sec. to encode a 4 minute song on my P4-3,4Ghz.
(with --preset cbr 128) Well, I know he doesn't want any feedback but this is so amazing!
Holy Cow!
It took only 17 sec. to encode a 4 minute song on my P4-3,4Ghz.
Maybe it's more highly optimised for the Athlon at the moment becuase I'm getting nearly double that speed (about 8 seconds to encode a 4 minute track) on my AthlonXP 2800+. That was using vbr (-V4) which is the same as the old --alt preset medium. The default cbr 128 is much the same speed.
Hang on, I just found the "-h" (high quality mode) option, yeah that slows down the cbr encoding quite a bit. My cbr encoding time goes up to about 16 seconds (4 min track) with that option. It doesn't seem to have any effect on my vbr ecoding times however, which are still amazingly fast at about 7 or 8 seconds per 4 minute track !
just wanted to give out a short "thank You" to Takehiro, Gabriel and the other LAME people that probably don't post here
by the way, what ever happened to Naokis nspytune2 before he retired?
I just read something about it on his old dev notes.
It encoded a 7 minute song in about 20 seconds using -V 2...!
I tested fatboy at 128 kbps using 4.0 alpha 11 and 3.96.1, and the latter definately has better quality, though of course neither is transparent. Certainly, it's only an alpha, so what can you expect?
Not transparency, that's what.
I found it pretty interesting that LAME 4.0 alpha --preset standard lowpasses at ~17000 hz but still produces a higher bitrate than LAME 3.96.1 even though it lowpasses at ~ 19000 hz...I always thought high frequencies are the 'most expensive' ones...so that doesn't make any sense to me...
4.0 is not yet tuned.
You can play with it, but I would advise you to NOT USE IT for production.
4.0 is not yet tuned.
You can play with it, but I would advise you to NOT USE IT for production.
[a href="index.php?act=findpost&pid=263395"][{POST_SNAPBACK}][/a]
Gabriel, why is there development of LAME v4.0 whilst LAME 3.97 is still being developed? From a dev lifecycle point of view it doesn't seem logical to go from 3.97 to 4.0 (I know neither are released yet or indeed in beta form). Does 4.0 have everything that 3.97 has?... but more. Will ther be 3.98, 3.99?
I guess what I'm really trying to get at is, why invest time to work on and release 3.97 when those developers could work on 4.0 and possibly get that version out sooner?
BTW this isn't me having a go or anything, I'm simply interested from a LAME progression point of view, and as a developer myself.
Thanks
jb
Lame 3.xx is reaching the end of its possible enhancements, regarding both speed and quality.
The current goal of v4 is to build a new solid basis removing current limitations as much as possible. Right now the v4 task is more an architectural one than a tuning or polishing one.
Thus it is not very important if v4 doesn't have the same tunings as the latest 3.xx versions.
Lame 3.xx is reaching the end of its possible enhancements, regarding both speed and quality.
The current goal of v4 is to build a new solid basis removing current limitations as much as possible. Right now the v4 task is more an architectural one than a tuning or polishing one.
Thus it is not very important if v4 doesn't have the same tunings as the latest 3.xx versions.
[a href="index.php?act=findpost&pid=263458"][{POST_SNAPBACK}][/a]
Great, thanks. Makes sense.
3.97alpha5 is now available at Rarewares.
3.97alpha5 is now available at Rarewares.
[a href="index.php?act=findpost&pid=263987"][{POST_SNAPBACK}][/a]
What's the difference between alpha 4 and alpha 5?
What's the difference between alpha 4 and alpha 5?
[a href="index.php?act=findpost&pid=264112"][{POST_SNAPBACK}][/a]
Gabriels post on the Lame 3.97.4 thread was:
3.97a5 is comitted in cvs.
I'd mainly like opinions about "-b 128 -X 10,10" against 3.90.3.
It also includes a few tuning changes to all presets.
Lame 4.0 alpha 12 is now available: http://homepage.ntlworld.com/jfe1205/lame4.0a12.zip (http://homepage.ntlworld.com/jfe1205/lame4.0a12.zip).
Same warnings apply as before regarding usage.
Lame 4.0 alpha 12 is now available: http://homepage.ntlworld.com/jfe1205/lame4.0a12.zip (http://homepage.ntlworld.com/jfe1205/lame4.0a12.zip).
Same warnings apply as before regarding usage.
[a href="index.php?act=findpost&pid=264333"][{POST_SNAPBACK}][/a]
Great
First impressions...
The quality on the alpha 12 it's improved again,i've done a 96 kbps encoding,sounds more clear than alpha 11 No bitrate/speed tests yet
Edit: Bug,i guess...
with --alt-preset 112
the log reports
Encoding as 44.1 kHz average 111 kbps j-stereo MPEG-1 Layer III (12.6x) qval=5
111?
Edit n.2
There's a quality problem
Encoded with APS,but also with --alt-preset 96,112,128,160...even with 320,still problems with cbr @96kbps,112,128,160....less @224,no more problems @256 and above
http://djlux.altervista.org/base_a12.mp3 (http://djlux.altervista.org/base_a12.mp3)
No problems with 3.97 Alpha 5
http://djlux.altervista.org/base_397.mp3 (http://djlux.altervista.org/base_397.mp3)
Is the Lame 4.0 alpha sourcecode available?
Is the Lame 4.0 alpha sourcecode available?
[a href="index.php?act=findpost&pid=265448"][{POST_SNAPBACK}][/a]
Yes, from the CVS. You'll need to check out by tag/branch - "takehiro-2002_05_07-experimental" (without the quotes).
Thanks John.
After some searching I found your instructions to checkout LAME 4.0 here:
http://www.hydrogenaudio.org/forums/index....ic=9238&st=50&# (http://www.hydrogenaudio.org/forums/index.php?showtopic=9238&st=50&#)
(Link posted in case someone else finds it useful)
Not sure if anyone is interested in this sort of bug with Lame4 at this stage but I'll post it here anyway. When I tryed to encode from Lame4 (both alpha 11 and 12) from the foobar2000 CLI diskwriter plugin then it failed to encode properly. Some files seemed to be encoded ok but others were zero bytes? The same files however all ecoded 100% fine when lame4 was rubn from a command line.
Any ideas?