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?

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

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

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?

That's possible, but I think in 3.96 the psymodel got some major "improvements".


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

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?

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

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.


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

But using the vbr psymodel?

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

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.

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

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?

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.

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

From the Lame documentation:

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.

I did indeed. Thanks for pointing that out.

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

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

And are you sure that those older versions produced CBR and not ABR. IIRC I made some 128kbit MP3s using some older LAME version (don't remember which) and came up with ABR files despite selecting CBR. It could have been the frontend messing up, though (RazorLame)...

I'm sure they were CBR, I would have noticed that if they were VBR in encspot, with dbpoweramp file info, bitrate switching when playing in Winamp...

Do you use -b 128 or --alt-preset cbr 128?

I use -b 128 -h --lowpass 16 -X6

why lowpass? Because default one is at 15k, too low. (16-17k is the standard for 128kbs)
why -X6? I have found it reduces ringing, but this is to everyone's experimentation of course.

try --alt-preset cbr 128 --lowpass 16 (the default lowpass is higher, and it shouldn't). Of course, that's twice as slow as your commandline.

lame 3.90.3, 3.93.1, 3.96.1:

lame 3.97, 3.98:

So I wonder: can "-b 128 -h --ns-bass -6" be better than "-b 128 -h" for lame 3.97/3.98?

for 320 kbps: is it better to go with -b 320 or -V0 -b 320 -B 320, in case of quality? (Lame3.98)

I think the artifacts I mentioned are non-existant above ~256kbs so I would go with -b320.