IPB

Welcome Guest ( Log In | Register )

Multichannel Channel Order
xslig
post Dec 12 2011, 22:21
Post #1





Group: Members
Posts: 20
Joined: 29-September 11
Member No.: 94046



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
Go to the top of the page
+Quote Post
 
Start new topic
Replies
bryant
post Dec 13 2011, 21:43
Post #2


WavPack Developer


Group: Developer (Donating)
Posts: 1292
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



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.

Go to the top of the page
+Quote Post
Gumboot
post Dec 13 2011, 22:26
Post #3





Group: Members
Posts: 51
Joined: 11-December 11
From: United Kingdom
Member No.: 95728



QUOTE (bryant @ Dec 13 2011, 20:43) *
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.


I could only repeat my previous response to that quote.
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd October 2014 - 09:16