Re: [codec] Comments on draft-ietf-codec-ambisonics-01

["Timothy B. Terriberry" <[e-mail]>]

Jean-Marc Valin wrote:
> For family 3, if you already have a Cx(N+M) weight matrix, then the
> mapping table becomes completely redundant.

I think the issue boils down to whether it's worth it to have a table of 
size C to allow a matrix of size Kx(N+M) instead of Cx(N+M) in the 
headers where D is some number smaller than C (probably D=N+M). If more 
than 80% of your matrix is filled with zeros (100 out of 121 rows for 
10th order with only horizontal channels), that could be seen as a 
little wasteful.

That said, we very intentionally chose the direction of the channel 
mapping table for RFC 7845: one value per output channel that says which 
decoded channel to use. That makes it impossible to send multiple 
decoded channels (mixed channels after multiplying by the weight matrix 
in this draft) to the same speaker (ACN number in this draft). As Mark 
Harris points out, this is a failure case the current draft doesn't 
specify how to deal with. By doing the mapping in the same direction as 
RFC 7845, the worst failure case is that someone specifies a channel 
index larger than what's actually available, but that's easily 
detectable (i.e., you can tell without having to look at any other 
values in the mapping table). You also don't need to handle the diegetic 
channels separately. There is a special case for silent channels, but as 
a benefit it become easy (O(1)) to tell if a channel isn't used.

Having the mapping work in this direction would also be more consistent 
with Channel Mapping Family 2.