Multichannel Channel Order Options

[xslig]

I've found that the option "--channel-order=" only works with raw PCM.

I had a 5 channel WAV (FL,FR,LFE,BL,BR) that I encoded. I then used "wvunpack -s foo.wv" and got back "channels: 5 (unassigned speakers)"

I wanted to have the channels assigned so

CODE

wavpack --channel-order=FL,FR,LFE,BL,BR foo.wav

and got back "this WAV file already has channel order information!"

I converted the WAV to raw PCM then

CODE

wavpack --channel-order=FL,FR,LFE,BL,BR foo.raw --raw-pcm=48000,24,5

which worked.

Is the option "--channel-order=" supposed to work like this?
I would think it's counter-intuitive that one couldn't change the channel order of a WAV file with the "--channel-order=" option.

---
Edit:

It was actually a WAVEX if that makes any difference.

This post has been edited by xslig: Dec 12 2011, 22:37

[bryant]

I agree that having SoX unconditionally write a "best guess" for the dwChannelMask field is sub-optimal, and I suggested as much when I submitted the patch in this sox-devel mailing list thread.

But I still believe that this is better than writing zero because zero does not mean unknown as some are suggesting; zero means undefined and is just as definitive (and just as much a guess) as a non-zero value. This is why some programs (like Foobar2000) refuse to play files with a zero channel mask (at least it did at that time). I think that for the vast majority of users having a logical value in that field is better than zero, and the users who require zero there are probably more sophisticated and able to get around any issues generated.

Microsoft:

Having nChannels exceed the number of bits set in dwChannelMask can produce inconsistent results and should be avoided if possible.

[Gumboot]

zero does not mean unknown as some are suggesting; zero means undefined and is just as definitive (and just as much a guess) as a non-zero value.

How is this semantic distinction a step forward?

Should nChannels exceed the number of bits set in dwChannelMask, then the remaining channels are not assigned to any particular speaker location. An audio device would render the remaining channel data to output ports not in use.

We have it there that a file with dwChannelMask=0 has no channels assigned to any particular speaker location. Not that those channels fall outside of the set of known channels. It is quite emphatically a lack of information.

The claim that "this WAV file already has channel order information" is baffling to me. After reconsidering I did wonder if --channel-order is an instruction for the output, rather than the input, and that when used it will find each channel by its name in the input and then put it in that order in the encoded file, but that would be a different error.


Microsoft:

Having nChannels exceed the number of bits set in dwChannelMask can produce inconsistent results and should be avoided if possible.

I could only repeat my previous response to that quote.