Hilbert transform in Stereo to 5.1 conversion

[juha_p]

I'm going to try prepare a stereo to 5.1 conversion 'preset' for EqualizerAPO use by this paper:
https://www.researchgate.net/publicatio ... tic_Sounds
Figure 1 there shows the procedure.

Phase shifting block is intended to be done using Hilbert transform, which is new subject for me (and looks quite complicated by papers google returned). Well, google brought me this page http://www.katjaas.nl/hilbert/hilbert.html (see also linked page http://yehar.com/blog/?p=368) which is showing another path to do it (which actually would suite to my 'work' well).

I was thinking to try use this IIR based method but I have no glue if
- this method can be used in this 'work'
- those (Olli's) coefficients showen there can be used in this 'work' or do I need to calculate new ones

Any thoughts.

[camsr]

The "olli" hilbert will require recalculation for different sample rates. Also, it is a causal filter pair, so it's expected to have group delay on the 0 degree half.

[juha_p]

The "olli" hilbert will require recalculation for different sample rates. Also, it is a causal filter pair, so it's expected to have group delay on the 0 degree half.

Looks like Olli has given out the s-plane coefficients so re-calculation shouldn't be a problem.

There's another allpass based method showen at dsp.stackexchange.com. Is there ready to use implementation available for this method?

[Z1202]

If you're looking for a generic method to design an IIR Hilbert transformer pair (dome filter) in the s-plane, the VAFilterDesign book contains a formula for direct computation of pole positions (7.43) given the desired order and bandwidth (7.45).

[juha_p]

<deleted>

[JCJR]

Does your 5.1 process require cancelling the raw signal channels against one or the other hilbert outputs?

If so, then maybe the cascaded IIR two-path "fake hilbert" would not work, because as camsr mentioned both outputs would have significant group delay against the original input signal.

Z1202 in his book excellently explains it assuming a fella is smart enough to understand the math good enough to "do creative work with it" which unfortunately disqualifies me.

If you don't need hilbert alignment over the entire frequency range you can reduce the latency by using fewer stages of allpass filter. I made a three-stage "low frequency" two branch IIR hilbert for an RMS compressor. The idea being that the IIR lowpass envelope smoothing at fairly short time constants was "good enough" without help from the hilbert, and I only needed better short time constant smoothing in the bass and low mids. Using fewer stages of allpass had less latency and seemed better behaved in that application. The cookbook "wideband hilbert" I scrounged up somewhere had rather big latency when I coded it in and tested it.

I used first order ZDF allpass from Vadim's book. I adjusted the frequencies of the stages with a big Open Office spreadsheet, tweaking frequency offsets until the phase response of the two legs was "close as I could get it" over as wide band I could get it. A better understanding of the math would have been better, but "whacking at geese with a rake" in the spreadsheet managed to get an answer quicker than trying to re-study enough math to calculate it the smart way.

[juha_p]

Does your 5.1 process require cancelling the raw signal channels against one or the other hilbert outputs?

If so, then maybe the cascaded IIR two-path "fake hilbert" would not work, because as camsr mentioned both outputs would have significant group delay against the original input signal.

...

Dolby Pro Logic II matrix

[camsr]

You use octave, you can easily write a fortran loop to generate a hilbert transform for +90 degrees. IIRC, the idea is to add sines linearly incremented in frequency, and scale each by 1/f. If you do the same with cosines, you get the bandlimited 0 degree half.

[juha_p]

You use octave, you can easily write a fortran loop to generate a hilbert transform for +90 degrees. IIRC, the idea is to add sines linearly incremented in frequency, and scale each by 1/f. If you do the same with cosines, you get the bandlimited 0 degree half.

Thanks for the info, I'll check this.

[juha_p]

Two 1st order filters :

--[ b0, b1, a0, a1]
1 [ -1.40374673978609e+008 1.40374675978609e+008 1 1.000000235752411 ]
2 [ 2.22044577169459e-016 2.22044632680604e-016 1 -1 ]

When used with other software (as like VST Analyzer (SynthEdit for to build VST plug-in) or some web based 'plotters'), why do I get different results (even with single filter) from what I get with Octave which I used for design?

Is it just because of transfer function (1st order vs biquad) behind the differences?

[mystran]

Two 1st order filters :

--[ b0, b1, a0, a1]
1 [ -1.40374673978609e+008 1.40374675978609e+008 1 1.000000235752411 ]
2 [ 2.22044577169459e-016 2.22044632680604e-016 1 -1 ]

These don't seem very stable. Assuming (b0+b1*z^-1)/(a0+a1*z^-1) you need abs(a1/a0)<1 to keep the filters from blowing up. Your feed-forward coefficients (b0, b1) are also very far from "sensible gain" but I guess this is just a result of normalising (for a0=1) with poor pole placement (eg. the first one is unstable, the second one was probably marginally stable before normalisation and coefficient rounding).

[juha_p]

...

These don't seem very stable. Assuming (b0+b1*z^-1)/(a0+a1*z^-1) you need abs(a1/a0)<1 to keep the filters from blowing up. Your feed-forward coefficients (b0, b1) are also very far from "sensible gain" but I guess this is just a result of normalising (for a0=1) with poor pole placement (eg. the first one is unstable, the second one was probably marginally stable before normalisation and coefficient rounding)

Looks like unstable output when connected in serie.

After normalizing by a0, in parallel system total gain is just around +6.3dB but the phase is 180 deg ... not 90 deg ... not even when just one filter is implemented --> Octave shows 90 deg phase for both filters.

[juha_p]

1 [ -1.50119987579016e+015 1.50119987579016e+015 1.0 0.999999999999999 ]
2 [ 6.66133814775094e-016 6.66133814775094e-016 1.000000000000001 -1.0 ]

I designed those two 1st order filters in Octave. Somehow I can't get the same mag/pha responses when implement the filters in SynthEdit (VST Analyzer). I have tried with single filter, series and parallel connections and none gave equal responses:

Octave:
https://s12.postimg.org/atqcho6q5/2allpassoctave.jpg

SE:
Filter 1&2:
https://s2.postimg.org/grsgjm589/mag_SE.png
https://s2.postimg.org/gt2ed1721/pha1_SE.png
https://s2.postimg.org/q24kn5fy1/pha2_SE.png
Series:
https://s18.postimg.org/tr7e4ku2h/mag_SE2.png
https://s18.postimg.org/p6pt3dzqx/pha2_SE2.png
https://s18.postimg.org/62whn1mwp/pha_SE2.png
Parallel:
https://s27.postimg.org/x2wx22yo3/AP12parmag.png
https://s27.postimg.org/xgy91oirn/AP12parpha.png

What could be the reason for this diffrence between Octave and SynthEdit?

[mystran]

1 [ -1.50119987579016e+015 1.50119987579016e+015 1.0 0.999999999999999 ]
2 [ 6.66133814775094e-016 6.66133814775094e-016 1.000000000000001 -1.0 ]

I designed those two 1st order filters in Octave. Somehow I can't get the same mag/pha responses when implement the filters in SynthEdit (VST Analyzer). I have tried with single filter, series and parallel connections and none gave equal responses:

Once again, please look at the actual numbers!

You have coefficients that are 10^15 and 10^-16 in magnitude in the numerator, which makes it obvious that the denominator is rounded due to limited number of digits and when you have values that are very close to 1 like this (in denominator), even double precision floats are not going to give you sensible results. So you are looking at difference in coefficient rounding errors and all the graphs are equally wrong, because even the coefficients are pretty much just rounding errors!

If you are trying to design all-pass filters (which is what I guess you want, considering your graphs are labeled AP1/2) then your magnitude plot in both cases should be straight line at unity. Anything else (from Octave or otherwise) and your coefficients are either wrong, or you are expecting too much from finite precision arithmetic (and I think it's the latter here).