Skip to main content

Notice

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

Lame 3.94a11

Adjustements to medium and medium1
Very small adjustement to standard.
Tuning of extreme.

I'd appreciate feedback about medium and medium1, as I do not know which one to choose.

Lame 3.94a11

Reply #1
Where can the binary be found please ?

Lame 3.94a11

Reply #2
Quote
Where can the binary be found please ?

At my 'Other' page at Mirror 1, link at foot of main page.

Lame 3.94a11

Reply #3
John, why use ICL6? Your own tests with oggenc showed that ICL7 is usually faster and produces results that are closer to the "reference" vc6.

FWIW, I definitely prefer --medium over --medium1. M1 has this metallic harshness to it that M doesn't. M on the other hand is a little more flat, but that's not nearly as objectionable.

 

Lame 3.94a11

Reply #4
Quote
John, why use ICL6? Your own tests with oggenc showed that ICL7 is usually faster and produces results that are closer to the "reference" vc6.

FWIW, I definitely prefer --medium over --medium1. M1 has this metallic harshness to it that M doesn't. M on the other hand is a little more flat, but that's not nearly as objectionable.

That was with the P4 optimised versions. In all other cases, so far, I've found the ICL7 versions compiled against the VC7 libs to be slower, and the ICL7 versions compiled against the VC6 libs to be no different. Worse, there are some instances where there is clear evidence that ICL7 is not as well integrated with VC7 as Intel would have you believe.

What would make more sense really, would be for me to compile all LAME versions against ICL4.5!!

Lame 3.94a11

Reply #5
I encountered the following error message in the log file after encoding a track with --alt-preset standard:

Quote
Command: C:\Temp\Downloads\lame.exe --alt-preset standard "C:\pulp\Pulp - Disco 2000.wav" "C:\pulp\Pulp - Disco 2000.mp3"
LAME version 3.94 MMX (alpha 11, Feb  9 2003 11:16:20) (http://www.mp3dev.org/)
warning: alpha versions should be used for testing only
CPU features: i387, MMX (ASM used)
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding C:\pulp\Pulp - Disco 2000.wav to C:\pulp\Pulp - Disco 2000.mp3
Encoding as 44.1 kHz VBR(q=4) j-stereo MPEG-1 Layer III (ca. 10x) qval=3
RazorLame encountered an unknown message from LAME while trying to encode "C:\pulp\Pulp - Disco 2000.wav"!

Encoded 0 files in 0:04:18
There was an unexpected LAME message for one file, please check log for error messages.


Despite saying that it encoded no files, it did completely encode the track, and it sounded fine.

Filesize of the MP3 was 7,479,416 and averaged at 219kbps.

With my usual LAME version, 3.92, using --alt-preset standard, the filesize is 7,994,548 and averages 234kbps.

Lame 3.94a11

Reply #6
the reason of that is because of the frontend.

As it says clearly, it has read a sentence that it doesn't expect. It might perfectly be this one "warning: alpha versions should be used for testing only" although I'm not sure.


For the general rule, don't use frontends for testing versions, and of course, don't use testing versions for real encodes.

Lame 3.94a11

Reply #7
Nah, I was testing.

Yeah, I realised that it might be the case after I posted it... thought I'd leave it up just in case, though. If it's just the usual alpha message that RL is not recognising then no problems.

Lame 3.94a11

Reply #8
Not sure if this will be of use to decide, but I've made some comparisons.
I can hear differences between standard and medium (haven't spent the time on ABX'ing, don't get this for sure, but I seem to hear a little bit of flanging on a cymbal and more noisy on a saw sound).
When trying to find differences between medium and medium1, I haven't succeeded (on this file, music made with PC and software synths).

And bottom line : Will the speed improve? It's half the speed now!

-3.90.2 -aps :

  8252/8255  (100%)|    1:20/    1:20|    1:21/    1:21|  2.6866x|    0:00
32 [  1] *
128 [ 544] %%%%**************
160 [ 988] %%%%%%%%%%***********************
192 [1361] %%%%%%%%%%%%%%%%%%%%%%%%*********************
224 [1949] %%%%%%%%%%%%%%%%%%%%%%%%%%**************************************
256 [2037] %%%%%%%%%%%%%%%%%%%***********************************************
320 [1375] %%%%%%%%%%%%%%%******************************
average: 228.6 kbps  LR: 2893 (35.05%)  MS: 5362 (64.95%)

3.94a11 -aps:

  8252/8254  (100%)|    2:24/    2:24|    2:24/    2:24|  1.4877x|    0:00
32 [  1] *
96 [ 150] %%*
112 [ 134] %**
128 [ 263] %****
160 [1288] %%%%%%%%%%%************
192 [3753] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%************************
224 [1836] %%%%%%%%%%%%%%%%%****************
256 [ 646] %%%%%%******
320 [ 184] %%**
average: 196.9 kbps  LR: 4453 (53.94%)  MS: 3802 (46.06%)

3.94a11 -ap medium :

  8252/8254  (100%)|    3:12/    3:12|    3:12/    3:12|  1.1227x|    0:00
32 [  88] %%
40 [  14] %
48 [  6] %
56 [  16] %
64 [  25] %
80 [  81] %*
96 [ 158] %**
112 [ 410] %%******
128 [ 888] %%%%%************
160 [3489] %%%%%%%%%%%%%%%%%%%%%%%%******************************************
192 [2315] %%%%%%%%%%%%%%%%%***************************
224 [ 574] %%%********
256 [ 154] %**
320 [  37] %
average: 166.0 kbps  LR: 2747 (33.28%)  MS: 5508 (66.72%)

3.94a11 -ap medium1 :

  8252/8254  (100%)|    3:01/    3:01|    3:01/    3:01|  1.1903x|    0:00
32 [  1] *
80 [ 135] %%**
96 [ 207] %****
112 [ 542] %************
128 [1205] %%%%%%***********************
160 [2840] %%%%%%%%%%%%%%%%%%%%%%%*******************************************
192 [1811] %%%%%%%%%%%%%%%%%%%************************
224 [1039] %%%%%%%%%%***************
256 [ 374] %%%******
320 [ 101] %**
average: 170.6 kbps  LR: 2709 (32.82%)  MS: 5546 (67.18%)

Lame 3.94a11

Reply #9
Hmmm, it seems as though the -b 128 (except for silence) has also been omitted from the --aps in this latest alpha. This results in an incredibly low average bitrate for one of my favourite tracks.  Unkle - Rabbit In Your Headlights, comes out as averaging 138kbps! I've abxed it against my current 3.92 --aps encode, and can't tell the difference though, so I suppose there is no need to worry, at least for me. Here's a grab of the bitrate allocation for reference. I couldn't help but be surprised at the amount of 112kb frames used; although the track can be quite quiet in places, there is no silence (apart from the usual small segments at the very beginning and end of the recording, which I assume is where those 32kb frames come in).



This is the allocation for the same track encoded with 3.92:



Quite a difference. I've read most of the previous threads on the alpha, and know that the VBR presets are undergoing changes, so I'm not panicking; just posting results to make sure that the changes are all as intended.

Lame 3.94a11

Reply #10
I prefer just medium. Both are not transparent so it is just a preference to me... Abx for preference Medium1 v medium 12/15.

What are your plans for the current dm presets? Will they stay or be ommited? And r3mix?

My vote is to include dm-radio and dm-portable omit dm-medium and include r3mix. It doesn't make sense to include 2 medium presets. I think r3mix should stay just because it provide fairly good quality at a much faster speed than any of the other presets.
r3mix zealot.

Lame 3.94a11

Reply #11
dm-xxx presets were just experiments from Dibrom, and were not final. They are used as one of the many sources of information by me, and will not be part of the release (in agreement with Dibrom)

Lame 3.94a11

Reply #12
Quote
I'd appreciate feedback about medium and medium1, as I do not know which one to choose.

Medium fares better than medium1 in most of the cases I've tried. It is almost always higher in bitrate, however.

Lame 3.94a11

Reply #13
Medium needs the -b 128 switch added.

Try it with this clip: First seconds of Steve Ray Vaughn's Crossfire.

Encode with --preset medium and --preset medium -b 128. The latter has better noise control and increases filesize (the whole 4:11 track) by only 0.3% or 0.5kbps.

Lame 3.94a11

Reply #14
From this I take it you plan to create a portable and/or radio presets.
Removal of the dm-xxx presets is a good idea in this light.

Are plans for tweaking of extreme planned?
And R3MIX? I am still of the opinion it should stay in the codec. Perhaps with a note : Use preset standard for higher vbr quality.
r3mix zealot.

Lame 3.94a11

Reply #15
@LordofStars

if you need more speed you could try "--preset fast standard" instead of "--r3mix"

Lame 3.94a11

Reply #16
I have. R3mix is still much faster. I only use it for my portable anyway. And half the time I use gogo at b192 anyway.

Still its a pretty well tuned preset although deprecated its pretty much the best quality you can acheive with standard switches. Alot of people still use it and just switching it on them will tweak alot of noses. I believe adding a note that aps is better quality should be sufficent.
r3mix zealot.

Lame 3.94a11

Reply #17
Quote
Still its a pretty well tuned preset although deprecated its pretty much the best quality you can acheive with standard switches.

I have to disagree with this on both counts.

--r3mix was never really "well tuned".  Many problem issues were simply ignored, and most testing was not rigorous or even blind (Roel was not an advocate of abx testing).  What's worse is that the "newer" --r3mix that uses nspsytune is likely worse in many ways than the old version.  We'll never know exactly how much though because there was overall very little testing utilized in deciding upon switches.  Furthermore, Roel always favored using switches that affected bitrate first and quality last -- he simply felt that most quality issues were rather irrelevant.  If this is how you feel also, that's fine, but that doesn't make --r3mix a "good" or even a "well tuned" preset in comparison.

And finally, I've proven that the second part of your statement is false (best quality available with standard switches) with the original dm-presets.

Lame 3.94a11

Reply #18
Thanks for the clarification. Apparently I am still under the r3mix stigma. I had seen some tests floating around the web about r3mix vs dm-xtreme and others, but was under the impression that the dm presets used code level tweaks. Since this is not the case I would be interested in seeing the documentation about what switches the old dm presets used. Of course if you are willing to share this info. Perhaps if you do not have time you could tell which version the dm presets were in and I could check out the source and look at the switches myself.

Thanks for the clarification. I am greatly considering my plans for r3mix continued use. In fact I will probably just continue using apextreme for quality and gogo for speed and drop r3mix.

And with the second part of my statement I meant best quality at that bitrate with standard switches. Sorry for the mixup, but perhaps there was a dm preset that was better quality at that bitrate as well.
r3mix zealot.

Lame 3.94a11

Reply #19
Shouldn't we also try an ABR solution to see if it betters the current medium VBR candidates? Something like "--preset 172 --lowpass 17.5 --nsmsfix 1.6 --shortthreshold 3.5,15 -X 3,3 -Z 1" or thereabouts?

ABR is a different animal and given that no medium preset will be transparent perhaps the general consistency of ABR is preferable. If LAME should incorporate lower bitrate presets (say something in the 130-140kbps range), ABR is pretty much the best choice. The 160-180kbps range is a toss-up between ABR and VBR.

Lame 3.94a11

Reply #20
Quote
Shouldn't we also try an ABR solution to see if it betters the current medium VBR candidates? Something like "--preset 172 --lowpass 17.5 --nsmsfix 1.6 --shortthreshold 3.5,15 -X 3,3 -Z 1" or thereabouts?

ABR is a different animal and given that no medium preset will be transparent perhaps the general consistency of ABR is preferable. If LAME should incorporate lower bitrate presets (say something in the 130-140kbps range), ABR is pretty much the best choice. The 160-180kbps range is a toss-up between ABR and VBR.

...but surely that would be needless, as we have --alt-preset XXX already?

Lame 3.94a11

Reply #21
Quote
Quote
Shouldn't we also try an ABR solution to see if it betters the current medium VBR candidates? Something like "--preset 172 --lowpass 17.5 --nsmsfix 1.6 --shortthreshold 3.5,15 -X 3,3 -Z 1" or thereabouts?

ABR is a different animal and given that no medium preset will be transparent perhaps the general consistency of ABR is preferable. If LAME should incorporate lower bitrate presets (say something in the 130-140kbps range), ABR is pretty much the best choice. The 160-180kbps range is a toss-up between ABR and VBR.

...but surely that would be needless, as we have --alt-preset XXX already?

--alt-presets are tweaked for non-alphas. You can get better results than --alt-preset XXX or --alt-preset CBR XXX, by using some other and new settings.

I agree with mithrandir that some ABR setting should be tested against medium-VBR preset.
Juha Laaksonheimo

Lame 3.94a11

Reply #22
Ahhh I see, thanks.

But I'm still not really clear... if we had an --alt-preset (whatever), which produced an ABR 180 file, then we'd have the somewhat confusing situation where there would be two presets for the same bitrate (i.e. ABR 180), only one would be better... if the --alt-preset XXX can be made better, then why not do that?

Knowing how much mithrandir and John know, I dare say I'm missing something, though   

...And having said all of that, out of principle I do agree that we should test some ABR settings against the "lower" VBR presets. I use the ABR presets with a custom lowpass a lot for radio recordings, and the predictability of the filesize is fantastic.

Lame 3.94a11

Reply #23
Quote
But I'm still not really clear... if we had an --alt-preset (whatever), which produced an ABR 180 file, then we'd have the somewhat confusing situation where there would be two presets for the same bitrate (i.e. ABR 180), only one would be better... if the --alt-preset XXX can be made better, then why not do that?

Before 3.94 is released, the --preset xxx switch needs to be revised so that it leverages the new tweaks. For instance, as the desired ABR bitrate increases we should have the preset scale the --shortthreshold switch from 4.5,15 to 3.5,15. If the ABR presets are left alone, they will all use the default value. This is suboptimal.

Presumably, if --preset medium produces a 180kbps ABR file then it would be ideal if --preset 180 would produce the same exact file. This kind of thing is possible because unlike Dibrom's --alt-presets, the new presets are packaged commandlines (at least I believe this is the case). They are "just" shortcuts.

It would be nice if LAME had a sliding quality scale like Vorbis and MPC and adding dynamic switch value logic to the ABR presets would be a fine, though admittedly complex, solution.

Lame 3.94a11

Reply #24
180 kbps ABR files as medium preset will often produce bigger files than preset standard with classical works. Especially with some quiet tracks. Maybe not a good idea...
The --preset medium, with lame 3.93.1, turns around 150-155 kbps, with my music. Sometimes below 140.