Understanding the inner workings of the Mid-side decoder...

[chr.hove]

The mid-side decoder (DCP->Audio->Processor) really puzzles me.
A stereo audio file with containing only signal in one channel will result in a LRC file with signal in all three channels.
I am referring to these lines of code:

Code: Select all

MidSideDecoder::run (shared_ptr<const AudioBuffers> in, int channels)
{
	int const N = min (channels, 3);
	auto out = make_shared<AudioBuffers>(channels, in->frames ());
	for (int i = 0; i < in->frames(); ++i) {
		auto const left = in->data()[0][i];
		auto const right = in->data()[1][i];
		auto const mid = (left + right) / 2;
		if (N > 0) {
			out->data()[0][i] = left - mid;
		}
		if (N > 1) {
			out->data()[1][i] = right - mid;
		}
		if (N > 2) {
			out->data()[2][i] = mid;
		}
	}

I understand the calculation of the center channel: Cout=(Lin+Rin)/2, but the Lout and Rout not so much.
Say if we have signal in only Lin (Rin=0), then
Cout = (Lin+0)/2 = Lin/2
and
Lout = Lin-Cout = Lin-Lin/2 = Lin/2
and
Rout = Rin-Cout = 0-Lin/2 = -Lin/2
That means that when signal is only present in the left channel of the stereo file, after mid-side decoding it will be played in all three channels at half amplitude, but in contra-phase in the right channel. I guess that some of the mixing then actually takes place in front of the speakers in the auditorium when Rout cancels out Cout?

Anyone that can point me to where the math origins?

I would have expected something along with:
Cout = (Lin+Rin)/2
S = (Lin-Rin)/2
Lout = (Cout+S)/2 = ((Lin+Rin)/2+(Lin-Rin)/2)/2 = Lin/2
Rout = (Cout-S)/2 = ((Lin+Rin)/2-(Lin-Rin)/2)/2 = Rin/2

Thanks,
Christian

[carl]

Hey Christian,

This is a very interesting question, and you make a good point about what the code is doing.

Strangely enough, the answer is: I don't remember. This code was added nearly 10 years ago, and I didn't document the thoughts behind it. My best guess is that I was trying to make an unsophisticated decoder for some Dolby encoding. It's strange to have a project so old that you forget things like this.

I don't know what the best way forward is. Nowadays I'm less convinced that these filters make so much sense. Certainly I think any filters that DoM does have should be fairly "safe bets" i.e. unlikely to make things any worse.

[Carsten]

I noticed this phase-reverse between L and R a while ago while I was testing some M/S DCPs on our sound system.

I think I brought it up on the forum or on Mantis then, but somehow lost it soon after, because it was in a thread about a different topic.

I think it's a good idea to have a Mid/Side-Decoder in DCP-o-matic, since so many source files are stereo.

Maybe Carl can fix this and create a test version.


edit: I found it, it wasn't on this forum...

http://www.film-tech.com/vbb/forum/main ... ound/page3

[Antti N]

Some kind of a "pseudo Pro Logic" or even just a basic and safe mid/side decoder would be much appreciated in future versions, too.

It's actually getting more – not less – useful for me nowadays. A lot of older audio processors with Pro Logic / matrix decoding for 2.0 DCP audio (such as Dolby DMA8+ and CP750) are being retired, and current solutions such as CP950 and the IMS3000's built-in audio processor don't have this capability.

In a couple of months, I'm doing a big short film festival with heaps of 2.0 content. For years, we've simply been doing Pro Logic decoding in the booth with great results, but since that won't be an option any longer…

Carl: if you can find the time to look into the phase shifting issue, I'd be happy to try out any test versions and report my results!

[chr.hove]

Carl:
Thanks for the explanation.
As Antti N I encounter 2.0 material on a regular basis (both new short films and old material) and would love a way to do 2.0 -> 3.0 in a safe and reliable way, preferably following some proven industry standard.

[dcouzin]

Hello Carl and all,
The mid-side decoder works in the most obvious way. Allow me to use algebraic language instead of coding language. At each sample point we have genuine L and R from which we produce artificial L', R', C' according to:
C' = L/2 + R/2
L' = L - C = L/2 - R/2
R' = R - C = R/2 - L/2
So where there was no initial stereo, i.e., where L = R:
C' = L = R
L' = 0
R' = 0
And where there was initial stereo, where L ≠ R, each of C', L', R' are non-zero, and L' = -R' so:
|L'| = |R'|.
The equality of amplitudes shows up in D-o-m's graph of audio levels: there is one curve for C' and just one other curve for both L' and R'. See attached screengrabs.

original L and R.png

mid-side decoded L', R', C'.png

Consider that we have two ears. Suppose fraction 3/4 of the L' signal reaches left ear and fraction 1/4 reaches the right ear, and correspondingly reversed for the R' signal. The C' signal is received equally in the two ears. Then the left ear receives:
C'/2 + 3L'/4 + R'/4 = L/2
The right ear receives:
C'/2 + 3R'/4 + L'/4 = R/2.
A sweet perfection. When the fractional distribution between the ears is different from 3/4 and 1/4 this is disturbed; there is some modification of the stereo to the two ears.

I have a voice recording that is mono and environmental and music recordings that are quite stereo. So far I've mixed these all together as 2.0 stereo and then, for DCPs only, used the mid-side decoder to make 3.0. Would I be wiser to make the voice recording the 3.0 center and the environmental and music recordings the 3.0 left and right? If somehow the observer can tell that there is a center sound source and two side sound sources, will it be queer that the voice is thus separated from environment and music? Maybe it will be wonderful. Using the mid-side decoder avoids that separation.

Dennis Couzin

[Kewl]

I'll just add my two cents here:

DOM should probably have a few options for mid-side processing* based on the ones available here: http://elias.altervista.org/html/3_speaker_matrix.html

* I think the "Mid-side decoder" in DOM should be renamed "Mid-side processor" or "Stereo to LCR processor" or... something else. I must admit that the first time I saw the Mid-side decoder option I was surprised as, in a strict sense, MS decoding suppose a MS source (like, for exemple, a cardioid microphone and a figure-8 microphone) and outputs left and right channels. So who in his right mind would bring a video in DOM with an un-decoded MS signal? In any case, MS processing of a stereo (left, right) signal hearkens back to the famous Blumlein patent from the 30s where he was also concerned about the audio spatial presentation of movies.