Skip to main content

Notice

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

Lame 3.98 beta 3

I tested beta3.

First I wanted to learn about differences against beta1 which I tested just a few days ago.
So I took the same samples and used -V1 on them.

beta3 provides for smaller file sizes than beta1 did.
beta3 behaves differently on eig. Using b3 -V1 the pulses usually are reproduced astonnishingly fine to me, better than with beta1, but sadly at ~ 3 sec there is one rather strong error which immediately gets into focus.

With my new test I wanted to learn about 192 kbps behavior (abr, cbr, -V2) of 3.98b3, but also compare this to the abr 192 and -V2 behavior of 3.97 as well as 3.92 abr 192 and FhG cbr 192.
FhG is of interest to me as I recently encoded my entire collection using FhG 4.0.3 cbr 192.
I was in the mood of testing 3.92 as in a recent short test triggered by a test of Porcupine's 3.92 came out pretty fine with eig.
For lead-voice and abr/cbr usage I used 112 kbps cause this is a mono sample (but I didn't want to go 96 kbps in order to avoid the encoder to go into a very different mode like resampling to 32 kHz).

As a preliminary remark I'm not interested in subtle details any more audible only in intensive abx tests as I want to stay within more or less a practical listening environment.
But with this test I noticed rather quickly that quality demand gets stronger pretty fast after listening to the result of several encoders and settings.
Most striking to me was herding_calls. In my test with just beta1 using -V1 I wouldn't have called the result annoying. Now - just a few days later - but with a lot of listening experience to this sample again I see things considerably worse. Part of it goes to the fact that I've done most part of this listening test with my new UE ear canal phones (didn't want to disturb my wife last night) which brings the herding_calls problems more into focus.

I didn't compare each encoder setting to each encoder setting, but roughly used 3.98b3 abr 192 as a comparison reference.

eig:
Bad results throughout as was to be expected.

abr/cbr behavior:
To me 3.92abr192 worse than 3.97abr192, 3.97abr192 worse than 3.98abr192, FhGcbr192 worse than 3.98abr192, 3.98cbr192 equivalent to 3.98abr192.

vbr behavior:
3.97V2 is better than 3.97abr192.
3.98V2 usually is also better with the pulses than 3.98abr192, but the one bad spot at ~ sec. 3 makes things so much worse that to me in the overall view I'd prefer 3.98abr192.

Looks like 3.98 is on it's way towards good eig behavior.

harp40_1:
Acceptable results throughout the competitors though bitrate is a bit too low for real good results.

abr/cbr behavior:
3.92abr equivalent to 3.97abr, and both are a bit better than 3.98abr (the attack of the first tone of the second sequence is worse with 3.98b3), FhG clearly worse than 3.98abr. 3.98cbr equivalent to 3.98abr.

vbr behavior:
3.97v2 is worse than 3.97abr: there is an error well audible shortly after the attack of the first note in the second sequence.  3.98v2 is on par with 3.98abr.

herding_calls:
All the competitors are at least slightly annoying to me.

abr/cbr behavior:
3.92abr a bit better than 3.97abr, 3.97abr a bit better than 3.98abr (surprise).
FhG better than 3.98abr,  3.98cbr on par with 3.98 abr.

vbr behavior:
3.97v2 real bad, 3.98bv2 on par with 3.98abr.

lead-voice:
Strange behavior with part of the competitors.

abr/cbr behavior:
3.92 abr is very distorted. 3.97abr, 3.98abr, 3.98cbr, FhG are okay to me.

vbr behavior:
V2 is very bad to me with 3.97 as well as 3.98.

trumpet:
Not a real problem to me any more with most of the competitors.

abr/cbr behavior:
3.92abr roughly equivalent to 3.97abr (the behavior is different: the 3.92 error is slightly larger but on the other hand sounds 'more homogenous' to me). 3.97abr is slightly worse than 3.98abr.
3.98cbr is equivalent to 3.98abr, FhG is better than 3.98abr.

vbr behavior:
3.97v2 is a lot worse than 3.97abr. 3.98v2 also suffers significantly compared to 3.98abr.

Trumpet My Prince:
Essentially a tremolo effect with vbr.

abr/cbr behavior:
All the Lame versions are fine to me. FhG has a slight tremolo problem with this sample.

vbr behavior:
Both 3.97v2 and 3.98v2 are significantly worse than their abr counterparts. 3.98v2 is a little bit better than 3.97v2 to me.

Birds:
A remarkable problem to Lame.

abr/cbr behavior:
3.92abr about the same problem level as with 3.97abr. 3.98abr better than 3.97abr but still rather easily audible (surprise: I thought 3.98 has overcome the issue). 3.98cbr slightly better than 3.98abr (surprise), FhG: no problem.

vbr behavior:
3.97v2 a lot worse than 3.97abr. 3.98v2 better than 3.98abr (surprise to me). I wouldn't call 3.98v2 even slightly annoying.

Taking it all together:
Compared to 3.97 3.98b3's VBR behavior is significantly improved.
Unfortunately the VBR tremolo problem obvious with lead-voice and Trumpet my Prince is still existing.
3.98 is on a good way for a good eig performance, and current version's advantages on eig may be of advantage for other pre-echo problems already.
Looking especially at herding_calls this kind of tonal problems is not really overcome with 3.98b3.
cbr behavior even at 192 kbps is competitive to abr behavior.

In the end 3.98b3's overall quality for the samples tested is good, but there's still potential available for further improvement.
If I would encode my collection again for mp3 use, I guess I'd use 3.98 cbr224 or cbr256 for robust high quality. Maybe I'll do a 3.98b3 CBR 256 test in the near future just because I'm curious whether using 3.98b3 CBR 256 is really a good idea.
lame3995o -Q1.7 --lowpass 17

Lame 3.98 beta 3

Reply #1
Cool you found b3 having different behaviour than b1 for some reason. The last alphas i tried a while back were nearly perfect with Birds and V2. Time to dedust my sample folder and try around. I still have a strange flute/piano sample around i wanted to test anyway.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Lame 3.98 beta 3

Reply #2
Yes, to me Birds is nearly perfect with 3.98b3 -V2 too. Hope my writing isn't confusing: 'I wouldn't call 3.98v2 even slightly annoying' is to say: 'it's nearly perfect'.

Nice to hear that you plan to do some tests cause my tests are a little lonesome.
lame3995o -Q1.7 --lowpass 17

Lame 3.98 beta 3

Reply #3
Me only tested some of the samples i complained about beeing messed up in 397V2.
For me all these added noise samples are improved or solved completely with 398b3 and i think this alone is a big step forwad. Just some small selection.
Birds, Deploration, Moon_short, Sophia2, s53_wind_saxophone_a from Guru and Breeze (not yet mentioned) are that clean with V2 i don´t bother anymore
In times of 1-click hosters i think i should offer the lazy ones a download with these samples already encoded to judge it against 3.97.
For people not knowing these artefacts it may be a simple start to train and see.
You will hopefully hear that serious ABX results aren´t necessary here.
The Link is over here (PW: 398b3)
http://rapidshare.com/files/33005418/398b3.7z.html
It contains the lossless samples also.

Just read about my old SeriousTrouble sample around here somewere and threw it in also. Ouch! This chirping the last time was that obvious to me in very old releases. Never realized 3.97 does such a bad job there also.
3.98b3 does fine btw.

Since halb27 mentioned some differences between 398b2 and b3 with the eig sample i added it also.
With b3V2 the overall attack clearness clearly improved above 398b2 and 3.97 but at sec. 2-3 a big swich is added.

This is only a small test but i hope it will lead to the final decission to make a 3.98 version to the new recommended one over here and helps weighing up the advantages.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

 

Lame 3.98 beta 3

Reply #4
Just a thought...

I've noticed by using -V0 the default -q value is 0

When I use -b320 the default is -q3

Does the -q value affect the CBR encoding? I know about the 0-3 being the same for VBR in 3.97...
Do your ever wonder about your soul?
Can it be saved...

Lame 3.98 beta 3

Reply #5
From changelog:
Quote
Bug tracker item: [ 1711980 ] LAME writes invalid Xing header when ID3 tags exist; LAME was sometimes writing an invalid Xing/Info header


I wonder if this problem could be at the root of the iPod/iTunes song length problem with Lame VBR files. Any opinions on this? Since which version has this bug been present? Or did it only come up in some 3.98alpha and was corrected in the beta?
Proverb for Paranoids: "If they can get you asking the wrong questions, they don't have to worry about answers."
-T. Pynchon (Gravity's Rainbow)

Lame 3.98 beta 3

Reply #6
Just a thought...

I've noticed by using -V0 the default -q value is 0

When I use -b320 the default is -q3

Does the -q value affect the CBR encoding? I know about the 0-3 being the same for VBR in 3.97...

Yes it does, but q1 and q0 are actually the same for CBR/ABR.

From changelog:
Quote
Bug tracker item: [ 1711980 ] LAME writes invalid Xing header when ID3 tags exist; LAME was sometimes writing an invalid Xing/Info header


I wonder if this problem could be at the root of the iPod/iTunes song length problem with Lame VBR files. Any opinions on this? Since which version has this bug been present? Or did it only come up in some 3.98alpha and was corrected in the beta?

I don't know if the fix has any influence on the IPOD issue, I don't own one. LAME always stored the file size into the LAME/Xing header and that was ok, as long as there were no ID3 tags added by LAME itself.