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

[nu774]

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

I had the very same assumption before. However, since dwChannelMask of 0 looks like legal, I had to fix my program to allow it.
http://msdn.microsoft.com/en-us/windows/ha.../gg463006#EMLAC

[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?

[Gumboot]

I had the very same assumption before. However, since dwChannelMask of 0 looks like legal, I had to fix my program to allow it.
http://msdn.microsoft.com/en-us/windows/ha.../gg463006#EMLAC

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.

[lvqcl]

http://msdn.microsoft.com/en-us/windows/ha.../gg463006#ECMAC :

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

http://msdn.microsoft.com/en-us/library/wi...2(v=vs.85).aspx

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.

IMHO current SoX behaviour is preferred: SoX output data are (usually) regular audio files (speech/music/etc), not some raw audio data.

[Gumboot]

Well, then by implication the channel allocation is simultaneously redundant and untrustworthy, because it's not derived from any real knowledge but instead inferred from a convention.

The inconsistency to which the Microsoft documentation refers is precisely the inconsistency you're proposing to make mandatory by writing a guess into an authoritative field.

This post has been edited by Gumboot: Dec 13 2011, 17:54

[lvqcl]

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.

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

[bryant]

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

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.

[nu774]

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

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,

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.

[Gumboot]

I think that a value of zero does specifically indicate that the channels fall outside the set of known channels.

Where's that?

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

Where's that? I see:

The channels that are specified in dwChannelMask should be present in the order shown in the preceding table, beginning at the top.

But, of course, that refers only to those channels that have been specified in dwChannelMask, and when that is zero obviously no channels have that constraint.