[LAD] ambisonics UHJ encoder
compose59 at gmail.com
Wed Feb 24 11:19:53 UTC 2010
2010/2/24 Jörn Nettingsmeier <nettings at folkwang-hochschule.de>:
> hi alex, fons!
> On 02/23/2010 02:37 PM, alex stone wrote:
> as fons said, jconv does a nice job of it, and i'm using it exclusively
> now. i did my first experiments with farina's method, described here:
> it's essentially the same, only that farina provides one IR per
> input/output pair, where fons does the same more elegantly with a single
> hilbert transform (they do the 90° phase shift indicated by the "j"
> coefficient as you find them on farina's page), and a couple of delays.
I'm on the Hilbert as of last night. Makes a challenging job simpler, i'd agree.
> if you want to do just the latter, and you already have a b-format, it's
> easier to use the vmic plugin which is part of fons' AMB plugins - it
> does the same job, but is simpler to use (no jack patching).
> if you have a b-format and want to produce stereo, these are the two
> options you have:
> 1. use UHJ to fold it down automatically (including extra surround
> information that allows the consumer to blow it up to horizontal
> surround again, with a few compromises). but since uhj basically moves
> the rear sound stage to the front, it can sound slightly over-ambient
> (not as extreme as blumlein stereo, though).
> 2. use a virtual stereo mike to pick out a stereo perspective. it allows
> for more control, is a lot easier to produce, and it's probably the
> safer option if you want your mix to be reliable on consumer gear...
1.) I've had the ambient overdone already, so i understand what you're
2.) Virtual stereo mike? I don't understand this bit. Do we have one
in Linux? Or are you referring to a process i have to build up myself?
>> The intent with this is provide ambisonic positioning, and convolver
>> tail, right up until downsizing to stereo as the last part of the
>> signal chain.
> i would definitely go that way, to be able to easily provide a b-format
Sounds like a plan.
> since you are dealing with artificial sources anyways, why stick to
> first order? do your panning in higher order instead. the use of
> resources is minimal (although it will create an insane amount of jack
> ports, so use -P2048). it won't make any difference to your UHJ, since
> it only ever sees WXY, but it would enable you to produce really crisp
> n.1 or HOA decodes without any extra work.
I don't know enough about higher order yet, but i am proficient in
handling insane amounts of of ports, so that bit isn't overwhelming.
> just one, totally unrelated, but smart(-ass) nonetheless: could you
> please edit your replies to quote only the part you are directly
> referring to? i'm usually very curious about things you have to say on
> the list, but my mouse wheel finger is getting RSI...
Good point, and i'll endeavour to do this in future.
My thanks to you and Fons for the info, and your continued generosity
midi-subscribe at openoctave.org
development-subscribe at openoctave.org
More information about the Linux-audio-dev