[Vorbis-dev] Ambisonics Proposal summary.
edeleflie at gmail.com
Tue Sep 30 00:01:01 PDT 2008
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
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
>> - 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.
More information about the Vorbis-dev