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 cbr seems to be broken :( (Read 25821 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lame cbr seems to be broken :(

Hi, while I know that Lame is focusing more on VBR than CBR, I think at least some basic tweaks could be done on CBR too.
Let's take CBR 128, the setting still a lot of people use for internet/audio streaming etc. On some samples it produces nasty artifacts, where older versions/different encoders have just little or no problems.

Most noticable artifacts include low frequency hissing/"thuddering" with tonal samples and high frequency dropouts on attacks ("double attack" hihats).
Samples with obvious dropouts include velvet.wav (also very bad problems with low frequency noise) and latenight.flac from my collection.

Distortion on tonal samples such as deploration and hissing sample from my collection. The hissing is more audible with earphones (I would say "extremely" audible).

So is the development of Lame CBR doomed forever?

Lame cbr seems to be broken :(

Reply #1
Have you tried ABR instead?

Lame cbr seems to be broken :(

Reply #2
Have you tried ABR instead?

ABR is usually slightly better (but I have no ABX results to support that).
I get the impression that with older Lame versions and other encoders, VBR>=ABR>=CBR, while with latest LAMEs it is more like VBR>>ABR>>CBR (by that I mean vbr is getting better while cbr is getting worse).

P.S. Hey, I have noticed you are from CZ too, zdravim z ceska

Lame cbr seems to be broken :(

Reply #3
CBR and ABR shouldn't have changed much from 3.97 to 3.98. With older versions, are you talking about versions before 3.97?

Lame cbr seems to be broken :(

Reply #4
CBR and ABR shouldn't have changed much from 3.97 to 3.98. With older versions, are you talking about versions before 3.97?

Yes, starting from 3.96.1 a new psymodel for CBR has probably been implemented, causing the problems stated above. Calling "--psymodel 1" on 3.97/98 alphas on CBR seems to get rid of most of the problems, I think that's a flavor of the original psymodel used in 3.90/3.93 (not nspsytune, the default one).

The only bigger problem of the older psymodel seems to be worse pre-echo, which is the only thing that is better in the new cbr psymodel IMO (and maybe a few rare cases of ringing).

Lame cbr seems to be broken :(

Reply #5
It seems, starting with 3.94 the presets (which imply nspsytune) became default for ABR/CBR/VBR encoding, not 3.96.1.

If you compare the following settings using 3.98:
a) -V6 -b96 -B96 -F --lowpass 15
b) -b96

Which one do you prefer?

Lame cbr seems to be broken :(

Reply #6
It seems, starting with 3.94 the presets (which imply nspsytune) became default for ABR/CBR/VBR encoding, not 3.96.1.
That's possible, but I think in 3.96 the psymodel got some major "improvements".


If you compare the following settings using 3.98:
a) -V6 -b96 -B96 -F --lowpass 15
b) -b96

Which one do you prefer?
With a) the problems are nearly non-existent, only I heard slight ringing on some samples.
b) has all the problems.

Wow, try to encode velvet.wav with Lame 3.98 -b96. That's one of the most profound artifacts I've ever heard, especially on earphones 

Lame cbr seems to be broken :(

Reply #7
Robert, are you trying to encourage us to use that kind of command line to produce cbr files with better quality?

BTW, just curious, how can we losslessly convert such file to true cbr file?

Lame cbr seems to be broken :(

Reply #8
Robert, are you trying to encourage us to use that kind of command line to produce cbr files with better quality?

I think he just wanted me to try how the vbr psymodel compares against the cbr one when restricted to the same bitrate.

Lame cbr seems to be broken :(

Reply #9
Robert, are you trying to encourage us to use that kind of command line to produce cbr files with better quality?

No, I'm just trying to understand what happend the last few years with CBR encoding. I didn't follow it as much as I probably should have done.

Quote
BTW, just curious, how can we losslessly convert such file to true cbr file?

That line produces a true CBR file with a leading VBR header.

Lame cbr seems to be broken :(

Reply #10
Quote

BTW, just curious, how can we losslessly convert such file to true cbr file?

That line produces a true CBR file with a leading VBR header.

But using the vbr psymodel?

Lame cbr seems to be broken :(

Reply #11
Yes, using VBR settings, psymodel and quantization routines.

 

Lame cbr seems to be broken :(

Reply #12
-V6 -b96 -B96 -F --lowpass 15
That line produces a true CBR file with a leading VBR header.
... using VBR settings, psymodel and quantization routines.


Very nice. I know that lame 3.98 has different psymodels for VBR and CBR. What you indirectly do here is to suggest the VBR psymodel (which is very good) for CBR. It seems to be easy to replace the current CBR psymodel... so
lame -q0 -V0 -b320 -B320 -F -t
actually is a CBR 320kbps MP3 file with the VBR pysmodel, VBR quantization routines and the CBR header ...?

By the way, I did not like 3.96.x CBR qualities (in contrast to 3.97 & 3.98 CBR) as the noise envelope for 3.96 was much more pronounced than for 3.97 with a quite clear souund for 3.97. But a low noise envelope also means that encoding quirks become much easier audible.

@jmartis: Maybe that is what happened here, that is why you find it easier to detect problems in 3.97 /3.98...

Lame cbr seems to be broken :(

Reply #13
lame -q0 -V0 -b320 -B320 -F -t
actually is a CBR 320kbps MP3 file with the VBR pysmodel, VBR quantization routines and the CBR header ...?

I think you meant a VBR header.

Lame cbr seems to be broken :(

Reply #14

lame -q0 -V0 -b320 -B320 -F -t
actually is a CBR 320kbps MP3 file with the VBR pysmodel, VBR quantization routines and the CBR header ...?

I think you meant a VBR header.

No. I meant CBR - header. The -t switch does it. I did it with a sample just a few minutes ago and all my mp3 file checkers tell me I get a 320kbps CBR file with CBR header.

Lame cbr seems to be broken :(

Reply #15
If you add -t the VBR frame is omited and there remains no "header" at all, just a sequence of MPEG frames.

Lame cbr seems to be broken :(

Reply #16
It can be easily fixed by foobar2000 using it's Rebuild MP3 Stream function, right?

Edit: Just tried and it cannot. How can I get a normal mp3 file from the raw mp3 stream?

Lame cbr seems to be broken :(

Reply #17
There is nothing to fix, only VBR files need the header. If you're streaming, nobody will ever see it anyway and yet be perfectly capably of decoding.

Lame cbr seems to be broken :(

Reply #18
I guess such an mp3 will decode to raw PCM instead of a wave file.

From the Lame documentation:
Quote
* -t    disable INFO/WAV header

Disable writing of the INFO Tag on encoding.
This tag in embedded in frame 0 of the MP3 file. It includes some information about the encoding options of the file, and in VBR it lets VBR aware players correctly seek and compute playing times of VBR files.

When '--decode' is specified (decode to WAV), this flag will disable writing of the WAV header. The output will be raw PCM, native endian format. Use -x to swap bytes.

Lame cbr seems to be broken :(

Reply #19
I guess such an mp3 will decode to raw PCM instead of a wave file.

Now you got confused. The -t switch for decoding is a separate thing. --decode -t will decode any MP3 file to raw PCM without a wave header.

The encoding switch -t just disables the LAME info tag creation (and the standard Xing VBR header part if the file is VBR). This also means that the file will not have LAME's gapless playback info.


EDIT

Perhaps the description could be rephrased:

During decoding (when -t is specified with --decode), this flag has a different function. It will disable writing of the WAV header. The output will be raw PCM, native endian format. Use -x to swap bytes.


Lame cbr seems to be broken :(

Reply #21
Off topic about LAME "-t" and "-T" switches:

LAME used for decoding:
-t disables WAV header, LAME writes RAW PCM data

LAME used for encoding:
-t disables writing of Xing/Info tag
-T enables writing of Xing/Info tag

Why would I want an Info tag in CBR case?
- it contains information about encoder delay and padding. A decoder like Foobar may use it for accurate length decoding.

More about the Info stored see: http://gabriel.mp3-tech.org/mp3infotag.html

Edit: Alex was faster

Lame cbr seems to be broken :(

Reply #22
LAME's excellent on VBR, but if I must use CBR, it's definitely not LAME (even 3.98 and the earlier 3.97), especially on CBR 128.  Much have been said on mp3 CBR 128 and below as to what encoder seems to be good at this.
"Listen to me...
Never take unsolicited advice..."

Lame cbr seems to be broken :(

Reply #23
LAME's excellent on VBR, but if I must use CBR, it's definitely not LAME (even 3.98 and the earlier 3.97), especially on CBR 128.  Much have been said on mp3 CBR 128 and below as to what encoder seems to be good at this.


I do not like to repeat myself but I do it here:

- lame 3.97 & 3.98 cbr produces a much clearer sound than 3.96.x and some earlier versions
- or saying it the other way round: 3.96.1 and earlier are much "noisier" than 3.97/3.98

This means that lame 3.98/3.97 encodes sound much clearer (better) than 3.96.1. "Unfortunately" this also means that you can hear artifacts much easier than in 3.96 as the noise envelope in 3.98/3.97 is much reduced. But that does not mean that all the same artifacts are not present in lame 3.96.1 - you simply do not hear them behind the noise curtain....

So everyone please be careful with stating "Lame cbr seems to be broken".

I would suggest to use Lame3.98 not only for vbr but also for cbr encodes - the little downside of having more audible artifacts is not really worth a mention if you look at the "clearer sound" you get....

Lame cbr seems to be broken :(

Reply #24
- lame 3.97 & 3.98 cbr produces a much clearer sound than 3.96.x and some earlier versions
- or saying it the other way round: 3.96.1 and earlier are much "noisier" than 3.97/3.98

This means that lame 3.98/3.97 encodes sound much clearer (better) than 3.96.1. "Unfortunately" this also means that you can hear artifacts much easier than in 3.96 as the noise envelope in 3.98/3.97 is much reduced. But that does not mean that all the same artifacts are not present in lame 3.96.1 - you simply do not hear them behind the noise curtain....

So everyone please be careful with stating "Lame cbr seems to be broken".

I would suggest to use Lame3.98 not only for vbr but also for cbr encodes - the little downside of having more audible artifacts is not really worth a mention if you look at the "clearer sound" you get....

I think that at this bitrate (128k), a bit of additional noise is what you want instead of obvious artifacts. I tried using Lame 3.98 with 128k cbr, and it literally hates sharp attacks (dropouts), badly distorts low-frequency "tonal drums" and has problems with long string-like passages with a lot of high frequencies.

I can give you a lot of samples from my music where 3.98 produces unacceptable artifacts @128CBR. And I have not heard any bad artifacts with 3.90.3 (this is what I use now when I must do 128k CBR, the only problems I have noticed are with pre-echo otherwise it is very stable).