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