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]

It was actually a WAVEX if that makes any difference.

Yeah, actually that does make a difference. It turns out that the original intent of the --channel-order option was to specify the channel order when it was unknown, either in the case of a raw file (which you discovered) or the case of a WAV file that does not have the extensible header. For WAV files with the extensible header, the assumption was that the channel order was well defined (almost the whole point of having that header was to supply exactly that info). It would seem that your WAVEX files do, in fact, specify unassigned channels (SoX files, for instance, appeared like this until a fix that I contributed).

Since this has come up a couple times, my plan for the next revision is to allow some option to override the channel order...perhaps a new option --force-channel-order. In the meantime, you should be able to use raw files or simply not write the WAVEX header (or, of course, have a WAVEX header that correctly specifies the channels).

Hope this helps and thanks!

David

[Gumboot]

It would seem that your WAVEX files do, in fact, specify unassigned channels (SoX files, for instance, appeared like this until a fix that I contributed).

Since this has come up a couple times, my plan for the next revision is to allow some option to override the channel order...perhaps a new option --force-channel-order.

Surely the error here is in taking the non-information supplied by the file as authoritative. If the file says it doesn't know then why not let the user fill that in?