Vorbis dev - Sep 2008 - Ambisonia proposal

> 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.
> It is indeed related. We are proposing a different ambisonic channel scheme
(not speaker mapping though) called N3D (different to the usual FuMa scheme).
The N3D scheme has a number of 'future proof' advantages, including no
extra header info required and support for Higher Orders (up to 6th and beyond).
It is also believed that the N3D scheme is more compatible with Vorbis
compression.
We are asking only for

- Mapping = 1 

- some help in adapting the present Vorbis Lossless Stereo Coupling to a
multi-channel file with highly correlated channels.

- the Vorbis decoder to have a simple default stereo decode of an Ambi file for
simple stereo players.
> Then, there's also the Ambisonics page at the Xiph Wiki[2], which I
recommend interested parties to check.
[2] http://wiki.xiph.org/index.php/Ambisonics

Unfortunately, this page has a lot of obfuscating info, some of it mine copied
(by Gregory Maxwell) from our discussions about a year ago when Monty confirmed
that Mapping = 1 was reserved for Ambisonics.

I should get rid of the confusing stuff which is no longer applicable.  But
I'm on a slow line and editing Wiki pages is both expensive and frustrating
for me.
> 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
horizonal 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.

We believe the scheme we propose will slot into Vorbis with little or no fuss
and provide immediate and long term enhancements for surround sound.

An Ambisonic Decoder Library is also in preparation but this is optional.  It
includes sophisticate stereo decoding facilities.

But a simple stereo player can just use the default stereo decode in the Vorbis
decoder.

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.524 / Virus Database: 268.0.0/1688 - Release Date: 24/09/08 6:29

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 :-).