Hi!

This is my first post on this board, and the reason why I'm posting is to find an explanation for one particular, interesting issue of LAME MP3 compression...

I took a sample from a live instrumental concert with clear high-frequency sounds. I compressed it with two different settings, using LAME 3.91.

-b 192 -m j -h -q 0 (= 192kbps constant, joint stereo, quality-optimised, max. quality) and
--alt-preset standard, which produced a slightly larger file, the bitrate averaging at 200kbps.

The results were both quite good and I couldn't tell the difference in sound - maybe I lack the equipment.

I performed a spectral frequency analysis on each of the results.

Here's what it looked like:


Let's look at the left image: the frequency meter suggests thet there's a sharp cut at 16kHz. Nevertheless, some sounds are given higher frequencies, but then there is another sharp cut just under 19kHz, above which nothing can be seen.

Now the right image: up to about 16kHz the frequencies are generally preserved. Then they gradually become thinner in a varying manner, depending, i suppose, on their importance. There is no sharp cut below ~19.8kHz.

I do not know much abot audio compression - maybe I'm misunderstanding the whole thing - so I'd like you to ask you first: which picture do you think corresponds to which compression method?

Immo

YOU CANT' SAY SOMETHING SOUNDS BETTER BASED ON A PICTURE.

I'd say that --alt-preset standard is the picture on the left.

gpsycho tends to leave little "speckles" of high-frequency low-amplitude sound which are disconnected from the rest of the picture. At lower bitrates these speckles appear at lower frequencies and can be audible to some people. They have been described by other people as "ringing" or just the classic watery sound.

The lowpass is probably another clue. I don't know for sure, but I think the default lowpass at 192 kbit/s is higher than --alt-preset standard (I'm talking about the higher cutoff frequency, near 19 kHz, not the 16 kHz cutoff).

But /\/ephaestous has a point: if you can't hear it, it's not important (at least at that bitrate).

ff123

I don't believe he said it did?

The regulars here know that looking at graphs is pretty irrelevant when coming to the actual listening. But I still think it's interesting from a technical point of view to see what the codecs are doing.

The left picture must be alt preset standard, because the lowpass is lower (18671 to 19205 Hz, vs 19383 to 19916 Hz for the other command line).

Nothing can be said about quality or audible difference looking at the pictures, because an MP3 encoder is targeted at removing as much inaudible sounds as possible. Therefore a lack of frequencies can as well mean that some audible parts are missing (bad work, or too low setting), than that the encoder managed a very good compression, removing a lot of unuseful things.

BTW, there are also alt presets for CBR, that provide better quality than your command line. the syntax is --alt-preset CBR 192, and, according to http://www.hydrogenaudio.org/forums/index....=ST&f=15&t=3076 , and to the verbose switch, it means

-h -b 192 --nspsytune -m j --lowpass 19500 --athtype 2 --ns-bass -6 --scale 0.97

There must be a slight difference in one of the settings, since I get is different files with the preset and the command line (JohnV ? Dibrom ?)

And before you ask, there is no equivalent command line to the VBR alt presets (FAQ)

i have to agree with /\/ephaestous on this.. you can't tell the sound quality by looking at a picture. well, sort of..

>>>'Now the right image: up to about 16kHz the frequencies are generally preserved.'<<<

this is not necessrily true. in many cases, the mp3 format in general doesn't code high frequencies very well. so, while these frequencies may "show up" on the graph, it doesn't mean that they are coded properly or sound like the high frequency content of the source file. this is why we use our ears, not eyes

>>>'I'd like you to ask you first: which picture do you think corresponds to which compression method?'<<<

i say the image on the left is --alt-preset standard because of the lowpass at ~19.5 kHz

not really, pictures are misleading, check out a Mp3pro or WMA graph and you'll think it sounds better than APS. and you can't tell what has been transformed trhu the graph, the most you can see is the lowpass,

Thanks for the replies, folks.

All who guessed, guessed right about --alt-preset standard - it's the picture on the left. But there's something bugging me.

I really didn't say anything about which sample sounds better - either my ears or my headphones are too bad for that. But REGARDLESS of the audible result it was a surprise for me to see that the lowpass filter, considering the two clearly visible boundaries, is applied much earlier in a VBR algorythm than in CBR. A question arises: how is the advantage of VBR being used? I earlier thought that VBR provides the possibility to preserve a broader range of frequencies where it is needed and cut down on them where it isn't.
As far as I understand, the VBR codec (like any other) "considers" the lower frequencies more important and cuts off the higher ones, which is, of course, a good idea to some extent, as people don't hear them very well. But then why does the CBR codec leave so much of them? It could as well apply a lower lowpass filter if it's such a good idea, but it doesn't. Why? After all, it's the same version of the same encoder, so the applied techniques are surely coordinated.
Doesn't this fact surprise you a bit? Just a little bit???
Or have I just gone mad?

The point is, I don't believe that the marginally higher frequencies preserved in the CBR really destroy the overall sound quality, especially they wouldn't in a VBR codec, where there is a possibility to assign more bits at a particular point...

Regards,
Immo

There's also the possibility that 192KBPS is transparent to you or very near transparent, and perhaps your hearing capabilities.

My hearing isn't getting any better as I am getting older, however I can just about always tell a high quality LAME --alt-preset standard MP3 versus the likes of a 192KBPS CBR MP3 encoded by LAME or FhG.

--alt-preset cbr 192 is: -b 192 -h -mj --nspsytune --athtype 2 --lowpass 19.5 --nsmsfix 1.7 --ns-bass -2 --scale 0.97

With v3.90.2 and these switches i get the same decoded wav.

To get the same MP3 files you must add --nssafejoint:

-b 192 -h -mj --nspsytune --athtype 2 --lowpass 19.5 --nssafejoint --nsmsfix 1.7 --ns-bass -2 --scale 0.97

This is quite strange because --nssafejoint before --nsmsfix has no effect. I think that it must be something related with LAME header. IIRC --nssafejoint is equal to --nsmsfix 1

Please, don't confuse newbies with those stupid commandlines...you already know what is the result of those commandline tweakings

Right, right,
It started when I was about to write "the alt presets are better than any command line", but it occured to me that we were speaking about alt preset CBR, and it didn't make sense.

Immo, the global lowpass needed depends on the hearing ability of the listener. There have been some tests with sweep tones and music lowpassed here recently, to see how high people could hear, but they are affected by the fact that most soundcard resample, and therefore produce low frequency sounds when high frequency ones are fed into them (the "alias" effect).

The lowpass used in the command line and the one used in the alt preset can't be compared, because they were developed at a different time by different people.
Lowpassing is a powerful way to reduce the bitrate of a VBR file, that's why lowpass filters are used in the presets.

One phrase: sfb21.

Scalefactor band 21 is the nemesis of MP3 VBR (well, one of them). Unlike the first 20 scalefactor bands (<16KHz), scalefactor band 21 (>16KHz) doesn't use a scalefactor and this leads to many problems. You'll find more technical explanations about sfb21 here at HA but understand that the lower lowpass of VBR is a result of a MP3 design flaw. The more you cram in sfb21 (i.e. greater HF retention) the more the bitrate will bloat. If you are shooting for a certain bitrate like --alt-preset standard does, you don't want to waste all you bits in a single sfb, especially one that is arguably the least critical.

CBR doesn't have the same limitation because it doesn't employ sfb21. Does that make CBR superior? No, because the workarounds for sfb21 are generally effective.

But I wouldn't worry. Who can really hear the difference between a 19KHz and a 19.5KHz lowpass?

I just wanted to point out, Immo, that your commandlin is kind of funy. you specifiy -h, which is equivalent to -q2 for your information, but then you specify -q 0 (which in current versions of the encoder is flawed so the quality is not better), which overrides the -q 2.

Not exactly an issue now, though.

It's good to have you here. Happy ripping!...

Good afternoon,

thanks for the tip, NeoRenegade, the reason for that is my (supposedly lame) usage of the RazorLame frontend.

Thank you all for the explanations. The picture becomes clearer to me, at least after Mithrandir's post.

I'm not so sure about Pio2001's answer, though:


I suppose lowpassing is just as powerful a tool to reduce the bitrate of a CBR file, if not, in fact, even more powerful, as VBR should have more tricks up the sleeve. But I'll settle me with the information I have now

I tried to use Lame 3.93.1 with the same CBR settings: -b 192 -m j -q 0.
Here is the comparison. The first image is 3.91, the second - 3.93.1:


What do we see? In the 3.91 there is no clear cut at 16kHz, as opposed to 3.93.1, where we can distinguish a cut much better.

Maybe the developers had noticed something similar to what I did, and made an effort to cut more on the CBR high frequencies?

Anyway, before I forget, here are the original two sound samples, in case you want to listen to them and see if you can tell a difference:
3.91 CBR 192 (-b 192 -m j -q 0), 380KB
3.91 --alt-preset standard, 404KB

Regards,
Immo

Adding a lowpass switch to a cbr 192 command line won't decrease it's bitrate to anything else than 192 kbps.

Don't worry, you're not the first one to make this mistake

Sorry, you're right!

What I meant was that lowpassing is an even more important tool in CBR to increase the overall sound quality than in VBR, as you don't have the possibility to assign more bits to a particular place, isn't it?

In 128kbps CBR, for instance, LAME applies a lowpass filter sooner than in --alt-preset 128 (VBR), so it's the other way around and corresponds to my understanding of VBR, so that makes this whole thing even more mysterious.

Cheers,
Immo

/\/ephaestous:



Heh, worlds most ironic sig-line

Immo: VBR isn't about preserving HF content. It's about providing the same sound quality over the whole piece of music. The sound complexity of your music can vary a great deal so VBR tries to find the bitrate needed to encode a small piece of sound at a given quality level. There are a lot more things to worry about than just HF content.

Hearing the difference between --alt-preset standard and your command line is a matter of training mostly. Equipment, as long as it is halfway decent, plays only a very minor role in hearing these differences. Give headphones a try, they can be more "revealing".

Lev: it gets even more ironic when the author makes the line come true

Gecko: yes, well, I guess it is another way to put the thing. But it doesn't really explain why, if a higher quality can be obtained by using up to 320 kbps available on lower frequencies, the CBR codec uses its 192 on higher...

And - my sound "equipment" at the moment actually is a pair of low-end headphones, that's why I don't rely much on it, but maybe it's not that bad.

Immo

Agree but doesn't adding a lowpass enhance/optimise the use of the bit reservoir in CBR mode?

CBR is shit...always. The entire fact of giving the same bitrate for transients than for silence is...idiotic.
As for quality, when you set CBR mode, you set VQ, CBR (variable quality, constant bitrate) opposed to VBR (constant quality, variable bitrate)

That happens because CBR uses always a fixed bitrate, so it becomes both overkill and lack of bits at the same time: bits that aren't used while encoding are set to null data to fill the specified bitrate, while other times it will run short of bits on harder-to-encode parts.

VBR, however, will decide what shall be encoded and what has to be left, without wasting bits: it can use bitrates as low as 128kbps or as high as 320 if it considers it necessary.

--alt-preset standard, --alt-preset extreme and --alt-preset insane* are code-tweaked: it's impossible to reach them through commandlines [no, do NOT use them!!!] in terms of quality.

*--alt-preset insane is CBR, yes, but it's on the highest bitrate allowed for the mp3 standard, so it won't get short of bits (inside of mp3's specs) , but it also will happily start wasting bits.....

CBR is not "always shit", plz stay serious. Especially not for the music I listen to (Rock, Heavy etc) where are no silent parts and pure tones.

If you plan to use your encodes for listening on the PC and playing them in your car/portable/DVD player, "--alt-preset cbr 192" is a very good choice, especially since lame is told to have very good short block/bit reservior handling (mp3 CBR is not really CBR), and the VBR files give serious trouble to some hardware players.

Oh btw, does anyone know if the "--alt-preset cbr" modes have been improved between lame 3.90.2 and 3.93.1, or are the CBR modes more or less "finished". Thanks.

The lame development team works on the encoder and the switches. Mainly Dibrom works on the Alt Presets. There should be no difference between the presets in 3.90.2 and 3.93.1 other than that 3.93.1's VBR Alt Presets may not function totally properly, and 3.93.1 has "Alt Presets" under 80kbps which 3.90.3 doesn't...

To Immo
About your 1st pictures...
Can you think about VBR as a manner of redistributing bitrate between intensive and easy sections, instead of CBR, where such sections gives equal bitrate? From that point maybe those pics will be cleaner?
I.e.: for intensive section (we see widefreq beat) coder uses more bitrate, which he needs to take from unintensive section. And he does it, casually lowering lowpass filter further.
Am I right, at least a bit?

P.S. Seems, Gecko says a kind of it.

You used -q 0 for your test, and this setting cause quality problems on Lame.
Maybe you get those unexepted results because of -q 0.

Try to use -q 2 on both Lame 3.91 and 3.93.1 to see if it's the same problem.

sony666



If you wanna stick with files around 192 kbps why don't you use "--alt-preset 192" instead? (ABR). That would surely give better quality than 192 CBR.

neorenegade



I'm pretty sure Dibrom has quit working on the LAME presets. Too bad though... Since his presets in 3.90.2 are so extremely well tuned, It'd be cool if he could do some wonders with 3.94! JohnV and Gabriel and the rest of the guys are doing a great job nontheless!

Roman: I guess ti prav explaining how VBR acts

But although I'm conscious of the basic principle of VBR, the mystery to me was - why doesn't the CBR codec apply the same or even lower low-pass filter than the VBR codec, because it's perfectly possible and, judging from what VBR does with the high frequencies, a good idea. Although the CBR codec doesn't have the possibility to vary bps, there is still nothing, as far as I'm concerned, keeping it from using the available (192 in this case) bits on lower frequencies depending on situation.

But I've kinda lost a bit of interest in this investigation since I was practically the only one being surprised by that fact.

My greatest concern is at the moment - why is LAME 3.93.1 a good deal slower than 3.91. Could it be a bad compilation?

Cheers and poka,
Immo

Oge_user:I just tried it, the results weren't 100% the same, but essentially the same: no visible tendency in any direction.

Immo

Because it would result in a mp3 with variable bitrate again (ABR), and that is exactly what you might not want when you aim at hardware playback.
I know the quality of ABR/VBR is potentially better, but I wanted to point out the advantage of CBR in regard to hardware devices in this topic.