Dont want to make a new topic for it. But i got from Lame3.98a7 to Lame 0.398b6 - daily build05112007. I have a P4 - 3ghz winxp 1gb ram and my cpu went from 2% to 50%..54%. Thats a very big jump, why's that?

I tried different setting q0, q2, q4 (all vbr, range 32..320kps) no diffenrce in cpu usage.
Its no big problem, i dont use the comuter when recording now, but i wonder why that is and or it stays this way.

Also i read that b5 was better for now, but i searched the intenet and all they offer is the old 397stable or new 398b6 daily build or torrents but torrents I dont trust, dont want any virusses. So were to find a good B5 dont wanne compile one myslef dont have the knowledge.

I still have 3.98b4 flying around, if you'd like to use that I'll upload it for you somewhere.

if anyone wants b5, or b4 for that matter, you can d/l them from: http://homepage.ntlworld.com/jfe1205/LAME

thanks i will check b5 later.
Anybody an idea why B6 ask 25 times more cpu usage the A7. Is this normal and only temparory?

I'm not sure what are you are talking about soultrain? When encoding you should be using all available CPU power, the higher the better!!!. You say you're now using 50%, well too bad it's not 100% because then your encodes would be twice as fast (btw is you cpu dual core?). It's only during playback that you want low CPU usage like 1 or 2 percent.

I'm pretty sure you are wrong about previous versions encoding with 2% CPU usage. Maybe you could go test it again and report back.

I could not believe at first and did even triple testing / checks to be sure.

When i record with totalrecorder pro using the lame a7 codec (vbr standard = new). It only uses 2%..3% of the cpu, i can watch minutes long at the taskbar but TR doesnt come above 3%.

Switching from a7 to b6, TR (same settings) uses now 50..54% when recording. I guess it would take more cpu, if it could it, but like you guessed its a P4-3ghz hyperthreading cpu, so it uses one core you could say.

I think it could be explained by:
A) the new B6 build use some sort of very complex algorithms that uses more cpu power, 25 time son my cpu to be precise.
B) new algorithm but has to be optimized but that happens after all the coding is finished.
C) new intructions that don't work well on my old P4.
D) the vbr mode says it uses standard/new but in reality uses the old and slow method, slow means more cpu? Don't know about hat one.

More i cant tell.

Remember i encode realtime a analog audio stream (radio to pc). Not a cd, a cd or lots of wave files would indeed take 100% were it could. But realtime encoding takes only the cpu it needs for the analog signal, more cpu has no use. It cant speed up the analog signal if it is finished with its encoding job
I hope this explains a bit more.

Ok, I think you now clarified it some more.


You are encoding to mp3 in realtime, and now Lame is using substantially more CPU to do the same thing. Right?

(Previously, it didn't make much sense that encoding used just a few %'s ).


I would suggest you to tell us which parameters are you using for lame, since it's quite sure they are the reason that causing this increase of CPU, because there hasn't been such a general slowdown.

Yes you have it right thats what i mean.

My settings doesnt matter it always 54%, but here are the ones i tried
allways joint stereo
vbr standard= vbr new.
vbr quality q0, q2, q4 even q9 didt make difference cpu wise.
very high quality or lowest quality also no difference.

q9 and lowest quality still 53%

for extra info i will try b5 and posts my results here.

If you have a dual-core processor, 50% = one process taking up no more than 100% of the equivalent of one core (quite often) with the remaining 4 % as overhead (operating system, whatever you're looking at the processing throughput with, etc.).

I installed B5 and now the cpu is at max 2..4% again, so it seems to be a B6 specific problem.

Are there things so good in B6 that i better stay with B6 or is it ok to go back to B5? I can use the extra freed cpu time. Dont want to cripple an mp3 when recording in B6 and opening firefix.

After thinking a bit more about the subject, i would think that this new version of lame has changed the way stdin works, and waits for new data, instead of sleeping. I cannot assure this. A developer could comment more on that.

Since you say that no parameter changes the amount of CPU that it uses, and that is ~50% is synonim of topping one core, this explanation could have sense.


Edit:
Of course, the compiler used could have the culprit aswell.

hm then i hope it is a bug and not a feature

Yeah that's exactly what I was thinking once I realized we were talking about real-time encoding where it's constantly waiting on data. I'd call it a bug, but not a really serious one since the majority of people use lame at full speed rather than real time. Still it would be nice it was fixed in the next beta.

Only 7 days on the forum and i already found my first lame bug :

But seriously, uart can you take care of the bug one day, are you a lame programmer?
Or do i have to summit it somewhere or to someone, so someone beside us knows about it and can fix it?
I dont mind submitting it if someone can tell me where.

Dont know or the programmers of Lame read this topic.

bugreport send :-)

I have the Nov 6, 2007 build of 3.98b6 from Rarewares, and I'm also experiencing some strangeness with stdin with dBPowerAmp Music Converter 11.5 and the mp3lame.exe plugin (I've been using aps_killer_sample.wav for all these tests, but I also get the exact same results with longer files).

No matter what bitrate or VBR level I use, all I get is full-scale white noise - adding "-x" to the command line doesn't make any difference.

Even stranger: Encoding straight from the command line to V5 or V4 and playing those files back in foobar2000 0.9.4.1 produces a pronounced "thump" right at the start of the file, but the file plays fine. However, if I convert to WAV, my CPU usage goes to maximum (and conversion speed drops from blink-of-an-eye to 0.66x), and the resulting WAV file - viewed in Cool Edit 2000 - is nothing but two straight lines at maximum negative level, i.e. 100% negative DC offset. Everything's fine with V3, V2, b128, and b192.

These same V5 and V4 files play back perfectly in iTunes 7.4.3.1, and are also converted to WAV just fine.

Very, very strange...

Edit: ...and it gets stranger. On a whim, I tried changing the dither and output settings in fb2k. I had "only lossy sources" selected in the converter, and my playback output was 24-bit to my Soundblaster USB Live. I went from "only lossy sources" to "never" with no change. Changed my output to 16-bit - with no dither - no change. Back to 24-bit...and here's where things get a little fuzzy. I can't remember if was after changing back to 24-bit output, or setting the converter dither option back to "only lossy sources"...but now both playback and conversion are perfect...and I can't recreate the original problem(s).

dont use beta6, it was not official released, try beta5

I downloaded both b4 and b5 from the link john33 provided, and they both exhibit the same encoding problem with dBPowerAmp. After searching my hard drives, I found a copy of 3.98b1 (dated May 16, 2007 when run from the command line), and it works just fine.

I had similar problems with dbpoweramp and extremely noisy/distorted encoding results from Lame 3.98b5 onwards. Upgrading to the latest dbpoweramp version and mp3exe-plugin solved the problem for me. I guess something to do with stdin handling was changed in 3.98b5 that can lead to problems with older dbpoweramp versions.

There's a new 2007-11-26 beta 6 build on Rarewares.

there is en new build every two days

Ah, I just haven't noticed

New builds just posted at Rarewares. Significant changes:

This sounds like the most significant development since 3.90

Lately I decided to find which bitrate corresponds to values of VBR quality settings. So I took one of my CDs and 4 lame binaries: 3.96.1, 3.97, 3.98 (beta 6, Nov 26 2007) and 3.98 (beta 6, Dec 10 2007).
Encoding settings:
1) -Vx --vbr-new
2) -Vx --vbr-old
3) -Vx --vbr-new -Y
4) -Vx --vbr-old -Y
where x=0...9

Results are here:


(Horizontal axis is -V setting, vertical - bitrate.)
Apparently vbr-new changed in new beta and it has visible impact on bitrate. It became lower and closer to vbr-old

I tested my usual problem samples Birds, eig, harp40_1, herding_calls, lead_voice, trumpet, trumpet_myPrince with current 3.98b6 @ -V2, -V1, -V0, --abr 230.

One of the most remarkable things is that eig has improved even more. This extremely bad pre-echo sample is abxable of course, but quality for -V1 is so good that it isn't a practical problem to me. It's pretty good even with -V2.

Other than for eig everything was fine (not abxable) to me with -V0.
Quality scales well when going -V1, -V0. With -V1 for instance I can abx eig, harp40_1, and lead_voice. trumpet_myPrince is a bit on the edge (7/10). But quality is very good to me even with those tracks I can abx. -V2 is fine as well though inferior to -V1 as expected (I can clearly abx trumpet_myPrince, and trumpet is a bit on the edge).

I've liked to use ABR in the very high frequency range, but with this version ABR isn't an alternative any more for me. To me ABR 230 quality is very good too, but inferior to -V1 (with the exception of the tremolo problems lead_voice and trumpet_myPrince which however aren't too bad with -V1).

I have tested my velvetrealm sample. There is a noticeable improvement moving from V2 to V1 ... though V1 is still 100% abx-able. V0 shows no improvement to my ears on this sample.

I thought VBR NEW was used by default since some time ago now? So is this the same "new" or a new "new" available since Lame 3.98 beta 6 only?

vbr new was never default and still isn't, it just means that when you use vbr new it will use a new psy model.

yes it is, at least for some of the -V presets. I think since Lame 3.97 since it has been found superior in sound quality. So, is this new vbr-new mode a new algorithm and is it safe it use?

From the wiki:

from the changelog: "The newer VBR code is now LAME's default VBR routine"

ok, so vbr-new became the default setting since 3.98b1. anyway, back to the original question, what's up with that new vbr-new routine mentioned in beta 6?

Are you asking what is meant by:



Seems to be a minor bug that was caught and fixed.

I did a short test (single sample, I know, kind of like anecdotal evidence) at -V9 and found the quality of the new beta slightly worse than the same file encoded with 3.98b4 (more distortion in the voice and guitar). In both cases, there is a loud "click" at the beginning of the track that is not audibly present in the original file. This click was only on the right channel with b4, and centered (and a bit quieter) with b6.

You can download the sample here.

Edit: The "click"-issue exists only with --vbr-new, it's gone when using --vbr-old. Also, it vanishes when you use -V9 but --resample to anything other than 24khz. It's not present with -V8 --resample 24000 either.

Interesting update - Sun Dec 9 22:47:37 2007 UTC @ lame.cvs.sourceforge.net

merger from test branch:

• features a new psy model, a modification from NSPSY

VBR NEW uses the new psy model, unless you call lame with --nspsytune, or the developer only switch --psymodel x, with x in {1,2}

features of the new psy model:

• speed: it does determine the resulting block type before doing the fft and other psy stuff and will calc long/short blocks only as necessary
• interchannel masking effect: it will be calculated after the mid-side fix and it's working on convolution bands, instead of scalefactor bands
• mid-side fix: calculated on convolution bands, instead of sf bands
• mask_adjust feature: it's now used earlier in the convolution calculation

The 'official' beta 6 is now at Rarewares.

Thanks. I found no improvement on the sample I discussed above with this new version.

I just tried the offical Beta 6, its seems to be faster then 3.97 (3.97 = 24x - 25x 3.98b6 = 25x - 27x) at encoding on my Core 2 Duo E6600 CPU. Also the bitrates on a few encodes i did are just slight bigger then 3.97 by 1 - 3 kbps but alot smaller then the early 3.98 betas.

Stigmata V2



This really sounds alot better then 3.90.3 and much much better the 3.97. I would find it transparent but i got a feeling that the bacground noise was faster and a possible warbling after a few secs where the precho would appear on lossy encode.

Die In A Crash (Sample) V2



A very easy to ABX artifact on the wierd noise at the start of the track around 0:03 - 0:06. Anyway a lossless sample can be found here if anyone would like to try it since it is a killer sample at V0 --vbr-new on 3.97.

Die In A Crash (Sample) V0



So far i recken its transparent, i had trouble trying to ABX this track at V0 on Beta 6 unlike 3.98b5 and 3.97.

Thanks from me, too. Just interested: does this compile includes "fixing typo" in vbrquantize.c (Mon Dec 17 00:08:56 2007 UTC)?

any chances BETA 6 becoming 3.98 final? Or will we have to wait a whole year....

What player software are you using? I can't hear any loud click in the beginning of your sample. Maybe you can upload your encoded file too.

I used foobar2000 0.9.5 beta 5 for playback (tried beta 8 now with the same result). Winamp and the decoding function of lame itself work ok, as does an older version of Foobar. So it's probably my fault for trusting a beta version . I can upload the encoded file as well as the version decoded by the foobar beta if you like, but it's probably rather a case for the foobar support forum.

Related to this: is there a recommended decoder for doing comparisons? I was under the impression that the differences between them were inaudible these days, but this problem gives me some doubts.

Well, yes it sounds like a problem of foobar then.

The 3.98 stable release will be a little bit faster too. Alpha and Beta versions do have some debugging code inside, which is disabled in stable releases. I for myself have no use of LAME's own replaygain calculation and add "--noreplaygain" to my commandlines, which makes encoding faster again.

Yeah, I hear that click too in foobar. I don't hear it on my ipod, though.

Can we get 3.98 final as a Christmas gift?

From HA wiki:

Maybe 3.98 final will be anniversary edition...

I tested the EIG sample, and it's very good with 3.98b6. I cannot ABX it anymore at V0. (I could with 320CBR). Good work, and please RELEASE IT!

Could you just stop telling lame developers how to handle development? Besides, this beta introduces changes to the psymodel - and you propose to do a stable release immediatelly afterwards without much public testing? Maybe better stick to the stuff which you understand: being a user.