List of recommended LAME compiles, Discussion Options

[Dibrom]

Originally posted by AgentMil
Dibrom is it possible to upload test results as in a text file onto this forum?

Not at the moment since I have attachments disabled. I'll probably be changing this soon.

For now, you can just paste your histogram in here and use the:

[code ][/ code] (no spaces in the brackets) to surround the text..

It should come out formatted correctly.

[superorc]

hehe ok i guess im happy with 4.7x compared to .24 ;-)

EDIT: im not even concerned over disk usage esp. since i have 60 gigs free form 80 total ;-)

EDIT 2:hmm gcc for linux and msvc must be real similiar:

CODE

[root@192 root]# lame --alt-preset standard fatboy.wav fatboy.mp3

LAME version 3.90  ([url]http://www.mp3dev.org/[/url])

Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz

Encoding fatboy.wav to fatboy.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

  191/193    (99%)|    0:25/    0:25|    0:25/    0:25|   0.1993x|    0:00

32 [  1] *$<3>

128 [  6] %%%%*$<3>

160 [ 26] %%%%%%%%%%%%%%*****$<3>

192 [  9] %%%%***$<3>

224 [ 11] %*******$<3>

256 [ 49] %%**********************************$<3>

320 [ 91] %*****************************************************************$<3>

average: 263.3 kbps   LR: 33 (17.10%)   MS: 160 (82.90%)



Writing LAME Tag...done

[root@192 root]#

[CiTay]

Originally posted by AgentMil
It also seems that there is two different compiles of mitioks binaries.

I downloaded one from mitioks site as soon as it was available, and then today I decided to download it again (because it was not on my laptop, and was too lazy to boot up desktop to copy file), and then went to run, I noticed that the ")" at the end of the (www.mp3-dev.org) had reappeared in the "new" exe as in the first release exe the ) was missing, so I booted up my desktop and did fc/b on the two exe, and found that it was different.

Can anyone else verify this?

Hehe..

From the IRC channel:

[04:16] <@CiTay> hey mitiok, will you compile a "fast" version again? i really liked it
[04:17] <+mitiok> only in the future after most people donload lame
[04:17] <@CiTay> and why does it say "LAME version 3.90 MMX (http://www.mp3dev.org/"
[04:17] <@CiTay> the ")" is missing, after (http://www.mp3dev.org/
[04:17] <+mitiok> i.e. wait 1-2 weeks
[04:18] <@CiTay> ok, nice
[04:18] <+mitiok> dammed ) is missed
[04:18] <@CiTay> yea
[04:19] <+mitiok> should i recompile it?
[04:19] <@CiTay> with the ")"?
[04:19] <+mitiok> yeah
[04:19] <@CiTay> why not, it's not too late
[04:19] <+mitiok> ok

[Dibrom]

Removed the "fast" compiles, since with the latest compile the normal versions were actually slightly faster. For clarification, yes, that means that the new "normal" compile is faster than the old "fast" compile which was faster than the compiles on Mitiok's page.

[ff123]

For clarification, yes, that means that the new "normal" compile is faster than the old "fast" compile which was faster than the compiles on Mitiok's page.

Oh, that's clear as mud.

[Dibrom]

Sorry. Translation = "fast" compiles are no longer needed (at least for now).

[Dibrom]

Uploaded an MSVC compile of 3.90.2 due to popular request. I do NOT recommend that people use this compile over the ICL compile though but they are now free to do so if they wish

[Jens Rex]

Originally posted by Dibrom
Uploaded an MSVC compile of 3.90.2 due to popular request.  I do NOT recommend that people use this compile over the ICL compile though but they are now free to do so if they wish :)

Isn't the only tradeoff size vs. speed?

I thought the MSVC was more accurate because of less aggressive optimizations. How could this ever yield lower quality MP3, compared to ICL.

[Dibrom]

Originally posted by Zalkalin

Isn't the only tradeoff size vs. speed?

No. This "tradeoff" is not implicit.

I thought the MSVC was more accurate because of less aggressive optimizations. How could this ever yield lower quality MP3, compared to ICL.

Once again, more accurate floating point precsion != better quality. For that matter, its not always a matter of float precision, sometimes ICL just changes the way the compiler handles things such as casts and rounding which may not comply 100% to the C standard but will offer greater speed and will usually bring very similar results.

At any rate, this difference may soon be a non-issue as the cause of the bitrate difference may have been pinpointed (I need to test some more to be sure).

[Dibrom]

Just found some interesting stuff after a short discussion on the lame-dev...

I've recompiled my ICL build and turned off one of the flags that is normally defaulted on. The results show that the compiled binaries are now extremely close in bitrate (often the same) to MSVC. Often times the new modified ICL compile very slightly differs in the bitrate histogram, but for the most part things are much closer and the speed hit isn't too bad. I'll probably post this compile a little later for people to mess around with since it basically offers the lower bitrates than MSVC does but with the speed of the normal ICL compiles.

Some results:

--alt-preset standard:

MSVC File1:

LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding fatboy.wav to fatboy.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
  191/193    (99%)|    0:25/    0:26|    0:25/    0:26|  0.1935x|    0:00
32 [  1] *
128 [  6] %%%%*
160 [ 26] %%%%%%%%%%%%%%*****
192 [  9] %%%%***
224 [ 11] %*******
256 [ 49] %%**********************************
320 [ 91] %*****************************************************************
average: 263.3 kbps  LR: 33 (17.10%)  MS: 160 (82.90%)

Writing LAME Tag...done


Modified ICL File1:

LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding fatboy.wav to fatboy.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
  191/193    (99%)|    0:20/    0:20|    0:20/    0:20|  0.2476x|    0:00
32 [  1] *
128 [  5] %%%%
160 [ 27] %%%%%%%%%%%%%%%%****
192 [  8] %%%***
224 [ 12] %********
256 [ 50] %%***********************************
320 [ 90] %*****************************************************************
average: 263.3 kbps  LR: 33 (17.10%)  MS: 160 (82.90%)

Writing LAME Tag...done


ICL File1:

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding fatboy.wav to fatboy.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  191/193    (99%)|    0:20/    0:20|    0:20/    0:20|  0.2527x|    0:00
32 [  1] *
128 [  2] %%
160 [ 24] %%%%%%%%%%********
192 [ 14] %%%%%%%%***
224 [ 13] %%********
256 [ 47] %%********************************
320 [ 92] ******************************************************************
average: 265.3 kbps  LR: 30 (15.54%)  MS: 163 (84.46%)

Writing LAME Tag...done

File1 (normal standard) = 22% faster than MSVC, 3% slower than Normal ICL compile



[b]--alt-preset fast standard

MSVC File1:

LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding fatboy.wav to fatboy.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
  191/193    (99%)|    0:03/    0:03|    0:03/    0:03|  1.3956x|    0:00
32 [  1] *
128 [  4] %%%*
160 [ 22] %%%%%%%%%%%%%%%****
192 [ 21] %%%%%%%%%%%*******
224 [ 27] ***********************
256 [ 78] ******************************************************************
320 [ 40] %%%%%*****************************
average: 243.1 kbps  LR: 38 (19.69%)  MS: 155 (80.31%)

Writing LAME Tag...done


Modified ICL File1:

LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding fatboy.wav to fatboy.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
  191/193    (99%)|    0:02/    0:02|    0:03/    0:03|  1.7005x|    0:00
32 [  1] *
128 [  4] %%%*
160 [ 22] %%%%%%%%%%%%%%%*****
192 [ 22] %%%%%%%%%%%%********
224 [ 28] *************************
256 [ 75] ******************************************************************
320 [ 41] %%%%%********************************
average: 242.9 kbps  LR: 38 (19.69%)  MS: 155 (80.31%)

Writing LAME Tag...done


ICL File1:

LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding fatboy.wav to fatboy.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  191/193    (99%)|    0:03/    0:03|    0:02/    0:02|  1.8527x|    0:00
32 [  1] *
128 [  3] %%*
160 [ 18] %%%%%%%%%********
192 [ 26] %%%%%%%%%%%%%%**********
224 [ 27] %************************
256 [ 74] %*****************************************************************
320 [ 44] %%%%************************************
average: 245.4 kbps  LR: 33 (17.10%)  MS: 160 (82.90%)


Writing LAME Tag...done

File1 (fast standard) = 18% faster than MSVC and 8% slower than Normal ICL compile



[b]--alt-preset standard

MSVC File2:

LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding Andy McCoy-Mind Over Matter (clip).wav to andy.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
  4507/4510  (100%)|    2:22/    2:22|    2:22/    2:22|  0.8274x|    0:00
32 [  1] *
128 [  29] **
160 [ 204] %********
192 [ 503] %********************
224 [1332] %%%%%**************************************************
256 [1612] %%%%%%%%%%%*******************************************************
320 [ 829] %%%%%%%%%%%%%%%%******************
average: 246.0 kbps  LR: 774 (17.16%)  MS: 3736 (82.84%)

Writing LAME Tag...done


Modified ICL File2:

LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding Andy McCoy-Mind Over Matter (clip).wav to andy.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
  4507/4510  (100%)|    1:47/    1:47|    1:48/    1:48|  1.0951x|    0:00
32 [  1] *
128 [  29] **
160 [ 205] %********
192 [ 497] %********************
224 [1344] %%%%%***************************************************
256 [1604] %%%%%%%%%%%*******************************************************
320 [ 830] %%%%%%%%%%%%%%%%*******************
average: 246.0 kbps  LR: 774 (17.16%)  MS: 3736 (82.84%)

Writing LAME Tag...done


ICL File2:

LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding Andy McCoy-Mind Over Matter (clip).wav to andy.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  4507/4510  (100%)|    1:42/    1:42|    1:42/    1:42|  1.1514x|    0:00
32 [  1] *
128 [  13] *
160 [ 165] %******
192 [ 404] %***************
224 [1156] %%%%****************************************
256 [1736] %%%%%%%%%*********************************************************
320 [1035] %%%%%%%%%%%%%%%%%%**********************
average: 252.8 kbps  LR: 775 (17.18%)  MS: 3735 (82.82%)

Writing LAME Tag...done

File2 (normal standard) = 24% faster than MSVC, 5% slower than Normal ICL compile



[b]--alt-preset fast standard

[b]
MSVC File2:

LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding Andy McCoy-Mind Over Matter (clip).wav to andy.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
  4507/4510  (100%)|    1:39/    1:39|    1:39/    1:39|  1.1803x|    0:00
32 [  1] *
128 [  85] ****
160 [ 389] %*****************
192 [ 933] %%****************************************
224 [1494] %%%%%%%***********************************************************
256 [ 995] %%%%%%%%%%%%%*******************************
320 [ 613] %%%%%%%%%%%%%%**************
average: 230.1 kbps  LR: 769 (17.05%)  MS: 3741 (82.95%)

Writing LAME Tag...done


Modified ICL File2:

LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding Andy McCoy-Mind Over Matter (clip).wav to andy.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
  4507/4510  (100%)|    1:18/    1:18|    1:19/    1:19|  1.5034x|    0:00
32 [  1] *
128 [  85] ****
160 [ 390] %*****************
192 [ 942] %%*****************************************
224 [1478] %%%%%%%***********************************************************
256 [ 996] %%%%%%%%%%%%%********************************
320 [ 618] %%%%%%%%%%%%%%**************
average: 230.2 kbps  LR: 769 (17.05%)  MS: 3741 (82.95%)

Writing LAME Tag...done


LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding Andy McCoy-Mind Over Matter (clip).wav to andy.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  4507/4510  (100%)|    1:13/    1:13|    1:13/    1:13|  1.6138x|    0:00
32 [  1] *
128 [  61] ***
160 [ 351] ****************
192 [ 760] %%*********************************
224 [1467] %%%%%%************************************************************
256 [1144] %%%%%%%%%%%%****************************************
320 [ 726] %%%%%%%%%%%%%%%%%****************
average: 235.9 kbps  LR: 766 (16.98%)  MS: 3744 (83.02%)

Writing LAME Tag...done

File2 (fast standard) = 21% faster than MSVC, 7% slower than Normal ICL compile


Summary:

CODE

File1 (normal standard) = 22% faster than MSVC, 3% slower than Normal ICL compile

File2 (normal standard) = 24% faster than MSVC, 5% slower than Normal ICL compile



File1 (fast   standard) = 18% faster than MSVC, 8% slower than Normal ICL compile

File2 (fast   standard) = 21% faster than MSVC, 7% slower than Normal ICL compile



 Avg (normal standard) = 23% faster than MSVC, 4% slower than Normal ICL compile

 Avg (fast   standard) = 20% faster than MSVC, 8% slower than Normal ICL compile



           Overall Avg = 22% faster than MSVC, 6% slower than Normal ICL compile

[Wombat]

ok. When somebody has the "Song Of Sophia" from "Dead Can Dance", "A Passage in Time" it is worth comparing it!! I can´t upload anything and test at the moment - Sorry!

But this is a one that sounded bad without adding -b128 to preset standard. It added noise to some vocals. So i think it would be interesting to test a compile which even needs less bits.

Wombat

[Dibrom]

Originally posted by Wombat
ok. When somebody has the "Song Of Sophia" from "Dead Can Dance", "A Passage in Time" it is worth comparing it!! I can´t upload anything and test at the moment - Sorry!

But this is a one that sounded bad without adding -b128 to preset standard. It added noise to some vocals. So i think it would be interesting to test a compile which even needs less bits.

Very interesting.. Well I hope you can upload an LPAC from this sometime, then I'll certainly test it

[Wombat]

Are you in IRC? I will be able to be there in about 20 min.!?

Wombat

[Dibrom]

Yes I am.

[SNYder]

kick ass! YOU GOT THE ICL FILE SIZE DOWN! Now there is no need for MSVC or for me to make my own gcc compiles. YES!!!!!!

just make sure mitiok knows about this new found ICL change so his compiles will produce smaller files too.

WOOOOOOOOOOOO!!!! /me does backflip!

p.s. Dibrom. You know how you were showing me where to get the official CVS site for the LAME source code? Well, as I found HERE, under "latest versions/In tar.bz2 format", a link to this site... ftp://cedric.vabo.cz/pub/linux/apps/lame/ ... with the latest source strait from cvs, packed into one nice little tar.bz2 file. just to let you know, incase you didn't.

And here... http://lame.sourceforge.net/download/src/ ... is the official place to get the source. But everything is in rpm format. Do you have any idea what the rpm format is? =

[Dibrom]

Originally posted by SNYder
kick ass!  YOU GOT THE ICL FILE SIZE DOWN!  Now there is no need for MSVC or for me to make my own gcc compiles.    YES!!!!!!

Hehe..

just make sure mitiok knows about this new found ICL change so his compiles will produce smaller files too.

Eh... don't think this is too likely to happen (/me vaguely refers to the crap going on at lame-dev)..

p.s.  Dibrom.  You know how you were showing me where to get the official CVS site for the LAME source code?  Well, as I found HERE, under "latest versions/In tar.bz2 format" is a link to this site...  ftp://cedric.vabo.cz/pub/linux/apps/lame/  ... with the latest source strait from cvs.   just to let you know.

Yes, this is where Mitiok gets his source from. I prefer getting it straight from CVS though instead of going through someone else who also gets it from CVS

And here... http://lame.sourceforge.net/download/src/ ... is the OFFICIAL place to get the source.  But everything is in rpm format.  Do you have any what the rpm format is? =

The problem is that this source isn't from CVS, it's only from official builds, so you can't really use it for testing much. RPM is the Redhat (Linux) packaging format.

[SNYder]

Originally posted by Dibrom
Eh... don't think this is too likely to happen (/me vaguely refers to the crap going on at lame-dev)...

Huh?

I believe you are refering to their bitching about you making a 3.90.2 and other junk that is making you consider forking lame. Am I right?

If so, what does that have to do with Mitiok and him just changing one simple switch to make his compiles produce smaller files? =

you see, the reason I got so happy was because I thought Mitiok was going to be doing this thingy too... So I could just stop by his site and grap the latest compile when I need to make an mp3 for one of my artists mp3 sites and know they will be the same size as a MSVC or GCC compiled version. But if he doesn't do it, then I'm still gonna have to compile my own because your not always gonna be making compiles available for download. Only when you add stuff, or when there is an increase in quality.

In other words, I was happy because I knew that no matter when it was I needed to make and upload an mp3, I would be able to get the latest compile and do my thing. Now, if the compile you have up isn't the latest, I'll have to make my own... Sure the quality might not be different, but I'm pretty damn close to being obsesive compulsive about this type of thing I need to use the latest version of everything (except Windows Media Player) or else I go INSANE!!!

Originally posted by Dibrom
Yes, this is where Mitiok gets his source from.  I prefer getting it straight from CVS though instead of going through someone else who also gets it from CVS

Well, I don't even know how to download the entire CVS thingy yet, so this is rather conventient.

Originally posted by Dibrom
The problem is that this source isn't from CVS, it's only from official builds, so you can't really use it for testing much.

I'm not sure I get what your saying. Are they compiled by the LAME developers themselves (which would make the official ) or somthing?

Originally posted by Dibrom
RPM is the Redhat (Linux) packaging format.

oh. well... redhat sucks! Go Mandrake!

[Dibrom]

Originally posted by SNYder
Huh?

I believe you are refering to their bitching about you making a 3.90.2 and other junk that is making you consider forking lame.  Am I right?

Yes.

If so, what does that have to do with Mitiok and him just changing one simple switch to make his compiles produce smaller files? =

Umm.. because Mitiok is busy spending all of his time trolling me there.. heh. After the initial discussion just died down, he decided to start a new thread about it again... argh. At any rate, I have enough to worry about just trying to take care of the people on this site.. and especially with the circumstances, I have little desire to go out of my way to try and "suggest" this to such a person.

you see, the reason I got so happy was because I thought Mitiok was going to be doing this thingy too... So I could just stop by his site and grap the latest compile when I need to make an mp3 for one of my artists mp3 sites and know they will be the same size as a MSVC or GCC compiled version.  But if he doesn't do it, then I'm still gonna have to compile my own because your not always gonna be making compiles available for download.

Says who?

I'm going to be making compiles available for download from now on, and my compiles will be synchronized with any major quality developments also... so from that standpoint you'd be even safer to use mine.

Only when you add stuff, or when there is an increase in quality.

I'll be making compiles available that mirror improvements in functionality and quality. Nightly compiles are not really necessary.

In other words, I was happy because I knew that no matter when it was I needed to make and upload an mp3, I would be able to get the latest compile and do my thing.  Now, if the compile you have up isn't the latest, I'll have to make my own...  Sure the quality might not be different, but I'm pretty damn close to being obsesive compulsive about this type of thing   I need to use the latest version of everything (except Windows Media Player) or else I go INSANE!!!

Well the sad fact of that matter is that Mitiok and I do not work together. I thought we did, but he seems to have mood swings to where one day he'll link to my site and be more than happy to work with me, then the next day he won't like a revision number on my compile or something I say about quality so he'll remove it all again.. heh.

It seems the more I do with LAME, the more I end up having to rely on myself and the people that help me run this site because many others already established in the community end up having "issues" with something that I'm doing, whether it be improving a preset they think is pointless or providing a bug fixed compile so people can actually have a nice release for christmas and a relatively bug free 3.90 after nearly a year and a half. Sometimes you just gotta wonder what the hell some people are thinking when they make such a fuss about what should be a good thing.

[b]Well, I don't even know how to download the entire CVS thingy yet, so this is rather conventient.

CVS isn't hard to use really. All you need is CVS.exe if you are on windows, and you just type in the exact command shown on the LAME CVS page.. it will checkout the LAME source and expand it in the directory you run the .exe from.

I'm not sure I get what your saying.  Are they compiled by the LAME developers themselves (which would make the official ) or somthing?

They are built and maintained by the developers, yes.

oh.   well... redhat sucks!  Go Mandrake!

Hehe. Actually Mandrake uses RPMS also, but you probably knew that.

[Dibrom]

Originally posted by SNYder
p.s.  Dibrom... Has your changes in 3.90.2 made it into the official lame source code yet?  like in this guys "ftp://cedric.vabo.cz/pub/linux/apps/lame/".

Yes. It's in 3.91 CVS.

[Dibrom]

Alright, Linux stuff was getting a little too far off topic, so I split it out and moved it to the off-topic section for further discussion

[Jan]

I don't know if this is in the right thread...

I know that the small mistake in alt-preset fast standard in 3.90 is gone in 3.90.2

What about alt-preset fast extreme? Is there a similar bug as in fast std?? Or was it only in fast standard???

Thanks in advance for your reply


And another thing: Since fast standard and fast extreme are equally speedy, is there a reason not to use fast extreme instead of fast standard despite of the space issue? I don't here differences (don't have the high-end equipment anyway).
Would you advise to use fast standard because it is maybe more tweaked or tested?

[Dibrom]

Originally posted by Jan
I don't know if this is in the right thread...

I know that the small mistake in alt-preset fast standard in 3.90 is gone in 3.90.2 

What about alt-preset fast extreme? Is there a similar bug as in fast std?? Or was it only in fast standard???

I don't believe there was a similar bug in extreme, but if there was, it was fixes simultanoesly.

And another thing: Since fast standard and fast extreme are equally speedy, is there a reason not to use fast extreme instead of fast standard despite of the space issue?

No.

[SNYder]

Originally posted by Dibrom
Well the sad fact of that matter is that Mitiok and I do not work together.  I thought we did, but he seems to have mood swings to where one day he'll link to my site and be more than happy to work with me, then the next day he won't like a revision number on my compile or something I say about quality so he'll remove it all again.. heh.

It seems the more I do with LAME, the more I end up having to rely on myself and the people that help me run this site because many others already established in the community end up having "issues" with something that I'm doing, whether it be improving a preset they think is pointless or providing a bug fixed compile so people can actually have a nice release for christmas and a relatively bug free 3.90 after nearly a year and a half.  Sometimes you just gotta wonder what the hell some people are thinking when they make such a fuss about what should be a good thing.

well... if that's how it has to be. so be it. you still got this community backing you up.

Originally posted by Dibrom
Says who?

I'm going to be making compiles available for download from now on, and my compiles will be synchronized with any major quality developments also... so from that standpoint you'd be even safer to use mine.

I'll be making compiles available that mirror improvements in functionality and quality.  Nightly compiles are not really necessary.

ah cool glad to hear that

[olcios]

it basically offers the lower bitrates than MSVC does but with the speed of the normal ICL compiles.

Wow!
That's the best news I've heard since alt-presets were released!
Good work!
Could you specify what exactly is that flag you've changed? I'm very curious.

Maybe you should add a small note about that change to the main "List of recommended Lame compiles" post because otherwise some ppl will be downloading MSVC because they think it still produces 3% smaller files. Most ppl don't read replies to the "Recommended settings/compiles" posts and they may not notice that (IMO very significant) change.
Just to be sure, you've already upgraded the links with the modified versions of compiles, right?

Well the sad fact of that matter is that Mitiok and I do not work together. I thought we did, but he seems to have mood swings to where one day he'll link to my site and be more than happy to work with me, then the next day he won't like a revision number on my compile or something I say about quality so he'll remove it all again.. heh.

I'm very sad to hear that.
It would suck if because of stuff like that he didn't change the settings for his compiles. I don't want the Lame project to be affected by issues like that. Is there anything we can do about that?

[Dibrom]

Originally posted by olcios
Could you specify what exactly is that flag you've changed? I'm very curious.

/QIfist and/or /Qrcd

Maybe you should add a small note about that change to the main "List of recommended Lame compiles" post because otherwise some ppl will be downloading MSVC because they think it still produces 3% smaller files.

I'll be completely removing the MSVC compile soon so that should take care of the issue. I may still add a note of some sort though, we'll see.

Just to be sure, you've already upgraded the links with the modified versions of compiles, right?

Nope, I haven't had time in the last few days since I've been moving. I only have limited computer and internet access at the moment so I won't be able to fix this until I compile 3.91 (which is taking a bit longer due to a few decisions I recently made which I'll specify shortly).

I don't want the Lame project to be affected by issues like that. Is there anything we can do about that?

Not really.. but LAME being Open Source, we have the power to do what we think needs to be done on our own regardless of what other people are not doing when they should be. Sometimes we take some flack over this (think 3.90.2) though, but as long as progress is being made and the actual "users" are made happy by these actions...

I'm going to just keep doing what I do now. That is, work on this website, continue to work on the Tools sphoid and I have mentioned on occasion (we may see the first part released pretty soon here now..) and work on LAME. I don't really have the time, energy, or desire to worry about what other people are doing or not doing anymore at this point.