High level overview
e deleflie
I thought I'd take a look at the Universal Ambisonic spec from the
perspective of our original aims. Unfortunately, our aims have been
moving somewhat. The original was:
1) A file format for delivery of ambisonics over the Internet
that quickly expanded to
2) a general file format for representing ambisonics that scales to
higher orders in an elegant fashion.
which then ended up (now) as
3) a standard for round-trip processing of ambisonics.... a standard
that can be understood in all environments (universal to all
contexts)... from production to delivery to consumption.
I am guilty of that last 'bent'.
I think the 'moving goal posts' approach has tired a lot of people.
(Next time, instead of spending 1% of the time thinking about is
required, then 99% running rings around it, I will attempt to spend
90% of the time defining is required).
Etienne
e deleflie
- Universal Ambisonic limits scaling to higher orders (4P and 5H1P).
This is a loss of the first goal. I'm looking for a way to adjust
this.
- What is the difference in 'philosophy' between Universal Ambisonic
and FMH? There's a more elegant normalisation scheme ... and a
'round-trip' approach (i.e. Universal Ambisonic defines
software/decoding standards etc.). But this makes me think that we
need to somehow allow un-restricted expansion to higher orders.
- How would a second order horizontal microphone represent their data
in Universal Ambisonic? They'd be using 2H1P ... but what do they put
in Z1? ... is there a logical algorythm for filling Z1?
Etienne
e deleflie
> This is a loss of the first goal. I'm looking for a way to adjust
> this.
Are there any channel count conflicts when doing XP and XP1H?
The advantage of limiting to 4P and 5H1P is that it produces a 'limit'
to which software authors can work. It offers a goal.
Is there perhaps a 'Universal Ambisonic Extended' that has no
restriction on order? Would doing that be a complication to the
standard (and hence a weakening)? Would it be better to have no limit
on the orders at all (thereby removing the satisfying goal of having
implemented a 'fully compliant Universal Ambisonic decoder'?)
Etienne
e deleflie
>> - Universal Ambisonic limits scaling to higher orders (4P and 5H1P).
>> This is a loss of the first goal. I'm looking for a way to adjust
>> this.
>
> Are there any channel count conflicts when doing XP and XP1H?
I meant XH1P
Etienne
e deleflie
>> This is a loss of the first goal. I'm looking for a way to adjust
>> this.
>
> Are there any channel count conflicts when doing XP and XP1H?
no, you cant have horizontal only (+Z) and full 3D channel counts.
They conflict.
the horizontal only ones (+Z) are all even number channel counts ...
the full 3D ones are squares ... lots of squares are even numbers.
Like 16.... which is also 7H1P
6H1P is 14 channels ... I wonder if it should be included in the valid
Universal Ambisonic valid component combos. How likely is a 14/15/16
channel horizontal layout ...
Etienne
Oliver Thuns
> 6H1P is 14 channels ... I wonder if it should be included in the valid
> Universal Ambisonic valid component combos. How likely is a 14/15/16
> channel horizontal layout ...
Not very likely, but possible... But then why not support also 7th,
8th and 9th order horizontal? I would just be pragmatic and stop at
5th order horizontal and 3rd order full periphonic. It could be
extended later... My alternative suggestion is to cover these channel
mappings:
4: 1P
6: 1P2H
8: 1P3H
10: 1P4H
12: 1P5H
9: 2P
11: 2P3H
13: 2P4H
15: 2P5H
16: 3P
18: 3P4H
20: 3P5H
some extended schema:
1P to 1P6H
4 6 8 10 12 14
2P to 2P9H
9 11 13 15 17 19 21 23
3P to 3P12H
16 18 20 22 24 26 28 30 32 34
4P to 4P15H
25 27 29 31 33 35 37 39 41 43 45 47
5P to 5P18H
36 38 40 42 44 46 48 50 52 54 56 58 60 62
etc.
P.S.: I still don't like N3D(xW), but open for pure SN3D :-)
e deleflie
>
>> 6H1P is 14 channels ... I wonder if it should be included in the valid
>> Universal Ambisonic valid component combos. How likely is a 14/15/16
>> channel horizontal layout ...
>
> Not very likely, but possible... But then why not support also 7th,
> 8th and 9th order horizontal?
> I would just be pragmatic and stop at
> 5th order horizontal and 3rd order full periphonic. It could be
> extended later... My alternative suggestion is to cover these channel
> mappings:
order (i.e. there would be an expectation to have 6th order
horizontal) ... I think there has to be some kind of logical
progression
Not sure if the multiple P and H schemes (like 2P3H) would complicate
the decoder (the simple horizontal or full 3D options simplify the
decoder (dont they?)). And the reasoning for the choice between them
is easily encapsulated for the ambisonic-ignorant end-user.
> some extended schema:
>
> 1P to 1P6H
> 4 6 8 10 12 14
>
> 2P to 2P9H
> 9 11 13 15 17 19 21 23
>
> 3P to 3P12H
> 16 18 20 22 24 26 28 30 32 34
>
> 4P to 4P15H
> 25 27 29 31 33 35 37 39 41 43 45 47
>
> 5P to 5P18H
> 36 38 40 42 44 46 48 50 52 54 56 58 60 62
what's an example of a speaker array that would be served by a 2P3H,
for example.... and how could that 'mixed order combination' be
presented to an end-user such that they would know to use it? (i.e.
what questions would you ask the ambisonic-ignorant end-user that
would determine that 2P3H is the way to go?)
> P.S.: I still don't like N3D(xW), but open for pure SN3D :-)
that we can move on. If we could just sort out a good no-metadata
mixed order scheme (which I think is just as, if not more, difficult).
Etienne
> >
>
Oliver Thuns
>> some extended schema:
>>
>> 1P to 1P6H
>> 4 6 8 10 12 14
>>
>> 2P to 2P9H
>> 9 11 13 15 17 19 21 23
>>
>> 3P to 3P12H
>> 16 18 20 22 24 26 28 30 32 34
>>
>> 4P to 4P15H
>> 25 27 29 31 33 35 37 39 41 43 45 47
>>
>> 5P to 5P18H
>> 36 38 40 42 44 46 48 50 52 54 56 58 60 62
>
> hmmm ... that has a bit of logic to it. But is there a benefit? ....
> what's an example of a speaker array that would be served by a 2P3H,
> for example.... and how could that 'mixed order combination' be
> presented to an end-user such that they would know to use it? (i.e.
> what questions would you ask the ambisonic-ignorant end-user that
> would determine that 2P3H is the way to go?)
Ok, let's keep it simple. This was more an example that it could be
easily extended.
>> P.S.: I still don't like N3D(xW), but open for pure SN3D :-)
>
> I know. but at the end of the day, we have to settle on something so
> that we can move on.
Universal Ambisonics as you are proposing it, looks to me like it is
designed for common DAWs, plugins and available file formats like Flac
and Wavpack. Even Fons mentioned that you want to do the metering with
an application that is designed for N3D Ambisonics metering. I'm
convinced N3D is not the right format for DAW+plugin setups we have in
mind. SN3D is so much better suited for that case.
> If we could just sort out a good no-metadata
> mixed order scheme (which I think is just as, if not more, difficult).
Not everything can be solved without metadata. I think the most common
setups are covered by 1P to 1P5H, 2P and 3P. There will be a matadata
format anyway, which will most likely introduce more stuff than just
HVP.
Dave Malham
On 23/04/2009 13:10, Oliver Thuns wrote:
>
>
> Universal Ambisonics as you are proposing it, looks to me like it is
> designed for common DAWs, plugins and available file formats like Flac
> and Wavpack. Even Fons mentioned that you want to do the metering with
> an application that is designed for N3D Ambisonics metering. I'm
> convinced N3D is not the right format for DAW+plugin setups we have in
> mind. SN3D is so much better suited for that case.
>
>
I think that's absolutely right. The more I think about it, the more
solid is my feeling that N3D is only suitable for use within specialised
applications (such as inside plugins or stand alone software) and should
never be exposed to users. SN3D (or, better yet, SN3DxW) for any
situations where signals may be "out in the open", so to speak, is
definitely my format of choice for the future, dropping FuMa altogether
after the current generation of plugins wither away in the naturalness
of time....hey, as I retire in 2012, maybe that's the time ;-)
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
> designed for common DAWs, plugins and available file formats like Flac
> and Wavpack. Even Fons mentioned that you want to do the metering with
> an application that is designed for N3D Ambisonics metering. I'm
> convinced N3D is not the right format for DAW+plugin setups we have in
> mind. SN3D is so much better suited for that case.
now you've got me thinking about exactly what is philosophy behind
Universal Ambisonic. Its latent in my head, but I'll try to put it
down.
Universal Ambisonic is not so much designed for DAW's / plugins ...
its more a 'round trip' standard. It defines acceptable defaults for
every step of the ambisonics lifecycle from artist's production, to
software creation, decoder creation, speaker arrays, file
representation. etc.
Tries to remove as many decisions as possible... for all parties
involved (fewer decisions to be made = more 'useable' technology).
Tries to be a standard that could be implemented by hardware
manufacturers. Its not just a normalisation scheme ... its everything
from what orders MUST be implemented, to what arrays decoders MUST
support ... etc.
Tries to present mixed orders in such a way that producers need not
know anything about ambisonics to make the right choice about what
component combination to use.
(can anyone poke holes in those statements?)
SN3D vs N3D..... Ok, lets revisit.
Advantages of SN3D:
Oliver Thuns
standard (IMHO). Few people will care about what MUST be supported,
just because there is some new standard. You don't want to do
Universal Ambisonics certification, do you?
The problems Universal Ambisonics could solve:
- Interoperability between different plugins and software encoders / decoders.
- Storing Ambisonics in files formats that doesn't support Ambisonics (yet).
The decoder part is a delicate one, which should be discussed
independently. What we need is good documentation and I don't mean
more scientific papers.
But I agree very much with the overal idea: fewer decisions to be
made, a simple pragmatic subset, instead of a standard that covers
every possible case.
e deleflie
> standard (IMHO). Few people will care about what MUST be supported,
> just because there is some new standard. You don't want to do
> Universal Ambisonics certification, do you?
well, that kind of thing. If someone labels something as Universal
Ambisonic but doesn't implement all defined speaker array decodes then
everyone loses...
Etienne
Oliver Thuns
>
>> And I think you are again trying to solve to many problems with a new
>> standard (IMHO). Few people will care about what MUST be supported,
>> just because there is some new standard. You don't want to do
>> Universal Ambisonics certification, do you?
>
> yes.
>
> well, that kind of thing. If someone labels something as Universal
> Ambisonic but doesn't implement all defined speaker array decodes then
> everyone loses...
The biggest problem is the implementation. What we need is a standard
decoder library, preferably under BSD, LGPL or similar license. What
also could improve the situation is a file format for storing decoding
equations / speaker presets. Configure it once - use it with any
Ambisonics decoder or automatically generate a LADSPA-plugin,
VST-plugin or a Jack application.
Chris Travis
I am trying to catch up after one month on other things.
This is in part to help me limber up to write the two papers that I
will be presenting at the Ambisonics Symposium.
---
Etienne wrote..
>Are there any channel count conflicts when doing XP and [XH1P]?
Oliver wrote..
>My alternative suggestion is to cover these channel mappings:
>-
>4: 1P
>6: 1P2H
>8: 1P3H
>10: 1P4H
>12: 1P5H
>-
>9: 2P
>11: 2P3H
>13: 2P4H
>15: 2P5H
>-
>16: 3P
>18: 3P4H
>20: 3P5H
---
A quick comment on *H*P signals. They are not the way forward. *H1P
signals have a place, partly because they only cost only one additional
channel! But at higher numbers of channels, *H*V is the way to go.
I strongly disagree with the emphasis placed on *H*P in the 'Universal
Ambisonic' draft. It puts a fault line through the middle of the
document.
Chris Travis
e deleflie
If you look at the speaker arrays served by the component combinations
defined by XP and XH1P, it satisfies a good cross-section of typical
speakers. The compromise, the loss, I guess is with 3 rows. But then
then loss only occurs when you have *many* speakers in 3 rows (if I
understand right).
I think that's the way to look at component combinations ... what
speaker arrays do they serve? (rather than how many mixer order
permutations can be supported).
Can you qualify your statement? What unambiguous component
combinations would you suggest ...and what speaker arrays do they
serve? If your suggestion is significantly better, I'd change the
standard ... (but it would have to be significatly better).
Etienne
Chris Travis
I wrote..
>I strongly disagree with the emphasis placed on *H*P in the 'Universal
>Ambisonic' draft. It puts a fault line through the middle of the
>document.
Well, it was an earlier draft that I was looking at. The latest draft
has H1P but no H2P, H3P etc. So cancel that particular comment.
>[ED] If you look at the speaker arrays served by the component
>combinations defined by XP and XH1P, it satisfies a good cross-section
>of typical speakers. The compromise, the loss, I guess is with 3 rows.
>But then then loss only occurs when you have *many* speakers in 3 rows
>(if I understand right).
No, the loss is with any number of rings greater than one, and occurs
with any horizontal order greater than 1.
>[ED] I think that's the way to look at component combinations ... what
>speaker arrays do they serve?
I agree with that.
>[ED] What unambiguous component combinations would you suggest ...and
>what speaker arrays do they serve?
I'll give it some thought. But a proper answer might now have to wait
until after my "new mixed-order scheme" paper at the Ambisonics
Symposium. Here is its abstract...
>>Ambisonics is a scalable 3D surround-sound system. Mixed-order
>>Ambisonic signals have higher directional resolution in the
>>horizontal plane than at the poles. In the existing mixed-order
>>scheme (HP), the signals consist of the union of a horizontal-only
>>version and a fully-periphonic version of lower order. We present a
>>new mixed-order scheme (HV), which truncates the spherical harmonic
>>expansion in a different way. It gives resolution-versus-elevation
>>curves that are flatter in and near the horizontal plane. A combined
>>scheme (HVP) can also be used. The paper includes simulation results
>>for several different mixed-order signals and loudspeaker layouts.
Chris Travis
PS. I so wish you hadn't called your "Universal Ambisonic" thing a
"standard". See e.g. my email to the Ambisonics Association of 30th
October 2008, which was precipitated by some comments that Aaron made
on Michael Chapman's "standards" web pages.