[Vorbis-dev] Ambisonia proposal

[Oliver Thuns]

On Fri, Sep 26, 2008 at 9:38 AM, Richard Lee <ricardo at justnet.com.au> wrote:
>> Also, there has been some recent work on channel mappings for OggPCM (uncompressed PCM data in an Ogg container), which may be related:
>
> Our proposal involves only Vorbis.  Uncompressed PCM Ambisonics is already well catered for.

I think Conrad talked about the OggPCM channel mapping spec, not about
the audio data. Unfortunately nobody has come up with a solution how
to squeeze the OggPCM mappings into the Vorbis header. So it seems to
be off the table.

>> that is what the spec draft proposes. but one channel mapping type is not enough for defining all combinations of horizontal and vertical orders above 3rd order. for example 9 channels can be interpreted as 2/2 or 4/0 (2nd order horizontal 2nd order vertical or 4th order horizontal without any vertical component).
>
> Mr. Oli, if you are AKA Mr. Thuns, you will see from
>
> http://docs.google.com/Doc?id=df4dtw69_3626qqq6st
>
> that we adopt the Thuns / Travis scheme that allows us to specify any number of channels up to and beyond 255 without ambiguity and without further mapping types or metadata.

I have read your draft. What I wanted to highlight is that this scheme
doesn't support every possible combination of H and V. It's not
possible to support e.g. both (2,2) and (4,0) with only one channel
mapping type for Ambisonics. Your solution is to forbid (4,0) and only
allow (2,2). I don't see why we should introduce any artificial
limitations here, just for saving a dozen plus two channel mapping
types, when we have 65535 left?

Don't get me wrong. I don't want to bloat the specification and I
would be satistfied, if Vorbis supports Ambisonics up to third order.

But squeezing as much as possible into one channel map doesn't make
the specification simpler, quite the contrary. And if you think from a
user's perspective, it introduces problems and potential
misunderstandings we don't need.

It's bad bad usability. You have to educate the user that Vorbis
supports Ambisonics up 40th order, but not if it's horizontal only.
plain horizontal Ambisonics is supported only for 3rd order and lower.
Of course you could use silent channels then, but that could probably
confuse the decoder.... No, (7,1) is also not possible, and (10,2) is
a no-no too.... (12,3) would be okay... (13,3) not...

BAD USABILITY!!!

Maybe I'm repeating myself, but I still think we should

a) support only up to 3rd order Ambisonics
or
b) write a spec that supports all possible combinations of H and V
order up to 255 channels, without any exceptions.

with b) having the advantage not to start another discussion about, if
3rd order is good enough for a consumer format or not.

The "Thuns / Travis scheme", is a pretty clever workaround, but I'm
not convinced that it is the right thing to do.

Enough critique. The rest of the specification is in my opinion fine
and it seems complete. I would post it to the sursound mailing list
and wait if anyone finds any flaws or if some good idea for
improvements pops-up. After that do the last corrections and bump the
version number to 1.0 (beta) and then we pray that someone finds the
time and motivation to do the programming :-).