Yes but remember that this thread was trying to explain the concept to a person who's only current understanding of the subject was that the word "stereo" sounds better than the words "joint stereo" and for whom even the most rudimentary explanation of how joint stereo worked was considered to be incomprehensible "techno mumbo jumbo". Under the circumstances I think some over-simplification was neccessary in this case.

The appropriate term for joint stereo vs. plain stereo would be 'lessloss'.

Like someone here said, the result of joint stereo is smaller size with same bitrate, or same size with more bitrate. It deppends on the song, I guess.

Now, if LAME V2 is transparent for most of us, in that case joint stereo would be the same as stereo. Am I wrong?

I listeng to metal music, so channels left and right are in most cases different, if not always. So in my case stereo would be the same as joint stereo.

Joint Stereo is better in quality, but increasing the quality and keeping stereo is the same or better. Right?

What do you think guys?

No. Size = bitate * time.
The result of joint stereo is smaller size with same quality, or same size with more quality. And bitrate is limited: it cannot be higher than 320 kbit/s.

You still haven't learned. Stereo is not the same as joint stereo, they are two completely different processes. One is more efficient and produces lossless results (joint stereo) while another wastes bits (stereo). Joint stereo will produce full channel separation while more effectively using an encoder. Many formats such as AAC, FLAC (I think), and other use a process similar to Lame with its joint stereo setting.

I suggest that you go back and actually read through this thread in order to understand what joint stereo does. It is not a process that degrades audio quality, it does not use the same procedure as simple stereo encoding, etc.



No. You would be better off just keeping joint stereo. I am not sure why you are having reservations regarding joint stereo encoding. Plenty of documentation and previous posts are at your fingertips yet it seems like you are refusing to use them.

yes, I read "joint stereo keeps both left and right channels".

So, how can JS create smaller files if the channels are kept untouched.

If the file is smaller, some information is gone.

And if JS works with side and mid channels, thats different from left and right.

So, if something in a song is supposed to be heard from the left speaker, with joint stereo is still heard from the left? the same as the right

Math.

Sure, information that is redundant.

Actually, it is a different way of expressing the same exact thing.

Yes.

Lame's joint-stereo has the ability to encode frames as either M/S or L/R depending on which way is more efficient. If you actually did a little research on the subject rather than making uneducated guesses based on what the methods are called, you would know this already. Simply reading this discussion from the beginning would have told you this!

[Edit] I removed my intro, Greynol beat me to it and was more useful [/edit]

The easiest example I can think of is the following. Consider a file which is encoded with simple stereo, where the L and R channels are exactly the same. Because of the similarity between the two channels, a joint stereo file would contain exactly the same audio data but at 1/2 the size. No loss, simply a more efficient way to present the exact same information.

Please let me know if you're with me so far.

It's the way it represents the samples mathematically.

For example, what if Left channel has 12800 Hz, and Right channel has 11800 Hz as the sample at that point in time for the frame?

So, you represent the sample's L/R data as 12800 and 11800 but as bits. It requires 14 bits to store each value (2^14 = 16384 so values up to 16383 can be done in 14 bits). That's 28 bits to represent both values.

What if you use M/S joint to represent it instead as M = L+R / 2 = ( 12800 + 11800 ) / 2 = 12300 and S = L - M = 500.

Then L = M + S = 12300 + 500 = 12800 and R = M - S = 12300 - 500 = 11800.

Same values decoded right?

However, it requires fewer bits to store the M/S values 12300 and 500 than it does the L/R values of 12800 and 11800.

14 bits to store the M value of 12300, but only 9 bits to store the S value of 500. So, 23 bits M/S joint stereo or 28 bits standard L/R stereo. Same values decoded though. That's where M/S joint stereo is more efficient.

It stores the sample values in a mathematically different, but ultimately equal, way so that fewer bits are required.

Now, extrapolate that to the many samples and frames over the course of a song.

It's how a frame of audio can be stored in say, 160kbps using M/S joint stereo, but may need 192kbps if done as L/R normal stereo.

By using fewer bits to store the same values in a different way mathematically, you "free up" those bits to be used for other frames which may require higher bitrate even with M/S to represent properly.

Counterpoint: flac exists

OK

So left and right are untouched, thats good.
L/R is the same as M/S. I thought the mid and side channels were fisically in the song, replacing the left and right.

I think I¡ll encode in V0 or V2. I encoded a CD from FLAC and in V0 is 130Mb with around 300kbps, and in V2 is 115Mb with around 270kbps

It would be nice to have all FLAC, but is way bigger.
I guess I'll have to re-think FLAC if I buy a bigger hard drive

Why are you ripping to FLAC and then converting the FLAC files to mp3 if you won't keep the lossless files? Might as well just rip directly to mp3.

During the encoding process the left and right channels are converted to mid and side, which are then encoded. During decoding the mid and side signals are decoded, then converted back to left and right.

These are surprisingly high bitrates for V0 and V2.

The bitrates are about normal for what I have seen with tracks in the metal genre. The album "The Fall Of Ideals" by All That Remains produces tracks with overall average bitrates of around 300kbps when using -V 0. Lamb Of God's latest album is also like this.

you are right, next time i'll rip directly to mp3.
i was just trying flac out.

i was very organized, so i wanted every mp3 in my computer to have the same quality, but i guess i'll stop thinking that.
becouse of the quality loss if you encode mp3 files, for example 320kbps to V0.

i'm really considering a 500GB hard disk, that's common sence this days.

thanks guys, i finally got this right into my head.

FYI, we call that transcoding.

Understandable. I just didn't know if you thought that ripping a CD to FLAC and then converting the FLAC files to mp3 produced better quality than going directly to mp3 (it doesn't, it produces the same quality).



FYI - I am not sure where you live but stores such as Best Buy have external hard drives on sale nearly all the time. Right now, Best Buy is selling a 500GB USB 2.0 hard drive for $70, 750GB USB 2.0 for $90, and 1TB USB 2.0 for about $100. Check out their ads every Sunday as they almost always have sales on USB 2.0 hard drives. Other websites such as Amazon.com and newegg.com also have sales on USB 2.0 hard drives. I remember paying $300 for my older 500GB USB 2.0 hard drive. You can now get 1TB drives for a third of that. A really smart investment if you ever plan on ripping your CDs to a lossless archive (one of the best decisions people can make with their music).

1 TB ! ! !
Thats sick dude.
Whith that much space FLAC is the only way to go.

I'm actually from Argentina, and the biggest hard drive you can get in my city is a 500GB one, maybe 750GB.
The prices here are the same.

My first PC had a 3GB hard drive, and I was just fine with it (no music though, I was 12). Now I have a 80GB HD, very nice when I bought it, but as you know computer hardware gets older by the day. So now I'm starting to feel like if I had a PC from stone age.

Anyway, we'll see what happens.

Best luck, and keep listening to great music.

This seems like a fairly decent explanation, but also a gross oversimplification from my understanding. Maybe someone with knowledge of how the mp3 is actually encoded can answer my questions.

First of all, you can't just stream bits like that because you need length information as well. Since we're dealing with 16-bit audio the largest number of bits any value can take up is of course 16. In the standard stereo example, a full sample requires 32-bits, assuming no length information. If you throw in length information (i.e. how many bits the next sample is going to take, and this length information must be 4 bits long itself) then any sample above 4095 is going to cost you space (4 bits for length and 13+ for the sample) while any sample below 2048 will save space. I don't know which frequencies are most common, so I've got to ask whether MP3s simple stereo uses length information or not?

M/S MUST either use a length value OR there's some rule such that if S would be greater than some standard bit value i.e. 255, 4095, etc then we force simple stereo. Otherwise the bit savings would seem to be minimal to non-existant.

I wouldn't mind someone with more knowledge on these things chiming in

WonderSlug's explanation is not about MP3; it's rather describes some lossless codec such as FLAC or WavPack.
About MP3 encoding - see http://wiki.hydrogenaudio.org/index.php?title=Mp3

I was basing my understanding of M/S joint stereo from the information obtained in this link:

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

These are compression formats, so they don't send raw bits like you're thinking. They're sent compressed, generally using variable length coding.



Your explanation is fine. Smaller numbers do take less bits to send then larger numbers, although the exact number used depends on how they're encoded.

I agree that "Joint Stereo" is a terrible name for an encoding technique. Because "Stereo" and "Mono" are traditionally used to describe the number of output audio channels, "Joint Stereo" gives the impression of some kind of compromise on "pure" Stereo. At least, this is the assumption I made back in my pre-HA days.

First off, I wasn't trying to denigrate WonderSlug's description, it just didn't make a whole lot of sense to me.
I'll admit that I don't know a whole lot about VLC or Huffman coding. I've tried to do some reading about the subject and how it applies in these audio codecs, but I still have trouble understanding how this kind of thing can work. I know they don't just send raw bits and that the data is losslessly compressed but it still seems to me that when it's uncompressed either all the samples/data has a standard bit size, or you have to know the bit length. Maybe I'm just completely misunderstanding the concept though, it certainly wouldn't be the first time.

Who said anything about uncompressed? You asked about MP3 and I answered . . .



Of course if the audio is uncompressed every sample has the same size. Thats why its called uncompressed

You only get to save bits when you apply some kind of compression.

Wonderslug was discussing M/S as a bit saving measure to simple stereo (which it is in many cases) which wasn't what I was referring to when I used the term compression. It's my understanding that that data is then VLC'd using Huffman to further compress. Maybe I'm completely wrong with regards to MP3 though... I've already stated that I barely even know what Huffman is.

When you start saying things like "The M takes 13 bits to encode and the S requires 9 which is a big savings over simple stereo which would require 28 bits for L+R" there are inherent problems. You can't just have random bit lengths for M/S without knowing how many bits to read for each sample. Just saying it's VLC'd doesn't seem to make the problem go away. When you decode back, you still have the problem of knowing when the different bit sections start and stop. How do you know the M takes 13 and the S takes 9 without either a length field or constant bit lengths (i.e. M is always 15 bits and S always 10)?

You split it into blocks and fix the quantiser (bit depth) across the block.

Anyway, with mp3 you're taking about frequency domain coefficients, not samples.


If you don't understand it fully (and why should you?) it makes some sense to trust those that do.

It's a pity people never seem to use that rule in audio - it's like "a little knowledge is a dangerous thing - expect in audio, where a tiny bit of knowledge suddenly makes me an expert!".

Cheers,
David.

I know, which is why I told him this! Maybe reread this part of my post:

"Smaller numbers do take less bits to send then larger numbers, although the exact number used depends on how they're encoded."

You can't compute an exact savings without knowing more, but the general ideas is correct.



Maybe you should look up what variable length coding does instead of just guessing, or if you're not interested in knowing, just take our word for it.

Well I read parts of the link that lvqvl posted last night, but it started making my brain hurt. It did seem that what I was talking about didn't really apply with how mp3 work.


It's not that I don't trust people who understand things better than me, I was asking for more information, precisely because I don't know. A "you're wrong" (which was the impression I got) without explaining (at least well enough for me to understand) why wasn't helping. I'm not some arrogant dumbass here to show you all what idiots you are, I'm trying to figure this stuff out. I like it here precisely because of the knowledge you guys have.

You are correct, I did kind of gloss over that.


Maybe reread the part of my post where I said that I did read up on Huffman and VLC. I'm just having trouble figuring out how it works in this context, which bugs me, which is why I'm asking more questions. Also, "just take our word for it" isn't necessarily the best answer when earlier in this thread cries of "Joint Stereo is Lossless!!!" filled the thread until 2bdecided came along and showed that was a misleading oversimplification for mp3... which was something I didn't know.

Sorry if I've upset anyone... I'm just trying to figure this stuff out. I'll bow out gracefully now and try to figure it out on my own.