Mid/Side-Stereo

2014-07-21 14:42:36

I do not know if this is a scientific discussion or just an audio question, but i do not really care.

What i care about now is this question that takes my mind since months:


How can Mid/Side-Stereo save storage room in compressed audio formats like FLAC when it does increase the space needed in RIFF/WAVE?


What i mean is this:

Mid/Side-Stereo

Reply #1 – 2014-07-21 15:59:20

You're absolutely right about the bits needed. However, this is basically the same question as why FLAC compresses at all.

The thing is, mid-side doesn't always work to your advantage. It only works when the two channels are correlated. In L-R you have two 16-bit channels that have some entropy, but in case both channels are related, the M-S channels have less entropy.

Maybe it's easier to see it like this: think of a stereo file that is actually mono, i.e., both channels carry the same information. In L-R, you'll need to encode both, but in M-S, the M-channel is as hard to encode as either the L of R (it is only twice as loud) and the S channel is silent (so very easy encode). In this case, L-R means you have to encode two 16-bit channels, while in M-S, you would have to encode only one 17-bit channel. This is of course an extreme, but I can't explain it any easier.

Mid/Side-Stereo

Reply #2 – 2014-07-21 16:04:55

M/S is usually used only in blocks or frames where it will help the compression ratio and L/R is used otherwise.

Where it does help most is where there is good positive or negative correlation between channels, and usually this is in the form of positive correlation (i.e. mid) as most music is mastered to sound OK on monophonic equipment as well as stereo.

By only predicting a monophonic waveform that is common to both channels once and encoding one residual (the difference between predicted value and actual) that components it coded efficiently. The side channel is often less correlated and less predictable but usually lower in amplitude, and the savings on the mid channel will outweigh this (otherwise M/S will not be used, and L/R will be used instead for that block).

Mid/Side-Stereo

Reply #3 – 2014-07-21 17:25:30

Create a 2 bit test example where the L and R channel are 80% correlated and you'll get a lot of small numbers and zeros in the M/S case.

Mid/Side-Stereo

Reply #4 – 2014-07-21 19:45:49

There's one thing that hasn't been mentioned. There's actually only 1 extra bit required for uncompressed M/S encoding, not 2 as in your examples. This is because (L + R) and (L - R) have the same LSB, so only one of them requires 17 bits. In WavPack, I store the “mid” value as (L + R) / 2, which fits in 16 bits.

This can be seen in your table too. In every case where M is an even integer (no fraction), S is an even integer also.

Mid/Side-Stereo

Reply #5 – 2014-07-22 10:13:34

bryant, I do not understand. LSB is the lower sideband or the least significant bit? My English ain't perfect, sorry.

Mid/Side-Stereo

Reply #6 – 2014-07-22 11:38:14

LSB denotes the least significant bit in this case. To explain what bryant said in other words again: In the binary representation of numbers you can think of the LSB as the bit which encodes the parity (whether the number is even or odd) of a number. Since the Mid and Side channels always have the same parity, you can save one additional bit when encoding the signal. You can re-use the parity bit of the Mid channel for the Side channel, you don't need to explicitly store the information that "Side channel is even", because that information is already stored by the Mid channel.

In your table you can see that the Mid channel is always an integer number if the Side channel is an integer. It is always a fractional number, and multiple of 0.5, if the Side channel is fractional. By multiplying your columns by a factor of two, you can easily see that the parities of the Mid and Side channels are always the same.

Mid/Side-Stereo

Reply #7 – 2014-07-22 13:42:16

Oh yeah, thank you very much, all of you people!