How bout this:

[e deleflie]

Richard L noted off-list that Universal Ambisonic had lost its way because it was supposed to allow arbitrary scaling to higher orders. True.

So I propose the following:

------------------
Universal Ambisonic Processing Format:

    - Always has 16 channels (if compressed, must be non-lossy)

Universal Ambisonic Software Environments:

    - Must always support 16 channels and only ever 16 channels.

Universal Ambisonic Delivery Format:

    - mixed orders allowed, using header metadata. No restriction on 3P... can go up to whatever orders is required. (can use lossy compression).

Universal Ambisonic Decoder:

    - must be capable of decoding all possible mixed order combos up to 3P. Can go on to support higher orders if it wants to.

---------------------- USE CASES -----------------

Want to mix 1st order with 3rd order?
    - you cant do it. Well, sure, you can use Fons' method, but at your own risk.

Want to re-mix someone's work?
    - get the processing format (16 channel) version. Pump it into 16 channel VSTs. Or use the Delivery format version but then you'll be dealing with funky channel counts.

Want to distribute a second order horizontal recording?
    - use the delivery format.

Want to create a 7th order horizontal composition?
    - use your own software to create it, but you can deliver it in Universal Ambisonic Delivery format.
-------------------------

so that covers:

a) dramatically simplified software environments
b) easy interchange between file and software env ... but you are restricted to using the processing format version.
c) any higher order combo is supported, via the delivery format and its meta-data headers.... but you'll need to use your own software to generate the greater-than-16-channel count.

Etienne

[e deleflie]

What I am essentially suggesting, is that mixed orders should only be used for the last mile .... for the end point delivery ... when you know exactly what speaker array you are working on.

If I am not mistaken, this makes sense with the original motivation for mixed orders ... to reduce channel counts (and data rates(?)).

The complexity with mixed orders comes when writing software to encode or process which _already_ assumes a specific mixed order. This would have been valid to start with ... since ambisonic pieces would have been initially created with only one specific target array in mind.

But now we are concerned with sharing / transmission of ambisonic data ... in other words ... truly leveraging ambisonics' promise of speaker array agnosticism ... and so I question whether mixed orders have a role in authoring stage.

therefore, the suggestion is that:
1) a processing format should not be mixed-order capable
2) a delivery format should.

Etienne

[Dave Malham]

On 18/06/2009 02:57, e deleflie wrote:
>
> therefore, the suggestion is that:
> 1) a processing format should not be mixed-order capable
> 2) a delivery format should.
>

But, if the production format _doesn't_ somehow support mixed order, how
would you produce such for the delivery format??

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/" */
/*********************************************************************/

[e deleflie]

On 18/06/2009 02:57, e deleflie wrote:
>
> therefore, the suggestion is that:
> 1) a processing format should not be mixed-order capable
> 2) a delivery format should.
>

But, if the production format _doesn't_ somehow support mixed order, how
would you produce such for the delivery format??

The delivery format would have knowledge of the end-point speaker array.

I guess I'm thinking of mixed order as being a kind of half-way-g-format. The actual mixed order chosen for the delivery format would be a function of what speaker array you want to play the thing on.

So for example, a second order horizontal mixed order would be popular for playback on 5.1. How is it different to G format?... it leaves the art of decoding to the decoder on the consumer end.

Basically, you'd end up with a bunch of different delivery format versions (a 5.1 version, an octophonic version). This is not optimal. A single delivery format would be better. (how can we do that?)

The delivery format is very different to the production format ... it has meta-data ... HPV (or whatever).... and is _not_ restricted to 3rd order... it can be used by anyone with any order, and any mixed order. (it is only similar to the processing format in its normalisation scheme). Consumer-level ambisonic decoders (that play the delivery format) ...must be capable of understanding this metadata. . Essentially, the delivery format solves a different set of problems to the processing format... it is amenable to the complexity of mixed orders.

The processing format is not amenable to mixed orders ... because these introduce just too many complications when routing signals between apps, choosing plugins, etc.

(BTW ... I'm just thinking of these things as we discuss them ... trying to see if it can make sense).

Etienne

[Dave Malham]

On 20/06/2009 11:27, e deleflie wrote:
>
> On 18/06/2009 02:57, e deleflie wrote:
> >
> > therefore, the suggestion is that:
> > 1) a processing format should not be mixed-order capable
> > 2) a delivery format should.
> >
> But, if the production format _doesn't_ somehow support mixed
> order, how
> would you produce such for the delivery format??
>
>
> The delivery format would have knowledge of the end-point speaker array.
>

Now, I'm confused.... how does it know?

>
> The delivery format is very different to the production format ... it
> has meta-data ... HPV (or whatever).... and is _not_ restricted to 3rd
> order... it can be used by anyone with any order, and any mixed order.
> (it is only similar to the processing format in its normalisation
> scheme). Consumer-level ambisonic decoders (that play the delivery
> format) ...must be capable of understanding this metadata. .
> Essentially, the delivery format solves a different set of problems to
> the processing format... it is amenable to the complexity of mixed orders.
>
>

Surely only the decoder knows what the speaker layout is and the
metadata stream is one way production system -> delivery format ->
decoder?

[e deleflie]

On 20/06/2009 11:27, e deleflie wrote:
>
>     On 18/06/2009 02:57, e deleflie wrote:
>     >
>     > therefore, the suggestion is that:
>     > 1) a processing format should not be mixed-order capable
>     > 2) a delivery format should.
>     >
>     But, if the production format _doesn't_ somehow support mixed
>     order, how
>     would you produce such for the delivery format??
>
>
> The delivery format would have knowledge of the end-point speaker array.
>

Now, I'm confused.... how does it know?

 
sorry, I stated it badly...

If the delivery format is 2H ... it is so because the person who chose to "compress" the 3P to 2H knows that the target array is more or less 5.1 horizontal.

> The delivery format is very different to the production format ... it
> has meta-data ... HPV (or whatever).... and is _not_ restricted to 3rd
> order... it can be used by anyone with any order, and any mixed order.
> (it is only similar to the processing format in its normalisation
> scheme). Consumer-level ambisonic decoders (that play the delivery
> format) ...must be capable of understanding this metadata. .
> Essentially, the delivery format solves a different set of problems to
> the processing format... it is amenable to the complexity of mixed orders.
>
>

Surely only the decoder knows what the speaker layout is and the
metadata stream is one way production system -> delivery format  ->
decoder?

 
There's 2 levels where a user makes decisions WRT speaker arrays. There is
a) mixed order choice
b) decoder configuration

In UA, choice a) is removed (from the processing phase) ... and pushed as far downstream as possible. The mixed order choice comes in just before you deliver the data to someone.

This strategy is not optimal. Its not optimal because it means that the person "compressing" the ambisonic data, has to have knowledge of the end-point array. Either that or they have to produce several mixed order versions of the 3P piece. Producing several mixed order versions then means that the end user has to work out which one to use .... which means that they have to have knowledge of ambisonics and orders and speaker arrays.

The only way this could work is if the end point decoder could communicate with some kind of server and say "hey, I'm spitting out to 4 speaker horizontal, please give me the appropriate file". Then the server would say, "OK, here's a 3 channel file".

We've discussed this kind of strategy before. Its not optimal.

Etienne