On Wed, Jan 5, 2011 at 1:07 PM, David Bryant <david@...> wrote:
> Hi Chris,
> Chris Bagwell wrote:
>> On Tue, Jan 4, 2011 at 10:26 PM, David Bryant <david@...> wrote:
>>> A couple times in the past I have received e-mail from WavPack users who
>>> were having trouble encoding 24-bit wav files written by SoX. The problem
>>> turned out to be that when SoX creates wav files with the extensible wav
>>> header it unconditionally sets the dwChannelMask field to zero, which
>>> implies all channels are unassigned, even in the case of a 1 or 2 channel
>>> Strictly speaking, this is not a problem for WavPack, but it does mean that
>>> WavPack will put each channel into its own mono stream (instead of combining
>>> them into a single stereo stream), and some versions of the WavPack decoder
>>> (like the one in Rockbox) will not correctly handle multiple-stream WavPack
>>> files (because they can take more memory to decode).
>>> Setting the channel mask to zero causes problems with other programs as
>>> well, for example Foobar2000 refuses to play them.
>>> I could not find discussion of this issue anywhere, so I decided to just
>>> provide a quick patch to set the channel mask to reasonable values for
>>> common channel counts (1, 2, 4, 6, and 8). It's possible to argue that
>>> unless the channel configuration is actually known for certain, then a
>>> channel mask of zero is safest, and it's also true that a real solution
>>> would allow the channel configuration to pass through SoX from input to
>>> output. However, I feel that for the overwhelming majority of cases, this
>>> solution will provide the user with the most usable result.
>> If I recall correctly, 24-bit support was partially driven by
>> Foobar2000 users liking that format. So for sure we should try to
>> accommodate that application. I do not personally use Foobar2000 so
>> I'll trust your indication of issue.
>> I recall talking briefly about topic way back and seemed like sample
>> applications at the time were OK with but we understood basic issue
>> could occur.
>> The patch seems reasonable to me so I'll commit soon.
>> Perhaps longer term we might have a Ogg-like tag "ChannelMask=0xff".
>> This is only way sox passes meta data between formats right now (see
>> vorbis.c and mp3.c) for most part and would allow the channel mask to
>> be passed from input file to output file... And user can pass in
>> options using --add-comment syntax.
> Obviously you are far more familiar with the design and philosophy of
> SoX than I, but I would suggest that the longer-term solution would be
> to put the channel assignment information right in the sox_signalinfo
> struct. I feel that the channel assignment is as fundamental to the
> signal as the number of channels and the sampling rate (or nearly so).
Making it part of structure is probably more memory efficient way. I
was thinking about keeping a fixed mapping for internal buffers and
filling in null channels for unused channels in hopes that simpler
file format handlers wouldn't have to understand channel map concepts.
But its just a quick thought.
Whom ever writes the patch first will most likely win. :-)
>> Thanks again for all the patches!
> No problem...I am very happy to be able to contribute!
OK, all three patches now submitted. Thanks again.