Maybe a futile point, but i am lot more concerned of quality then size.
So i do prefer stereo over joint, i wan`t to get as close to the source
as a lossy codec allows. But then again, it depends on how good the codec is.

As of q0, if there is proven that this setting/swich is more or less redundant,
why do it exist.

Then use --alt-preset insane: it should be the "best quality" MP3 can offer.
But it is CBR, not VBR nor ABR.

I consider using api a waste, though.


IIRC, not only q0 doesn't give significant improvement, in some versions it is even buggy.
I do believe it exist for backward-compatibility reasons, but I'm not sure.



[edit] removed untrue statement "--alt-preset insane has "full stereo" " [/edit]

FireStarter, please read the section "Why is joint stereo better than pure stereo" in the FAQ, here.

If you want your MP3s to sound as close to the source as possible, then you should definately not use pure stereo, since it will degrade the quality.

For FireStarter:

Pure stereo and joint stereo are audio coding methods, not quality levels nor "stereo detail" settings.

Pure stereo is more efficient when the two channels are completely different (ie: in rare cases).

In all other cases, for a given bitrate, joint stereo is more efficient (typically by ~25-33% IIRC). This means you can store more audio information in the same number of bits.

Now in a complex part of a song, the encoder can only use at most 320kbps (a mp3 limitation). This limitation translates into an "audio quality barrier". This barrier is higher in joint stereo than in pure stereo, because of the improved coding.

So in difficult parts of a song, artifacts are more likely to appear in the pure stereo encoding than in the joint stereo encoding.

With LAME's --alt-presets, you get the best of both methods. The optimum coding method is determined per-frame (ie: for this frame, is joint stereo or pure stereo more efficient?) and coded accordingly. So it's best than either pure stereo or joint stereo

Eh, @Atlantis. As of api. 320 CBR is a waste, both quality and bitrate wise.
and if am not misstaken, have a default lowpass wich i stay way clear of.
to my ears, this is over api in q. and between ape/api in size:
(i know, don`t mess around with the pressets. try this:
--preset extreme -m s --allshort -k -X m -q 0.
ps. just a experiment))
@PoisonDan. first of all, where does it state that HA is conclusive and absolute.
and i don`t get this, when a source is stereo, how can then joint be better,
maybe for the purpose to have a better compress ratio, but am talking quality.
If a stereo source are getting worse in quality with audio compression,
i take it that the foult lies within the encoder.
@NumLOCK. I belive i know what`s the diff. between stereo & joint stereo.
of course the joint are more efficient, that`s the idea.
Am not so into lame structure, but i assume this regards CBR.
If you (as above) have a good but small vbr line, you will have
plenty of "headroom" for upper frequency`s.

I am really wondering what this switch does...

If you can not understand, what is joint-stereo this does not mean it is lossy or bad. Seeing second quote I assume you does not understand idea of L/R to M/S transfrom completely...
Please, do not confuse other people...

Yes.
To be extremely precize, also there is a freeformat, which allows you to use vbr up to 640Kbit. Anyway, freeformat is not popular and there is no decoder which support it normally...
(but seems that last decoder in lame package can decode freeformat)
EDIT:

The idea was to have better precision...
But it give lesser bitrate too.

No lowpass?
Then you'd better forget about lossy audio compression, and switch to lossless.

Something related to compression level ???
that m is confusing...

No. Freeformat can only be used in CBR.
Note that mp3 compliant decoders are REQUIRED to support it at least up to 320kbps.

Oh, Sorry ! I mean cbr, was too busy with that joint-stereo stuff...
My fault.

Hmm, didn't know it...

Well, if i gonna do a backup, i prefer a image to HD as wav, and burn that.
the only compressing i do is for own use on HD, and for that am settled for
mpc. (even that isn`t perfect, but as lossy, close.)
So personally lossless coding is not a option.
Regarding lame, i am only into lame for compabilety issues, and as
frequency filtering goes, i solely are after "what goes inn, must came out".
am not interested in compression efficiency, but music quality.

Music quality means that you want a lowpass.

Why is that, if you need lowpass in your encoding, wouldn`t that mean
the lame can bring up artifacts, without it. If not, i don`t follow you.
This is going slightly off topic, i wan`t from my lame: (true) stereo channels,
no audible frequency filtering, what so ever. To say that 320CBR is the best
lame can do, is utterly not true.

- SAFETY: Using a lowpass is one of the safest and most simple things in audio that you can do. It's probably the least dangerous operation (quality-wise) in LAME. Probably 99% of artifacts come from the psymodel, not the lowpass. (If you don't believe it, try to disable the psymodel and see what happens).

- BITRATE: If you don't use a lowpass, the encoder will need to cope with many unperceptible frequencies, all of which fall into the sfb21 area, which will take a lot of space (2nd mp3 weakness). So the bitrate will bloat, and you'll bump into the 320kbps limit much more often.

- NYQUIST: If you want to get rid of the lowpass, set it at the maximum valid value -- if you disable it completely, all sorts of nasty things may happen in the signal processing algorithms. High frequencies may wrap to zero, you'll hear ringing, twinkling, etc. See LAME help and a good signal processing textbook for more info

- QUALITY: Well, 320CBR is the best quality you can have, if you care about compatibility but not size

@FireStarter,

You seem to not be understanding some things. I don't want anyone reading this thread to get any bad ideas, so I'm going to try to clarify a bit. I've simplified a few of these points for the purposes of this discussion to make them easy to understand.

One important thing to realize is that mp3 files are working from a limited "pool" of bits. There is a limit to how many can be used to encode each part of the music. Reducing the space required to encode a particular component of the sound can increase quality because those bits can be spent on other, more important things.

You seem to think that joint stereo is audibly inferior to standard stereo. This is not the case. It's just a different way of representing the same information. In places where there is correlation between the two channels (which is true very often), mid-side stereo takes up less space than left-right stereo. When there is little correlation between channels, left-right sometimes takes up less space. By letting lame choose whichever would be smaller, fewer bits are used to encode stereo information allowing more to be spent improving other aspects of audio quality. If you use the "-ms s" switch, you force lame to use left-right stereo encoding all the time, which often wastes bits. This doesn't just mean that the file is bigger - on some difficult-to-encode blocks it will run into the 320k barrier sooner because bits were wasted. Quality can suffer because a limited supply of bits are spent on something that makes no difference in audio quality.

The reason why the insane present (320k CBR) is the highest quality is because the maximum bitrate of any mp3 block is 320kbps. With that preset, every block will be given as many bits as possible, even if they aren't needed. The only way to make that VBR would be to spend less on some blocks, thereby decreasing their quality (though this wouldn't necessarily be audible). The whole point of ABR and VBR is to reduce the bitrate on some blocks (that contain easy-to-encode music) and increase the bitrate on hard-to-encode blocks. The only way lame could do better than 320k CBR would be if it could increase the bitrate even further. This isn't possible in standard mp3.

The reason why lowpass allows higher quality encodings is because:
a) high-frequencies can cost a lot of bits to encode (again, working from a limited supply)
b) high-frequencies are often not audible, so the bits are better spent on audible frequencies

If you have very good hearing, you can perhaps hear a loud, pure sine tone up to about 20kHz. If there are other frequencies present, or if the high-frequency tones are not that loud the limit will be much lower. In other words, having a mix of frequencies will prevent you from being able to hear very high frequencies (this is called masking). It doesn't make sense to spend some of your limited supply of bits on frequencies you can't hear. If you spend a lot of bits on inaudible high frequencies you'll have fewer left over for other frequencies that are in the peak sensetivity range of your hearing. Those frequencies will have to be quantized more, possibly introducing audible artifacts. This problem is espescially bad in mp3 because of some dubious design choices in the file format that make high frequencies espescially expensive to encode (sfb21).

At last somebody with not so crappy English as mine posted the explanation.
Hope this will help...

I will try to make amend to this,


All these is refering to lames capabilety`s, i can see why my preferences and
"experimental" command line would be considered as unsafe to use with lame.
But frankly, if a full band, not can be archived with lame safely, the problem can only be within lame, not the given commands.

Wherever you turn, HA lame wiki, lamedev etc. --preset insane is considered
to be the best lame can perform.
1. You can easy ABX mentioned "experimental" command line with api.
2. api have a default lowpass, so it can not be said to be either "transparent" or
"cd-quality" per definition.


I have not said "audible inferior versus stereo " but inferior as signal carrier in
compressed data.

I do not think that you are able to hear a 23kHz component in music.

In general people may not hear a pure tone, but i gather micro dynamic is also a topic when it regards audio compression.

"micro dynamic" has nothing to do with frequency range but with coding precision (ie bit depth for uncompressed samples)

It means that by letting the default lowpass, you will improve coding precision because of the more available bits.

"Tonal Pleasure". yes. well, i wouldn`t go so far to say micro dynamic
isn`t related to frequency respons.

That`s obvious, but with a lowpass filtering, the depth is equaly limited.
Hence the word "micro" dynamic.

???
What are you talking about ?
If you didn't know, signal carrier in this case is simply 16Bit numbers.
One numeber can not be inferior or superior to other....

Or you mean M/S tranformed data is less compressible ?
Then you are wrong again for stereo signal when channels have correlation...
The point using M/S not L/R sometimes, was that it is more precise and more compressible in some circumstances, so it worth that 1bit flag used...
EDIT:
Transferred to the next post.

A question to you SirGrey. "What are happening" with those two channels, when you compress it.

Ok, seems that I've found what can kill you !!!
1. Monkey Audio uses only M/S coding (sic! only M/S, w/o L/R, mpeg is more advanced in this area) when compress (losslessly(!!) or you doubt it ?) the data.
See: http://www.monkeysaudio.com/theory.html
2. Lossless Predictive Audio Compression (LPAC) uses the same methods.

He-he, no.
1. Yes
2. Yes
3. It is lame we are discussing.
4. You have not answered my question.

It is not very interesting what happen when you compress, interesting what you get when decompress.
You get errors (difference).
When you have L/R coded signals, error in both L and R are large.
When you have (L+R)/2 and L-R, error in second ch is much smaller.
(if channels are correlated, so means difference is not large)
That the idea of Joint stereo basis...
EDIT: That's the basis, of course, things are not that simple

Look sunshine,

If you force "discrete" stereo, the codec can put different coding noise in the left and right channels. That's the only choice it has.

If you allow "joint" stereo, then the codec can switch between M/S and L/R representation as it sees fit. It can hide the coding noise in either pair of channels, and weight the noise between the pair.


The coding noise sits under the wanted signal - that's the whole point of a psychoacoustic based codec. If it didn't, you'd hear it!

Now, please tell me, for a nearly mono signal, how a "discrete" stereo encoder can hide the coding noise under the signal, when the signal appears to come from the middle of the stereo sound stage, while the coding noise is being added at extreme left and right?

The "unmasking" from moving something away from the signal that was masking it, is up to 25dB!!! Which means that, if you insist on forcing the coding noise to be spatially separate from the signal, then it has to be (up to) 25dB lower in order to remain inaudible.

Given a finite (and relatively low) limit of 320kbps total, how is this a benefit?


btw, that's a theoretical argument. In practice of course, the codec can make mistakes. But if you don't trust the codec to choose what stereo mode to use, or what lowpass to use, then I don't know how you can even think about letting it choose which spectral band to add most coding noise in!

Maybe we need a special switch to force the codec not to add any coding noise. Oh, hang on - we already have that function - it's called a lossless codec!


It's just silly to use a psychoacoustic based codec which aims to code audible areas with greater accuracy than inaudible areas, and then to prevent it from doing its job properly!


As FireStarter ignored phong's excellent post, I suppose he's the kind of FireStarter who likes to come back and fan the flames!

If you were really interested FireStarter, then you'd have read the FAQ more carefully, and you wouldn't be making arguments which have already been answered plenty of times.

Cheers,
David.

Ahh. Hence my statement about "What goes inn, must come out"
and diffrences coused by compression.
A. preserve stereo separation, you got a two channel source, with compression
the two channels are ex: joint, when decompress theres quite a bit information
that get lost. So atm. i see true stereo as a better sulution.
There are other lossy formats that don`t have this behaviour,
so it would be quite safe to say, that it is not the method itself that are unwanted,
but rather the code and implementation in lame.
(if joint was perfect, i stil would prefer stereo.)

/Edit/
I am not your Sunshine 2b.
regarding the mention of FAQ, i repeat, where do it state
that HA. is conclusive and absolute.
As preferance,