Fixed channel counts - mixed orders -
e deleflie
I'm still working up Universal Ambisonic ... I dont see a better
proposal ... but ...
>> This is all too complicated. Let's settle on 4 channel 1st order
>> B-Format and 8 channel HOA mixed-order.
A fixed channel count definately has advantages. I'm thinking,
shouldn't it be possible to have different mixed-order combos in a
fixed channel count? ... bear with me...
Why did mixed orders get invented? .... would it not be accurate to
say that mixed orders were created to allow smaller channel counts?
We are trying to reduce the channel count at the processing/production phase.
It would be far far far simpler if the reduction in channel count (or
data rates) was done at the compression level.
Imagine if all HOA plugins / software /hardware etc. consisted of 12
channels. All of them. You always have to route 12 channels from one
plugin to the other. But when you 'mixed down' your work for
distribution ... its at that phase that the reduction in data rate
would occur. This would mean that we would have to create our own
compression scheme / file format (which may end up being easier).
Can anyone list some of the technical difficulties with always
encoding for a fixed channel count?
Etienne
e deleflie
end of the process, break it all back down to 2H1V ... would the
result be different to doing all the encoding / processing at 2H1V?
Etienne
Dave Malham
On 04/06/2009 01:00, e deleflie wrote:
> All,
>
> I'm still working up Universal Ambisonic ... I dont see a better
> proposal ... but ...
>
>
> A fixed channel count definately has advantages. I'm thinking,
> shouldn't it be possible to have different mixed-order combos in a
> fixed channel count? ... bear with me...
>
> Why did mixed orders get invented? .... would it not be accurate to
> say that mixed orders were created to allow smaller channel counts?
>
>
I believe that it was either me, or me and Chris who came up with the
concept back in the mid-nineties, (I am not absolutely certain and I
seem to have lost the emails where we talked of this, though I did find
one from 1996 where we were talking of 1.5 order), but I can
unequivocally state that it was indeed to allow for lower channel counts
and particularly to allow the magic number 8 (as in 1/2 inch eight
track, Adat/Tascam eight track) to be usable. This concept was very
useful when I came to write the VST plugins since Nuendo 1 had only 8
channels. Of course, my approach when I wrote them was not quite the
same as being talked about here, since in fhh plugins, the higher order
horizontal components also only have 1st order vertical variation,
rather than second or third, as appropriate.
> We are trying to reduce the channel count at the processing/production phase.
>
> It would be far far far simpler if the reduction in channel count (or
> data rates) was done at the compression level.
>
> Imagine if all HOA plugins / software /hardware etc. consisted of 12
> channels. All of them. You always have to route 12 channels from one
> plugin to the other. But when you 'mixed down' your work for
> distribution ... its at that phase that the reduction in data rate
> would occur. This would mean that we would have to create our own
> compression scheme / file format (which may end up being easier).
>
>
Why 12? If it's to fit into Nuendo, forget it - Nuendo becomes less of a
viable option with every "up" grade.
Dave
--
These are my own views and may or may not be shared by my employer
/*********************************************************************/
/* Dave Malham http://music.york.ac.uk/staff/research/dave_malham/ */
/* Music Research Centre */
/* Department of Music "http://music.york.ac.uk/" */
/* The University of York Phone 01904 432448 */
/* Heslington Fax 01904 432450 */
/* York YO10 5DD */
/* UK 'Ambisonics - Component Imaging for Audio' */
/* "http://www.york.ac.uk/inst/mustech/3d_audio/" */
/*********************************************************************/
Chris Travis
>[DM] I believe that it was either me, or me and Chris who came up with
>the concept back in the mid-nineties
It was Dave who came up with the mixed-order concept. I recall Dave
mentioning it to me at an event in London. Probably the "Managing the
Bit Budget" conference in May 1994.
Chris Travis
e deleflie
>> We are trying to reduce the channel count at the processing/production phase.
>>
>> It would be far far far simpler if the reduction in channel count (or
>> data rates) was done at the compression level.
>>
>> Imagine if all HOA plugins / software /hardware etc. consisted of 12
>> channels. All of them. You always have to route 12 channels from one
>> plugin to the other. But when you 'mixed down' your work for
>> distribution ... its at that phase that the reduction in data rate
>> would occur. This would mean that we would have to create our own
>> compression scheme / file format (which may end up being easier).
>>
>>
> Why 12? If it's to fit into Nuendo, forget it - Nuendo becomes less of a
> viable option with every "up" grade.
12 was more or less plucked out of the air (weren't you saying that
there was a VST host that had a 12 channel limit?).
16 would clearly be more 'complete' (3P).
... can I ask people to muse on the thought-suggestion that ambisonics
authoring should always target all channels of a specific order (say
3rd) .... and lowering channel counts (or data rates or whatever)
would be more appropriate in a delivery format file?
Etienne
e deleflie
> authoring should always target all channels of a specific order (say
> 3rd) .... and lowering channel counts (or data rates or whatever)
> would be more appropriate in a delivery format file?
I'm just hovering over this thought. Imagine how easy it would be to
create Ambisonic plugins .... you only have to target 1 order! Only 1
rotation/yaw/spin plugin, only 1 point-source encoder plugin, only 1
reflections plugin, only 1 blablabla.
This would make life very simple for the software people.
The complexity comes in the 'mixdown' to lower orders as desired, and
in the compression strategy (or "lose some channels" strategy) when
translating into the target delivery format.
Etienne
> Etienne
>