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).
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
