[Vorbis-dev] Mapping = 1 Ambisonic Vorbis flag

[Richard Lee]

>> When we start distributing 4th order stuff (which requires >16 speakers) we can get around this by having missing channels simply silent.  Vorbis compression is very efficient at coding silence.  Thanks to Gregory Maxwell for this excellent suggestion on the sursound forum.

>Fons killed that proposal already on the sursound list. The Ambisonics decoder have to be setup before the playback starts. 

For higher orders, Gregory's scheme, has silent channels.  The player would need to look at the first sec. or so to determine the order for horizontal and vertical.

By the time we need higher orders, the decoders will need to be so complex that allocating buffers and then freeing them would be trivial.

Before this happens, we also need a new professional format which is likely completely different from the present one.

In the meantime, I'm very much against repeating info at different places and in different form.  This always begs the question of what does the player do if the info conflicts.  And many applications will cheat and/or get one wrong.

>> This can stay in Ogg.  It is a VERY bad idea to have with Vorbis Ambi (Mapping = 1)  They are fundamentally VERY different in their approach.

> Are we sure we know what we are talking about? What is Ogg, what is Vorbis and what OggPCM?

> I don't see any reason why a flexible universal channel mapping approach is a VERY bad idea. Just don't call it Ambisonics channel mapping. There are hybrid formats, how could you describe these with a simplistic Ambisonics-only channel mapping? I'm thinking of B+ Format (Ambisonics + Stereo) or maybe WXY(Z) plus a center channel and optional LFE as a 5.1 alternative.

As I understand it, Ogg is a container and may have several streams eg Video, vorbis sound, FLAC sound, subtitles, karaoke etc.

The sensible way to do mixed modes like Ambi with dedicated CF speaker channel is to have the extra channel and its metadata in a separate Ogg stream.  This way, Vorbis Ambi & AmbiDecLib have a clean interface and only deal with Ambi type signals.

Making Ambi Vorbis cater for these will seriously complicate the decoder and its API which we are attempting to simplify.

If Monty grants us bit1 rather than Mapping = 1, we can ask for more bits later.

Don't want to be too greedy and ask for the full OggPCM channel mapping, especially as none of it is necessary at present.