Skip to main content ↑ ↓

Notice

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

Update to the --dm-presets now in the Official L.A.M.E.

The long awaited --alt-presets have finally made it into the mainline L.A.M.E.!

Basically the changes include everything that was in lame_dm_rev7 (http://www.hydrogenaudio.org/forums/showth...s=&threadid=411).

In addition, I have ported the modifications and tunings over the vbr-mtrh which means that "--alt-preset fast standard" and the like now have a similar increase in quality especially on impulses and everything that the slower modes improved on.

In short:

1. --alt-preset standard is lower in bitrate than before.
2. Bitrates with --alt-preset standard now come very close to --r3mix but do not dip as low or bloat as much (the bitrate is in general more stable).
3. --alt-preset standard is even higher in quality than before.
4. Areas improved upon include impulse handling, pre-echo handling, joint stereo thresholds, noise measuring usage improvements, noise shaping usage improvement, etc.
5.  Clips which show large improvements over --dm-preset standard include fatboy, spahm, them, gbtinc, ravebase, short.  Others include florida_seq, death2, castanets, etc.
6.  Lower volume clips have generally been improved (and usually the bitrate does not go as low or too low).

Now that these changes are in, it looks like a new beta/stable of L.A.M.E. could come out any day now, so I'd advise everyone to test out this current alpha (http://static.hydrogenaudio.org/extra/lame_dm_rev8.zip) in case there may be any last minute outstanding issues.

Update to the --dm-presets now in the Official L.A.M.E.

Reply #1 –
Great work Dibrom...

Did I read you correctly that the fast option retains ALL (or is it most) of the quality of --alt-preset standard?

If --alt-preset fast standard is just a good quality wise then there is no reason to use --alt-preset standard

Also have you added the tweaks to extreme and insane?

Thanks for the great work!!!

Update to the --dm-presets now in the Official L.A.M.E.

Reply #2 –
Quote
Originally posted by RD
Great work Dibrom...


Thanks.

Quote
Did I read you correctly that the fast option retains ALL (or is it most) of the quality of --alt-preset standard?

If --alt-preset fast standard is just a good quality wise then there is no reason to use --alt-preset standard


Yes, it uses all of the same modifications as the normal mode, but due to differences in the vbr modes (old vs mtrh), I cannot implement them in exactly the same fashion.  In addition, it is not tested as heavily as the non-fast mode and the quality is not quite as high on some of the more difficult signals (its slightly worse on impulses but not by much) so for those reasons I have not defaulted it yet.

Quote
Also have you added the tweaks to extreme and insane?


Yes.

Update to the --dm-presets now in the Official L.A.M.E.

Reply #3 –
One other question about standard fast - will it have a higher bitrate than standard, as the other fast options do?
It's is not, it isn't ain't, and it's it's, not its, if you mean it is.  If you don't, it's its.

Update to the --dm-presets now in the Official L.A.M.E.

Reply #4 –
Quote
Originally posted by Amadeus93
One other question about standard fast - will it have a higher bitrate than standard, as the other fast options do?


Not necessarily.  It should be roughly around the same.  I'll have to encode some more albums to be sure but the difference doesn't seem too great right now and sometimes it goes up slightly, sometimes it goes down slightly.

Update to the --dm-presets now in the Official L.A.M.E.

Reply #6 –
Great, thank you Dibrom!

Update to the --dm-presets now in the Official L.A.M.E.

Reply #7 –
freeeeeakin awsome shit Dibrom!  just updated all my artists music sites to use the new preset, and I made sure to give ya big props

Quote
Originally posted by Dibrom
or if you prefer MSVC:
whats MSVC?  some sort of compression algorithm type thingy?

Update to the --dm-presets now in the Official L.A.M.E.

Reply #8 –
Quote
Originally posted by SNYder
whats MSVC?  some sort of compression algorithm type thingy?

Different compiler.
This thread: http://www.hydrogenaudio.org/forums/showth...s=&threadid=467
Has some information on the differences between ICL and MSVC

Update to the --dm-presets now in the Official L.A.M.E.

Reply #9 –
da da da!  Somebody to the rescue!

ok... let me make sure I read this correctly.

So ICL will produce larger files but much faster and (possibly) a microscopic bit less accurate...

and MSVC will make smaller files but will take a lot longer since it is not optimized code?  or not optimized as much?

is this correct? 

[edit]do either of these decrease the file size of lame.exe itself  (the MSVC lame.exe is much smaller)?  or are they just meant to increase speed?

sorry for all the questions  ... gotta learn sometime

[edit2]Just encoded a file using both compiled versions.  the ICL mp3 came out to 6,809KB and the MSVC came out to 6,638KB.  That was expected, but what was unexpected was that both files took almost exactly the same amount of time to encode (9min30sec) for a 5min23sec rap song. :confused:

Update to the --dm-presets now in the Official L.A.M.E.

Reply #10 –
Quote
Originally posted by SNYder
freeeeeakin awsome shit Dibrom!   just updated all my artists music sites to use the new preset, and I made sure to give ya big props


Thanks

Quote
So ICL will produce larger files but much faster and (possibly) a microscopic bit less accurate... 

and MSVC will make smaller files but will take a lot longer since it is not optimized code? or not optimized as much? 

is this correct?


Pretty much.  The "less accurate" part should be clarified though.  "Less accurate" only means not as accurate on the math operations, but that doesn't necessarily mean it leads to lower quality, it could go either way.  What I mean is because the math operations may not be as precise, the encoder may end up spending more bits or less bits somewhere but you can't really gauge on a whole how that is going to affect quality.  The good thing is that so far, I don't know of a situation where ICL has produced a worse sounding file than MSVC or the other way around.

Quote
do either of these decrease the file size of lame.exe itself (the MSVC lame.exe is much smaller)? or are they just meant to increase speed?


ICL usually actually produces a larger .exe from the use of automatic mmx and other things like that which tend to increase size.  Most of the time I use upx to compress the .exe though so it doesn't really matter afterwards.

Quote
Just encoded a file using both compiled versions. the ICL mp3 came out to 6,809KB and the MSVC came out to 6,638KB. That was expected, but what was unexpected was that both files took almost exactly the same amount of time to encode (9min30sec) for a 5min23sec rap song.


Hrmm.. well usually the ICL compile is faster, I can verify that.. but it will very from file to file.  Sometimes it's alot faster, sometimes its not too much faster.

Update to the --dm-presets now in the Official L.A.M.E.

Reply #11 –
did you upx the two compiles you made above?  i figure you did.

anyway...  why do you and Dmitry use ICL as standard practice if it leads to larger files?  I've seen in my own files, on average, a 200KB increase.

If one of the constant ongoing struggles is to get mp3's smaller and smaller without sacrificing quality, why use ICL?  I mean, there's 200 extra KB's off the filesize plus a microscopic extra bit of quality (in theory ) for ya.

I guess it's the speed issue, but wouldn't you agree that speed over size is not usualy the preference people go for? (atleast not the people i know.... forums.winamp.com)

I weigh this as "an extra minute saved" on one side of the scale, and "200KB smaller file" on the other side.  Dealing with multiple artists music pages...  the more downloads the better, and the smaller the filesize the more downloads.

2 cents =

Update to the --dm-presets now in the Official L.A.M.E.

Reply #12 –
Quote
Originally posted by SNYder
did you upx the two compiles you made above?  i figure you did.


Yes.

Quote
anyway...  why do you and Dmitry use ICL as standard practice if it leads to larger files?  I've seen in my own files, on average, a 200KB increase.


Because of speed.  Many people complain that --alt-preset standard is too slow, especially for those that do not have p3's or higher so any extra gain in that department is helpful to them.

Quote
If one of the constant ongoing struggles is to get mp3's smaller and smaller without sacrificing quality, why use ICL?   I mean, there's 200 extra KB's off the filesize plus a microscopic extra bit of quality (in theory ) for ya.


Well if we are really going for the smallest file sizes we might as well use gcc or something like that... of course it's much slower.  Personally, I don't mind the tad bit of bitrate increase for the gain in speed.  As for quality, it's not even theoretically lower.  The math operations are not as accurate, but that doesn't mean lower quality.  It could go both ways, in fact leading to higher quality in some cases.. it just depends.

Quote
I guess it's the speed issue, but wouldn't you agree that speed over size is not usualy the preference people go for? (atleast not the people i know.... forums.winamp.com)


I think it's really an issue of balance.  MSVC does provide a pretty nice balance, but I'd opt for ICL myself... maybe it's just me.

Quote
I weigh this as "an extra minute saved" on one side of the scale, and "200KB smaller file" on the other side.  Dealing with multiple artists music pages...  the more downloads the better, and the smaller the filesize the more downloads.


I can understand this point of view, which is why I've included an MSVC version also

Update to the --dm-presets now in the Official L.A.M.E.

Reply #13 –
Quote
Originally posted by Dibrom
Well if we are really going for the smallest file sizes we might as well use gcc or something like that... of course it's much slower.
hmmm...  do you think you could point me in the direction of this gcc compiler (or whatever provides the lowest size without andy quality loss) and mabey a site which explains the steps to compiling (since I never have ).

Quote
Originally posted by Dibrom
As for quality, it's not even theoretically lower.  The math operations are not as accurate, but that doesn't mean lower quality.  It could go both ways, in fact leading to higher quality in some cases.. it just depends.
Oh... ok.  I understand now

Quote
Originally posted by Dibrom
I can understand this point of view, which is why I've included an MSVC version also
tanka tanka

Update to the --dm-presets now in the Official L.A.M.E.

Reply #14 –
snyder,

what's your os? on mac osx, installing the developer tools installs gcc, which apple calls "cc". the tools are available at http://www.apple.com/developer/ -- free registration required.

once gcc is installed, to compile, simply "cd" to the newly created lame directory. "sudo -s" into root. then "./configure" wait "make" wait "make install" wait. you are done. "rehash" to get your shell to acknowledge the changes.

you can now type "lame --alt-preset standard" and point to a .aif and it will encode. or you can use a script to encode an entire directory at a time, seriatim, such as:

Code: [Select]
for i in *.aif

do

echo "lameing ${i}"

lame --alt-preset standard "$i"

done


save the script and make it executable, then call it while you are in your desired directory.

thanks to applescript, there is hope for even more ease-of-use in using the cl version of lame on the mac (to my knowledge, no gui versions exist that give you control over the presets). check out the script discovered by this page:

http://www.macosxhints.com/article.php?sto...011210092939561

the gcc compile of lame is very slow on my mac -- i doubt any compile would be very fast on a mac -- but i have a couple of dualies, so i have 6 or so terminal windows open at a time churning away (half of them via ssh). in any event, the product is worth the wait, imo.

brett.

ps -- i still can't get any version of rev8 source from here to "./configure" on my mac (i've had mail from a few otherswith the same experience). i had no problems compiling rev7 previously. and the daily alphas from cedirc.vabo i've tried -- including today's, which should have rev8 changes incorporated -- also compile without problems. i'll keep looking into it.

Update to the --dm-presets now in the Official L.A.M.E.

Reply #15 –
thanks for tryin to help, but I'm on WinXP

Update to the --dm-presets now in the Official L.A.M.E.

Reply #16 –
http://www.hydrogenaudio.org/forums/showth...hp?threadid=324

Discusses some things about compiling LAME with Mingw

Another place that discusses it although for DJGPP (which is another gcc port to win32) is here:

http://www.maindex.com/lame/howto/

There are probably some others somewhere, and you could probably contact john33 or RD for more specific information on how to do it under Mingw if that's what you want to use.  Hope that helps some..

Update to the --dm-presets now in the Official L.A.M.E.

Reply #17 –
OK.  I've spent the last hour downloading setting up, testing, and kinda learning how to compile LAME with DJGPP.

After many painstaking compleat failueres to even get this sucker to compiling for more then 2 seconds, I get it to goooooo!  I was so happy until BAM!

ERROR ERROR ERROR! :eek:

Add on another half an hour of trying to solve the problem myself.

Now I am forced to ask for help

ok.... so it compiles for a while and then stops at this one spot (which come right after it makes libmp3lam/interface.o) ...  I'm not gonna type it all...  so I'll insert some (.......) thingy's to skip parts.

----------------------------------------------------------------------

ar cr libmp3lame/libmp3lame.a  libmp3/bitstream.o  libmp3lame/encoder.o  libmp3lame/fft.o  .............  mpglib/layer3.o  mpglib/tabinit.o  mpglib/interface.o
D:DJGPPBIN/ar.exe: libmp3lame/libmp3lame.a: rename: Not enough memory (ENOMEM)
make.exe *** [libmp3lame/libmp3lame.a] Error 1

----------------------------------------------------------------------

Please tell me it has nothing to do with my memory  But I fear this is so. 

I'm running WinXP Pro, 128mb SD-RAM, Athlon K-6
Using all the latest DJGPP Basic files as suggested from that site
Trying to endode your LAME 2.90.2 Plain

Update to the --dm-presets now in the Official L.A.M.E.

Reply #18 –
It has to do with DJGPP running out of memory in it's environment or something like that.  I suggest you compile with:

MingW

or

CygWin

Update to the --dm-presets now in the Official L.A.M.E.

Reply #19 –
SNYder

If you want to switch to using MinGW32, I can send you the relevant 'fully working' makefiles for lame.exe and for lame_enc.dll, and DOS batch files to run the whole thing for you.

If you want them, private message me with your mail address.

john33

Update to the --dm-presets now in the Official L.A.M.E.

Reply #20 –
[deleted]

Update to the --dm-presets now in the Official L.A.M.E.

Reply #21 –
hmmmm...  i read a lot of documentation, but I guessed I missed that

I'll try MinGW.  Thanks for the help/info guys

check ya pm, john.

Update to the --dm-presets now in the Official L.A.M.E.

Reply #22 –
Thanks a lot guys!    I got this sucka to work!  Only freakin took me an hour to set up  Kept gettin errors.

Anyway... Dibrom,  check ya pm.

Peace.

Update to the --dm-presets now in the Official L.A.M.E.

Reply #23 –
[deleted]

Update to the --dm-presets now in the Official L.A.M.E.

Reply #24 –
i built several test versions of lame using icl 5.0, msvc, mingw. well it seems that the mingw is much faster then msvc, but produces a similiar file:

msvc --alt-preset standard
C:mp>lametest2 --alt-preset standard test.wav testtest2.mp3
LAME version 3.90 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding test.wav to testtest2.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  8989/8991  (100%)|    2:12/    2:12|    2:12/    2:12|  1.7750x|    0:00
32 [  43] *
128 [ 313] %******
160 [1206] %%%%%*********************
192 [3112] %%%%%%%%%%%%%%%%%*************************************************
224 [2973] %%%%%%%%%%%%%%%*************************************************
256 [1015] %%%%******************
320 [ 330] %%*****
average: 207.2 kbps  LR: 1949 (21.67%)  MS: 7043 (78.33%)

mingw --alt-preset standard
C:mp>lamemin --alt-preset standard test.wav testmin.mp3
LAME version 3.90  (http://www.mp3dev.org/)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding test.wav to testmin.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  8989/8991  (100%)|    1:17/    1:17|    1:17/    1:17|  3.0131x|    0:00
32 [  43] *
128 [ 313] %******
160 [1206] %%%%%*********************
192 [3112] %%%%%%%%%%%%%%%%%*************************************************
224 [2973] %%%%%%%%%%%%%%%*************************************************
256 [1015] %%%%******************
320 [ 330] %%*****
average: 207.2 kbps  LR: 1949 (21.67%)  MS: 7043 (78.33%)
hmm faster, and same filesize. i wonder which one id use...

fc confirms that. http://www.mycgiserver.com/~superorc/lame.zip for my mingw compile