Skip to main content

Notice

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

Lame 3.98 beta 6

Reply #150
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.
Surf's Up!
"Columnated Ruins Domino"

Lame 3.98 beta 6

Reply #151
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.

Lame 3.98 beta 6

Reply #152
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.

Lame 3.98 beta 6

Reply #153
Are there any source tarballs for 3.98b6? Or you can get it only through cvs?

Lame 3.98 beta 6

Reply #154
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.

Lame 3.98 beta 6

Reply #155
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.
lame3995o -Q1.7 --lowpass 17

Lame 3.98 beta 6

Reply #156
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.

Lame 3.98 beta 6

Reply #157
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.
lame3995o -Q1.7 --lowpass 17

Lame 3.98 beta 6

Reply #158
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 "*"?

Lame 3.98 beta 6

Reply #159
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).

Lame 3.98 beta 6

Reply #160
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.
lame3995o -Q1.7 --lowpass 17

Lame 3.98 beta 6

Reply #161
If its a cbr only problem, then it would be also intresting to know at which bitrate it dissapears, if it dissapears.

Lame 3.98 beta 6

Reply #162
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...

Lame 3.98 beta 6

Reply #163
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.

Lame 3.98 beta 6

Reply #164
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!
Glass half full!

Lame 3.98 beta 6

Reply #165
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

Code: [Select]
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

Lame 3.98 beta 6

Reply #166
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.

Lame 3.98 beta 6

Reply #167
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.

Lame 3.98 beta 6

Reply #168
Ah ok i didnt knew that

Lame 3.98 beta 6

Reply #169
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

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.

Lame 3.98 beta 6

Reply #170
Sorry I ran upon another problem for Lame I could abx 10/10 using Lame (3.98b6) -V0.
lame3995o -Q1.7 --lowpass 17

Lame 3.98 beta 6

Reply #171
is the latest cvs code change affect in encoding speed?
im just compiled one 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 

Lame 3.98 beta 6

Reply #172
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

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...

Lame 3.98 beta 6

Reply #173
@halb27

does the problem you spotted in LAME persists in 320kbps CBR?

Lame 3.98 beta 6

Reply #174
@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).
lame3995o -Q1.7 --lowpass 17