[Vorbis-dev] Mapping = 1 Ambisonic Vorbis flag

[Richard Furse]

Are we saying that something like the excellent OggPCM stuff would be
difficult to implement in Vorbis? This does seem a shame...


That aside, the suggestion below is nicely simple and directly
backwards-compatible, give or take the unusual ordering for the mixed/full
channel cases and the extensions to higher order. Some possible tweaks:

Furse/Malham encoding is only defined to third order, and at higher order I
guess it isn't going to be the standard as it makes more sense to redefine
in a general way from the spherical harmonics - using the FuMa components
here for the lower orders only is entirely possible but ugly. The problem
with redefining now is that we'd lose direct backwards-compatibility and
we'd need to herd the cats long enough to agree which formulation and
normalisation to use; I think this will scare some folk and I'm probably
going to regret mentioning it ;-)

However - either way, and perhaps within the OggPCM formulation, I think it
makes sense to reserve a place-holder for a *separate* higher order
encoding, rather than risking confusion of the FuMa approach. We could
extend the stream type list to
{fuma_horizontal,fuma_mixed/full,hoa_horizontal,hoa_full}. We could add a
hoa_mixed, but it would be messy and I don't think it is likely to be much
used as new synthesisers can render horizontal sounds onto the full
periphonic form and hopefully the compression will do the rest. (In general,
in periphonic form, horizontal sources generate components in Y(L,-L),
Y(L,+L) and, for L even, Y(L,0) - the last case doesn't occur in the
horizontal-only encoding, but in the periphonic form I expect it to compress
nicely as synthetic horizontal Y(L,0) streams will typically be simple
products of each other, give or take NFC etc.)


... but I'd still rather we based with the OggPCM stuff for consistency if
we can. Players delegating to an Ambisonic decoder library of some kind
would probably be hoping to have data from either OggPCM or Vorbis in
roughly the same format?


Incidentally, was it Gregory looking at the actual Vorbis channel coupling?
I'd be really interested to find out what's going on in there and to help
out if I can. Let me know if there's anything I can do...


Best wishes,

--Richard

> -----Original Message-----
> From: vorbis-dev-bounces at xiph.org 
> [mailto:vorbis-dev-bounces at xiph.org] On Behalf Of Oliver Oli
> Sent: 12 September 2008 15:56
> To: Sampo Syreeni
> Cc: Vorbis
> Subject: Re: [Vorbis-dev] Mapping = 1 Ambisonic Vorbis flag
> 
> 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
> >
> _______________________________________________
> Vorbis-dev mailing list
> Vorbis-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/vorbis-dev
>