I have recently installed LAME 3.97 and have been using EAC to rip music. I usually rip at -V4 or -V3 in terms of quality. Once completed and transferred to iTunes, I see that all of my songs are encoded (at least according to the iTunes info display) in joint stereo (jstereo). The LAME site indicates that normal stereo is the default for encoding above ~192 kbps, but even when I use -V3, my files still indicate "jstereo".

I want to insert a command on the command line to have LAME always encode in normal stereo when using these quality settings, but can't seem to write a command line that works correctly! When I put the command "-m s" onto the line after "-V4 - vbr new", I always get an error message and EAC will not compress the WAV file.

Could anyone provide an example of what such a command line should look like?

Thanks.

Joint stereo is on by default and you should not turn it off.

Hi, the command is "-ms" with no spacing.

Hi, welcome to Hydrogenaudio!

Could you tell us where it says that, please? It might need fixing.

This is directly off the LAME site at http://lame.cvs.sourceforge.net/*checkout*/lame/lame/USAGE


=======================================================================
Modes:
=======================================================================

-m m mono
-m s stereo
-m j joint stereo
-m f forced mid/side stereo
-m d dual (independent) channels
-m i intensity stereo
-m a auto

MONO is the default mode for mono input files. If "-m m" is specified
for a stereo input file, the two channels will be averaged into a mono
signal.

STEREO

JOINT STEREO is the default mode for stereo files with fixed bitrates of
128 kbps or less. At higher fixed bitrates, the default is stereo.
For VBR encoding, jstereo is the default for VBR_q >4, and stereo
is the default for VBR_q <=4. You can override all of these defaults
by specifing the mode on the command line.

jstereo means the encoder can use (on a frame by frame bases) either
regular stereo (just encode left and right channels independently)
or mid/side stereo. In mid/side stereo, the mid (L+R) and side (L-R)
channels are encoded, and more bits are allocated to the mid channel
than the side channel. This will effectively increase the bandwidth
if the signal does not have too much stereo separation.

Mid/side stereo is basically a trick to increase bandwidth. At 128 kbps,
it is clearly worth while. At higher bitrates it is less useful.

For truly mono content, use -m m, which will automatically down
sample your input file to mono. This will produce 30% better results
over -m j.

Using mid/side stereo inappropriately can result in audible
compression artifacts. To much switching between mid/side and regular
stereo can also sound bad. To determine when to switch to mid/side
stereo, LAME uses a much more sophisticated algorithm than that
described in the ISO documentation.

FORCED MID/SIDE STEREO forces all frames to be encoded mid/side stereo. It
should only be used if you are sure every frame of the input file
has very little stereo seperation.

DUAL CHANNELS Not supported.

INTENSITY STEREO

AUTO

Auto select should select (if input is stereo)
8 kbps Mono
16- 96 kbps Intensity Stereo (if available, otherwise Joint Stereo)
112-128 kbps Joint Stereo -mj
160-192 kbps -mj with variable mid/side threshold
224-320 kbps Independent Stereo -ms

The problem I have is that LAME appears to be encoding in joint stereo even at bitrates above ~192 kbps, which I don't want. Thanks!

I think that only refers to CBR, and once you use a VBR preset, proper stereo settings are selected automatically.

Seems that we should update the USAGE file, as the default is always joint stereo.

(side note: perhaps we should rename the current "stereo" into "legacy stereo" and the current "joint stereo" into "stereo" ;-) )

You may be right. I don't understand why the files would be indicating "joint stereo" in settings like -V 3 or -V 2. At lower bit rates, I understand the reasons for using it. But at high bit rates (above ~192) I think it could diminish the sound quality.

Is it your opinion that, when encoding at greater than ~192 kbps, there's still a qualitative reason for using joint stereo as opposed to independent stereo?



Now I am confused...and admittedly, I am probably not an expert on the machinations of how joint stereo works. But I would prefer to hear the music in a format as close as possible to the original, as opposed to having the channels altered in some way in order to get more bandwidth and better sound quality. Isn't that essentially what joint stereo does?

Nope, a good explanation can be found on this site

http://home.freeuk.net/mostync/

Yes, and that's a desirable thing. But you rather want worse sound quality?

I found rather good explanation of what joint stereo is here.

Please do

I guess I should have articulated what I meant - at some point, say about ~224 kbps, I would prefer not to compromise the original stereo imaging in favor of a few more bits per second. That said, I have not read the linked explanations of joint stereo in these threads yet - maybe I'll change my mind!

There is no compromise. Joint stereo is just a different way of representing the same data. It is lossless.

Even if this was just a joke, +1. Maybe it will help stem all the misconception going on that joint stereo is somehow inferior.

If it wasn't meant to be a joke, please do not change the names since this would surely lead to more confusion. There already are lots of names for how stereo signals are being coded (simple stereo, joint stereo, mid/side stereo as part of JS, intensity stereo as part of JS, channel coupling in Vorbis, etc.).

Having now read through several explanations of what joint stereo is, I am inclined to agree. I don't consider myself out of the ordinary - but the connotation of "joint" in front of a term like "stereo", which everyone knows means two-channel, is pretty obvious. A "joint" (apart from usage while in college) is where two or more objects intersect and/or become attached.

Thanks for everyone's assistance. I'm glad I signed up for this site. This has been really helpful.

Livy, those are very serious concerns you have there. I'm sure everyone will agree that with quality archiving, stereo imaging is an important matter.

Joint stereo (the mid/side kind) exists to conserve bandwidth, that's true. But there's no loss to any quality whatsoever, so it can only help compression and/or quality. The worst that can happen is that you get the same efficiency as plain left-right stereo, AFAIK.

I once read that stereo is useful when you are encoding music that contain a lot of stereo differences between both channels and encoding in joint stereo could make the quality sound even worst. The opposite would be from stereo, trying to encode tracks with little separation between both channels, while j-stereo would be a lot better because it saves bandwidth from L+R. Is this true?

Yes, but luckily lame joint stereo automatically choses between L+R and M+S, so you don't need to worry about it at all.

Only the second half is true.

Joint stereo has the ability to encode both ways as cabbagerat already mentioned. Depending on the correlation between channels in any given frame, Lame will choose the most appropriate method.

Without lossy compression regular stereo (left / right) gives exactly the same result as mid / side stereo. The difference between the channel is not lost, it's saved in the side channel. However after lossy compression the results may be slightly different (worse or better) and if it's used incorrectly may cause lower quality.

Probably first versions of LAME and other codecs from the same time didn't have a good algorithm to choose whether to use regular stereo or mid/side stereo, resulting in lower quality. However now LAME uses a better algorithm, reducing the bitrate without losing quality. Actually js may increase quality with high bitrate because a difficult part may require more than 320 kbps to archive transparency with regular stereo but less than 320 kbps with joint stereo.

Yes, that's why I'm asking this. I've read this a long time ago and this was true because when I used j-stereo with high stereo separation, the sound was worse than encoding in simple stereo.

Good to know that LAME can change between SS and MS frames when is needed so maybe that's why j-stereo in on by default.

This applies to high bitrate vbr files, but also applies to any bitrate cbr files.

How about calling JS "smart stereo"? (alliteration can be catchy...) The fact that "joint stereo" can refer to both M/S and I/S coding methods has long been grounds for misinformation.

Old school Napster users have called, they want their evil Joint Stero myths back.

Based on this statement, why do you even bother using lossy files? There are plenty of lossless codecs out there free of choice (FLAC etc.) for you to use.

Besides that, you should do some ABX'ing to base your thoughts about mp3 quality on instead of "thinking" that it's not good enough. Everything else is just placebo and old rumours that no longer stays true.

Is there ever a scenario (aside from testing) where joint stereo shouldn't be used? If not, why not disable the switch (at least in the final release versions)?

I can think of two just off the top of my head:

1) Situations where L&R have absolutely no correlation like multilingual applications

2) Files encoded which may be used for karaoke

Does anyone want to address mono encodings?

since threads like this one keep popping up I think this step is overdue. Modern codecs sell their joint-stereo as stereo anyways...

3) Surround sound encoded material, or stereo material played as surround sound

For #1 at least (and possibly #2), you shouldn't be using L/R stereo either, thats what dual channel mode is for.

In terms of separation I don't think it matters. The only difference is whether each channel gets exactly half of the bits or the bits can be divided unequally.

I included suggesting dual channel for #1 but thought the same thing that pdq said and decided removed it prior to submitting my post. Besides, the question was when not to use joint-stereo.

Since you guys aren't going at the meat of my post, I guess I did ok.

Good point. I guess we could remove the L/R switch and leave DC in, but then you'd probably have people screwing up their encodes using DC on stereo material.

Still, it should probably be made more clear that JS is right for stereo material. Perhaps an "automatic stereo" switch for material that lame can assume is stereo, a "not stereo" switch when lame cannot assume either stereo or mono channels, and a "mono" switch when lame should assume mono and process accordingly.

Basically tell lame what you want and let it figure out the right flags for the bitrate, rather then expecting the user to know that L/R is good for karaoke but not normal music.

I think you're misinterpreting my post, perhaps taking me too literally and also reading statements made before I had a correct understanding of joint stereo. I do think mp3 quality is good enough - my statements were based on the erroneous premise that use of joint stereo limited the potential sound quality.

I wouldn't worry about it too much. Zealotry takes on many forms on this forum.

I think "smart stereo" is a good solution, considering "the stereo setting that you should use unless you have an extremely good reason not to" is a little long.

Why not just call it mid/side stereo, then?

That's still confusing because people would assume that mid/side is used for all frames.

Why should Joint Stereo not be recommended for those cases? In case there is no correlation, Simple Stereo frames will be used when coding with JS. I really don't see any case where forced Simple Stereo should be recommended over Joint Stereo.

Where the source material is true mono (both channels have identical bits) joint stereo encoding should be just about as efficient as mono.

In the case where the channels are not identical but the material is actually mono, such as a mono tape played back on a stereo deck, it is worth while to tell the encoder to merge the two channels, or possibly to select just one or the other for encoding.

For multilingual content, the stream should be encoded in dual channel instead of joint stereo because of two reasons:

*proper semantics: dual channel flag makes it clear that the stream features a dual content, and that both channels should not be played at once

*ability to decode a single of the channels: while joint stereo would not lower the quality (the stream would anyhow be mostly made of L/R frames), it would remove the ability for a dual-channel aware decoder to only decode a single channel, without decoding the other one (because of the few frame which could be encoded in M/S).

In case #2, if you subtract right from left in order to eliminate the voice in the center, you tend to exaggerate artifacts in the L-R signal because relatively fewer bits were used to encode it.

Conversely, if you force stereo then you may not get as accurate cancelation of the voice in the center. Probably the best way to handle this is to subtract right from left before lossy encoding.

I've been there with the J_S confusion. Around 1997 I believe, I was using DAC (the precursor to WinDAC) under win95 to rip cds, and some fraunhoffer compressor exe that was floating around the net. I remember thinking Stereo (it would also be called Dual Mono, Discreet Channels etc. in GUI frontends) ought to be better than Joint_Stereo which looked like some sort of compromise option. For the life of me I couldn't figure out why my 128kbit mp3's with "true stereo" were sounding horrible. The dark ages of audio encoding...

In 1997 there is no guarantee that joint stereo would have been implemented correctly. Even LAME before version 3.90 might have been less than 100% perfect.

If you will do this, please update also lame --longhelp text:



-m s for stereo (or simple stereo, as in longhelp), and -m j for smart stereo? It seems inconvenient.

I propose to break backwards-compatibility in a non-disruptive way, by mapping -m s to to "smart stereo". Reason: More than 90% of people who use -m s dont know what they're doing and are affected by the misunderstanding, which you seek to "fix". The few remaining sane users of -m s, are geeks who know what they're doing - and will therefore be able to adapt to the new syntax.

I can consider myself as a geek . I agree that if you are a 100% sure that the file you are going to encode will be better than encoding in -mj, you should use -ms, but if you don't know which mode to use, it's better to use -mj instead.

Why would you substract right from left? I hope you do know that Joint Stereo can also contain Simple Stereo frames. That is why I don't see any reason why "pure" Simple Stereo should be preferred over Joint Stereo that can use Simple Stereo frames when L and R are not similar and Mid/Side Stereo when L and R are similar.

My recommendation would be to remove the -m s switch alltogether.

Then how about -m d for dumb ("simple") stereo? And -m dd for dual-channel ("dumb dumb").