[Vorbis-dev] Mapping = 1 Ambisonic Vorbis flag

[Oliver Oli]

Hello Sampo!

I fully support your view. Although I think someone who knows more
about Vorbis has to make a proposal on how to apply the OggPCM channel
mapping to Vorbis, otherwise it will not happen.

Until then the only simple proposal we have is to define two static
channel mappings, one for horizontal-only and one for mixed-order/full
B-Format.

horizontal:
3: WXY
5: WXYUV
7: WXYUVPQ
9: WXYUVPQ 4,4 4,-4
11: WXYUVPQ 5,5 5,-5
...
255:

mixed/full:
4: WXYz
6: WXYzUV
9: WXYzUVstr
8: WXYzUVPQ
11: WXYzUVstrPQ
16: WXYzUVstrPQnolmk
...
225:

I don't think we can make it any simpler, but suggestions are welcome...

But I would prefer a more flexible mapping like OggPCM. Not to map
overly complex stuff, but for simple things as B-Format plus center
channel for movies.

On Fri, Sep 12, 2008 at 2:52 AM, Sampo Syreeni <decoy at iki.fi> wrote:
> On 2008-09-11, Oliver Oli wrote:
>
>>> 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.
>>
>> I have to agree. Sometimes it's hard to see the obvious and simple
>> solution.
>
> First of all, I do *not* want to get in the way of a simple, easily adopted
> solution. Even if such economies shoot down every bit of clue I've
> exhibited.
>
> But I still have to note that the above reasoning falls short of the
> relevant practicalities. Second, even if you would like to do mixed setups
> using multiple Ogg streams, you would still need some way of indicating what
> each of those streams mean. Currently the only comprehensive way to indicate
> something like that is OggPCM channel maps, or some of their subsets.
>
> Third, Richard Lee's argument about ambisonic channel metadata carries over
> to channel semantics in general: you need to know what each channel means
> from the word go, so channel mappings need to be present in the codec
> initialisation headers, and not, say, in Skeleton. Otherwise we're going to
> experience delay before the channels can be played properly, which isn't
> going to be appreciated by the better part of people who are used to fast
> synch in DVDs, big screen movies, and indeed the other container formats.
>
> And fourth, carrying parts of a single multichannel soundtrack in different
> Ogg streams seems dubious to me. After all, a multichannel soundtrack is an
> indivisible whole: if we exclude a given channel, that'd usually mean that
> in the mastering stage the whole thing would have to be rethough. That is, a
> multichannel audio stream is *fundamentally* an integral unit; you cannot
> just treat any piece of it as separate from the whole. If you then encode it
> as multiple separate streams, you just invite a slew of compatibility
> issues; especially since inter-stream binds via Skeleton or similar metadata
> are mostly optional in the Ogg container design.
>
> So, while I *do* undertand (and perhaps even support) the idea that the
> ambisonic mapping in Vorbis should be as simple as possible, I *still* think
> the above reasoning for it is gravely mistaken.
> --
> Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
> +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
>