Re: [codec] Ambisonics in an Ogg Opus Container

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

Michael Graczyk wrote:
> https://datatracker.ietf.org/doc/draft-graczyk-codec-ambisonics/

Thanks for presenting this document to the group.

With my chair hat on: I think it would be helpful for us to gage the 
level of interest if people would comment on the list if they think this 
is something useful for this group to work on.

As an individual, I had a few comments on the draft:

> The Ogg format is a container for transmission and storage of audio.

Ogg is a general purpose container, supporting audio, video, subtitles, 
etc. (though its most common use in current applications is for audio).

I think it may be useful to say that this channel mapping number will 
also likely impact other formats which use the same channel mapping 
families, e.g., Maktroska, MP4, MPEG TS. Just adding a sentence to the 
introduction along the lines of, "This mapping can also be used in other 
contexts which make use of the channel mappings defined by the Opus 
Channel Mapping Families registry."

> Allowed numbers of channels: (1 + n)^2 for n = 0...14.  Explicitly 4,
> 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, 225.

For n = 0, (1 + n)^2 == 1, but that's not on your explicit list. Was the 
intention here to exclude mono as redundant with other channel mapping 
families? We didn't do that for channel mapping family 1 (since, for 
example, the presence of an explicit channel mapping table allows you to 
extract a single channel from an already-encoded coupled stream, which 
is not possible with channel mapping family 0). But if you did intend to 
exclude mono, you should explicitly say why, and adjust the range of n.

> sqrt((2 - delta(m)) * ((n - m)! / (n + m)!)),

I've read the [ambix] reference before, and it still took me a while to 
figure out what this normalization coefficient is actually referring to. 
It might be useful to say in more detail what "normalization" even 
means: is this a factor you are expecting encoders to apply to the audio 
before encoding? Are you defining what decoders will apply during 
reconstruction? The coefficient in general seems highly dependent on how 
you express the spherical harmonic basis functions. E.g., part of this 
just comes from the Legendre polynomials, which could have simply been 
expressed by saying to use Legendre polynomials with unit norm (under 
some norm).

It may be better to simply refer to [ambix] Section 2.1, equation (1) 
for the definition of the spherical harmonics basis functions (the 
explicit section/equation makes it easy to find), and leave out this 
equation entirely. Conversely, it would be reasonable to spell out the 
full equation for those basis functions in this document (to make it 
more self-contained). But this kind of sits in-between, where it looks 
like it's trying to say something that you can understand on its own, 
but in fact it's impossible to interpret outside of the context of that 
reference (which already says it).

> Figure 1: Stereo Downmixing Matrix

I doubt this will really cause confusion, but you don't define W and Y. 
You might want to say they correspond to the first two ambisonics 
channels, explicitly.

> Updates: 7845 (if approved)

Does this actually update RFC7845? I think the intent was to allow 
updates to the channel mapping registry to be done without an explicit 
update of 7845, since it's possible it might not even be done with an 
IETF RFC (e.g., if there were some broadcast-specific standard done at a 
different standards body).