Hey, Thanks for the comments!
> You say the mixing matrix is "stored column-wise." I assume this means > the order of the coefficients in the file is D11, D21, ..., DC1, D12, > D22, ..., D1K, D2K, ..., DCK. Is that correct? Since matrix > representation conventions vary, I suggest being more explicit here, > perhaps by listing a few coefficients in figure 4. > Changed to the more prevalent notion "column-major order" As you note at the end of section 3.2, the identification header must > fit within a single page as described the Ogg Opus RFC 7845. This is > also in the Ogg Format RFC 3533 (section 4, third paragraph). Violating > this constraint will definitely cause interoperability problems. I'd > like to see the language about this strengthened to a MUST limit on the > packet size and some guidance given about maximum order and channel > indexes for common configurations. Section 3.3 should be updated to > mention this as well. It would be an easy thing for implementors to > overlook. > Section 3,2 changed to MUST for 12th order, if full order is used. This is also repeated in Section 3.3. > However, the RFC 7845 channel mapping table is only 'C' octets long, the > length of half a row of the mixing matrix. It seems to me encoders could > insert a compatibility table before the matrix coefficients without > adding much to the encapsulation overhead or limiting the mixing options > much. Was this considered by the working group? > This has not been considered. The structure proposed in the draft has been implemented into Opus. > I don't see an Implementation Status section (as recommended by RFC > 6982). Are there multiple implementations of this draft? Test vectors? > > This draft has been implemented and is fully available in the official Opus repository. An experimental flag was recently removed. No specific test vectors have been produced. Cheers, Jan
_______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec
