[Vorbis-dev] Decoding for ambisonic Ogg audiob

[Gregory Maxwell]

On 2/27/07, xiphmont at xiph.org <xiphmont at xiph.org> wrote:
> FWIW, vorbis 'Mapping 0' is what specifies the Dolby-style
> multichannel output maps.  To say 'this doesn't support ambisonics
> mappings' is only partially correct-- that's what I intended 'mapping
> 1' for.  There simply wasn't time to do any work on it before 1.0 as
> the Vorbis project got discovered early and there was a push to
> release the full 1.0 in a timely manner.

Right. I expect mapping 1 to be be used with the coupled ambisonic modes.

  > > I think that some form of downmix support will be an essential feature
> > in the libraries. Most users will not have software or systems which
> > are equipt to play b-format Vorbis files, at least initally. Anyone
> > distributing such files will have a hard time if the files refuse to
> > play at all for people.
>
> There needs to be a distributed 'core' library for this, I agree.  It
> shouldn't be part of libvorbis, but it would have to be part of the
> distribution with libvorbis.

My thought is that existing non-multichannel apps should be able to
play downmixed ambisonic vorbis files simply by being linked against a
newer version of the libraries.  Is this  unreasonable?

Would it be acceptable for libvorbis to have an dependancy on this
libxiphsurround? One which is enabled by default but which can be
disabled by people building libraries for embedded systems which do
not need any compatibility with ambisonic files?

There are a lot of pre-existing applications. Adoption of ambisonic
Vorbis files will be significantly hampered if applications need to be
updated to support the most basic support for the files.

Because these mapping 1 multichannel files will not playback on things
like hardware players, is there any aspect of the Vorbis subset
specification which you believe we should explore breaking, in effect
defing a new vorbis subset for ambisonic audio?

> > A full speaker decoder as well as a binaural decoder will require a
> > user-interface and can't really be done automagically. So I think they
> > should be dropped from consideration as compatibility features for the
> > core libraries.
>
> I think the capability should be there, programmatically, even if a UI
> for setting it up is not.

Reasonable enough if the surround feature set is provided in a second library.