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).

Yeah, sox was better off using 0. If someone's going to make an assumption, it's better that the player does it rather than having false information committed to file, and forcing everybody else to learn to ignore it so that the field is consequently overloaded to be meaningless.

Its current behaviour has been a huge pain in the arse for me. It's taken files which had non-standard (Dolby) channel ordering and imposed an incorrect channel map on them, and I've had to manually zero that field to get correct the behaviour at the next stage.

KSAUDIO_SPEAKER_DIRECTOUT represents a configuration with no speakers and is defined in Ksmedia.h as zero. [...] For example, channels 0 through 30 might contain, respectively, drums, guitar, bass, voice, and so on. For this kind of raw audio data, speaker positions are meaningless, and assigning speaker positions to the input or output streams could cause a component such as KMixer to intervene inappropriately by performing an unwanted format conversion. If a device is unable to process the raw audio streams, it should reject a request to change its speaker configuration to KSAUDIO_SPEAKER_DIRECTOUT.

The best option is to write correct channel map; however, SoX doesn't read it from a source file. The only thing that this program can do is to write some arbitrary value (e.g. 0 or 0x3F) to the dwChannelMask field.

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:

QUOTE

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

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?

QUOTE (Microsoft)

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:

QUOTE

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

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.

It's only semantics, but I would disagree with this interpretation of the Microsoft docs. I think that a value of zero does specifically indicate that the channels fall outside the set of known channels. And the specs indicate that the known channels must appear in the prescribed order, so you can't use zero just to indicate "not in the MS order".

QUOTE

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.

It is an instruction for interpreting the input when it is not unambiguously defined. If the order specified in the option is identical to the Microsoft order, then the option only determines the channel mask, but if the order specified is different then the channels will be reordered in the stream. This is actually kind of handy for reformatting files; you can pipe raw audio (or WAV without WAVEX) into wavpack with the --channel-order option and then pipe that into wvunpack to create a valid WAVEX file with the correct channel order and mask.

Wow, when it comes to interpretation of spec written by English, it's too difficult to me.

QUOTE

A dwChannelMask of 0 tells the audio device to render the first channel to the first port on the device, the second channel to the second port on the device, and so on.

To me, it looks like saying that as long as the same audio device and same configuration is in use, the result of dwChannelMask of 0 is completely deterministic, and it will be rendered/mapped in the device port order. However,

QUOTE

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

This is inconsistent because wave file itself doesn't define the asignment, but asignment is defined by the device configuration (in other word, it's device dependent).I don't know if this can be said channel layout/asignment is defined or not.

Anyway, Windows Media Player, foobar2000, winamp seems to treat wave files with dwChannelMask 0 by it's implicit default order (probably exactly the same way as if it were not WAVEFORMATEXTENSIBLE).6 channel wav seems to be interpreted as FL FR FC FLE BL BR by them.