Re: [codec] Benjamin Kaduk's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Mon, Aug 06, 2018 at 07:43:30PM +0200, Jan Skoglund wrote:
> Thanks for the comments! Our responses are inline below. A new version of
> the draft has been uploaded.
> 
> Cheers,
> Jan
> 
> 
> > I see that Section 5.2 attempts to Update RFC 7845 to allow for the larger
> > channel mapping information used by family 3, but I'm still a little
> > unclear about what behavior I should expect from a pure RFC 7845
> > implementation that receives a family 3 stream.  The actual mapping table
> > would be "too long", but would the implementation detect that, or just note
> > that it's an unrecognized family and generate silence?
> >
> 
> This is the reason the changes below to 7845 are necessary. I.e., not
> interpreting as channel mapping family 255, and instead “A
> demuxer implementation encountering a 'channel mapping family'
> value that it does not recognize SHOULD NOT attempt to decode the
> packets“
> I think that, depending on implementation, an old decoder would interpret a
> Q15 value as an index and either, most likely, decide the value to be
> invalid and not decode, or, if the index is lower-valued, decode the
> streams according to the old rule
> “If 'index' is less than 2*M, the output MUST be taken from
> decoding stream ('index'/2) as stereo and selecting the left
> channel if 'index' is even, and the right channel if 'index' is
> odd. If 'index' is 2*M or larger, but less than 255, the output
> MUST be taken from decoding stream ('index' - M) as mono. If
> 'index' is 255, the corresponding output channel MUST contain
> pure silence”
> So, it would either decode and play an unintended mixing, or not produce
> audio at all.

Did you consider adding some text describing this situation to the
document?  I guess it is not strictly required from a protocol description
point of view, but would probably save readers some effort, when aggregated
over time.

> 
> 
> 
> > Section 1
> >
> > I think we want to say "by adding itesm with values 2 and 3" to the
> > registry, since we add two entries and not a single superposed entry.
> >
> 
> Changed.
> 
> 
> > Section 3.1
> >
> > While I can deduce this from the list of allowed numbers of channels,
> > noting that both ends of the range (0 and 14) are allowed values probably
> > would add clarity.
> >
> 
> It is now written as ”n = 0, 1, …, 14” , which we feel that most readers
> will interpret such that all integers in the given range, including 0 and
> 14, are valid.
> 
> 
> > Section 3.2
> >
> > Figure 3 could perhaps make it more clear that C and K are not necessarily
> > equal.
> >
> >
> We feel it's sufficiently clear in the figure, since the endpoints of the
> vectors, and the rows and columns have specifically differently named
> values (C and K). Added a mention in the paragraph.
> 
> 
> > The term "side information" is used without definition (and is not used in
> > RFC 7845).  Does this clause really add anything in comparison to if we
> > just say "The matrix MUST be provided in the channel mapping table portion
> > of the identification header, in place of a normal channel mapping table"?
> >
> >
> Changed.
> 
> 
> > Section 5.1
> >
> > Family 255 is specified in Section 5.1.1.3 of RFC 7845, not 5.1.1.4.
> > (Also, the unqualified Section references should probably all be of the
> > form Section N of RFC 7845, for the benefift of the HTML linkification
> > tooling.)
> >
> 
> Changed.
> 
> 
> > Section 8
> >
> > Sometimes I see a "Description" column that allows for in-registry
> > visibility that a range is for experimental usage.  I suppose it would not
> > be too hard to also modify the registry structure to add such a thing, if
> > you want.
> >
> >
> Perhaps, but I’m afraid I wouldn’t know how to do that:)

We can help you out if you do want to go down that route, but I don't think
anyone is insisting on it :)

Thanks,

Benjamin