Well, for family 2 is makes sense to have just a mapping table (1-D array of size C) and no matrix. Note that in previous comments, I was using the term "permutation matrix" only in the sense that the 1-D array is mathematically equivalent to a (sparse) permutation matrix.
For family 3, if you already have a Cx(N+M) weight matrix, then the
mapping table becomes completely redundant.
Jean-Marc
On 13/03/17 06:25 PM, Jan Skoglund wrote:
> Ha, sorry, wrong name! I meant avoiding permutation matrices.
>
> Jan
>
> On Mon, Mar 13, 2017 at 3:19 PM Jean-Marc Valin <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 13/03/17 06:17 PM, Jan Skoglund wrote:
> > Our idea was to avoid a mapping table, potentially sparse, completely
> > for family 2, and replacing it with a channel numbering list for
> family 3.
>
> Can you explain what you mean here by "avoid a mapping table" for family
> 2 and "channel numbering list" for family 3?
>
> Jean-Marc
>
> > Cheers,
> > Jan
> >
> > On Mon, Mar 13, 2017 at 3:12 PM Jean-Marc Valin
> <[email protected] <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>> wrote:
> >
> > On 13/03/17 06:04 PM, Drew Allen wrote:
> > > so just to be clear, if a user, say, wants to encode some
> mixed order
> > > ambisonics using ch253, how does the decoder know what ambisonic
> > > channels it has received and know how to render them correctly?
> >
> > Well, each line of the matrix would correspond to a channel in the
> > ambisonics channel order. If that channel isn't encoded, then
> the line
> > would have only zeros.
> >
> > The only way to avoid that situations would be to encode a
> separate D
> > value (D <= C) for the number of non-zero channels among the C
> > ambisonics channels possible. Then you'd store C values in the
> channel
> > mapping array (equivalent to a CxD permutation matrix),
> followed by a
> > Dx(M+N) weight matrix that would no longer have entire lines
> of zeros.
> > The result would be more compact in the case of sparse
> representation,
> > but IMO it'd be pretty ugly and prone to implementation
> errors. And if
> > you force D==C and don't code the D (which is what I'm
> proposing), then
> > the channel mapping permutation automatically becomes redundant.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> > > On Mon, Mar 13, 2017 at 3:00 PM Drew Allen
> <[email protected] <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>
> > > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>> wrote:
> > >
> > > Got it. In that case, it certainly seems reasonable if I
> > understand
> > > correctly. Thanks for clearing that up!
> > >
> > > On Mon, Mar 13, 2017 at 2:55 PM Jean-Marc Valin
> > <[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>> wrote:
> > >
> > > On 13/03/17 05:44 PM, Drew Allen wrote:
> > > > I think the issue is that the number of total
> channels rises
> > > > quadratically in respect to the ambisonic order (N +
> > 1)^2. If
> > > a user
> > > > wants to use just the horizontal channels, it is
> only 2
> > * N +
> > > 1. If they
> > > > wish to code very high-order (>10th order) horizontal
> > > channels, they
> > > > would be artifically limited by all the zero
> channels being
> > > produced,
> > > > no? Or can this handled without actually creating
> all those
> > > empty channels?
> > >
> > > As far as I understand, the current draft already
> has all the
> > > limitations you're describing. The channel mapping
> array is
> > > basically
> > > equivalent to a CxC permutation matrix that
> multiplies the
> > Cx(N+M)
> > > weight matrix. The result is still a Cx(N+M) matrix, so
> > using the
> > > resulting matrix as weights can still do everything
> > without the
> > > need for
> > > the channel mapping to do the permutations.
> > >
> > > Cheers,
> > >
> > > Jean-Marc
> > >
> > > > On Mon, Mar 13, 2017 at 2:41 PM Mark Harris
> > > <[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > > > <mailto:[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>> wrote:
> > > >
> > > > On Mon, Mar 13, 2017 at 10:38 AM, Jan Skoglund
> > > <[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > > > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>> wrote:
> > > > > Hey,
> > > > >
> > > > > Thanks for your comments
> > > > >
> > > > > On Mon, Mar 13, 2017 at 10:08 AM Mark Harris
> > > <[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > > > <mailto:[email protected]
> <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>>>>
> > > wrote:
> > > > >>
> > > > >> On Fri, Feb 17, 2017 at 1:57 PM, Jean-Marc
> Valin
> > > > <[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > > <mailto:[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>>
> > > > >> wrote:
> > > > >> > 3.2. Channel Mapping Family 3
> > > > >> >
> > > > >> > I would suggest removing the "Output Channel
> > > Numbering" field
> > > > because it
> > > > >> > is fully equivalent to simply permuting lines
> > of the
> > > matrix.
> > > > Also, I
> > > > >> > believe that the size of the matrix was
> meant to be
> > > "32*(N+M)*C
> > > > bits"
> > > > >> > rather than "32*N*C bits".
> > > > >>
> > > > >> To expand on this a bit, a mapping family
> maps M+N
> > > decoded channels
> > > > >> (corresponding to the actual order of the
> coupled and
> > > uncoupled
> > > > >> channels in the bitstream) to C output channels
> > > (channels with a
> > > > >> specific semantic meaning). The additional
> > "Output Channel
> > > > Numbering"
> > > > >> table confuses things by adding an
> additional mapping
> > > from the output
> > > > >> channel numbers to a different set of
> numbers with
> > > actual semantic
> > > > >> meaning, leaving the output channel numbers
> with no
> > > apparent meaning.
> > > > >>
> > > > >> This does have a potential benefit as a matrix
> > > compression technique,
> > > > >> to reduce the size of the matrix when it would
> > contain
> > > rows that are
> > > > >> all zero. However considering that the
> matrix occurs
> > > only once, and
> > > > >> mapping family 2 already offers a way to
> compress the
> > > matrix, this
> > > > >> alone does not seem worth the complexity of
> another
> > > level of
> > > > >> indirection. If matrix compression is
> desired it
> > would
> > > probably be
> > > > >> less confusing to describe it in those
> terms and keep
> > > the semantic
> > > > >> meaning tied to the output channels.
> > > > >>
> > > > >>
> > > > >> The description of the Output Channel
> Numbering also
> > > does not specify
> > > > >> the intended behavior if the same value appears
> > in the
> > > table multiple
> > > > >> times.
> > > > >>
> > > > >> Additionally, section 4.2 describes how to
> > perform a stereo
> > > > downmix of
> > > > >> mapping family 3, but makes assumptions
> about the
> > > output channel
> > > > >> numbering. This seems harmful and likely
> to promote
> > > implementations
> > > > >> that make similar assumptions. If it is
> necessary to
> > > apply the
> > > > output
> > > > >> channel numbering described in section 3.2 in
> > order to
> > > implement a
> > > > >> correct stereo downmix, then it would be
> better to
> > > simply use the
> > > > >> output channels from section 3 as input to the
> > downmix,
> > > consolidating
> > > > >> sections 4.1 and 4.2, rather than specify new
> > formulas
> > > that make
> > > > >> assumptions about the mapping. That would also
> > greatly
> > > simplify
> > > > >> section 4.
> > > > >>
> > > > >> Eliminating the Output Channel Numbering
> table as
> > > Jean-Marc suggests
> > > > >> should resolve these concerns.
> > > > >
> > > > >
> > > > > The problem is that once we allow mixed orders
> > there is
> > > no unique
> > > > way for a
> > > > > receiver/decoder
> > > > > to resolve the mapping to ACNs from just a
> number of
> > > total output
> > > > channels.
> > > >
> > > >
> > > > In mapping family 2, the channel count (C) is
> the number
> > > of channels
> > > > in the fully periphonic configuration, but it
> is not
> > > necessary to
> > > > encode them all. The channel mapping table
> can map each
> > > ACN to a
> > > > specific decoded channel or to silence. For mixed
> > order,
> > > some of the
> > > > ACNs will be mapped to silence and will not be
> encoded.
> > > >
> > > > In mapping family 3, the matrix can do everything
> > that the
> > > channel
> > > > mapping table can do and more. Why not treat
> C in the
> > > same manner, as
> > > > the number of channels in the fully periphonic
> > > configuration, even if
> > > > some are silent?
> > > >
> > > > - Mark
> > > >
> > > > _______________________________________________
> > > > codec mailing list
> > > > [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>
> > > > https://www.ietf.org/mailman/listinfo/codec
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > codec mailing list
> > > > [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > > > https://www.ietf.org/mailman/listinfo/codec
> > > >
> > >
> >
> >
> >
> > _______________________________________________
> > codec mailing list
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/codec
> >
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
