Vorbis dev - Oct 2008 - Vorbis, ambisonics and 'Vorbis Tools'

All,

Progress has been made on the proposed draft spec for integrating
ambisonics into vorbis. We are not yet finished (should be soon), but
you can see the progress here:

http://docs.google.com/Doc?id=df4dtw69_3626qqq6st

The issue we have hit now concerns how/who would implement the
encoding and decoding in Vorbis Tools. Because ambisonics uses
spherical harmonic components, an ambisonic file could contain
anything from 3 channels up to (potentially) 16 and more channels.
Both encoding and decoding would then be error prone to getting the
right channels in the right place with the right metadata.

My question is, how should we approach Vorbis Tools ... would the
ambisonics community write their own encoding tools? ... does Vorbis
Tools *have* to contain support for ambisonics? Would the ambisonics
community write code to roll into Vorbis tools? Should we spec this
out, or leave it to the better intuition of the vorbis devs?

In the draft spec, we have begun specing this out in Section 1.7 ...
but some of our members feel strongly that this should not be in
there.

Etienne

On Tue, Oct 28, 2008 at 7:49 AM, e deleflie <edeleflie at gmail.com>
wrote:
> Progress has been made on the proposed draft spec for integrating
> ambisonics into vorbis. We are not yet finished (should be soon), but
> you can see the progress here:
>
> http://docs.google.com/Doc?id=df4dtw69_3626qqq6st
Note that I'm responding before reading the above... I need too, just
daon't have the spare cycles to concentrate on it now :-(
> The issue we have hit now concerns how/who would implement the
> encoding and decoding in Vorbis Tools. Because ambisonics uses
> spherical harmonic components, an ambisonic file could contain
> anything from 3 channels up to (potentially) 16 and more channels.
> Both encoding and decoding would then be error prone to getting the
> right channels in the right place with the right metadata.
>
> My question is, how should we approach Vorbis Tools ... would the
> ambisonics community write their own encoding tools? ... does Vorbis
> Tools *have* to contain support for ambisonics? Would the ambisonics
> community write code to roll into Vorbis tools? Should we spec this
> out, or leave it to the better intuition of the vorbis devs?
This is actually something I want to tackle myself.  And my instinct
is that I would like first class support for Ambisonics across the
Vorbis toolchain.  Ambisonics is where my professional life and
hobbies meet, so I look forward to having some time to really get lost
in it :-(

Assuming I ever get to do that.  Uninterrupted thinking time is always
the rub these days.

Nor do I mean to imply I want to 'take this over', just that I want to
fully lend my own shoulders to pushing ahead.
> In the draft spec, we have begun specing this out in Section 1.7 ...
> but some of our members feel strongly that this should not be in
> there.
I'll have to go read it. :%)

Monty

> Nor do I mean to imply I want to 'take this over', just that I want
to
fully lend my own shoulders to pushing ahead.

Monty,  one missing item which is entirely within your province and would 
benefit other areas or Vorbis is Multichannel Coupling.

Ambi would benefit the most from good Multichannel Coupling cos the high 
amount of correlation between channels for direct sounds.  (Diffuse fields 
are, by definition, uncorrelated)

Even the schemes used by Dolby Digital, MLP and probably AAC would give 
substantial efficiencies.

On Tue, Oct 28, 2008 at 12:49 PM, e deleflie <edeleflie at gmail.com>
wrote:
> All,
>
> Progress has been made on the proposed draft spec for integrating
> ambisonics into vorbis. We are not yet finished (should be soon), but
> you can see the progress here:
>
> http://docs.google.com/Doc?id=df4dtw69_3626qqq6st
> In the draft spec, we have begun specing this out in Section 1.7 ...
> but some of our members feel strongly that this should not be in
> there.
I would also remove it. It's not important that you cover the command
line tools (IMHO) and it doesn't influence the Vorbis format in any
way. Besides that it seems that not much work went into that part of
the document. The proposed command line options are not compatible
with getopt and inconsistent with oggenc's command line options. Also
you completely ignoring the HVP scheme you introduced in 1.3.

1.6 is also problematic. The URL comment field has nothing to do with
Ambisonics, the AMBISONICFORMAT is not specified at all. I would
remove that, this could be specified later, if it's really needed.

1.8 (streaming) is not needed. Ogg/Vorbis was created as a streamable
format and I cannot imagine that anyone wants to introduce changes
that prevents streaming.

The Appendix talks about H and P only and not about HVP. Also it would
be helpful, if there is some explanation what H, V and P order means
exactly.

The component names in the Appendix are not needed. There is no
agreement on how to name the components and it is not needed for the
Vorbis spec.