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: Lame 3.98 beta 6 (Read 167540 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lame 3.98 beta 6

Reply #50 –
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.

Lame 3.98 beta 6

Reply #51 –
Quote from: soultrain on
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.

Lame 3.98 beta 6

Reply #53 –
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?

Lame 3.98 beta 6

Reply #54 –
Quote from: soultrain on
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.

Lame 3.98 beta 6

Reply #55 –
Quote from: uart on
Quote from: soultrain on

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.

Lame 3.98 beta 6

Reply #56 –
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.

Lame 3.98 beta 6

Reply #57 –
Quote
' date='Nov 15 2007, 19:03' post='530053']
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.

Lame 3.98 beta 6

Reply #58 –
Quote from: soultrain on
Quote
' date='Nov 15 2007, 19:03' post='530053']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.).
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

Lame 3.98 beta 6

Reply #59 –
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.

Lame 3.98 beta 6

Reply #60 –
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.

Lame 3.98 beta 6

Reply #61 –
hm then i hope it is a bug and not a feature 

Lame 3.98 beta 6

Reply #62 –
Quote
' date='Nov 15 2007, 11:07' post='530072']
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.



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.

Lame 3.98 beta 6

Reply #63 –
Quote from: uart on
Quote
' date='Nov 15 2007, 11:07' post='530072']
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.



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.

Lame 3.98 beta 6

Reply #64 –
bugreport send :-)

Lame 3.98 beta 6

Reply #65 –
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).
"Not sure what the question is, but the answer is probably no."

Lame 3.98 beta 6

Reply #66 –
dont use beta6, it was not official released, try beta5

Lame 3.98 beta 6

Reply #67 –
Quote from: ZinCh on
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.
"Not sure what the question is, but the answer is probably no."

Lame 3.98 beta 6

Reply #68 –
Quote from: mixminus1 on
Quote from: ZinCh on

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.
Proverb for Paranoids: "If they can get you asking the wrong questions, they don't have to worry about answers."
-T. Pynchon (Gravity's Rainbow)

Lame 3.98 beta 6

Reply #69 –
There's a new 2007-11-26 beta 6 build on Rarewares.

Lame 3.98 beta 6

Reply #72 –
New builds just posted at Rarewares. Significant changes:

Quote
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

Lame 3.98 beta 6

Reply #73 –
This sounds like the most significant development since 3.90

Lame 3.98 beta 6

Reply #74 –
Quote
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