Dolby Pro Logic II encoding test (90° vs 180° phase shift)

[Rockaria]

Yes, in a microphone's point of view, standing upright, scanning 360 deg. horizantally, 48000times a second(48khz/sec), but mostly recoding the waves from the origin direction [* check edit] on the zero phase degree zone when properly mastered[/*].

The WAV recoded, should be regarded as a bunch of all the waves(coils) scanned having different freq(hz), phases(circles), varying volumes(diameter)..
This might cause a problem synchronizing all the inner waves causing a significant delay in the phase shifting.

The inverting(flipping, mirroring) is a simple negative movement of the wav images on the same time(phase) axis of the grand wav(the captured wave), having no phase advance.
But the changing the polarity might have two different possible interpretations by the axis on the target waves : when the each inner wave is considered, the phase shifting will also make sense, but when the grand wav is considered, the inverting will be more reasonable, provided & proved that the phase shifting on the grand wave will result in different phase shifts on the inner waves because of each differnt frequencies(asking an analogic process or synchroniztions of all the channels when a DSP is used..).
But considering Dolby also included the '90deg phase shifting' in the diagrams, I believe they used the 'polarity' for inverting.

@raquete, thanks for the link that best visually explaining the coil(wave), as well as the related topics. :thanks:

[edit] The recoded mono wave might having the direction(phase shifted) is based on the fact that Dolby's doc on DD saying 'the simple downmixing the properly mastered waves from mics will be enough for DPL(II)...", just a simple assumption.
. some modification on the polarity change

[Rockaria]

A verification of avisynth's Amplify(-n) or MixAudio() when n=0.000~1 == invert()
not -180 deg phase shift as explained in the doc

<shift360.avs>
a=DirectShowSource("SSWAV06.wav")
a1=GetChannel(a,1)
a2=a1.Amplify(-1)
a3=a2.Amplify(-1)
a4=a3.Amplify(-1).Amplify(-1)
a5=a4.Amplify(-1).Amplify(-1)
a6=a5.Amplify(-1).Amplify(-1)
MergeChannels(a1,a2,a3,a4,a5,a6)

<capwav.cmd>
bepipe.exe --script "import(^shift360.avs^)">6ch380sft.wav

Audacity in max magnified scale on 48khz 6~sec 6ch wav clip
. 0.00001 sec increment view :: 0.00001 * 48000hz :: 0.48sample or cycle
. no advance with all 6ch(except a2 exactly inverted), identical

So all the - signed mix in similar scripts/language might also be the simple invert(), no advance in the phase*time domain.
If this is true, all the existing s/w DPL II emulations are using invert() only : partial implementations : no 90 deg phase shifts
Also note that the Hilbert() used in the quoted matlab script is not a built-in function implying the test result having no basis at all.
I believe that's enough for the verification.

I need to find a way to use the PhaseBugMono correctly :
. assuming it being the allpass phase shift filter
http://www.harmony-central.com/Effects/Articles/Phase_Shifting/
http://en.wikipedia.org/wiki/Phase_shifting
. mapping the input scale(0.000~1.000) to +-90 & +-180 deg scales : it's almost random (to me)
. synchronizing(aligning) the filtered channels to the exact phase*time domain of the clip
. or find other filters to do it more efficiently & effectively.
. or use other environment(tools)

It's taking time...

[raquete]

from Phase_Shifting article:
"To create the notches, we only need to mix the allpass filters output with the input....So when we mix a delayed copy of the signal with the original, there will be notches at equally spaced frequencies. This is exactly how the flanger operates, and thus, the flanger is merely one type of a phase shifter."
i can "proove" it! :cool:
in 1981 i did one miraculous phaser for guitar(inside analog sintesizer) that had 8 all pass filters turning like spiral using 8 FETs(2n3819 if i right remember) and 8 operational amplifiers(741) !

good link and another cool post Rockaria, thanks.

[Rockaria]

The invert(), -90 deg phase shift(PhaseBug, allpass filter) and the coefficients did the tric!:)
The earlier mentioned simplest model with -90 phase shift played by far the closest to the AC3 6ch out mode.

<m11> adjusted : no relations between the coefs, polarity between the channel : simple coefs mix
Lt = mix(Lf.0°, C.0°, *Ls1.-90°, *Rs2.-90°) == mix(Lf, C, *mix(Ls1, Rs2).-90°)
Rt = mix(Rf.0°, C.0°, Ls2.-90°, Rs1.-90°) == mix(Rf, C, mix(Ls2, Rs1).-90°)

Firstly over 95 % of the rear stereo seperation leaded the rest channels seperation further around 85%, considering the center/lfe are inherently unable to be seperated perfectly(simple mix). Now we can say the 90deg shift model reconstructs the channels over 90%.

<PhaseBug>
I had to mess around with the PhaseBugMono input scales to best map to the degrees and the amount of the delay to be adjusted.
. 48k/44.1k PhaseBug value 0.322 shifts -90deg
. 360 deg(4time) advances 0.256 sec
. -90 deg advances 0.064 sec
. +-180(2times of 90deg shifts) deg advances 0.128 sec
. +90(270 : 3times of -90deg shifts) deg advances 0.192 sec
. somebody might be able to theorize and establish a more accurate formula

<6ch source>
I chose the previously mentioned winamp5 bundled aac 'Hey Buddy.....aac' because it's open and by far one of the best clip having variety/clear channel harmony.
. transcoded to ogg -q5 6ch with foobar to be imported in the Audacity.
. the channel order might be different depending on the ogg cli encoder versions. but can be easily verified within Audacity.

<fronts stereo mix>
I made the front mix in a seperate project first because the rear can be simply mixed with the front mix again to make a complete DPL II
. copied L,R,C,LFE to a new project named front. L & R already set to correct channel attributes when imported.
. center -3dB, LFE as it is(kinda low initially)
. performed the quickMix() & played to verify : OK

<rear stereo mix>
I made a rear mix to make a complete mix with the prior front mix
. copied the rears to a new project named rear ans set the channel names/attributes to Ls1 & Rs1 : -3dB
. duplicated the Ls1 to Ls2 having the channel attribute to Right, Rs1 to Rs2 attributed to Left : -9dB
. performed invert() on Ls1 & Rs2
. performed the PhaseBugMono 90deg shifts on all the coefficients(0.322)
. performed the cut() of the beginning 0.064sec(align() also can do it) on all the coefs
. performed the quickMix() & played to verify : it played clearly on each rear speakers.

<complete mix>
I made a complete mix and exported to complete.ogg
. copy the front streo mix to the rear & played to verify : almost identical to the original AC3 out mode
. perform the quickMix() & played to verify : same , now safe to export to complete.ogg.

<remaining issues>
. the worldcup
. refine the models for further test : well, I think the coefs did the 'rear stereo channel seperation algo' perfectly.
. OPENing the conclusion & result : the best way is 'DIY' but can share the clips by email requests.
. Theorizing(formulating) the process and automation(programming) : will discuss some time later

@raquete, thanks for the confirmation(allpass filter) and I want to let you guys know that all the cricial issues are hinted by ursamtl in just few words. :thanks:
We did some research, reasoning and tried to adapt to the facts and tools....
Also there might be some mistakes I couldn't catch. Any corrections will be apprciated.

Thanks.

[edit] flawed! the rear cancellation occured(in the beginning on Ls). check below details.
[edit jun14] I meant it that we cannot conclude the best model, not flawed in the approach.
[edit Jun17] verified PhaseBugMono(0.322) = -90 deg shift, as said in a Dolby's doc.
[edit Jun18) typo on the model

[Rockaria]

Well, it seems too earlier to draw the conclusions. I admit above tests contains some flaws, not enough considerations.
The major problem is the CANCELLATIONS occured when merging the front and rear.inv.90deg-shfted stereos, killing the surround images.(especially the Ls in the beginning). We still need to refine the models and procedures.

. when reviewing the rear channels while phase shfting, I see the image spinning on the time-axis.
. the 90 phase shifted images also contains somewhat altered informations which might be CANCELLED/ALTERED when merged with other channel images which also contains informations on the same phase zones.
. if I understand it correctly, all the channel images reviewed have some directional information(not totally round or flat on the time-aixs, phase shifts imbeded initially), as what DarkAvenger introduced, which might lead to the perfect rear seperation impossible inherently, without any proper mastering maybe.

I's gonna take far more time for me, especially these days....step by step....well, It couldn't be that simple...:(

[3dsnar]

Also note that the Hilbert() used in the quoted matlab script is not a built-in function implying the test result having no basis at all.

1) hilbert(...) one of the functions from signal processing toolbox
http://www.mathworks.com/access/helpdesk/help/toolbox/signal/hilbert.html
2) you can view phase shift as a time delay, but also as an instantaneous operation. I.e. cosinusoid can be viewed as a time shifted sinusoid. Since in digital spectrum, signal is represented as a set of sinusoids/cosinusoids, thus appropriate time shift of each component is equal to instantaneous operation. Hence both are equivelent.

[Rockaria]

hilbert(...) one of the functions from signal processing toolbox
OK. Now I see, it is included in a related mathwotk package implying it should perform 90deg shifts correctly on all the inner waves(frequencies) with some delay.
you can view phase shift as a time delay, but also as an instantaneous operation
I agree we can have different interpretations and applications depending on the point of views, if we can ignore the time(frequency cycle) advance.

But what matters here is, how Dolby used the definitions for the DPL(II) encoding.
. how did you interpret the dolby's DPL I diagram in your formula?
. the - sign in the formula, interpreted as -180deg shift in your formula, actually works as invert() or -180 deg shift with the mathlab script?
. the 90 deg shift as +90 deg shift withs *1/4 cycle advance or something else?
(*1/4cycle : minimum sync cycles +1/4 cycle of the lowest freq.)

[3dsnar]

As I understand Dolby recommendations (which identical to Tebasuna's interpretation) that the 90 deg. shift is necessary as some preprocessing operation. I.e. it depends on the signal, and may or may not be applied to achieve the best separation during DPLII decoding. For example, probably in the example that I provided, the 5.1 input had already properly shifted FL and FR signals. But in some cases it may be necessary.
If I am correct, such speculation probably implies that during the decoding phase, the inversion of 90 deg. shift is not applied. Since the decoder cannot assume what was the original signal.
It requires some tests. But I think we are pretty close to find out how is it done.
- 180 deg. shift is identical (from mathematical point of view) to sign change. For example if you would apply the hilbert transform twice, than you would obtain something identical to the sign change (with some numerical error differences, which can be ommited).

imag(hilbert(s)) is like converting sinus to minus cosinus. And it is applied to all sinusoidal components of the input signal.

This is frequency dependent operation, which means that with the increase of frequency, the time shift gets smaller (since period duration decreases). I think that dolby is talking about the same thing. Especially because they refer to the hilbert transoform (which is applied in time domain as convolutive filtration, but this is the same to the FFT based operation used in matlab).

[Rockaria]

Matrix 1 (like BeSweet/Azid)
LT = L + 0.7 C - 0.8 SL - 0.5 SR
RT = R + 0.7 C + 0.5 SL + 0.8 SR

Matrix 3 (with inverted signs for back channels)
LT = L + 0.7 C + 0.8 SL + 0.5 SR
RT = R + 0.7 C - 0.5 SL - 0.8 SR
Isn't it too early to say/believe something/somebody is right or wrong?
I believe it just tends to lead to the simple justifications making things ambiguous again..
We are just guessing(interpreting) and testing to figure out the best model for DPL II decoders.
What matters here is the correct OPEN approach to figure out the uncertain matters.

We may not be sure if those rear shifts are meant for the channel seperations in 5.1 DD(I strongly doubt it).
But they may just have some directions by the mic positions(unintended side effects), but certainly not intended for the DPL II channel seperations.

But if you regard the - sign above(180deg phase shift initially to easy implement & replace the 90deg shifts) as the invert() now,
isn't it too dangerous to genralize the formula(without the 90deg shifts) to be used for the general type of clips?
Another irony is Tebasuna seems to have experienced the Matrix3 generally better than the same Matrix1(yours)...

Anyway, if we have to align the shifted channels(like I did), it might have a similar effect as the instantanuous half-flipping.
Maybe I need some more research and tests to understand & implement 'how the 90deg phase shifts works in DPL II with the coefs'.
moved to http://forum.doom9.org/showpost.php?p=841158&postcount=65

[edit]
The quoted type of models with LS.invert() only(without the 90deg shifts) actually produces unbalanced volumes on the fronts as I theoretically proved before.
Now I am clearly excluding them from the candidate list.
The Matrix1 showed Lf < Rf while the Matrix3 showed Lf > Rf.
The closest-Dolby model <m11> showed no such unbalances.
Also my 90deg version <m21> showed no such unbalance but showed not enough seperation of the rear : rears mixed to fronts.

I want to temporarily conclude the <m11> is the most faithful & simplest model so far, until we get any progress.

<m11> no other relations between the coefs, polarity between the channel, coefs +90 deg off from the fronts
Lt = mix(Lf.0°, C.0°, *Ls1.-90°, *Rs2.-90°) == mix(Lf, C, *mix(Ls1, Rs2).-90°)
Rt = mix(Rf.0°, C.0°, Ls2.-90°, Rs1.-90°) == mix(Rf, C, mix(Ls2, Rs1).-90°)

When * == invert(), -90° == 1/4 phase shift

[edit Jun17] verified PhaseBugMono(0.322) = -90 deg shift, as said in a Dolby's doc.
[eidt Jun18] typo on the model

[raquete]

i can't do good questions/answers in english :o then...
the colors in this screenshot are showing the details that are relevants for me, i will this help the thread:
http://img153.imageshack.us/img153/4018/surroundchannelprocessing2aa.png

i understand "can be" as "we can" and not as " (we) have to".
please,comments and corrections in my "colored details".

no answers:
and reading lots of .pds from Dolby.Inc i can't find answer for this question:
is -90 or +90 degrees?

thanks.

[Rockaria]

i understand "can be" as "we can" and not as " (we) have to".
please,comments and corrections in my "colored details".

no answers:
and reading lots of .pds from Dolby.Inc i can't find answer for this question:
is -90 or +90 degrees?

thanks.
There are two different modes in the downmixing from the Dolby DD 5.1 sources:
. simple downmix for a stereo speaker mode : don't need the invert() and .90 deg phase shift. But you can apply them expecting almost no difference for the stereo speaker.
. DPL (II) encoding for 5.1ch speaker mode through a DPL II decoder : as well as the invert() & phase shifts, the volume controls are necessary(as seen in many matrix form and the -3dBs in Dolby's documents)

I am going to test the +90 deg shift, but I think it's at best same as the -90 phase shift.
[result]
same result with <m11> having all coefs -90deg shifted.
it seems with the + or - 90 deg shifts, the rear images are crossed on the front phase that the decoder counts.

[edit Jun17] verified PhaseBugMono(0.322) = -90 deg shift, as said in a Dolby's doc.

[raquete]

I am going to test the -90 deg shift, but I think it's at best same as the +90 phase shift.
[result]
same result with <m11> having all coefs +90deg shifted.
it seems with the + or - 90 deg shifts, the rear images are crossed on the front phase that the decoder counts.

as ask don't hurt (but can bore...lol):
did you could listen differences from -90 to +90 ? some type of "cancelations" ?

thanks so much Rockaria, (you are very dedicated and interested) .

:-)

[Rockaria]

did you could listen differences from -90 to +90 ? some type of "cancelations" ?
That's a very important point which I was about to verify if the 1/2 cycle offs between the channels or coefs makes any differences on the cross(1/2 : 90-270 degree) phase pane shifts.

The rear channels will be 1/2 cycle(from 1/4 cycle or phase) advanced-mixed to the fronts, creating different mixtures.

When I was doing the above test, I didn't feel any noticeable differences between them, especially on the beginning part(as I mentioned before).
I will report back anytime soon. :thanks:
as ask don't hurtActually you are helping ourselves in a very positive manners!
you are very dedicated and interested
So you are in your best;) contributing way!

[3dsnar]

There is a simple way to find out how exactly the DPLII downmix should look like. And we also should be certain about the result.

In order to find out we need to
* know the original 5.1 source
* The source has to be a test file, where at the same time only one channel is playing and all channels are used through the sample
* the source waveform should be easy to analyze (i.e. periodic with easy to determine amplitude)
---------------------
* The source can be downmixed with any proposed matrix.
* We need to record output of the certfied Dolby decoder.

As we already know, for such a test sample,
the decoder should nearly perfectly recreate the source (no leakage between channels).
By analyzing how the produced 5.1 signal looks like, we will be able to determine the amplitude of each channel (i.e. what weights should be used) and phase.

I have provided such a test sample (the source and just in case two downmixes).
http://forum.doom9.org/showthread.php?t=112122&page=2
I guess the most problematic thing is to record the output of the certified decoder.
If someone will be able to produce such signal, I will do all the analysis in Matlab, and provide
all pictures (presenting input signal against the decoded one), etc.

[Rockaria]

In my previous test :

I just proved invert(+90 deg phase shift) not = -90deg phase shift.
-90.align()==+90.+90.+90.align() <> +90.invert() : looks similar but plays differently.
so +90.align() <> half-flipping : +90.+90.align() == +180.align() <> invert()

It turned out having some critical flaw in the method align() because of the gui nature of the Audacity.
I used the 'finding the muting point' for the alignNew() when exactly inverted. Now it has proved :
+180.alignNew() == invert(), when PhaseBugMono(1.000) = 180 Deg Shift
It also proved :
-90 == +90.alignNew().invert()

The effects this introduces are :
. the coefs' alignment must be strictly controlled. ( I am not sure if it affects the cross channels).
. the accuracy of the 90 deg shift seems not affecting much.
...
So far <m11> has proved itself being the most provable model for DPL II, best seperations with no unbalance between the front as seen on existing models.

The issue on the originally shifted rears still remains :
. Is it a mastering problem(neutralizing the position) or need some flattening processing while phase shifting?

[Rockaria]

Some interpretations :

%180 deg phase shifts
y(:,1) = FL*wgF + C*wgC + LFE*wgC - wgA*SL - wgB*SR;
y(:,2) = FR*wgF + C*wgC + LFE*wgC + wgB*SL + wgA*SR;

%90 deg phase shifts
y2(:,1) = FL*wgF + C*wgC + LFE*wgC + wgA*imag(hilbert(SL)) - wgB*imag(hilbert(SR));
y2(:,2) = FR*wgF + C*wgC + LFE*wgC - wgB*imag(hilbert(SL)) + wgA*imag(hilbert(SR));

<formula 1>
Lt = mix(mix(Lf, C, LFE), mix(Ls1, Rs2).invert())
Rt = mix(Rf, C, LFE, Ls2, Rs1)

<formula 2>
Lt = mix(mix(Lf, C, LFE), mix(Ls1.hilbert(), Rs2.hilbert().invert()))
Rt = mix(mix(Rf, C, LFE), mix(Ls2.hilbert().invert(), Rs1.hilbert()))

<formula 3>
Lt = mix(mix(Lf, C, LFE), mix(Ls1, Rs2).hilbert().invert())
Rt = mix(mix(Rf, C, LFE), mix(Ls2, Rs1).hilbert()))

- when L,R,C,LFE,Ls1,Ls2,Rs1,Rs2 are attained by any matrix including the Dolby dB format.

@3dsnar,
You can verify the hilbert() by checking if hilbert().hilbert() = 180 deg phase shift becomes invert() with the formula 1.
The formula 3 or similar must have been a better choice for a reanoable comparison than the formula 2.

[3dsnar]

The matlab function produces -90 phase shift (it is like converting
cosine to sine). The function produces returns the real part of the signal (which is the input) and its imaginary part (the phase shifted signal).
So hilbert().hilbert() prduces -180 phase shift (equal to sign change).
Here is a picture:
http://forum.videohelp.com/images/guides/p1514168/hilberthilbert.jpg
cheers, 3d

[Rockaria]

%90 deg phase shifts
y2(:,1) = FL*wgF + C*wgC + LFE*wgC + wgA*imag(hilbert(SL)) - wgB*imag(hilbert(SR));
y2(:,2) = FR*wgF + C*wgC + LFE*wgC - wgB*imag(hilbert(SL)) + wgA*imag(hilbert(SR));
..
The matlab function produces -90 phase shift

Then you tested with a brand new formula.
Some other points :
. how did you output the graph, through matlab scripts or photoshop(no help in this case)?
. is the imagepart any delayed ? 0/4, 1/4, 3/4 or any reasonable length?
. when I did the 90deg Shift with PhaseBug with a sine, it altered the signal(lower) as the phase shifts repeats. with a complex image, I couldn't notice such alteration.
. can you output the graph with a complex image through matlab script?

[3dsnar]

Hmm, I did not test the formulas. I have prepared some test signals, according to the formulas, so maybe someone will be able to use it with a DPLII decoder and record results.
They may be incorrect, it is not important. By analysing the produced signal it should be possible to see what the decoder produces, and thefore to guess how the correct formula should look like. I explained that here:
http://forum.doom9.org/showthread.php?p=841101#post841101
-------------------------
Yes, in Matlab. you can draw any signal in Matlab, and then export is as JPG for example (this is what I did).
When you copy-paste these instructions to the Matlab command window:
s=sin((1:44100)/1000);
figure;plot(s); hold on; plot(imag(hilbert(s)),'r'); hold on; plot(imag(hilbert(imag(hilbert(s)))),'g')
legend('sine','imag(hilbert(sine))', 'imag(hilbert(imag(hilbert(sine))))')
You will obtain the same picture.

[Rockaria]

Hmm, I did not test the formulas. I have prepared some test signals, according to the formulas, so maybe someone will be able to use it with a DPLII decoder and record results.
They may be incorrect, it is not important....
..... That seems to be the major difference between us...
No consensus & progress can be reasonably made with this different approach.

Anyway, what I can say here is :
. prove first and open to the public for evaluations : now you can test freely with my approach.
. also I make corrections ASAP whenever I find flaws in my approach to prevent any misleading : now you see I am also a human.

I will stop the activity on this issue for a while until we get any significant progress than the model <m11>.

/DoItYourself

[3dsnar]

Ineed, my conclusions were made to early, as I admitted here
http://forum.doom9.org/showthread.php?t=112122&page=2
Now I am trying to find out the truth, based on analysing the DPLII output signal, but I am not able to record a decoded signal (outputed by a DPLII decoder), but I hope that someone will be able to provide it.
If someone will be able to, it will be possible to determine precisely what should be the phase shifts, as well as weights. Without it I cannot make any progress.

[ursamtl]

Ok here are a couple of curve balls to get you guys out of the Hilbert rut ;)

Perhaps a bit of background reading might help you guys in your quest. Check out an archive of Michael Gerzon's papers at http://www.audiosignal.co.uk/Gerzon%20archive.html. Although he doesn't discuss Pro Logic directly, he does discuss a lot of the fundamentals behind modern surround sound systems. When I recently posted a question on the necessity of a 90deg phase shift to the experts on the sursound mailing list, one of them suggested the answer could be found in one of these papers. I found no obvious quick answer, but there are a lot of fascinating aspects here.

Another issue worth investigating is the whole notion of steering logic, which is quite fuzzy to me. I understand the purpose, but not the implemention. According to Dolby, steering logic is the big difference between DPL versions I and II. Therefore, it follows that, if you want to successfully model a DPLII decoder in software, you have to be able to model the steering logic circuit.

Regards,
Steve.

[Rockaria]

@raqueue,
This time I got somewhat different/detailed results than before, probably because of the more accurate new align method with more attention.
The (check edit)+90 model(m11a) was worse than -90 shift producing some right-shifted sounds in the beginning part.

<test condition>
. AN7(soundstorm) spdif pcm out mode, Onkyo TX-L5 in DPL II movie mode.
. 6ch source clip : winamp5 bundled 'Hey Buddy.aac' encoded to ogg using foobar2k v0.9 for Audacity input
. Source AC3 Play : FFDShow Ac3 6ch 640kbps out mode
. Audacity + PhaseBugMono : mix processing, DPL II preview. : system mixer spdif pcm out mode
. DPL II ogg play : FFDShow AC3 out mode for 2ch ogg DPL II input.

<tested models> 1:3 -dB ratio on Ls1:Ls2, Rs1:Rs2, ch-coefs are cross-ch mixed
<m10> : (Ls1,Rs2).invert() : 80%, not enough seperation on Rs, Lf < Rf
<m10a> : (Rs1,Ls2).invert() : 80%, not enough seperation on Ls, Lf > Rf
<m11> : (Ls1,Rs2).invert(), rear.hilbert() : 90% to ac3 6ch out
<m11a> : m11.rear.invert() == (Ls1,Rs2).invert(), rear.hilbert().invert() : 85%, the beginning part(airplain) a bit shifted to the Rf
<m21> : (Ls1, Ls2).hilbert(), (Rs1, Rs2).hilbert().invert() : 80%, actively balanced(L-R, F-S), not enough rear seperation
<m21a> : similar to m21
<m22> : (Ls1, Rs1).hilbert(), (Ls2, Rs2).hilbert().invert() : ...
...
Best Candidate : <m11> 3:1 ratio relations between the coefs, polarity between the channel, coefs +90 deg off from the fronts

Lt = mix(Lf.0°, C.0°, LFE.0°, *Ls1.-90°, *Rs2.-90°) == mix(mix(Lf, C, LFE), mix(Ls1, Rs2).hilbert().invert())
Rt = mix(Rf.0°, C.0°, LFE.0°, Ls2.-90°, Rs1.-90°) == mix(mix(Rf, C, LFE), mix(Ls2, Rs1).hilbert())
- when * == invert(), -90° == hilbert() == PhaseBugMono(0.322),
channels are properly attenuated with panning(weights on F-S & L-R) & ratio(center, lfe, coefs)
<conclusion>
. rear.hilbert() seems to affect the rear seperations from the fronts.
. invert() seems to affact the seperation of mixed rear channels.
. the cross mixed rear coefs(3:1 ratio on Ls1:Ls2, Rs1:Rs2) seems to affect the stereo seperation

. the <m11> seperation plan seems to be enough for the DPL II decoder
. other combinations tested so far, produced at best negative effects

<Audacity Issues>
. easily align the shifted channels with time-shift-tool mode.
. can preview the different models easily with undo/redo, quickmix,duplicate.. features

<other remaining Issues>
. treating the originally imbeded positioned ch image
. test,evaluating & gathering the reasonably working candidates.
. automation(programming) with Avisynth, mathlab or other scriptbased(batch) gui tools.
...

@3dsnar,
I hope somebody can provide some help for you to figure out the DPL II decoder functionality.
I believe some better Dolby certified S/W DPL II decoder may provide some ways to capture at any point of the stream processing.

@ursamtl, thanks for another pinpointing lecture(clues). It's gonna be some good brain-soothing time for me.

Hope anybody can test with my setup and find any better models...
I will also report back when I find any better models.... Thanks.

[edit]
http://www.dolby.com/assets/pdf/tech_library/44_SuroundMixing.pdf
Enforced basis by an another document explaining DPL II in a DPL I's point of view.

1. encoder models(look @P7-1) : several types
a. polarity inversion : like most existing s/w invert() only encoder
This method lets you place sounds at each of the four cardinal points: Left, Center, Right and Surround. This is an approximation of Dolby Surround and is limited in its capability. ... However, it does not allow for either interior sounds or center-to-surround pans. To achieve these effects, phase encoding is needed.
...
2. h/w encoder(@P8-1) : it clearly mentions all-pass network, lag(delay), large-frequence.
The all-pass networks are designed so that over the range of the surround bandpass filter, the phase shift of the surround path output always lags that of the left and right by as close to 90 degrees as pratically possible. All-pass networks with this property have large frequencydependent phase lag.
...
3. rear stereo seperation in DPL II : where can I find a Dolby's doc explaining in terms of coefs?

[edit Jun17] verified PhaseBugMono(0.322) = -90 deg shift, as said in a Dolby's doc.
above attached Dolby's doc says it's -90deg shift, so I tested it with a sine signal.
The PhasBugMono(0.322) shifted backward, which is -90 deg. and concures the behaviors of other tools.
Thanks for reminding me. I will adjust the models I tested.

[edit Jun18] about the volume control & phase-shift/invert mix
What need to be kept in the coef stereo seperation is the ratio between them to minimize the residuals and possibly to best seperate the rear channels by cross-ch-embeded-coef-image comparisons.
. weights : controls the PANNING between F-S & L-R. also controls the relative volumes on C & LFE
. coefs : the ratio approximating 3:1 on coef1:coef2, -3dB vs -9~-12dB was best for me with minimum residuals
. clipping control : Amplify(-3~-6dB) on the related channels(fronts or rears) will be proper prior to any mixing, depending on the original volumes.
. gain setting on each channel will be proper to control the weights and coefs ratio prior to any mixing or exporting.
. normalizing should be used on the mixed clips : T(Lt,Rt) or Ft(front)/St(rear)
. removing any possible DC-offsets in the normalize() option will be useful prior to any hilbert() or PhaseBugMono(0.322)
. be reminded the dB is the ratio on the logarithmic line. the resulting dB will be multiplied(not added) in the same sign region. http://en.wikipedia.org/wiki/Decibel
[edit Jun 22] typos on the tested models

[bleo]

Hi everyone. I authored the thread A better Dolby Pro Logic II downmix (http://forum.doom9.org/showthread.php?t=57988) almost three years ago, and I'm glad to see that there's still interest in Dolby Pro Logic II! :)

I see that the current debate has several different arguments rolled in together so I would like to address them separately.

The first is Rockaria's proposal that I shall describe in my own words as "inverting SR with respect to SL". Specifically, I am referring to the matrices:

<m21>
Lt = FL + 0.7071 C + 0.7071 LFE + 0.866 SL {+90} + 0.5 SR {-90}
Rt = FR + 0.7071 C + 0.7071 LFE + 0.5 SL {-90} + 0.866 SR {+90}

<m22>
Lt = FL + 0.7071 C + 0.7071 LFE + 0.866 SL {0} + 0.5 SR {+180}
Rt = FR + 0.7071 C + 0.7071 LFE + 0.5 SL {+180} + 0.866 SR {0}

I believe these are wrong. Take the case that SL and SR are identical, that is, the audio is intended to sound from between the surround speakers. When encoded through <m22>, Lt and Rt will each contain S at half power and phase {0} (the SL/SR has been dropped since I have defined SL and SR as identical). Thus when decoded, S will wrongly sound from C' (I shall use the apostrophe ['] to denote decoded sound channels).

Similarly for <m21>, Lt and Rt will each contain S at half power and phase {+90}. Thus when decoded, S will wrongly sound from C' but also with {+90} phase shift with respect to the original S.

I have not done 3dsnar's test in post 1 of this thread since I have no convenient internet or audio equipment where I am currently. However, going on the word of others, tebasuna51: "'weapons loaded' and 'Yes, Sir' are presents in FL, FR, BL, BR original audio, and not at Center channel". 3dsnar later reveals that version A uses <m21>. The results of scharfis_brain: "sample A lets it sound from the center" and tebasuna51: "In A "Yes, Sir" is basically only at Center channel" agree with my explanation above.

In conclusion, <m21> and <m22> will sound fine when only one channel is active at a time. Even SL and SR will decode to the correct channel since the {180} phase difference between Lt and Rt is maintained. However, the matrices will be incorrect when multiple channels are active, such as in the case where SL and SR are identical as I have described, but also when they are different, the decoded SR' will be {180} out of phase with SL'. The result will be similar to listening to a stereo CD with reversed polarity on one speaker. I can elaborate on this if anyone requests but I wish to keep this post concise.


The second debate is whether we should use {90} or {180} phase shifts. I shall refer to the following matrices:

<m11>
Lt = FL + 0.7071 C + 0.7071 LFE + 0.866 SL {-90} + 0.5 SR {-90}
Rt = FR + 0.7071 C + 0.7071 LFE + 0.5 SL {+90} + 0.866 SR {+90}

<m12>
Lt = FL + 0.7071 C + 0.7071 LFE + 0.866 SL {+180} + 0.5 SR {+180}
Rt = FR + 0.7071 C + 0.7071 LFE + 0.5 SL {0} + 0.866 SR {0}

Again, both matrices will sound fine when only one channel is active at a time. However, take the case that C and S are identical (SL/SR omitted for brevity), that is, the audio is intended to sound from between the center and surround speakers, such as in the case of a front to rear pan. When encoded through <m12>, S will cancel out C in Lt and only Rt will contain the sound, so it will be wrongly decoded to R'.

This will not occur in <m11> because S is {90} out of phase with respect to C. The {180} phase difference is also maintained for S between Lt and Rt so the decoder will be able to decode it to S'.

This explanation seems to agree with what ursamtl has quoted from the Dolby literature in post 41 of this thread. Dolby seems to imply that downmixers will use simple {180} phase shifts like <m12>. The original audio engineer should apply the {90} phase shift to the original SL and SR if they contain "point-source elements panned from S to C". Thus <m12> will be transformed into <m11> and we will not have the problem described above.

My conclusion is that it is too difficult to do the {90} phase shift ourselves. I would stick to <m12> and hope that there are no C/S pans or that the original audio engineer already applied the {90} phase shift if required.


The third debate is whether Lt or Rt should have SL and SR mixed (+) or (-). I shall refer to the following matrices:

<m12>
Lt = FL + 0.7071 C + 0.7071 LFE + 0.866 SL {+180} + 0.5 SR {+180}
Rt = FR + 0.7071 C + 0.7071 LFE + 0.5 SL {0} + 0.866 SR {0}

<m12a>
Lt = FL + 0.7071 C + 0.7071 LFE + 0.866 SL {0} + 0.5 SR {0}
Rt = FR + 0.7071 C + 0.7071 LFE + 0.5 SL {+180} + 0.866 SR {+180}

It is plain to see that SL' and SR' in the decoded output will both be {180} phase shifted with respect to the original SL and SR when using the incorrect matrix. The results of tebasuna51's tests in Software Dolby Pro-Logic II decoder?, post 41 (http://forum.doom9.org/showpost.php?p=836023&postcount=41), show that <m12a> may be the correct matrix. However, do note that when using a DPL1, or DPL2 decoder in Movie mode, SL' and SR' are delayed by 10msec which will have a frequency-dependent effect on your phase measurements. tebasuna51's results do in fact show that there are phase differences between DPL2 Movie and Music modes, even when using the same downmix matrix. My conclusion is that further tests are required to determine the behavior of different hardware and software DPL2 decoders.

[Rockaria]

Hi bleo, I felt I need to put some comments on your post.

I also read your guide long ago and tried to adapt myself to the formula <m12> but have experienced some problems that made me seek other models :
. the rear seperation is not applied fully that it causes the unbalances in normal music play : Lf < Rf for m12 and Lf > Rf for m12a.
. the m2~ models which I tested did not make such unbalances and actually produced better seperations on some/most types of clips (to me).
. to be precise, only one faithful model(by the spec) is correct, others are just partially implemented or incorrect.

But I finally concluded that the 180 deg shift(actually invert by dolby's spec) models are lacking something crucial, which later turned out being the C-S panning which will also affect the front seperation(Lf <> Rf).
You can easily notice the unbalanced playback when you switch between <m12> & <m12a>(Lf <> Rf), unless anybody want to be satisfied with the approximated implementation, as Dolby themselves admitted(as linked in the edit part above in my post).

As you see, I am now settled down to the <m11> model which is adopting the invert & -90 degree shift(as a result +-90 deg shifted & aligned). And it's not that hard to encode, just not automated yet.
I have tested with various clips so far and in fact got astonished by the seperation quality it might have been able to provide earlier to the DPL II users who still prefer the advantages than any other discrete formats can do : compact size, multi platforms ...
The hilbert transform seems not have been any new algorithm since very long ago.

The only issue I am having is that I am looking for a theoretical background which explains the rear stereo seperation with the cross-channel-imbeded-rear-coefficients reasonably. It proves to be correct through my ears & heart but yet through my brain and eyes. Everything else(invert, 90 phase shift) is clearly explained(and linked here) by their DPL I explanations and diagrams.

One more thing I want to point out is that the PowerDvd DPL II decoder might not be complete yet.
I believe there is no reason the music mode to have inverted channel seperations than the movie mode in normal DPL II decoding.

Anyway, I know I got the correct results finally, even though I am not relying on the DPL II encoding that much on 6ch play. (once experienced, I won't go back:)
I just want it treated as a plain fact. As you said it has been partial implementation. The difficulty of the hilbert() implementation is another thing.
But it's also my pleasure exchanging different opinions especially when we read & understand each other's views clearly.;)

[bleo]

Hi Rockaria. I welcome your debate and especially your test results. In fact, I hope that you will see that your results agree with my theories!

In reply to your concerns:
[Rockaria]: the rear seperation is not applied fully that it causes the unbalances in normal music play : Lf < Rf for m12 and Lf > Rf for m12a.
For <m12>:
Lt = FL + 0.7071 C + 0.7071 LFE + 0.866 SL {+180} + 0.5 SR {+180}
Rt = FR + 0.7071 C + 0.7071 LFE + 0.5 SL {0} + 0.866 SR {0}

let us take the case that FL and S are identical (SL/SR omitted for brevity). When encoded through <m12>, S will cancel out half of FL in Lt, and be present in Rt at half power and phase {0}. Thus, the sound will be wrongly moved towards R' and in this case be decoded to C'. Even when FL and S are only partially identical, that is, they contain only some identical waveforms, these waveforms will cancel each other out in Lt and be added to Rt, resulting in an overall output where FL' < FR' as you have seen.

<m12> is a compromise for easier downmixing and the example illustrates the difficulties of matrix encoding multiple concurrent channels.

[Rockaria]: the m2~ models which I tested did not make such unbalances and actually produced better seperations on some/most types of clips (to me).
Perhaps this is true, but you have created another problem for the case where SL and SR are identical (a mono surround) which I have already described. I believe that this may be common in movie soundtracks, which is very relevant to Doom9 Forum readers!

Furthermore, the better separation that you hear is probably the result of SL' being {180} out of phase with SR', again as I have already described.

[Rockaria]: to be precise, only one faithful model(by the spec) is correct, others are just partially implemented or incorrect.
The correct matrix is <m11>. However, <m12> is much easier computationally. How long does it take to {90} phase shift the two surround channels of a 2 hour movie soundtrack containing some 700 million samples?? Also, if the original soundtrack engineer already applied the {90} phase shift as per the Dolby specifications, then <m12> is the correct matrix to use.

[Rockaria]: I believe there is no reason the music mode to have inverted channel seperations than the movie mode in normal DPL II decoding.
A DPL1, or DPL2 decoder in Movie mode (but not in Music mode) delays SL' and SR' by 10msec which will have a frequency-dependent effect on your phase measurements.

[Rockaria]

It seems you are starting the debate when I want to save the words.:(
I think I understood your points clearly but unfortunately you seems not because I see you repeating the formula again.

Actually I found some issues with your formula style because of several reasons I described before.
. The + & - signs in the equations : I've already seen them misleading some people to do arithmetic operations on the wave images.
. the varibles regarded as constants : we have seen already too many matrices having different combinations when Dolby only suggested -3dBs in th spec. Your constants does not consider the clipping control, normalizations and custom pannings. I believe what is important is the ratio(1:3) between the rear coefs to minimize the residuals and best seperate the stereo images from the cross mixed 4 coefs images.
. does not faithfully reflect the Dolby's spec : Dolby says (Ls1, Rs2).invert then apply hilbert() to all the rear coefs resulting +-90 shifts on the rear coeffs. But your formula interpreted and simplified it as '180 deg off only' and applied the invert(-) only.
The simplification can be used only for analysis or optimization of the logic(definitely with a full formula remarked).

Now, some people will still regard the 180deg and the matrix as the magic numbers when they are just simple relative ratios and forget the invert(), hilbert() and any other necessary gain contols by your insistent contributions.
If you read my linked Dolby's doc again, the invert only matrix is considered for game surrounds, not for the professional music.
The movie sounds may be actually similar to game sounds that I agree it might suit for casual movie users but certainly not for music users.

The channels might having the directions is also another variables. I believe there is no constant such as already 90 deg shifted channels if the original engineer mastered the clips for general purpose use(especially for DD5.1). Please provide the links to generalize your concerns. I believe the positioned channels are just some minimul unintended side effects.
And the 10ms rear delay in the PowerDVD in movie mode play... Do you really believe if you shift your listening position to 1 m or so backward, the SL is played inverted? I think the DAC & speaker set is another layer..and the DPL II process is limited to encode & decode layer.
It is also possible for some people to try to use anyting in hand to backup the theory. And when they are abused, we call it a justification.
And 'how long does it take to phase shift?'.... I'd say it depends on the experience. I can't make people understood who just try to debate without any personal tests(verifications) and formal basis(link please!). It took me just 1.5 times of the invert().

Please read the linked Dolby's doc & my previous posts(to understand my views) and test it for yourself to verify if you want to continue the conversation. I've tried to keep the consistency but corrected anything I found wrong ASAP. Because I believe they are just simple facts, nothing related to human as far as they keep the correct approach(conversation).

[bleo]

The correct matrix is <m11> or <m11a>. (The one with {+/-90} phase shifts). I don't know how much clearer I can be.

Now, according to ursamtl's quote in post 41 of this thread from the "Dolby Digital Professional Encoding Guidelines", the encoding engineer of a DD5.1 soundtrack may or may not apply the {90} phase shift to the surround channels. If it is applied, then since:

{90}*<m12> = <m11>

thus <m12> would be the correct matrix to use when downmixing this particular soundtrack to DPL2, and in these cases only.


We are not discussing the coefficients here (0.7071, 0.866, 0.5); they were already discussed three years ago. If you wish, you may normalize them to prevent clipping.

And Rockaria, you need to go and learn how a time delay will cause a frequency-dependent phase shift...

[Rockaria]

The correct matrix is <m11> or <m11a>. (The one with {+/-90} phase shifts). I don't know how much clearer I can be.
Did I say <m11> incorrect? And have you ever mentioned the <m11> model in all through your post before we started to verify the models? Why do you appear in the last stage of the research and use my <m11> for a justification of your severe mistakes on <m12>?

Now, according to ursamtl's quote in post 41 of this thread from the "Dolby Digital Professional Encoding Guidelines", the encoding engineer of a DD5.1 soundtrack may or may not apply the {90} phase shift to the surround channels. If it is applied, then since:
...{90}*<m12> = <m11>
thus <m12> would be the correct matrix to use when downmixing this particular soundtrack to DPL2, and in these cases only.
I know ursamtl is a person with inspirations, experiences and no-biased opinions.
But quoting his message for your justifications won't be welcomed by anybody and it does not make yourself another ursamtl especially without the correct understandings.
If you read the message again, there is no proof that Dolby is using the positioned channels for the DD5.1 encoding.
The originally positioned mic sources might be useful for simple DPL II mix, like HRTF. It may not even need the invert(), a very special case especially customed to bleo.

We are not discussing the coefficients here (0.7071, 0.866, 0.5); they were already discussed three years ago. If you wish, you may normalize them to prevent clipping. Then we wasted 3 years because of your misleading simplified formula.

And Rockaria, you need to go and learn how a time delay will cause a frequency-dependent phase shift...
What is this?:angry: Do you want to believe you understand better than me? Simply because you joined this forum 2 years earlier?
You definitely need to prove you are not accusing & depreciating people. Or I might feel we need to correct your immature attitudes onto people and matters.

You are still not providing any resonable or formal basis(yeah, a simple blinded debate).:cool:

[specise_8472]

Here is a good reson for 90 degree phase shift!!


The surround channel should ideally be processed so that the
components of the signal in the two encoded Left Total (Lt) and
Right Total (Rt) channels are at +90 degrees and -90 degrees
phase shifts from the original surround signal. This is because of
the need for dynamic panning effects, for example causing a
sound to sweep over the heads of the audience, front to rear. If no
plus and minus 90 degree phase shift is applied, then the
Surround channel would have to be panned fully left, and then
phase inverted and panned fully right. Then the following would
occur during a front to rear sweep:
When the signal is in the Centre channel, it consists of
L + R. When the signal is in the Surround (i.e. rear) channel, it
consists of L - R. For a moving sweep from front to rear, the
level must be reduced from full to zero level over time in the
Centre channel, and increased from zero level to full level over
the same amount of time in the Surround channel. However , the
problem occurs when the level of the Centre channel is the same
as the level of the Surround channel. The ‘+R’ component in the
Centre channel and the ‘-R’ component in the Surround channel
will cancel each other out completely, leaving the signal only in
the Left reproduction channel. Thus the sound will appear to
sweep from front to the left and then to the rear, which is not the
desired effect.
In order to alleviate this effect of leftwards sweeping,
the plus and minus phase shifts are added in order to de-correlate
the -R component of the panned sound in the Surround channel
from the +R component of the panned sound in the Centre
channel. Therefore the component of the sound in the +R part of
the Centre channel is not the exact inverse of the sound in the -R
part of the Surround channel, and thus the sound is not cancelled
in the Right reproduction channel when the levels of the Centre
and Surround channels are the same during the front to rear
panning. The actual way to implement these phase shifts was
examined in some detail, however, the solution used was to delay
the surround signal before sending it and its inverse to the Left
Total and Right Total channels respectively.
If the Surround signal is delayed by a time interval
equal to 90 degrees of the wavelength of a frequency which is in
the centre of the bandwidth occupied by the surround signal, then
the phase shift is 90 degrees at that frequency, and deviates from
90 degrees as the frequency gets higher and lower than the centre
frequency. At this point the signal can be approximated as having
been phase shifted by 90 degrees. The delayed signal can be
lowered by 3 dB, and sent to the Left Total channel, then the
signal can be inverted and sent to the Right Total channel. In this
way, there is an approximate phase shift of plus and minus 90
degrees, and the signal is encoded differentially onto the two
transmission channels Left Total and Right Total. The time delay
causes the surround channel’s -R component to be de-correlated
from the centre channel’s +R component, in a similar fashion to
the way the pure plus and minus 90 degree phase shifts decorrelate
these signal components. 800Hz seems to be a good
mid-frequency point on the 100Hz to 7kHz bandwidth ( taking
into account the logarithmic frequency law). At this frequency, a
full wavelength phase shift is achieved by a time delay of 1/800
seconds. This is equal to 1.25 milliseconds. Thus a 1/4
wavelength phase shift is equal to 0.3125ms. The lowest
frequency in the reproduced surround channel is 100Hz. This has
a period of 10 ms, and thus a 1/4 wavelength period of 2.5 ms.
The time delay value chosen should then be a multiple of the
value for 1/4 wavelength of 800Hz , that is it should be a multiple
of 0.3125ms. It should also be greater than 2.5ms , in order to
effectively de-correlate the surround signal effectively at the
lower frequencies. A time delay of 7.8 ms was found to be most
effective during algorithm testing. This is the equivalent to a
delay of 6.25 wavelengths at 800Hz.

[ursamtl]

Here is a good reson for 90 degree phase shift!!

Interesting reading, specise. What's your source for this?

[specise_8472]

Interesting reading, specise. What's your source for this?

http://profs.sci.univr.it/~dafx/Final-Papers/pdf/Carugo.pdf

[bleo]

Thank you specise_8472. That explanation was what I was trying to say when I was describing the deficiencies of <m12> (the matrix with {180} phase shifts for the surrounds in Lt). The only difference being in <m12>, a front to rear pan wrongly goes from C' to R' to S'. Your explanation uses a slightly different matrix that is actually <m12a>--{180} phase shifts for the surrounds in Rt). So as described, a front to rear pan wrongly goes from C' to L' to S'.

[Rockaria]

That seems to be a fairly well described resoning on DPL 1, although we are not sure of the source.

. rear.hilbert() seems to affect the rear seperations from the fronts.
. invert() seems to affact the seperation of mixed rear channels.
. the cross mixed rear coefs(3:1 ratio on Ls1:Ls2, Rs1:Rs2) seems to affect the stereo seperation
The major difference between the DPL 1 and DPL II is of cource the third step of algo : rear stereo seperation.
The DPL II decoder steering logic(we have no spec yet, ursamtl) refined by the servo feed back may perform the three stacked seperation plans almost concurrently that any approximated results from each step will affect each other instantly.

The all-ch mixed Rt of the invert-only versions will undoubtedly confuse the DPL II decoder to some degree.(theorectically & practically proved)
Even when we play these invert-only encoded clips in stereo mode, I mostly experience the Lt <Rt making me assume :
. the playback volume of the inverted image not identical to the original image.
. the cross phase stacked(90 deg shifted) image has generally lower altitude(volume) differenthiating it a little from the simple downmix.

The limitation of the 'mid-frequency of 100Hz to 7kHz bandwidth' seems to be excluded from the DPL II version, iirc, correct me if wrong.
And I agree there are two possible approaches in the phase shift :
a. 1/4 cycle time delay on all frequencies(inner waves) and align(sync) them(look at Valex's post below) : depending on the granularity of the frequency band(to perform the shift together), the amount of delay and phase shift degree will be differently approximated. http://forum.doom9.org/showpost.php?p=360179&postcount=20
b. The alteration of the wave signal on all the frequencies(hilbert...) : basically same as the upper methods but might alter the signal resulting in some side effects.

Anyway, we need to theorize the two steps of the align() for any automations depending on the algo used for the 90deg phase shifting & target accuracies. I need some more research and analysis for this to formulate.

Thanks for the decent quote specise who has been providing quite unbiased opinions on the issues.

[raquete]

That seems to be a fairly well described resoning on DPL 1... right!

The limitation of the 'mid-frequency of 100Hz to 7kHz bandwidth' seems to be excluded from the DPL II version, iirc, correct me if wrong. .:goodpost: no corrections,you're completely right
DPL II channels are full range(less LFE of course)

[bleo]

Out of interest, I reread the Dolby Surround Mixing Manual (http://www.dolby.com/assets/pdf/tech_library/44_SuroundMixing.pdf) to investigate the concept in the 2nd part of specise_8472's quote: using a time-delay to cause a frequency-dependent phase shift. Note that this discussion is only relevant to DPL ONE encoders. In Chapter 8: Theory of Operation, 8.1: Encoder:
All processing [-3dB, 100Hz-7KHz bandpass filter, and Dolby B noise reduction] in the surround path contributes to the total degree of phase shift for that channel. The all-pass networks are designed so that over the range of the surround bandpass filter [100Hz-7KHz], the phase shift of the surround path output always lags that of the left and right by as close to 90 degrees as pratically possible. All-pass networks with this property have large frequencydependent phase lag. Thus for instance at 1 kHz, the left and right paths through the Dolby Model SEU4 give phase shifts of roughly –550 degrees, while the surround path, measured at the right total output, has about 90 degrees more lag (approximately –640 degrees total).
After doing some calculations, I take this to mean that processing of the front channels causes a delay of 1.528msec, and the surround channel by 1.778msec, so that the surround channel is delayed 0.25msec relative to the fronts. This will cause the following phase shifts in the surround channel relative to the fronts:
100Hz -9°
1KHz -90°
7KHz -630°
So it seems that DPL 1 does not use fixed phase shifts like +/-90° or 0/180°. This method should still be enough to decorrelate the surround channel from the fronts, but I suspect that this then requires the 100Hz-7KHz bandwidth limitation on the surround channel. Following this reasoning, if DPL2 is not bandwidth limited on the surround channels, then it probably does not use a time-delay phase shift, but instead I guess that the technology became available to do a constant 90° all-frequency phase shift.

[specise_8472]

This article is good at explaining more - that a sample delay of 3 gives the needed results.

http://www.gamasutra.com/features/sound_and_music/19981218/surround_01.htm

[specise_8472]

The major difference between the DPL 1 and DPL II is of cource the third step of algo : rear stereo seperation.
The DPL II decoder steering logic(we have no spec yet, ursamtl) refined by the servo feed back may perform the three stacked seperation plans almost concurrently that any approximated results from each step will affect each other instantly.


Yes but to my thinking, DPLII could be mixed exactly the same way, just that you mix LS into the left and RS into the right. Then you should be able to extract these back out by the fact that they have a phase difference. IE you can recover DPLI you should be able to do exactly the same with each individual channel.
Also DPLIIx would be the same, but with the CS mixed ito the Rear surrounds at -3db and easily recoverable out of the recovered rears.
I could be wrong here, just my thinking.

I did find last night some docs on the steering logic used in similar decoders. Based upon Right/Left and Left/Right.

I will play around with the DPLII encoder tonight and see what gives. It also offers decoding as well.

[bleo]

I've done some more reading of Mixing information of Dolby Pro Logic II (http://www.dolby.com/assets/pdf/tech_library/214_Mixing with Dolby Pro Logic II Technology.pdf) and in the section Music Mode vs Cinema Mode Decoding it says:
Cinema mode is very close to the standard Dolby Surround decoder, with the exception of the full-bandwidth stereo surrounds. Also, a polarity inversion of one of the channels is used to spread the signal in the room. So in fact, the inversion of SR' has nothing to do with the 10+msec delay of the surround channels.

Now, I have done some tests encoding stereo music with matrix <m11a> to L'/C'/R'; R'/SR'; and SL'/SR'. I used Cool Edit to do the 90° phase shifts, WinDVD's DPL2 decoder, Sonic Foundry Soft Encode DD5.1 encoder and finally WinDVD Dolby Headphone to listen to the result since I don't have 5.1 speakers where I am currently.

As an aside, the default option in Soft Encode is to 90° phase shift the surround channels... but that's another debate and more about DPL ONE compatibility anyway...

The main result was that I found SL' and SR' were 180° out of phase in Music mode, and in-phase in Movie mode. This agrees with tebasuna51's earlier results, but seems contrary to what the Dolby specs say.

anyway, it's very late and I'm a bit stumped right now... so does anyone have any clue what this is supposed to mean??

[specise_8472]

A snippet from the Surcode DPLII Encoder Manual.


9.4 Invert Right Surround
In Pro Logic II, the Ls and Rs outputs are intended to be out of phase by 180 degrees for surround steered inputs. However, if the decoder is set to Movie mode, the polarity of the Rs output is inverted in order for the Ls and Rs outputs to be in phase. This improves phantom rear center imaging.

[ursamtl]

A snippet from the Surcode DPLII Encoder Manual.

This would make sense since DPLII music mode is generally promoted by Dolby as intended for simulating 5-channel surround when listening to regular stereo music. As such, they don't want accurate phantom center imaging in the rear; they want diffuse ambience.

[scharfis_brain]

also I want to add that there won't be any phantom center surround anymore when inverting one of the surround channels before downmixing. The centered surround will be sent to the front center instead.

So this must be a mistake in the SurCode Manual or even in the SurCode program itself.

[Rockaria]

If I understand it correctly, the Music mode is designed for non-DPL(ii) encoded music, which will generally require some aggressive sparial effect through fronts and rears.
Also the Movie mode which is designed for DPL II encoded clips(it has the Ls inverted during the encoding time) will generally require the correct reconstructions of the original channels.

The problems we have now to verify prior to any conclusions seem to be :
. what happens if we decode the DPL II clip in Music mode? will it play the Ls inverted?
. is the Difussion/rear-phantom-center effect used after or during of the decoding process?
. for the DPL II Movie mode play, it is also possible to interpret as by inverting one of the channels again : 1. both out of phase : more difussion, 2. both in phase : rear phantom center, closer to the original
. what is the effect of one rear channel only inverted through the speakers? : unbalanced/directional playback?


I did find last night some docs on the steering logic used in similar decoders. Based upon Right/Left and Left/Right.

I will play around with the DPLII encoder tonight and see what gives. It also offers decoding as well.
It would be great to have the theoretical basis of the rear-stereo-seperation through the cross-mixed-rear-channels steering decoder logic. :thanks:
When not cross mixed, I got one rear channel playing in the front.
When not mixed in correct ratio(1:3), I got residuals(no full seperation) on both rears.
Of course, these experiences are limited to my DPL II decoders(onkyo, sony) and my s/w DPL II encoding experiments..

[bleo]

also I want to add that there won't be any phantom center surround anymore when inverting one of the surround channels before downmixing. The centered surround will be sent to the front center instead.

So this must be a mistake in the SurCode Manual or even in the SurCode program itself.

Hi scharfis_brain! Yes this is true if one of the surround channels is 180° out of phase with the other before or during downmixing. This is the case with <m21> and <m22> which we already agree on.

But I think the SurCode manual is referring to inverting the SR' output after decoding. The WinDVD DPL2 decoder also has this option.

This concurs with my test results. The only thing that remains to be interpreted is when the Dolby manual says: " a polarity inversion of one of the channels is used to...", does "spread the signal in the room" mean the [I]final SL' and SR' are in-phase or 180° out of phase? It would seem that the answer is in-phase.

[Rockaria]

also I want to add that there won't be any phantom center surround anymore when inverting one of the surround channels before downmixing. The centered surround will be sent to the front center instead.

Yes this is true if one of the surround channels is 180° out of phase with the other before or during downmixing. This is the case with <m21> and <m22> which we already agree on.
No, unfortunately it seems you are mistaking(in agreeing & quoting). If you read the model revision history :
I corrected the '180 deg phase shift 'to invert(), because they are misleading by misunderstanding.
I excluded all the invert-only models from the candidate list : to m10~
I revised all the models to have invert & 90 deg phase shift included : the model variations are basically for figuring out the best rear-stereo-seperation plan which some people here never have considered seriously.
Also I have repeatedly said, <m11> is the most faithful-simplest DPL II model so far, other combinations I've tested gave negative effects at best.

So as I said, it's basical now to understand the rear-stereo-seperation plan to have the complete skeleton of the DPL II architecture, by understanding the DPL II steering logic maybe.

[bleo]

one of the surround channels is 180° out of phase with the other before or during downmixing. This is the case with <m21> and <m22>

Translated to your notation, I meant:
if Ls = Rs, such as the case of a phantom center surround, then in <m21>, Ls1 = (Rs2).invert() and Ls2 = (Rs1).invert()
thus they will cancel each other out in Lt and Rt.

[Rockaria]

..<m21>, Ls1 = (Rs2).invert() and Ls2 = (Rs1).invert()
thus they will cancel each other out in Lt and Rt.
Then by your theory, any invert mixed channels will cancel each other (completely)!:scared:
Thus by your notation of 180 deg shift which is infact invert().delay(2/4cycle) :
Ls=0.85xxSL{180} + 0.5SR{180}, Rs=0.85xxSR{0} + 0.5SL{0}
Lt=L+C+LFE-Ls
should (completely) cancel each other, yeah no lefts..

<m2~> are kinda reasonable plans, but proved not complying the DPL II decoder mechanism by tests. Thus I can agree it need to be removed from the candidate list for this reason only.

Another thing : how were you able to connect his 'invert in one rear channel' to <m21>, <m22>?
Have you got any prej- information before decoding?

..inverting one of the surround channels before downmixing.
Also I want to remind you that without including the rear-stereo-seperation logic, affecting concurrently each other, I can only rely on the playbacks through the actual 5.1 speakers.

[bleo]

Then by your theory, any invert mixed channels will cancel each other (completely)!:scared:
Thus by your notation of 180 deg shift which is infact invert().delay(2/4cycle) :Actually I meant 180° phase shift = just invert() with no delay. Sorry for the misunderstanding.
Ls=0.85xxSL{180} + 0.5SR{180}, Rs=0.85xxSR{0} + 0.5SL{0}
Lt=L+C+LFE-Ls
should (completely) cancel each other, yeah no lefts..Yes! I think we are finally on the same wavelength! (pun intended! :)) For <m12> using 180° phase shifts, Ls will cancel out L in Lt if they are identical. This is the problem that both specise_8472 and I were describing. That is why we need to use 90° phase shifts. Then all of the channels will be nicely separated by being in different channels--Lt or Rt, or by phase--must not be 180° out of phase with another channel in the Lt or Rt mix.

[Rockaria]

Actually I meant 180° phase shift = just invert() with no delay. Sorry for the misunderstanding.
By the way, whose misunderstanding you meant? mine or yours?:rolleyes:

While you say 180 degrees, you actually use '-' in the formula, which is invert().

The 'out of phase' also is actually -180 ~ 0 phase region, not simply invert(-) or -180 deg.

Repeating my points, any correct description based on DPL 1 decoder behavior, might not be useful that much when the rears have STEREO channels in DPL II.

Anyway, I don't want to be trapped by so many exceptional what ifs based on the legacy DPL 1....;)

[bleo]

I believe there's a small typographical error in post #73:
<m21> : (Ls1,Rs2).invert(), (Ls1, Ls2).hilbert(), (Ls1, Ls2).hilbert().invert()should read:
<m21> : (Ls1,Rs2).invert(), (Ls1, Ls2).hilbert(), (Rs1, Rs2).hilbert().invert()

Another thing : how were you able to connect his 'invert in one rear channel' to <m21>, <m22>?Because <m21> = <m11a> with (Rs1, Rs2)invert(), you are effectively inverting Rs during downmixing.

Also I want to remind you that without including the rear-stereo-seperation logic, affecting concurrently each other, I can only rely on the playbacks through the actual 5.1 speakers.This sounds like the original work from 2002: BeSweet v1.4b12 & Dolby Surround II Matrix (http://forum.doom9.org/showthread.php?s=&threadid=27936). My thread A better Dolby Pro Logic II downmix (http://forum.doom9.org/showthread.php?t=57988) is a continuation of this work. I would like to add that the original 'surround2' downmix had the coefficients:
Lt = L + 0.7071 C - 0.8165 BL - 0.5774 BR
Rt = R + 0.7071 C + 0.5774 BL + 0.8165 BR
but all normalized by multiplying by 0.3225.

After those threads, the 'rear-stereo-separation logic' still has not been fully explained. But the results are still good enough for me ;)