Thoughts on stereo field

[KG_is_back]

Thanks for this tutorial!

I can follow a lot of the things. For example, the three points you mentioned. But I can only imagine how I use them to move around in the stereo field. What I still don't understand are the mechanics that actually widen an already existing stereo field? How to actually tweak the source to make that sound from the left coming from far left. From stereo to mono you just do (l+r) / 2, and all is fine. I know that it's not so easy the other way 'round. But there must be some algorithm, right?

The way stereo wideners are usually done, is to convert L-R sound format to mid-side format and then they simply boost the side element and convert back to L-R.

Code: Select all

streamin inL;
streamin inR;
streamout outL;
streamout outR;
streamin width; //0~pure mono 1~original 2~doubled width
float mid,side;

mid=(inL+inR)*0.5; //vertical/"mono"/in-phase part
side=(inL-inR)*0.5; //lateral/out-of-phase part

outL=mid+side*width;
outR=mid-side*width;


When widening the stereo field, you are basically boosting the difference between the channels. This mainly exploits the amplitude difference detection in our brain and partially also phase difference detection.

[tulamide]

Thanks for this tutorial!

I can follow a lot of the things. For example, the three points you mentioned. But I can only imagine how I use them to move around in the stereo field. What I still don't understand are the mechanics that actually widen an already existing stereo field? How to actually tweak the source to make that sound from the left coming from far left. From stereo to mono you just do (l+r) / 2, and all is fine. I know that it's not so easy the other way 'round. But there must be some algorithm, right?

The way stereo wideners are usually done, is to convert L-R sound format to mid-side format and then they simply boost the side element and convert back to L-R.

Code: Select all

streamin inL;
streamin inR;
streamout outL;
streamout outR;
streamin width; //0~pure mono 1~original 2~doubled width
float mid,side;

mid=(inL+inR)*0.5; //vertical/"mono"/in-phase part
side=(inL-inR)*0.5; //lateral/out-of-phase part

outL=mid+side*width;
outR=mid-side*width;


When widening the stereo field, you are basically boosting the difference between the channels. This mainly exploits the amplitude difference detection in our brain and partially also phase difference detection.

Thanks again, KG. This makes actually sense to me.
Left and right channel have the value +1
(1 + 1) * 0.5 = 1 mid
(1 - 1) * 0.5 = 0 side

Or left +1, right -1
(1 - 1) * 0.5 = 0 mid
(1 + 1) * 0.5 = 1 side

There's only one thing I have to ask: If I calculate with the last example using width = 2, I get
outL = 0 + 1 * 2 = 2 (!)
outR = 0 - 1 * 2 = -2 (!)

Shouldn't the range still kept being normalized (-1 to +1) ?

[KG_is_back]

Shouldn't the range still kept being normalized (-1 to +1) ?

Unfortunately it's not that simple. If you think about it, mid-side configuration is just an alternative way to represent a stereo signal. What you do when widening stereo field, you are boosting the side-channel and possibly cutting the mid-channel, literally with a gain knob. Clipping can easily occur in such situation...

one thing you can do to fix this issue is to scale the mid and side channel gains similar to how panning is scaled.

Code: Select all

streamin width; //in range 0-1 0~mono 0.5~original 1~side only
streamout midGain;
streamout sideGain;

midGain=cos1(width*0.25);
sideGain=sin1(width*0.25);



Note: in this case signal needs to be scaled by sqrt(0.5) instead of 0.5 during conversion to mid-side in original code.

[tulamide]

Just to not confuse things: Since * 0.5 in the original code is constant, I can use a calculated float instead of sqr(0.5), right? So, * 0.7071... instead of * 0.5

[KG_is_back]

Just to not confuse things: Since * 0.5 in the original code is constant, I can use a calculated float instead of sqr(0.5), right? So, * 0.7071... instead of * 0.5

yes exactly, the full code would look like this:

Code: Select all

streamin inL;
streamin inR;
streamin width;
streamout outL;
streamout outR;
float mid,side,gM,gS;
float sqrtHalf=0.7071; //replace with exact value

mid=(inL+inR)*sqrtHalf;
side=(inL-inR)*sqrtHalf;

gM=cos1(width*0.25); //note: cos1(0.5*0.25)=sin1(0.5*0.25)=sqrt(0.5)
gS=sin1(width*0.25);

outL=mid*gM+side*gS;
outR=mid*gM-side*gS;


Note, that this solution will not prevent clipping completely. If you have pure mono-signal and set the width to 0, it will get boosted by sqrt(2), which still may result in clipping. However, with signal that has on average same volume of mid and side element (has well balanced stereo field) the average volume of L-R channels will remain roughly the same, no matter what width you set.
In fact, what I've made above is equivalent of circular panning law, used in many DAWs:

Code: Select all

streamin inL;
streamin inR;
streamin pan;
streamout outL;
streamout outR;
float gL,gR;
float sqrt2=sqrt(2); //replace with exact value

gL=cos1(width*0.25); //note: cos1(0.5*0.25)=sin1(0.5*0.25)=sqrt(0.5)
gR=sin1(width*0.25);

outL=inL*gL*sqrt2;
outR=inR*gR*sqrt2;


With this panning law, average volume of whole signal stays the same when panning - drop in one channel is compensated by boost in another. This works, because volume is not arithmetic average - it is a quadratic average. Which roughly corresponds to the energy carried by the wave. RMS-meters work on the same premise - they are much more accurate indicator of volume than peak-meters.

Quadratic average of fully left-panned signal from above example:
L=sqrt(2);
R=0;
avg= sqrt( (L^2 + R^2)/2 ) = sqrt ( (2+0)/2 ) = sqrt(1) = 1;

This average of 1 is preserved with any value of pan.

[tulamide]

It's embarassing, but I still have to ask a question. I tried the code in an actual circuit. But it somehow sounds strange at times. But I'm sure that's because of me doing something wrong. For example, if I use a range of 0 - 1 for width, it seems to be quite good. Almost mono at 0, original at 0.5.
But the closer it gets to 1 the more information is lost. I tried with several songs, and the vocals almost disappear, the kick drums and pretty much all bass completely disappears, and at 1 all of this, plus no real stereo but more like phase issues with instruments from slightly the right side.

Can you imagine something I could have done wrong?

[KG_is_back]

that is expected. At width=1 only the side channel is present and mid is completely removed. Middle usually contains vocals, bass, lead instruments and kick and snare. At maximum (infinite) width, the ratio between side/mid reaches infinity, so mid is infinitely more quiet than side = it's muted.

It might be worth investigating, playing with the scaling of the knob that controls width.

[RJHollins]

additional comments ...

... listen to just the Mid channel, and you'll hear a direct, monophonic signal. Now lower the level of the Mid channel while raising the two Side channels. As the Side signals increase and the Mid decreases, you'll notice the stereo image gets wider, while the center moves further away. (Removing the Mid channel completely results in a signal that's mostly ambient room sound, with very little directionality – useful for effect, but not much else.) By starting with the direct Mid sound and mixing in the Side channels, you can create just the right stereo imaging for the track.

When we use M/S miking ...

Another great benefit of MS miking is that it provides true mono compatibility. Since the two Side channels cancel each other out when you switch the mix to mono, only the center Mid channel remains, giving you a perfect monaural signal. And since the Side channels also contain much of the room ambience, collapsing the mix to mono eliminates that sound, resulting in a more direct mix with increased clarity.

[tulamide]

Thank you guys!
(Yeah, I didn't do something wrong )

[tester]

Mixing manipulations on stereo signal will produce always the same scope of audible results. So if you play with mid/side and produce extremely wide side - it will not be more spatial, it does not work that way.

For spatial "binaural" sound you need different approaches, for example with hrtf reference database. Which wasn't done here (SM/FS) yet anyway.

The only good plugin I know, capable of producing relatively natual binaural sound (let me know if something is better) was made by Longcat, H3D. Actually they released app (for advanced sound tracking) and plugin (for basic manipulation), but the problem is - they no longer offer it. Just in case they stop activating the plugin, I created a virtual machine with it, so I can use it freely where I need.

When approaching binaural sound, there are few problems to keep in mind.

1) Back/forth switching. I use binaural setup for field recordings, in-ear microphones. They produce convincing 3D sound. But with no reference (visual cues, knowing the space), just headphones - everything sounds as if it was behind, although it was recorded in front. This probably could be compensated by additional mixing and filtering.

2) Vertical plane. Well recorded sound - can be perceivable in wide range of vertical axis, especially when the sound is close to the body; you can notice it down to your hips or even deeper.

3) Well recorded sound - sounds as if it was outside headphones, and not between them. Is "touching".

4) Person who records binaural sound - hears best spatial results; others may not perceive it that way. For example - while the person who records (with in-ear mics) and a group of similar individuals will perceive well the vertical axis (sound moving down to the bottom) - other people will hear it as if the sound was moving far away.

5) Listening perspective. If sound was recorded while standing up, and you listen to it while lying down - then sensory conflict may diminish the spatial effect.

6) Many hrtf based systems sound unnatural. It's the filtering curve. Even sounds recorded by inear mics - may need some re-filtering.

7) Slight head motion while live listening - provides additional cues. On offline recordings this probably can be compensated by a good model.

8) Binaural recordings are usually for headphones. But I know how to build a speaker system for that.

There are few other things to consider, but mentioned above are the most signifficant.

I was thinking on recording my own reference database for binaural plugin, but creating the plugin/framework is far above my skills. I think it would be good to have such framework here, in FS. Also there are few tricks to check on the capturing side, because from my measurements - there is something more than typical hrtf, and... I have some idea what could it be added in experimental design.