[Vorbis-dev] Ambisonics Proposal summary.

[e deleflie]

thanks Monty,

The critical 'bottle-neck' from the proposal's point of view is how to
ensure inclusion of higher order ambisonics in the channel scheme.

What we have come up with only requires mapping = 1, but has some (we
think minor) limitations. I will take your feedback to the ambisonics
google group and report back when/if we have come up with a simpler
scheme.

Etienne

On Tue, Sep 30, 2008 at 4:21 PM,  <xiphmont at xiph.org> wrote:
> Hm, I guess I'm going to have to finally finish all those monopole monitors...
>
>> To clarify. This is what the spec proposes:
>>
>> - that Mapping = 1 means the contents are ambisonic
>
> That's fine, and also means that decoders that are not at all
> ambisonic aware would reject the stream (I'd assume that's desirable).
>
>> - that the Vorbis encoder/decoder includes a quality stereo decode of
>> ambisonic streams (for ambisonic ignorant players)
>
> Whether the decoding functionality belongs inside libvorbis or not is
> a seperate issue (eg, we'd like the same code to work for Ghost), but
> it's essential the functionality is a) integrated and b) shipped as
> part of core.  Only an engineer should care about the distinction, it
> must Just Work for listeners.  No arguments there.
>
>> - some means for players to be able to tell the Vorbis encoder/decoder
>> whether they want the stereo decode, or the untouched ambisonic
>> streams
>
> Right.
>
>> - some help in adapting the present Vorbis Lossless Stereo Coupling to
>> a multi-channel file with highly correlated channels
>
> ...this is the real work.  A new coupling mechanism may be required (I
> seem to recall that Ambisonics is *very* touchy about phase
> information) and if it is, Mapping 1 would give us the needed hooks to
> do something entirely new if the old coupling mechanism is too far
> from optimal.
>
>> And what we would like to clarify is:
>>
>> - do we have any access to _other_ header metadata which might allow
>> us to offer a simpler channel map (or are we limited to Mapping = 1?)
>
> There's plenty of 'reserved' field territory in the headers if need
> be.  However, mapping 1 is not actually any easier or harder than the
> other options.  And, there's pleanty of ability to add
> ambisonic-specific data to the decode header.  There's no need to use
> tags if we don't want to; in fact, some players/restreamers ignore,
> strip or munge the tags anyway.
>
> Nor is mapping 1 required to add decode data for ambisonics elsewhere
> in the header.
>
>> Lastly, and optionally:
>>
>> - we would ideally like to include a "producer's suggestion for best
>> stereo decode". This would be in the form of angle/azimuth for the 3
>> axis  ... and would act as a 'hint' for ambisonic aware players to
>> offer a stereo decode recommended by the producer. (this kind of thing
>> is really leveraging the power of ambisonics).
>>
>> We originally thought that this could be done in the comment headers,
>> but it has been suggested that this would not be an appropriate place
>> to put this.
>
> Not so much 'inappropriate' (as anyone who knows about ambisonics
> might actually want to know some of this data) but perhaps 'error
> prone'.  We've encouraged implementors to treat the tags as data
> that's inessential to decode and as such it may be best to put truly
> essential data in the setup header to avoid accidents.
>
> Monty
>