Updated :
lame 3.98 beta 6 (small fix) (2008-03-12 13:47)Sources : http://sourceforge.net/project/showfiles.p...;package_id=309 (http://sourceforge.net/project/showfiles.php?group_id=290&package_id=309)
Binaries : Rare Wares (http://www.rarewares.org/mp3-lame-bundle.php#lame-beta)
CVS : http://lame.cvs.sourceforge.net/lame/lame/...me/?sortby=date (http://lame.cvs.sourceforge.net/lame/lame/libmp3lame/?sortby=date)
Official LAME v3.98 Beta 6 is out on
December 16 2007:
- Robert Hegemann:
- Feature request [ 1811483 ] WAVE_FORMAT_EXTENSIBLE support (PCM)
- Fix for some rare scalefactor selection issue the newer vbr code had at low compression levels
- Fix for Bugtracker item [ 1813496 ] AIFF parsing bug
- Latest changes to the new VBR code:
- it now has its own psy model, a derivation from NSPSY.
- some more tuning has been done for this new psy model. Many thanks to Horst Albrecht and Myles Thaiss.
- the "out-of-bits" strategy is reworked
- It was possible, that the "interchannel masking effects feature" was used by the dual-channel-mode for bi-lingual encodings too. It was meant to work on stereo L/R channels only.
Changelog - history.html (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html)
Can someone test with new killer samples??
For my personal use and maybe if someone wants to test beta 6 out on a Macintosh computer (and isn't command line savvy), I've compiled Max w/ LAME 3.98 beta 6.
http://www.vortec6.com/max071lame398b6.tar.gz (http://www.vortec6.com/max071lame398b6.tar.gz)
also the command line version in universal binary goodness
http://www.vortec6.com/lame398b6.tar.gz (http://www.vortec6.com/lame398b6.tar.gz)
EDIT: Compiled again for the changes mentioned below
Did a quick test with -V2, for some reason this version produces smaller bitrates then beta 5 and 3.97.
foo_abx 1.3.1 report
foobar2000 v0.9.5 beta 1
2007/10/22 01:15:12
File A: F:\Listen Tests\Die In A Crash (Sample) LAME 3.98b6 V2.mp3
File B: F:\Listen Tests\Die In A Crash (Sample).wav
01:15:12 : Test started.
01:16:40 : 00/01 100.0%
01:17:40 : 01/02 75.0%
01:17:55 : 02/03 50.0%
01:18:08 : 03/04 31.3%
01:18:32 : 04/05 18.8%
01:19:05 : 05/06 10.9%
01:19:19 : 06/07 6.3%
01:19:42 : 07/08 3.5%
01:20:16 : 08/09 2.0%
01:20:50 : 09/10 1.1%
01:21:15 : 10/11 0.6%
01:21:37 : 11/12 0.3%
01:22:08 : 12/13 0.2%
01:22:30 : 13/14 0.1%
01:23:01 : 14/15 0.0%
01:23:03 : Test finished.
----------
Total: 14/15 (0.0%)
Sounds the same or worse then beta 5.
Here is another killer track I have that is not transparent on LAME 3.90.3 --alt-preset standard and also not transparent on LAME 3.97 -V --vbr-new.
foo_abx 1.3.1 report
foobar2000 v0.9.5 beta 1
2007/10/22 01:08:48
File A: F:\Listen Tests\Stigmata LAME3.98b6.mp3
File B: F:\Listen Tests\Stigmata.flac
01:08:48 : Test started.
01:10:09 : 01/01 50.0%
01:10:13 : 02/02 25.0%
01:10:30 : 03/03 12.5%
01:10:40 : 04/04 6.3%
01:11:09 : 05/05 3.1%
01:11:28 : 06/06 1.6%
01:11:38 : 07/07 0.8%
01:12:00 : 08/08 0.4%
01:12:17 : 09/09 0.2%
01:13:01 : 10/10 0.1%
01:13:23 : 11/11 0.0%
01:13:29 : Test finished.
----------
Total: 11/11 (0.0%)
This track was transparent on beta 5, but it not at beta 6 and the beta 6 encode produced a smaller bitrate while ogg at q.6 and nero aac q.55 was in bigger bitrates. So far this the worst encode I heard of this track it also has the artifacts that were on -V 5.
LAME 3.98b5 205kbps
LAME 3.98b6 187kbps
LAME 3.97 187kbps
LAME 3.90.3 192kpbs
worse than b5??
Hmmm......
that's interesting.
anyway...
Thanks~ /mnt
Here is another test I did at V2.
foo_abx 1.3.1 report
foobar2000 v0.9.5 beta 1
2007/10/22 01:49:16
File A: F:\Listen Tests\Until It Sleeps LAME 3.98b6 V2.mp3
File B: F:\Listen Tests\Until It Sleeps.wav
01:49:16 : Test started.
01:51:30 : 01/01 50.0%
01:51:46 : 02/02 25.0%
01:52:07 : 03/03 12.5%
01:52:22 : 04/04 6.3%
01:52:57 : 05/05 3.1%
01:53:28 : 06/06 1.6%
01:53:56 : 07/07 0.8%
01:54:46 : 08/08 0.4%
01:55:17 : 09/09 0.2%
01:55:43 : 10/10 0.1%
01:55:47 : Test finished.
----------
Total: 10/10 (0.1%)
A hard to hear but not annoying warbling at 3:58, but my ears picked it up like there is something wrong.
This encode also produced a smaller bitrate then the past version i tested 192kbps LAME 3.98b6, 211 kbps LAME 3.98b5, 200kbps LAME 3.97 and 220kbps LAME 3.90.3. I find this version be worse then 3.97 and I find beta 5 to be better then 3.90.3 and 3.97.
/mnt, you make me go lossless all the way...
I wonder if you can ABX OGG at q.6 with the EIG sample.
it's so weird these new LAME versions not handling a lot of things...
/mnt, you make me go lossless all the way...
....
it's so weird these new LAME versions not handling a lot of things...
Codec development is a challenge, and this is especially true for mp3.
The ways towards improvement are not wide and straight.
It's always weighing advantages vs. disadvantages of a certain approach according to experience.
That's why /mnt's findings are so helpful, and why a forum like this is important where members are invited to contribute and share their experiences.
it's so weird these new LAME versions not handling a lot of things...
This is a case of selective perception aka ""Hasty Generalization" (http://en.wikipedia.org/wiki/Hasty_generalization) and "Proof By Example" (http://en.wikipedia.org/wiki/Proof_by_example). Both are typical mistakes made by "paranoid" and "idealistic" minds.
A bitrate test on 1 song:
3.98 b5 - V4 vbr new = 159 k
old = 158 k
3.98 b6 - V4 vbr new = 150 k
old = 133 k !!
25 k difference is too sus..
Looks like --vbr-new got recalibrated due to a bug fix.
http://lame.cvs.sourceforge.net/lame/lame/...tize.c?view=log (http://lame.cvs.sourceforge.net/lame/lame/libmp3lame/quantize.c?view=log)
Looks like --vbr-new got recalibrated due to a bug fix.
http://lame.cvs.sourceforge.net/lame/lame/...tize.c?view=log (http://lame.cvs.sourceforge.net/lame/lame/libmp3lame/quantize.c?view=log)
Its hard to believe that a late beta has such a bitrate gap - 10 k for vbr new and 20k for vbr old. All vbr is different.
Looks like --vbr-new got recalibrated due to a bug fix.
http://lame.cvs.sourceforge.net/lame/lame/...tize.c?view=log (http://lame.cvs.sourceforge.net/lame/lame/libmp3lame/quantize.c?view=log)
Its hard to believe that a late beta has such a bitrate gap - 10 k for vbr new and 20k for vbr old. All vbr is different.
Since me and others were very happy about the quality improvements with b5 i hope the devs don´t want to please the few that complaint about a bitrate rise to 3.97.
It looks like a bug or something. vbr old is 30 k lower than B5. I confirm it with another track: 163 k B5 vs. 139 k B6
It seems Robert is working on it:
http://lame.cvs.sourceforge.net/lame/lame/...by=date#dirlist (http://lame.cvs.sourceforge.net/lame/lame/libmp3lame/?sortby=date#dirlist)
psymodel.c 1.163 32 minutes robert re-establishing previous mask adjustments
presets.c 1.61 32 minutes robert re-establishing previous mask adjustments
I wonder if you can ABX OGG at q.6 with the EIG sample.
Thank god I can not ABX EIG (i tried my best) on Ogg at q.0.6 and Nero AAC at q.0.55, but on mp3 its very easy and so for I find iTunes mp3 encoder to do worse on EIG and it did worse then the first verion of l3enc
LAME 3.97 V 2 --vbr-newfoo_abx 1.3.1 report
foobar2000 v0.9.5 beta 1
2007/10/22 12:21:51
File A: F:\Listen Tests\eig (LAME 3.97 V2).mp3
File B: F:\Listen Tests\eig.wv
12:21:51 : Test started.
12:21:59 : 01/01 50.0%
12:22:04 : 02/02 25.0%
12:22:12 : 03/03 12.5%
12:22:37 : 04/04 6.3%
12:23:07 : 05/05 3.1%
12:23:21 : 06/06 1.6%
12:23:28 : 07/07 0.8%
12:23:41 : 08/08 0.4%
12:23:46 : Test finished.
----------
Total: 8/8 (0.4%)
I gave up at 8 because it was torture, sounds like a encode from a very old version of l3enc.
LAME 3.98b6 V 2foo_abx 1.3.1 report
foobar2000 v0.9.5 beta 1
2007/10/22 13:12:26
File A: F:\Listen Tests\eig LAME3.98b6 V2.mp3
File B: F:\Listen Tests\eig.wv
13:12:26 : Test started.
13:13:27 : 01/01 50.0%
13:13:33 : 02/02 25.0%
13:14:01 : 03/03 12.5%
13:14:10 : 04/04 6.3%
13:14:31 : 05/05 3.1%
13:14:46 : 06/06 1.6%
13:15:02 : 07/07 0.8%
13:15:08 : 08/08 0.4%
13:15:21 : 09/09 0.2%
13:15:40 : 10/10 0.1%
13:15:43 : Test finished.
----------
Total: 10/10 (0.1%)
A nice improvement from 3.97, but still not transparent at 0:11 was louder and still had artifacts awell but almost acpectable.
It seems Robert is working on it:
http://lame.cvs.sourceforge.net/lame/lame/...by=date#dirlist (http://lame.cvs.sourceforge.net/lame/lame/libmp3lame/?sortby=date#dirlist)
psymodel.c 1.163 32 minutes robert re-establishing previous mask adjustments
presets.c 1.61 32 minutes robert re-establishing previous mask adjustments
Thanks , No use testing this one until new builds are out.
Thanks , No use testing this one until new builds are out.
New builds at Rarewares now.
New builds at Rarewares now.
John, the LameDrop link for version 3.98b6 seems to be wrong ; it gives me the cli encoder package.
For my personal use and maybe if someone wants to test beta 6 out on a Macintosh computer (and isn't command line savvy), I've compiled Max w/ LAME 3.98 beta 6.
http://www.vortec6.com/max071lame398b6.tar.gz (http://www.vortec6.com/max071lame398b6.tar.gz)
also the command line version in universal binary goodness
http://www.vortec6.com/lame398b6.tar.gz (http://www.vortec6.com/lame398b6.tar.gz)
Thanks!
John, the LameDrop link for version 3.98b6 seems to be wrong ; it gives me the cli encoder package.
Oooops!! Thanks for the heads-up, I've corrected that now.
You're welcome, thanks for your work ;-)
You did not notice the difference with NERO q 0.55 ?
Which Nero Version did you use?
This is a case of selective perception aka ""Hasty Generalization" and "Proof By Example". Both are typical mistakes made by "paranoid" and "idealistic" minds.
The dogmatic strange devoted phylosophic writing-like you do reveals deeply to me that you have a strong religion inside your heart. Your religion is SCIENTOLOGY!!! LOL
"a lot of things" meant irony in case you didn't know. But you HAD to take it to the religious path... oh boy....
You did not notice the difference with NERO q 0.55 ?
Which Nero Version did you use?
I used Nero AAC codec / Feb 12 2007 build since the latest version produces a horrible metallic warbling noise on some AAD mixed songs such as Iron Man by Black Sabbath.
http://www.hydrogenaudio.org/forums/index....showtopic=56849 (http://www.hydrogenaudio.org/forums/index.php?showtopic=56849)
I tested 3.98b6 -V2 with Birds, eig, harp40_1, herding_calls, lead-voice, trumpet, and trumpet_MyPrince.
On the positive side is harp40_1 which was pretty hard to abx for me at -V2.
eig is good too with respect to this extremely hard sample.
The trumpet_MyPrince tremolo problem near the end is also very easy to accept.
Everything else was as expected with the exception of trumpet: second 2.6-5.7 isn't good (also a kind of tremolo) and easily abxable 10/10. I rechecked with 3.98b5: same thing here.
Very strange as I was convinced trumpet wasn't a problem any more due to earlier listening tests with 3.98.I remember having heard it before but either has it turned more serious or may be my listening sensitivity for such a kind of problem has "improved".
Out of curiosity I also tried --vbr-old with these samples. --vbr-old is so clearly worse on nearly all the samples that I suspect there is a bug with --vbr-old. It's very pronounced with lead-voice and herding_calls.
@ /mnt
Well, that is interesting... because I abx'ed Nero-Latest with EIG even at ~300kbps. It's truly a killer codec sample. For OGG, you used aoTuV-latest?
@ /mnt
Well, that is interesting... because I abx'ed Nero-Latest with EIG even at ~300kbps. It's truly a killer codec sample. For OGG, you used aoTuV-latest?
Yeah I used the latest aoTuV ogg encoder at q6 and got 242kbps.
Did someone try the new 3.98b6??
That makes bigger file than old 3.98b6~
I did some quick ABX testing with "Hoobastank - Better" and "Red Hot Chili Peppers - Easily" (which both have been problem samples for my ears as they contain a lot of hi-hat) and while I could always ABX 10/10 with 3.97 -V2 --vbr-new, I haven't been able to get better than 14/20 and 13/20 with 3.98b6 -V2. Keep up the tuning and the good work!
For some reason I was under the impression that there weren't going to be significant changes between 3.98b5 and 3.98 final... and then I saw this. Would you (the collective you) recommend waiting for the final version to do any serious re-encoding?
There is no "official" 3.98 beta 6 yet. I'll let you know when it's done.
There is no "official" 3.98 beta 6 yet. I'll let you know when it's done.
Thanks for the quick update!
There is no "official" 3.98 beta 6 yet. I'll let you know when it's done.
Phew! I was wondering when someone of the devs was about to react. IMHO, not a good move to test a half-finished release. Especially with the new VBR tunings half-done it caused a lot of havoc.
I think we all have to quickly forget about these ABX results in this thread for now...
I appear to have jumped the gun slightly, here, quite unintentionally. I reacted to the uplift of the version number in 'version.h', which did not seem unreasonable, and I have to question the wisdom of doing that prior to the release being ready.
well until now the release version is usually the last thing to be updated prior to "release" - that's how i've always checked out lame in the past
but i agree, something more official would be ideal
later
what's next after 3.98 ? Lame 4.0 ??
what's next after 3.98 ? Lame 4.0 ??
Good question. However, 4.0 has always been and, as far as I know, still is Takehiro's baby and that branch has been inactive for the best part of two years!! So, it's any ones guess, I think. It would be good if he found the time/interest to revive it as it was a radical redesign.
i'm looking forward to 3.100 - that's going to be interesting
no sarcasms accepted... I have seen this 4.0 branch and wonder why what was it...
I tested 3.98b6 using ABR 320 and it yielded 317 kbps on one of my tracks. Previously it yielded 298 kbps on 3.97. What happened here?
http://www.hydrogenaudio.org/forums/index....st&p=524979 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58355&view=findpost&p=524979)
I get bigger files with lame 3.98b6
I'm listening mostly to louder music, metal/hardrock and rock influenced
Is 3.97 or 3.98b6 better for metal?
I get bigger files with lame 3.98b6
I'm listening mostly to louder music, metal/hardrock and rock influenced
Is 3.97 or 3.98b6 better for metal?
Given some of the results listed in this thread and that the 3.98b6 isn't official, I would wait for the official next beta and see how that compares.
I'm new here so I'm just a little confused - why would there be a Lame 3.98 beta 6 bundle available for download on rarewares if no "official" Lame 3.98 beta 6 is out yet? Would that be like a beta to the beta?
BTW, I'm using the recent 3.98 beta 6 from rarewares and it seems to work pretty well for me - but I'll keep checkign back for the final version.
I'm new here so I'm just a little confused - why would there be a Lame 3.98 beta 6 bundle available for download on rarewares if no "official" Lame 3.98 beta 6 is out yet? Would that be like a beta to the beta?
BTW, I'm using the recent 3.98 beta 6 from rarewares and it seems to work pretty well for me - but I'll keep checkign back for the final version.
By way of explanation: The source code is freely available from the LAME project on Sourceforge. The LAME project, per se, does not provide compiled executables for people, such as yourself, to download, people such as I download the latest source code, compile it and offer the resultant executables for people to download and use. In the case of LAME, the version numbering is controlled by one of the library header files, namely - version.h. Historically, this is the last file to be updated as a new release is made. However, in this instance, it would appear that the version number was uplifted in anticipation of the new release. As a consequence I, not unreasonably, I think based upon the history of this, assumed that this was a full, new beta release and announced it as such. On this occasion, apparently the release was not ready!!
There have been some changes since the last compile was made available, but given what has just occurred, I am hesitant to provide any fresh compiles until it is clear that the beta release is complete.
I get bigger files with lame 3.98b6
I'm listening mostly to louder music, metal/hardrock and rock influenced
Is 3.97 or 3.98b6 better for metal?
I am finding LAME 3.98 beta to be better for Metal and Hard Rock at V2, I can ABX a few Metal and Hard Rock tracks on LAME 3.97 while I find them transparent on LAME 3.90.3 (preset standard) and LAME 3.98 beta (V2). Also the drums on Metal and Rock is more prone to preecho and LAME 3.98b is less prone to preecho artifacts then LAME 3.97.
I'm new here so I'm just a little confused - why would there be a Lame 3.98 beta 6 bundle available for download on rarewares if no "official" Lame 3.98 beta 6 is out yet? Would that be like a beta to the beta?
BTW, I'm using the recent 3.98 beta 6 from rarewares and it seems to work pretty well for me - but I'll keep checkign back for the final version.
By way of explanation: The source code is freely available from the LAME project on Sourceforge. The LAME project, per se, does not provide compiled executables for people, such as yourself, to download, people such as I download the latest source code, compile it and offer the resultant executables for people to download and use. In the case of LAME, the version numbering is controlled by one of the library header files, namely - version.h. Historically, this is the last file to be updated as a new release is made. However, in this instance, it would appear that the version number was uplifted in anticipation of the new release. As a consequence I, not unreasonably, I think based upon the history of this, assumed that this was a full, new beta release and announced it as such. On this occasion, apparently the release was not ready!!
There have been some changes since the last compile was made available, but given what has just occurred, I am hesitant to provide any fresh compiles until it is clear that the beta release is complete.
Thanks for the explanation and all your hard work John... I'll keep checking rarewares for the new build with the full beta - in the meantime I'll keep using the 3.98 beta 6 that you put up on the 22nd.
I hope we will see final this year
Thanks for the explanation and all your hard work John... I'll keep checking rarewares for the new build with the full beta - in the meantime I'll keep using the 3.98 beta 6 that you put up on the 22nd.
But isn't that a bad idea as the "beta6" was created in the midst of some important (but not yet completed) tuning changes from beta5. Wouldn't it be better to stick to the official beta5 and take down the unofficial beta6 from rarewares as some tunings may be still broken?
Thanks for the explanation and all your hard work John... I'll keep checking rarewares for the new build with the full beta - in the meantime I'll keep using the 3.98 beta 6 that you put up on the 22nd.
But isn't that a bad idea as the "beta6" was created in the midst of some important (but not yet completed) tuning changes from beta5. Wouldn't it be better to stick to the official beta5 and take down the unofficial beta6 from rarewares as some tunings may be still broken?
Good point... I'd like to know if the unofficial Beta 6 is best to use for -V 0 --vbr-new or if I should be using Beta 5 or even 3.97 final... I'm about to rip a lot of albums and I'd hate to end up redoing it later.
New 3.98b6 came out at rarewares on 2007-11-01.
is that official?
New 3.98b6 came out at rarewares on 2007-11-01.
is that official?
Not as far as I know, it's just the latest CVS build, but I think it fixes one or two things.
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.
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 (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?
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.
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.
' 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.
' 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.).
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
' 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.
' 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.
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
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.
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's a new 2007-11-26 beta 6 build on Rarewares.
there is en new build every two days
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:
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
This sounds like the most significant development since 3.90
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:
(http://img135.imageshack.us/img135/7607/3961nq4.th.png) (http://img135.imageshack.us/my.php?image=3961nq4.png) (http://img80.imageshack.us/img80/8452/397mz2.th.png) (http://img80.imageshack.us/my.php?image=397mz2.png) (http://img80.imageshack.us/img80/503/398b6pi2.th.png) (http://img80.imageshack.us/my.php?image=398b6pi2.png) (http://img100.imageshack.us/img100/4812/398b62wn3.th.png) (http://img100.imageshack.us/my.php?image=398b62wn3.png)
(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.
New builds just posted at Rarewares. Significant changes:
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}
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?
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.
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?
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:
The --vbr-new switch enables the new VBR mode. Lame will encode much faster than the old/default VBR mode. In terms of quality, --vbr-new appears to be better than the old model, but reports of artifacts when using the new model do exist. Despite these possible issues, --vbr-new is currently recommended over the default VBR mode due to both the speed and quality increases afforded by the new algorithm.
from the changelog (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html): "The newer VBR code is now LAME's default VBR routine"
from the changelog (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html): "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?
from the changelog (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html): "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:
Fix for some rare scalefactor selection issue the newer vbr code had at low compression levels
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 (http://www.uni-koblenz.de/~smaxein/The%20Arrogant%20Worms%20-%20Carrot%20Juice%20Is%20Murder.flac).
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 (http://lame.cvs.sourceforge.net/lame/lame/libmp3lame/?sortby=date#dirlist)
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.
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 V2foo_abx 1.3.1 report
foobar2000 v0.9.5 beta 8
2007/12/17 11:53:32
File A: F:\Listen Tests\Stigmata LAME3.98b6 Offical V2.mp3
File B: F:\Listen Tests\Stigmata.wav
11:53:32 : Test started.
11:54:53 : 00/01 100.0%
11:55:33 : 01/02 75.0%
11:55:52 : 02/03 50.0%
11:56:09 : 03/04 31.3%
11:56:32 : 04/05 18.8%
11:56:51 : 04/06 34.4%
11:57:34 : 05/07 22.7%
11:58:16 : 05/08 36.3%
11:58:29 : 06/09 25.4%
11:58:52 : 07/10 17.2%
11:59:08 : 07/11 27.4%
11:59:48 : 08/12 19.4%
11:59:51 : Test finished.
----------
Total: 8/12 (19.4%)
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) V2foo_abx 1.3.1 report
foobar2000 v0.9.5 beta 8
2007/12/17 12:03:33
File A: F:\Listen Tests\Die In A Crash (Sample) LAME 3.98b6 Offical V 2.mp3
File B: F:\Listen Tests\Die In A Crash (Sample).wav
12:03:33 : Test started.
12:03:51 : 01/01 50.0%
12:04:03 : 02/02 25.0%
12:04:33 : 03/03 12.5%
12:04:55 : 04/04 6.3%
12:05:07 : 05/05 3.1%
12:05:12 : 06/06 1.6%
12:05:24 : 07/07 0.8%
12:06:01 : 08/08 0.4%
12:06:11 : 09/09 0.2%
12:06:21 : 10/10 0.1%
12:06:22 : Test finished.
----------
Total: 10/10 (0.1%)
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=58152) 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) V0foo_abx 1.3.1 report
foobar2000 v0.9.5 beta 8
2007/12/17 12:06:46
File A: F:\Listen Tests\Die In A Crash (Sample) LAME 3.98b6 Offical V 0.mp3
File B: F:\Listen Tests\Die In A Crash (Sample).wav
12:06:46 : Test started.
12:07:58 : 01/01 50.0%
12:08:24 : 01/02 75.0%
12:09:03 : 01/03 87.5%
12:09:55 : 02/04 68.8%
12:10:18 : 03/05 50.0%
12:12:23 : 03/06 65.6%
12:13:23 : 03/07 77.3%
12:13:51 : 04/08 63.7%
12:14:21 : 05/09 50.0%
12:15:19 : 06/10 37.7%
12:15:48 : 06/11 50.0%
12:16:03 : 06/12 61.3%
12:16:08 : Test finished.
----------
Total: 6/12 (61.3%)
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.
The 'official' beta 6 is now at Rarewares.
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....
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 (http://www.uni-koblenz.de/~smaxein/The%20Arrogant%20Worms%20-%20Carrot%20Juice%20Is%20Murder.flac).
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.
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.
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.
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.
Well, yes it sounds like a problem of foobar then.
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.
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.
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 (http://www.uni-koblenz.de/~smaxein/The%20Arrogant%20Worms%20-%20Carrot%20Juice%20Is%20Murder.flac).
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.
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.
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?
Can we get 3.98 final as a Christmas gift?
From HA wiki:
LAME development began around mid-1998.
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.
Can we get 3.98 final as a Christmas gift?
It's very unlikely that it will be released this year, because there are some issues with Debian and Cygwin/MSYS, which our confi-GURU wants to solve first.
Can we get 3.98 final as a Christmas gift?
It's very unlikely that it will be released this year, because there are some issues with Debian and Cygwin/MSYS, which our confi-GURU wants to solve first.
That's good news as I'm away from Friday, 21 Dec until 2 Jan with only very limited Internet access. Happy hols everyone!!
It's very unlikely that it will be released this year, because there are some issues with Debian and Cygwin/MSYS, which our confi-GURU wants to solve first.
so AFTER that, it will be released ?!?! ;-)
so AFTER that, it will be released ?!?! ;-)
There is a lot of time left AFTER one particular point in time
... So dear LAME devs have a nice Christmas and a happy New Year! And thanks a real lot for your hard and excellent work
I get the impression that only LAME project is the most active against other codecs, followed by NERO Digital. Vorbis seems so abandoned, and not mentinoning the slug MPC...
Would it be the case that LAME heads on top against its competitors at some point?
Would it be the case that LAME heads on top against its competitors at some point?
thanks to the lame devs' hard work, it could very well happen. at 128 kbps, lame moved from last place here (http://www.rjamorim.com/test/128extension/results.html)to tied at first place here (http://www.listening-tests.info/mf-128-1/results.htm). lame also tied with former champ mpc here (http://www.hydrogenaudio.org/forums/index.php?showtopic=36465).
...and not mentinoning the slug MPC...
You're wrong here. Vorbis may be abandoned, but Musepack isn't.
http://trac.musepack.net/trac/timeline (http://trac.musepack.net/trac/timeline)
I guess active members on HA also expect activities on the most promising codecs, and if there are none many members consider a codec to be dead. Look at the discussion about MPC before the current MPC activities.
But this has nothing to do with the quality of a codec. Quality simply may be fine without real need for improvement (thinking about Vorbis for instance).
Anyway the great quality improvements of Lame are most welcome as mp3 is the most universally usable standard of audio compression.
Thanks a lot to the Lame devs who have made Lame mp3 competitive with newer codecs.
I just tried tried the official 3.98b6 at V0, and though my last test was with a version pretty close to this one eig has improved one more time. The 2 prominent impulses that have been a problem for so long were a pretty negligible problem with my last test, but now there is no problem at all with them for practical listening situations. I had a hard time to abx them - I had to listen over and over again before daring to abx.
Trained this way I was also able to abx harp40_1, but from previous tests I have the experience that with mp3 it only takes sufficient time to be able to abx harp40_1 with any mp3 encoder, even at very high bitrate. Again this is academic, for practical listening situations it's no problem at all.
I was also able to abx the tremolo problem of the artificial lead-voice sample. I could not do so with my last test, so I guess this is also due to my current abx training with eig. lead-voice isn't important however for practical purposes.
My other tremolo problem sample trumpet_myyPrince was fine, and this sample has a practical impact.
My other problem samples (Birds, trumpet, herding_calls) were all not abxable to me.
We'll get a great 3.98 version.
Any news about the B6 eating up the cpu bug? Would be nice if that was solved then i could use it.
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.
That doesn't make much sense, B5 and B6 should behave the same. Are you using lame.exe or lame_enc.dll?
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.
That doesn't make much sense, B5 and B6 should behave the same. Are you using lame.exe or lame_enc.dll?
The dll.
More info:
https://sourceforge.net/tracker/?func=detai...mp;group_id=290 (https://sourceforge.net/tracker/?func=detail&atid=100290&aid=1836074&group_id=290)
The lame_enc.dll frontend code hasn't changed from b5 to b6. The lame_enc.dll doesn't do any file IO, it's the calling application -- in your case totalrecorder -- that does all reading and writing from and to the files. The application calls lame_enc in a loop and passes the data in memory. So, it seems to be more of a compiler / compiling issue, than a change in LAME itself.
The lame_enc.dll frontend code hasn't changed from b5 to b6. The lame_enc.dll doesn't do any file IO, it's the calling application -- in your case totalrecorder -- that does all reading and writing from and to the files. The application calls lame_enc in a loop and passes the data in memory. So, it seems to be more of a compiler / compiling issue, than a change in LAME itself.
I just did a check with the official B6 (forgot wich site but it wasn't rareware this time) to see what happened. And gues what the problem is now gone i have a normal cpu % again.
So it could be indeed the compiler that rareware used.
What should i do with the bugreport?
I just did a check with the official B6 (forgot wich site but it wasn't rareware this time) to see what happened. And gues what the problem is now gone i have a normal cpu % again.
Good to know, where did you get it from?
What should i do with the bugreport?
Nothing, I'll take care of it.
I just did a check with the official B6 (forgot wich site but it wasn't rareware this time) to see what happened. And gues what the problem is now gone i have a normal cpu % again.
Good to know, where did you get it from?
What should i do with the bugreport?
Nothing, I'll take care of it.
Stupid me, i always thought i got my non official beta's 6 builds from rarewares, but in fact it was from http://lame.bakerweb.biz/ (http://lame.bakerweb.biz/)
I gues it read so much about rarewares that somehow it was printed in my head, sorry about that.
The official and working B6 however was dloaded from rarewares, sorry for the misunderstanding.
Sorry if this was asked in an earlier post, but around what time will the final version of 3.98 be coming out?
Sorry if this was asked in an earlier post, but around what time will the final version of 3.98 be coming out?
robert replied here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=58385&view=findpost&p=536473):
Can we get 3.98 final as a Christmas gift?
It's very unlikely that it will be released this year, because there are some issues with Debian and Cygwin/MSYS, which our confi-GURU wants to solve first.
Sorry if this has been discussed before, however from the changelog (here (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html)) it states:
Feature request [ 1811483 ] WAVE_FORMAT_EXTENSIBLE support (PCM)
Does this potentially mean multichannel MP3, or that LAME will be able to read/select certain channel from a WAVE_FORMAT_EXTENSIBLE *.wav file (and prodece a mono/stereo track from those)?
Cheers, Arite.
I get the impression that only LAME project is the most active against other codecs, followed by NERO Digital.
But there's a big gap between them. Nero digital devs keep on telling there's problems regarding putting up stuff onto the web page, but however. I lost trust in the codec because of some problems with classical, they soon told the source of the problem has been found, but this is some ages ago.
Feature request [ 1811483 ] WAVE_FORMAT_EXTENSIBLE support (PCM)
Does this potentially mean multichannel MP3, or that LAME will be able to read/select certain channel from a WAVE_FORMAT_EXTENSIBLE *.wav file (and prodece a mono/stereo track from those)?
No.
Are there still planned features and bug fixes which affect quality before 3.98 goes stable?
Feature request [ 1811483 ] WAVE_FORMAT_EXTENSIBLE support (PCM)
Does this potentially mean multichannel MP3, or that LAME will be able to read/select certain channel from a WAVE_FORMAT_EXTENSIBLE *.wav file (and prodece a mono/stereo track from those)?
No.
OK, thanks for the reply - what does it mean then?
Cheers, Arite.
You can have normal mono/stereo wave files with WAVE_FORMAT_EXTENSIBLE format definition. Previously LAME did reject them or interpreted them as raw PCM files. Now LAME recognizes and may read them.
You're wrong here. Vorbis may be abandoned, but Musepack isn't.
Musepack wears out with the long long lack of constant releases. But it's not just it, we're talking about here audio quality. Guruboolez once stated that he was so frustrated with MPC people that wouldn't even acknowledge a plain clear issue concerning audio quality, and that still was not looked into until today. And more... projects with no-dateline are pretty depressing, put everybody on hold and pain. It's easier to look forward to something when you see that there will be new releases in a time, that everything is moving on. But when a developer says "it's out when it's out" or "I just don't know when it's out... perhaps some day in life" is just so depressing... MPC have sinned in many ways like this.
I get the impression that only LAME project is the most active against other codecs, followed by NERO Digital. Vorbis seems so abandoned
Wrong about Vorbis. It is absolutely necessary to keep Vorbis I as stable and the codebase as constant as possible. This has to do with the lack of a formal "external" specification for Vorbis similar to the MPEG-specs so that it is necessary to keep everything as frozen as possible to allow hardware-vendors to trust Vorbis and to step in and to support Vorbis I on their devices (MP3-players). The exception is Aoyumi as he really does a fantastic job in optimizing the sound quality - actually without changing the already existing codebase (apart from adding a few possibilities).
As far as I know, the work on Vorbis II has started but I do not know more about the reasons to start it...
You can have normal mono/stereo wave files with WAVE_FORMAT_EXTENSIBLE format definition. Previously LAME did reject them or interpreted them as raw PCM files. Now LAME recognizes and may read them.
OK - thanks a lot .
Arite.
Wrong about Vorbis. It is absolutely necessary to keep Vorbis I as stable and the codebase as constant as possible.
Vorbis I is not even the recommended Vorbis encoder in HA. All spotlight is directing to the only one
aoTuV b5, which is good but without a release for almost a year. LAME had always been releasing betas and reaching one more final release early next year.
Vorbis I is not even the recommended Vorbis encoder in HA. All spotlight is directing to the only one aoTuV b5, which is good but without a release for almost a year. LAME had always been releasing betas and reaching one more final release early next year.
Ahem, the aoTuV versions are "just" patches to Vorbis I and these patches are now in the Vorbis I development branch...
Yes, lame releases one version each year but most important for these releases are sound quality improvements (if they happen). Lame 3.98 --vbr (especially the newest betas b5 and b6) is a true gem in that respect but between 3.90.3 and 3.97 I couldn't see that many improvements. In fact, 3.97 --vbr-new sounded quite bad to me (I was angry about -V2 several times) ) and I got the impression that --cbr and 3.90.3 is still a very good alternative. Now, how old is 3.90.3? It is from May 2003!
In your opinion, would you make the Vorbis I encoder the recommended encoder since it has been released a few weeks ago and has the aoTuV patches? Or is it only in development branch? If not why aoTuV keeps being the recommended encoder even with low level noise added to encoded files?
LAME 3.98b6 should be set as the default encoder now.
3.97b1/2 was the recommended encoder for a long while (no point saying HA likes only "final" releases as stated by a member).
Now, how old is 3.90.3? It is from May 2003!
2001
Sorry guys, I haven't been here for ages and I don't have time to read through all the posts...
I haven't used MP3 since 3.96.1 final but I bought my mom a new MP3 player and so I needed to grab her a few CDs.
I googled for "lame", picked the first download, it was version 3.98b6 (oct 22 2007). Then I accidentally listened to one of the ripped songs and it was a shock for me!
here is the sample
http://www.volny.cz/martel/mp3test/test.zip (http://www.volny.cz/martel/mp3test/test.zip)
I used lame -b 128 -h command line to encode the song. The 398b6 version produced real nasty mess in the beginning:
http://www.volny.cz/martel/mp3test/test398.mp3 (http://www.volny.cz/martel/mp3test/test398.mp3)
I somewhat remembered mp3 quality over those years and this was too much. So I used the 3.96.1 version I had on disk and encoded with the same command line:
http://www.volny.cz/martel/mp3test/test3961.mp3 (http://www.volny.cz/martel/mp3test/test3961.mp3)
And here it goes - the mess was gone!
I don't care much about MP3 development anymore but imagine a normal user which googles for Lame and gets this junk, far inferior compared to several years old version!
I was like "WTF?!!!" myself. There should really be some warning attached to beta releases or the code should be somewhat restricted so normal people googling for LAME get the best version available, not some hocus-pocus junk like the version i got.
EDIT: Sorry, the links are down as my hosting got deleted without notice. Unfortunately, I don't have those files anymore.
Some regression is normal as long as overall quality is showing improvement. Also is CBR going through much tuning / testing ? I guess most people are interested in the vbr scale. Also -h is q2 and is not the default noise shaping - maybe different from 3.96 q2. Sometimes I got increased ringing from it.
... it was version 3.98b6 (oct 22 2007) ....
Unfortunately premature and incorrect versions of 3.98b6 were compiled and published.
The 'real' 3.98b6 version was published december 17th and can be downloaded from Rarewares (http://www.rarewares.org).
I guess everything is alright with this version, and you're welcome to try it.
I used lame -b 128 -h command line to encode the song. The 398b6 version produced real nasty mess in the beginning:
http://www.volny.cz/martel/mp3test/test398.mp3 (http://www.volny.cz/martel/mp3test/test398.mp3)
I somewhat remembered mp3 quality over those years and this was too much. So I used the 3.96.1 version I had on disk and encoded with the same command line:
http://www.volny.cz/martel/mp3test/test3961.mp3 (http://www.volny.cz/martel/mp3test/test3961.mp3)
And here it goes - the mess was gone!
Can't ABX these two. They sound identical to me.
... it was version 3.98b6 (oct 22 2007) ....
Unfortunately premature and incorrect versions of 3.98b6 were compiled and published.
The 'real' 3.98b6 version was published december 17th and can be downloaded from Rarewares (http://www.rarewares.org).
I guess everything is alright with this version, and you're welcome to try it.
If you mean this file
http://www.rarewares.org/dancer/dancer.php?f=186 (http://www.rarewares.org/dancer/dancer.php?f=186)
then know that I tried it out now and it produces exactly the same mess as the previously mentioned version (oct 22).
I used lame -b 128 -h command line to encode the song. The 398b6 version produced real nasty mess in the beginning:
http://www.volny.cz/martel/mp3test/test398.mp3 (http://www.volny.cz/martel/mp3test/test398.mp3)
I somewhat remembered mp3 quality over those years and this was too much. So I used the 3.96.1 version I had on disk and encoded with the same command line:
http://www.volny.cz/martel/mp3test/test3961.mp3 (http://www.volny.cz/martel/mp3test/test3961.mp3)
And here it goes - the mess was gone!
Can't ABX these two. They sound identical to me.
No offense meant, but I sincerely hope that you or people like you don't help develop LAME.
If you don't know what to look for - the 398 version adds audible (pre?)echo to both audio channels (before vocals come in). 3961 adds only almost inaudible one.
I use Sennheiser HD 490 headphones and an integrated Realtek HD audio sound card (Asus P5K). And I can hear the mess despite the mediocre setup I have.
If noone else can confirm the fuzz, then there's no hope for you guys. LOL
I think I'm going to back up my 3961 version of Lame pretty good.
I haven't used MP3 since 3.96.1 final but I bought my mom a new MP3 player and so I needed to grab her a few CDs.
This new mp3 player should be able to play VBR mp3s. Try -V5 instead of -b 128 -h
I haven't used MP3 since 3.96.1 final but I bought my mom a new MP3 player and so I needed to grab her a few CDs.
This new mp3 player should be able to play VBR mp3s. Try -V5 instead of -b 128 -h
No offense meant, but CBR (128, 160 and 192) is bread and butter of MP3. Is there really ANY reason to wreck it up in newer releases of LAME? I don't care about VBR as long as there is no two-pass encoding. And even if there was, I wouldn't trust a version that can't do CBR properly.
128k cbr is the most archaic thing and was notorious for giving mp3 a stigma. IMO its too unstable no matter what encoder. You need at least 160 or better yet 192 for steady cbr.
[/quote]Can't ABX these two. They sound identical to me. [/quote]
Same here. No "mess" in my ears, as well.
@Martel
Most probably your Mother won't hear the "mess" either. It must be a real curse and a burden to go through life with your incredible hearing.
Happy New Year!
Martel, beta is beta, you need to use 3.97 final.
I can confirm that the problem exists, I can ABX it without trouble. Will try the official 3.98b6 now to see if the problem still exists.
Edit: It's still a problem with the Dec 17 build. In fact, the created file is bit-identical with the problem file provided by Martel. The most obvious thing I can make out is a stereo problem; you can hear added stuff coming from the right in the 3.98 encode. Hard to describe this more clearly, sorry.
Edit2: An interesting point maybe, lame -V6 -b128 -B128 -F (with the Dec 17 build, also tried V0 with similar result) sounds better to me than any of the -b128 versions I listened to (i.e. also better than the "unproblematic" 3.96.1 encode). This is not encoding advice - it just seems to me that the VBR code can (at least sometimes) be better at cbr than the cbr code, which is kind of weird...
Martel is correct. The problem is obvious. I can hear the phenomenon easily with my crappy PC speakers. No need to switch to headphones or to my Hi-Fi system. This is something completely different than a minor artifact that can be reliably detected only by ABX testing.
The same problem exists already in the official v. 3.97. I didn't have 3.96.1 anywhere near but I tried the old reference 3.90.3 and it is clean similarly like Martel's 3.96.1 sample.
Here is a screenshot of Spectrum Laboratory's waterfall display. It contains the first three guitar chords (about 3 s.). The additional artifacts can be clearly seen in the 3.97 sample. The problem is more obvious in the left channel. The samples are (from top to bottom):
1. LAME 3.97 "release" @ -b 128 (which should use the optimized CBR presets automatically)
2. LAME 3.90.3 @ -b 128 -h (-m j is enabled by default)
3. original wave
(http://i224.photobucket.com/albums/dd212/AB2K/lameproblem_tn.png) (http://i224.photobucket.com/albums/dd212/AB2K/lameproblem.png)
Click to enlarge. (http://i224.photobucket.com/albums/dd212/AB2K/lameproblem.png)
EDIT
The most obvious thing I can make out is a stereo problem; you can hear added stuff coming from the right in the 3.98 encode. Hard to describe this more clearly, sorry.
Could you have the channels reversed? Looks like there's more additional stuff on the left.
Could you have the channels reversed? Looks like there's more additional stuff on the left.
Might be, but there's already the guitar there. It's easier to spot something when it comes from a previously "silent" direction I'd say.
Edit: I just listened to it with my speakers instead of headphones for the first time, now the distortion on the left is far more noticeable.
...If you mean this file
http://www.rarewares.org/dancer/dancer.php?f=186 (http://www.rarewares.org/dancer/dancer.php?f=186)
then know that I tried it out now and it produces exactly the same mess as the previously mentioned version (oct 22).....
Yes, that's the link I meant. And like Med0 and AlexB I can confirm your finding: the -b128 encoding is real bad, kind of a long-lasting additional echo.
No offense meant, but CBR (128, 160 and 192) is bread and butter of MP3. Is there really ANY reason to wreck it up in newer releases of LAME? I don't care about VBR as long as there is no two-pass encoding. And even if there was, I wouldn't trust a version that can't do CBR properly.
I agree with you that CBR should be fine as well (at least with this sample), and it seems to me too that general focus is too much on VBR in recent years. But I do think the Lame devs are willing to improve on problems found also with CBR. So your sample is valuable especially as not many people use CBR.
But shadowking's comment is true as well IMO: when using CBR a higher bitrate is necessary to get at real good results with mp3.
You can also see it the other way around: Lame 3.98b6 has become real good at VBR, and it's not a bad idea to use it.
Anyway it's up to you, and if you want to stick with CBR and want to use it right now, you may be better off using 3.96.1 or even 3.90.3.
@Martel
Most probably your Mother won't hear the "mess" either. It must be a real curse and a burden to go through life with your incredible hearing.
I'm pretty sure my mother can hear the problem and she was born in the '30s.
@Martel
Most probably your Mother won't hear the "mess" either. It must be a real curse and a burden to go through life with your incredible hearing.
I'm pretty sure my mother can hear the problem and she was born in the '30s.
You know, I gotta re-listen to these samples again when I get home from work, because I coudn't hear it on these PC speakers. When Martel used the word "mess", I imagined this ungodly unlistenable noise, and even if there is this echo that you all hear is it that terrible that it makes it unlistenable? That LAME is useless because of it? Do I need to get a doctor's referral for a hearing test? My 50 year old ears just don't hear the "mess" that Martel does.
...even if there is this echo that you all hear is it that terrible that it makes it unlistenable? That LAME is useless because of it?
If Lame is regressing (the sample sounds fine using 3.96 and 3.90) then it should be brought to the attention of the developers.
... I imagined this ungodly unlistenable noise, and even if there is this echo that you all hear is it that terrible that it makes it unlistenable? That LAME is useless because of it? Do I need to get a doctor's referral for a hearing test? My 50 year old ears just don't hear the "mess" that Martel does. ...
It's personal judgement how to feel about a problem.
Anyway it's a real problem that hopefully will be repaired.
No offense meant, but CBR (128, 160 and 192) is bread and butter of MP3. Is there really ANY reason to wreck it up in newer releases of LAME? I don't care about VBR as long as there is no two-pass encoding. And even if there was, I wouldn't trust a version that can't do CBR properly.
No, there's no reason to wreck CBR quality and I hope this problem gets corrected. But why not care about VBR just because there is no two-pass encoding? And even if it butchers all samples with CBR, if it sounds better with VBR and works with your MP3 player then why not use it?
I don't care about VBR as long as there is no two-pass encoding.
VBR doesn't need "two-pass encoding".
"two-pass encoding" is for ABR.
It's personal judgement how to feel about a problem.
Anyway it's a real problem that hopefully will be repaired.
That is precisely the point; I didn't hear the problem, so I thought the original post was overly exaggerated. If there is a problem, I agree that it needs to be addressed, but it also sounded like a LAME trashing. Also, as kkumul pointed out, his rationale for not using VBR due to the lack of two-pass encoding was totally incorrect. The post just sounded like more of a rant than an actual issue. I stand corrected on the echo problem.
It's personal judgement how to feel about a problem.
Anyway it's a real problem that hopefully will be repaired.
That is precisely the point; I didn't hear the problem, so I thought the original post was overly exaggerated. If there is a problem, I agree that it needs to be addressed, but it also sounded like a LAME trashing. Also, as kkumul pointed out, his rationale for not using VBR due to the lack of two-pass encoding was totally incorrect. The post just sounded like more of a rant than an actual issue. I stand corrected on the echo problem.
I don't have any reason to put shame on LAME, I might have even exaggerated the problem as well, sorry. Perhaps it's all those years of not using MP3 and then hearing new version being much worse than the four-years-old one, than the standard I was used to. It kind of agitated me to see such "development" and as I barely remember, similar problems were with 3.97 early version some three years ago... Nobody listened to me at that time so I gave up. Now I returned after three years to try again, fortunately I see someone else noticed the problem as well this time... Perhaps, there is hope left after all.
I hope my contribution helps to open your eyes and get together. I have no reason to cause flame of any sort... I'm far too old for that stuff.
What people mean by telling that development goes to VBR? AFAIU it's about "polishing" -Vx modes. So, if even no development in CBR how it can happen we've got such degradation? Is it related to introduced new psy model? 3.98 still have 128 bps bandwith for encode as well as 3.96 had...
P.S. I hear the difference in provided samples, and amount of added sounds is very distracting. FYI: -V4 is transparent to me.
Are there any source tarballs for 3.98b6? Or you can get it only through cvs?
Yes, that's the link I meant. And like Med0 and AlexB I can confirm your finding: the -b128 encoding is real bad, kind of a long-lasting additional echo.
I can easily hear it as well (in both 3.96.1 and 3.98b6) but I tried to identify it on the left and right channel independently and here it might start to become interesting.
The thing is that the guitar is on the left side close to the micro and it gives a clear sound in the left channel for the WAV sample. Everything ok. 3.98b6 and 3.96.1 both really sound as if there is a permanent echo on the left side.
In the right channel on the other hand it sounds as if there is some interference and a permanent echo in the WAV-file (maybe a wall reflecting the sound waves). This echo can also be found in the two MP3 files. I cannot identify a difference between the WAV file and the two MP3 files for the right channel. The echoes in the WAV-file (right channel) sounded to me very similar to the permanent echoes present in the MP3 files on the left channel.
So I assumed that it might be not a standard pre-echo in the left channel (sounds a bit different from pre-echo as I understand it) but a channel coupling interference between the left and the right channel due to the joint stereo mode of the MP3 files.
So I used lame3.98b6 and encoded the test file with -h -b 128 -md, therefore producing a dual-channel file.
But apparently I was wrong and the left channel sounded as distorted as before - so (probably) no channel coupling issue.
I also thought of a joint stereo problem and tried forced stereo (-m s), but without success.
Quite interesting however that 3.96.1 is affected too. Didn't sound like that so far.
Hm i always thought i had a good hearing (i did a lot of testing before with different encoder settings/versions). But it seems i also dont have the golden ears because after listening 10 times to each sample, i just cant hear the difference between them on my pc / pcspeakers.
If you like to try it again: it's already within the first 3 seconds, and it's an added echo (I think 'echo' describes it best, but don't think of pre-echo problems).
Oh, and usually problems are easier to hear with headphones/earphones than with speakers.
Indeed, thanks if you know were and what to listen you can hear it very clearly. It remind me of the sound the plastic tubes made in the 70's. You had to swing them around your head and then the made a swoozing sound depending on the speed you rotated.
I also did a quick check with my own favorite setting lame --preset fast standard, then it is gone but ofcourse it is bigger 247k instead 183k.
Did another quick test and lowered Vbr from q3 to q4 to q5 (q5 is as big as the original 128k cbr sample mp3). And i could not hear the "swooz" anymore.
btw i have a question of my own. I noticed in cmd line mode that lame uses 2 different signs for the bars.
112 [ 82] %%%%%%%%%%%%%%%%%%%*****************
If i remember correct it was always 1 sign (*). Whats the meaning / difference of the "%" and the "*"?
Did another quick test and lowered Vbr from q3 to q4 to q5 (q5 is as big as the original 128k cbr sample mp3). And i could not hear the "swooz" anymore.
What I found most interesting was that the encoded file sounds fine if you use vbr, even if you only use one frame size (i.e. 128kbps).
Yes, and to me it's an indication that CBR/ABR mode was not as much in the devs' focus as was VBR.
I can confirm Ojay's finding that 3.96.1 is affected too. But to my ears it is so at a considerably minor degree.
I went further back in time and tried 3.93.1, 3.92, 3.91, 3.90.3, and it takes a lot of concentration now to abx the problem. If the problem wasn't known in advance I can't imagine it would be found within practical listening.
In contrary to Lame 3.96.1+ when using -b 128 with 3.93.1- the psy model gpsycho is used.
Using nspsytune with these older versions (as is done with 3.96.1+) by means of '--alt-preset cbr 128' brings back the problem to these old versions as well.
So it is a nspsytune problem which however is overcome when using VBR.
If its a cbr only problem, then it would be also intresting to know at which bitrate it dissapears, if it dissapears.
No offense meant, but I sincerely hope that you or people like you don't help develop LAME.
If you don't know what to look for - the 398 version adds audible (pre?)echo to both audio channels (before vocals come in). 3961 adds only almost inaudible one.
I use Sennheiser HD 490 headphones and an integrated Realtek HD audio sound card (Asus P5K). And I can hear the mess despite the mediocre setup I have.
If noone else can confirm the fuzz, then there's no hope for you guys. LOL
I think I'm going to back up my 3961 version of Lame pretty good.
OK OK I must admit that at first I didn't listen to carefully enough and I listened to it with crappy laptop speakers. Now with proper headphones I can definitely hear it...
btw i have a question of my own. I noticed in cmd line mode that lame uses 2 different signs for the bars.
112 [ 82] %%%%%%%%%%%%%%%%%%%*****************
If i remember correct it was always 1 sign (*). Whats the meaning / difference of the "%" and the "*"?
I think its about stereo-mono data distrubution in join mode.
As a praticle matter, if you are concerned about size, VBR is clearly the way to go and has no problems. If size doesn't matter, use CBR at a high bitrate which has no problems. Since VBR is superior to CBR at low bitrates, this is like trying to fit a square peg into a round hole!
If its a cbr only problem, then it would be also intresting to know at which bitrate it dissapears, if it dissapears.
The problem is still obvious at 160kbps, but it seems to disappear at 192 kbps.
I tried quickly the last 1.5 seconds of my "the first 3 s" clip of the provided sample (I set the additional offset to 1500 ms in the ABC-HR Java settings) using the following encoding settings:
LAME 3.98b6 -b 160 and -b 192
LAME 3.97 -b 160 and -b 192
LAME 3.90.3 -b 160 -h and -b 192 -h
ABC/HR for Java, Version 0.52b, 30 December 2007
Testname: CBR problem
Tester: Alex B
1R = U:\test\LAME_CBR_problem\3s_clip_3.98b_160.wav
2R = U:\test\LAME_CBR_problem\3s_clip_3.98b_192.wav
3R = U:\test\LAME_CBR_problem\3s_clip_3.97_192.wav
4R = U:\test\LAME_CBR_problem\3s_clip_3.90.3_160.wav
5L = U:\test\LAME_CBR_problem\3s_clip_3.90.3_192.wav
6L = U:\test\LAME_CBR_problem\3s_clip_3.97_160.wav
Ratings on a scale from 1.0 to 5.0
---------------------------------------
General Comments:
---------------------------------------
1R File: U:\test\LAME_CBR_problem\3s_clip_3.98b_160.wav
1R Rating: 3.0
1R Comment: the problem is obvious
---------------------------------------
2R File: U:\test\LAME_CBR_problem\3s_clip_3.98b_192.wav
2R Rating: 4.3
2R Comment: some additional high frequency noise (similar to tape hiss)
---------------------------------------
6L File: U:\test\LAME_CBR_problem\3s_clip_3.97_160.wav
6L Rating: 3.0
6L Comment: the problem is obvious
---------------------------------------
ABX Results:
Original vs U:\test\LAME_CBR_problem\3s_clip_3.90.3_160.wav
6 out of 8, pval = 0.144
Original vs U:\test\LAME_CBR_problem\3s_clip_3.98b_192.wav
7 out of 8, pval = 0.035
Original vs U:\test\LAME_CBR_problem\3s_clip_3.97_192.wav
4 out of 8, pval = 0.636
Original vs U:\test\LAME_CBR_problem\3s_clip_3.90.3_192.wav
2 out of 8, pval = 0.964
---- Detailed ABX results ----
Original vs U:\test\LAME_CBR_problem\3s_clip_3.90.3_160.wav
Playback Range: 00.776 to 01.221
11:35:22 AM p 1/1 pval = 0.5
11:35:36 AM p 2/2 pval = 0.25
11:35:44 AM p 3/3 pval = 0.125
11:35:56 AM p 4/4 pval = 0.062
11:36:00 AM p 5/5 pval = 0.031
11:36:08 AM f 5/6 pval = 0.109
11:36:17 AM f 5/7 pval = 0.226
11:36:30 AM p 6/8 pval = 0.144
Original vs U:\test\LAME_CBR_problem\3s_clip_3.98b_192.wav
Playback Range: 00.744 to 01.496
11:12:21 AM f 0/1 pval = 1.0
11:13:50 AM p 1/2 pval = 0.75
11:14:14 AM p 2/3 pval = 0.5
11:14:40 AM p 3/4 pval = 0.312
11:16:00 AM p 4/5 pval = 0.187
Playback Range: 00.000 to 00.469
11:17:01 AM p 5/6 pval = 0.109
Playback Range: 00.864 to 01.226
11:18:07 AM p 6/7 pval = 0.062
11:19:37 AM p 7/8 pval = 0.035
Original vs U:\test\LAME_CBR_problem\3s_clip_3.97_192.wav
Playback Range: 00.000 to 00.602
11:39:42 AM f 0/1 pval = 1.0
11:40:02 AM p 1/2 pval = 0.75
11:40:18 AM p 2/3 pval = 0.5
11:40:50 AM f 2/4 pval = 0.687
11:41:10 AM p 3/5 pval = 0.5
11:41:43 AM f 3/6 pval = 0.656
11:42:36 AM f 3/7 pval = 0.773
11:42:48 AM p 4/8 pval = 0.636
Original vs U:\test\LAME_CBR_problem\3s_clip_3.90.3_192.wav
Playback Range: 00.720 to 01.202
11:27:53 AM f 0/1 pval = 1.0
11:27:58 AM f 0/2 pval = 1.0
11:28:17 AM p 1/3 pval = 0.875
11:29:21 AM f 1/4 pval = 0.937
11:29:39 AM f 1/5 pval = 0.968
11:30:27 AM f 1/6 pval = 0.984
11:31:20 AM f 1/7 pval = 0.992
11:31:38 AM p 2/8 pval = 0.964
But then one could ask why would anyone still use cbr, cbr was usefull 10 years ago for mp3 players not supporting vbr.
But today the only use i could think of is for streaming (internetradio) but i believe we have the better abr for that now.
Also when converting al your dvd's without quality loss then 320cbr could be usefull. But thats all i can think of.
Maybe its not a bad thing that they focus only on vbr, dont know about abr. cbr seems to me something oldskool. vbr seems to me the only way to go.
This is not about CBR limitations in general. This is about something that worked fine before the v. 3.97 and for some reason doesn' t work anymore. I hope the LAME developers can find the reason for this obvious regression and fix it. Maybe it is just a mishap somewhere in the current code.
Ah ok i didnt knew that
I tried to find other samples which would have similar characteristics and possibly trigger the same problem. I have tested a few, but not found anything similar yet.
While doing this I noticed that Martel's reference sample has a lowpass filter applied at about 16 kHz. I am not trying to guess if the sample is from a lossy source or if one of the official versions of the track really has this kind of filter applied.
I have Bee-Gees' "Tales From The Brothers Gibb" compilation from the year 1990 in my archive. It has a version of the same track. It is quieter, less compressed and doesn't have a distinctive low pass frequency.
I uploaded a sample of the same passage here: http://www.hydrogenaudio.org/forums/index....showtopic=60113 (http://www.hydrogenaudio.org/forums/index.php?showtopic=60113)
In any case, the same problem exists when files are encoded from my version of the sample so the problem is not caused by the possibly transcoded sample.
Sorry I ran upon another problem for Lame (http://www.hydrogenaudio.org/forums/index.php?showtopic=60114&pid=538321&st=0&#) I could abx 10/10 using Lame (3.98b6) -V0.
is the latest cvs code change affect in encoding speed?
im just compiled one (http://y0ngc6.googlepages.com/3.98a6.7z) from cvs with mingw gcc4.21sjlj, encoding speed seems abit faster than rarewares build.
and i noticed some console info is mssing on new build,
eg:
quantization: xr^3/4
...
using psychoacoustic model: 1
psychoacoustic model: NSPsytune
is there something wrong with gcc or compiling problem?
P.S. im still pretty new to ha.org and coding world
I tried to find other samples which would have similar characteristics and possibly trigger the same problem. I have tested a few, but not found anything similar yet.
While doing this I noticed that Martel's reference sample has a lowpass filter applied at about 16 kHz. I am not trying to guess if the sample is from a lossy source or if one of the official versions of the track really has this kind of filter applied.
I have Bee-Gees' "Tales From The Brothers Gibb" compilation from the year 1990 in my archive. It has a version of the same track. It is quieter, less compressed and doesn't have a distinctive low pass frequency.
I uploaded a sample of the same passage here: http://www.hydrogenaudio.org/forums/index....showtopic=60113 (http://www.hydrogenaudio.org/forums/index.php?showtopic=60113)
In any case, the same problem exists when files are encoded from my version of the sample so the problem is not caused by the possibly transcoded sample.
The sample is from "Bee Gees - The Greatest Hits vol. 1". I think it's just the "modern" remastering...
@halb27
does the problem you spotted in LAME persists in 320kbps CBR?
@halb27
does the problem you spotted in LAME persists in 320kbps CBR?
I don't know but I will try it.
But it will take some time as my system is down (I'm just using my wife's notebook).
Forgive me for being a noob, but has anyone brought Martel's problem sample to the attention of Robert or another LAME developer? I can also confirm the 'swoosh' sound in 3.98b6, and its absence in 3.90.1.
What is all this noise ? Its low volume ringing. 3.97 is the same. I abx easily V5, V4 .. @ V3 I got a bit confused, but after a while I could do it. By V2 its really really close, but I managed 13/16.
Tracks with solo vocal, guitar are 'difficult'. Dibrom said this in old posts.
Tracks with solo vocal, guitar are 'difficult'. Dibrom said this in old posts.
Yeah, but the LAME version from "Dibrom's time" doesn't appear to have this particular problem when 128 or 160 kbps CBR is used. (I didn't try VBR because Martel's report was about CBR.)
I hope the regression is caused by some kind of mishap and can be easily fixed without breaking something else.
@halb27
does the problem you spotted in LAME persists in 320kbps CBR?
I've tried to build an uptodate system based on my old one, but didn't succeed. Looks like the mainboard or memory (or their cooperation) isn't alright. So I reinstalled my old components.
I just relistened to the problem again and - shame on me - can't abx it at all using -V0. Maybe I'm still too upset with my system trouble. I also tried -b320 and got at 5/6 which in the end turned out to be 6/10 - the very kind of result I formerly often got with french woman singers: too good to be ignored and too bad to take it as a proper abx result. Trying -V0 again for a final check I had no chance to abx it.
Despite my poor results I think it's enough to conclude that -b320 doesn't solve the problem.
@halb27
does the problem you spotted in LAME persists in 320kbps CBR?
I have the same experience as halb27. fail at 320kbps.
But even at q-0 the problem is very slight and not annoying. (for me at least) It may actually transparent to your ear.
Why there is no sources for 3.98 betas on SourceForget.net: LAME Dowload (http://sourceforge.net/project/showfiles.php?group_id=290&package_id=309) page?
There was betas before 3.97 version. Or its not good enought for it?
Why there is no sources for 3.98 betas on SourceForget.net: LAME Dowload (http://sourceforge.net/project/showfiles.php?group_id=290&package_id=309) page?
Available via CVS. For example, see here: http://sourceforge.net/forum/forum.php?thr...mp;forum_id=887 (http://sourceforge.net/forum/forum.php?thread_id=1817865&forum_id=887)
It has been some time since I followed LAME development and reading this thread shows that there are regressions and improvements provided by this new beta version, however I am not into the recent development/testing process.
I have to do some encodes at the V5 range and I was wondering if 3.98b6 is safe to use or if I should use the stable 3.97 version instead. I intend to use --vbr-new as well to speed up things. Do you see any problems?
thanks
... I have to do some encodes at the V5 range and I was wondering if 3.98b6 is safe to use ....
I'm very happy with 3.98b6 but my experience is with -V3+, and with this I prefer 3.98 over 3.97. I guess the advantageous behavior is valid for -V5 too, but can't really tell about it.
I tested a 30 second sample using 3.98b6 (Mar 12, 2008) vs 3.97 both with -V 6 --vbr-new, and on this sample, I noticed regression from 3.97. I'm sorry that I haven't done any listening test on Lame lately, and this finding may be too late to be any help for the final 3.98 release, but it might amount to something for your future development. I will try to find more regression later if I can.
Considering that very few people (or none that I remember) have reported regression issues with 3.98b6 at low bitrate, this may well be an exception, but I don't think this sample is a killer sample or anything. I will upload it to the Upload section in a few minutes (first 30 seconds of Giant Steps by Coltrane).
ABC/HR Version 0.9b, 30 August 2002
Testname: 3.97 -V 6 --vbr-new vs 3.98b6 -V 6
1R = C:\My Test Samples\gsteps\398.mp3.wav
2L = C:\My Test Samples\gsteps\397.mp3.wav
---------------------------------------
General Comments:
sample #2 was much harder to ABX.
---------------------------------------
1R File: C:\My Test Samples\gsteps\398.mp3.wav
1R Rating: 1.0
1R Comment: Distortion is severe throughout the sample.
---------------------------------------
2L File: C:\My Test Samples\gsteps\397.mp3.wav
2L Rating: 2.0
2L Comment: Distortion is not nearly as severe as #1.
---------------------------------------
ABX Results:
Original vs C:\My Test Samples\gsteps\398.mp3.wav
8 out of 8, pval = 0.004
Original vs C:\My Test Samples\gsteps\397.mp3.wav
7 out of 8, pval = 0.035
C:\My Test Samples\gsteps\398.mp3.wav vs C:\My Test Samples\gsteps\397.mp3.wav
8 out of 8, pval = 0.004
Just an observation from your results:
sample #2 was much harder to ABX.
1R Rating: 1.0
2L Rating: 2.0
2L Comment: Distortion is not nearly as severe as #1.
ABX Results:
Original vs C:\My Test Samples\gsteps\397.mp3.wav
7 out of 8, pval = 0.035
C:\My Test Samples\gsteps\398.mp3.wav vs C:\My Test Samples\gsteps\397.mp3.wav
8 out of 8, pval = 0.004
I would have no problems ABX ing something that I rate as "Annoying".
' date='Mar 24 2008, 05:32' post='554570']
Just an observation from your results:
sample #2 was much harder to ABX.
1R Rating: 1.0
2L Rating: 2.0
2L Comment: Distortion is not nearly as severe as #1.
ABX Results:
Original vs C:\My Test Samples\gsteps\397.mp3.wav
7 out of 8, pval = 0.035
C:\My Test Samples\gsteps\398.mp3.wav vs C:\My Test Samples\gsteps\397.mp3.wav
8 out of 8, pval = 0.004
I would have no problems ABX ing something that I rate as "Annoying".
That means that my ears aren't that good.
If people are complaining about 3.98b6, why aren't people using the previous beta that apparently didn't have those issues?
Is it because Rarewares doesn't have it anymore?
- Spike
That means that my ears aren't that good.
It is not about ears. It is about terminology. If it annoys you, you're disturbed while listening to it. i.e. you wouldn't listen to it for a prolongued period of time.
I am sure you meant to rate it between 4 and 5, which stands for "Perceptible, but not annoying". I.e. You could happen to hear it, (in your case you had to put efforts on it), so in a casual listening you wouldn't mind/notice it, and as such, not annoy you.
I stress this point, because else, the listening tests that we run sometimes here, wouldn't have much sense. If a thing is either 5 (Not perceptible) or 2 (Annyoing), The scale is converted to something like is either white or black.
Don't take this as personal, but rather as a thing to think about when doing abc-hr tests, alright?
The file I promised has been uploaded here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=62129&view=findpost&p=554652).
I can confirm the problem. 3.97 is better here with -V6 for me too .
is there a release schedule for the final version of 3.98?
Just noticed Updated Beta 6 :
"LAME 32bits version 3.98 (beta 6, Mar 12 2008) (http://www.mp3dev.org/)"
Sources - http://sourceforge.net/project/showfiles.p...;package_id=309 (http://sourceforge.net/project/showfiles.php?group_id=290&package_id=309)
Binaries - http://rarewares.org/mp3-lame-bundle.php (http://rarewares.org/mp3-lame-bundle.php)
"lame 3.98 beta 6 (small fix) Notes(2008-03-12 13:47)"
CVS - http://lame.cvs.sourceforge.net/lame/lame/...me/?sortby=date (http://lame.cvs.sourceforge.net/lame/lame/libmp3lame/?sortby=date)
// @ devs : check my ticket (http://sourceforge.net/tracker/index.php?func=detail&aid=1934729&group_id=290&atid=100290) please
Just noticed Updated Beta 6 :
"LAME 32bits version 3.98 (beta 6, Mar 12 2008) ...
Wouldn't it be better to have a new beta version instead of multiple versions of the same beta? This causes confusion when talking about found bugs.
Anyone know what's actually changed in the new beta 6?
- Spike
Anyone know what's actually changed in the new beta 6?
- Spike
http://lame.cvs.sourceforge.net/*checkout*...ml/history.html (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html)
Anyone know what's actually changed in the new beta 6?
- Spike
http://lame.cvs.sourceforge.net/*checkout*...ml/history.html (http://lame.cvs.sourceforge.net/*checkout*/lame/lame/doc/html/history.html)
The changelog on the url mentioned above still says, "LAME 3.98 beta 6 December 16 2007". Has it been updated to incorporate the changes that went into the subsequent re-released beta6?
--Vinu.
The changelog on the url mentioned above still says, "LAME 3.98 beta 6 December 16 2007". Has it been updated to incorporate the changes that went into the subsequent re-released beta6?
--Vinu.
You can read http://lame.cvs.sourceforge.net/lame/lame/...me/?sortby=date (http://lame.cvs.sourceforge.net/lame/lame/libmp3lame/?sortby=date) and other pages.
psymodel.c 1.178 9 hours robert some simpler spreading function for VBR NEW
set_get.c 1.87 9 hours robert some simpler spreading function for VBR NEW
version.h 1.114 9 hours robert some simpler spreading function for VBR NEW
presets.c 1.65 9 hours robert some simpler spreading function for VBR NEW
lame_global_flags.h 1.44 9 hours robert some simpler spreading function for VBR NEW
id3tag.c 1.52 19 hours robert changing some links from "www.mp3dev.org/mp3" to "www.mp3dev.org" and from "www....
Interesting: current CVS compile says it's beta
7:
LAME 32bits version 3.98 (beta 7, Apr 6 2008) (http://www.mp3dev.org/)
Edit: formatting
Time for a new thread (click) (http://www.hydrogenaudio.org/forums/index.php?showtopic=62453) then
Let's not get into the situation we had with b6 that the release number had changed but the beta wasn't ready for release yet. It's official now
Anyone know what's actually changed in the new beta 6?
could it be one of fixes in the remarks on rarewares?
(Includes the decoding fix for mp3 files and the fix for decoding through stdout. Both now included in CVS. Also now includes Nyaochi's Album Art Id3 Patch, also in the CVS.)
I'll get some beta 7 compiles up in a couple of hours, or so. (I was away over night and only just returned home. )
John, I have an old question to you... the Lame compiles doesn't have optimized versions for SSE and SSE2 like Vorbis compiles. Why that?
By the way, thanks for the binaries!
John, I have an old question to you... the Lame compiles doesn't have optimized versions for SSE and SSE2 like Vorbis compiles. Why that?
By the way, thanks for the binaries!
Basically because LAME has assembler routines that provide all the optimisation necessary and the Intel compiler options add no measurable speed benefit.
Beta 7 compiles now available.
Thanks a bunch for the changelog update- the LAME changelog now mentions beta 7.
Also, thanks as always to john33 for his new binaries! Really appreciated.
- Spike