anyone compiled and tried dcaenc ?

[Selur]

Thanks!
As a side note: Is it just me or do LoRd_MuldeRs binary get smaller and smaller each time? (not that I'm complaining, it's just an observation)

Cu Selur

[geminigod]

I feel privileged to be the first editor who is not a coder to jump in on this conversation and ask the dumb questions! :o

First...:thanks: for all your efforts to compile this and get it working.

I just downloaded Lord Mulder's latest exe, but when I try to have it convert a wave file from CMD using windows 7, I can't seem to get it to work. I have tried multiple wave files with the following usage:

dcaenc -i test.wav -o test.dts -b 1509

Every time I get the message:
"Could not open or parse "test.wav".
Error: Failed to open file!

I have been tracking Patrokov's work on this because I would ideally love to be able to take a 6 channel w64 audio track I have made and use DTS instead of Dolby Digital for blu-ray. Any thoughts?

[dj_doc]

geminigod try to pass your file through sox.

[geminigod]

I downloaded sox. Now I just need to figure out how to use it! Any advice on command line usage? What will take you a minute to explain will probably take me hours to figure out the proper syntax.

[LoRd_MuldeR]

Your syntax looks correct to me.

Error: Failed to open file!

This indicates the file could not be opened for reading at all. It failed before even "looking" at the file's content. Maybe the file is "blocked" by another app?

BTW: The Wave file reader in dcaenc doesn't support any "w64" files at all. This applies to most audio tools at this time...

(6 channel support in dcaenc should be working though, from normal RIFF/Wave files. You can even use "oversize" Wave/RIFF files with the "-l" option)

Any advice on command line usage?

Depends on what you want to do with SoX ;)

Usually the syntax is like "sox.exe [<infile options>] infile.wav [<outfile options>] outfile.wav [<filter_1> ... <filter_n>]"

For a simple sample rate conversion, for example, you'd use "sox.exe infile.wav -r 48000 outfile.wav" :)

[geminigod]

Thanks Lord Mulder! You were right. Once I closed my video editor that I rendered the wave file from, I was able to get dcaenc to read the file. Doh! Not sure why that was the case since it wasn't anything actively open in my editor and I had even moved the file around on my computer without problem.

Now I just need to figure out how to bypass the length restrictions on wave files to make a 6 channel wave file that is 7GB in size. (I thought that was the point of w64.) Maybe I can accomplish this with sox and convert the w64 to wav and then feed into dcaenc.

[Selur]

Now I just need to figure out how to bypass the length restrictions on wave files to make a 6 channel wave file that is 7GB in size.
decode with sox, pipe to dcenc and make sure you enable:
-l Ignore input length, can be useful when reading from stdin
source: dcaenc -h

[Midzuki]

(I thought that was the point of w64.)

And it still is :) The problem is, many/most applications simply don't support reading/writing W64 yet :(

[Midzuki]

@ Lord_Mulder --- a minor "cosmetic nitpick" :)

I think the following "output" should be improved :rolleyes:

[F:\XPERIMENTS\whatever]
=>dcaenc -v
dcaenc-1 [Jan 6 2012]

dcaenc-1
Compiled on Jan 6 2012 at 18:59:51 using GNU GCC 4.5
http://aepatrakov.narod.ru/dcaenc/

[F:\XPERIMENTS\whatever]
=>

[geminigod]

I think I've officially got a working workflow, though after re-reading through this thread I am still confused on the matter of byte swapping. Why and when should I be concerned about this? Patrokov kind of makes it sound like it always needs to be done, but i'm skeptical that is the case.

[Selur]

byte swapping changes between BE and LE encoding
LE is also in the DTS Standard but BE is better supported by decoders&Co -> stay with BE unless you know you need LE
(BE is default for LordMulders builts)

[Midzuki]

Never mind, I'd better just hexedit the binary --- and add an icon :devil: to it as well :cool:

@ Lord_Mulder --- a minor "cosmetic nitpick" :)

I think the following "output" should be improved :rolleyes:

[F:\XPERIMENTS\whatever]
=>dcaenc -v
dcaenc-1 [Jan 6 2012]

dcaenc-1
Compiled on Jan 6 2012 at 18:59:51 using GNU GCC 4.5
http://aepatrakov.narod.ru/dcaenc/

[F:\XPERIMENTS\whatever]
=>

[Midzuki]

As a side note: Is it just me or do LoRd_MuldeRs binary get smaller and smaller each time? (not that I'm complaining, it's just an observation)

Let's see...

compiled w/ MSYS+GCC: 348kB

compiled w/ ICL 12: 370kB

However Lord_Mulder applies UPX :devil: on his binary, so that it shrinks to 109kB :sly:

Anyway, I've just added a 32x32 icon to my build of dcaenc, and now it contains only 326kB :eek:

:cool:

[Midzuki]

To whom this may interest:

RENBRU5D.tar.gz @

https://skydrive.live.com/#cid=5ACF098E0EBAE8D5&id=5ACF098E0EBAE8D5!153

=>dcaenc

ERROR: Required arguments are missing.
Try 'dcaenc -h' for more information.



=>dcaenc -v

dcaenc-1
Compiled on Jan 12 2012 at 20:55:48 using GNU GCC 4.5.2
http://aepatrakov.narod.ru/dcaenc/
http://gitorious.org/~mulder/dtsenc/mulders-dtsenc

Copyright (c) 2008-2011 Alexander E. Patrakov <patrakov@gmail.com>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License <http://www.gnu.org/>.
Note that this program is distributed with ABSOLUTELY NO WARRANTY.

=>dcaenc -h

DCAENC --- experimental 'Coherent Acoustics' compressor.

Usage: dcaenc -i <input.wav> -o <output.dts> -b <kbps>

Optional:
-l Ignore input length, can be useful when reading from stdin
-e Set the byte-order to 'Little-Endian' (default is 'Big-Endian')
-h Print this help screen
-v Show version info

DETAILS:

The input .WAV file must be either 16-bit or 32-bit integer;
the input or output file name can be "-" for stdin/stdout;
only the following channel-layouts are accepted:
mono, stereo, quadro, 5.0, 5.1.

The *actual* bitrate can be any value between 32 and 6144,
however both the minimum and the maximum values vary,
depending on the channel-layout and on the sample rate as well;
for DVD-Video, only the bitrates 754.5 and 1509.75 are compliant;
as for Blu-Ray, only the following values are generally regarded as compliant:
192, 255, 318, 384, 447, 510, 639, 754.5, 960, 1152, 1344, 1509.75.

* Valid sample rates (in kHz):

8 11.025 12 16 22.05 24 32 44.1 48

* Transmission bitrates (in kbps):

32 56 64 96 112 128 192 224
256 320 384 448 512 576 640 768
960 1024 1152 1280 1344 1408 1411.2 1472
1536 1920 2048 3072 3840 open VBR LOSSLESS

[geminigod]

To whom this may interest :)


* Valid bitrates (in kbps):

32 56 64 96 112 128 192 224
256 320 384 448 512 576 640 754.5
960 1024 1152 1280 1344 1408 1411.2 1472
1509 1920 2048 3072 3840 open VBR LOSSLESS

WARNING:
Currently not all possible combinations of frequencies and bitrates are supported.



I guess there is an argument to be made for posting the low bitrates with the WARNING caveat, but posting above 1509 is a bit misleading since I believe that even the official DTS codec doesn't support higher than that.:scared:

Maybe better to only list 754-1509 with with no caveat for now?? Just my two cents.

While you are at it, it might be good to list the supported bit depths of 16 and 32 (no 24) as well. I seem to recall something about an issue with 32 floating point also??

[Midzuki]

I guess there is an argument to be made for posting the low bitrates with the WARNING caveat, but posting above 1509 is a bit misleading since I believe that even the official DTS codec doesn't support higher than that.:scared:

As I had said,

1) According to the file ts_102114v010301p.pdf ("ETSI TS 102 114 V1.3.1 [2011-08]"), the «targeted bitrates» above 1536kbps, together with the types "VBR" and "lossless", have been declared `invalid´ :scared:

Well, the open-source encoder itself supports those "overkilling bitrates", and so far I have not found a dca decoder that doesn't support them... In fact, and in practice, the software decoders seemingly care not about the targeted bitrate, but yes about the "playback rate" (read: the sampling frequency).

Maybe better to only list 754-1509 with with no caveat for now?? Just my two cents.

:confused: :confused: :confused:

[geminigod]

Well, the open-source encoder itself supports those "overkilling bitrates", and so far I have not found a dca decoder that doesn't support them... In fact, and in practice, the software decoders seemingly care not about the targeted bitrate

Oh, I read your WARNING statement more carefully. I didn't realize that the lower bitrates were possible with lower sampling rates. I just knew that 754 was lowest with 48k. I also wasn't aware that encoder allowed for higher than 1509. :o

Listing supported bit depths still is a good idea though. :p

[Selur]

If someone was the time it would be nice to know what bit rate & frequency combinations are possible and which are allowed by the standard.

[Midzuki]

FWIW, the DTS-HD Encoder Suite lists the following bitrates (for 48kHz of course):

192, 255, 318, 384, 447, 510, 639, 754.5, 960, 1152, 1344, and 1509 kilobits-per-second ;

Listing supported bit depths still is a good idea though. :p

Already on the "TODO list" :)

[geminigod]

Well crud. SoX is failing me in rendering my w64 to wav to manipulate in dcaenc, as is every other program. I'm assuming this is due to the wav file size being over 4GB. Thoughts on how to get around this? Worst case scenario I could split the audio track to two pieces, but previous posts seem to imply that there is a way for me to get around having to do this.

On a probably unrelated note, SoX also is reporting the wrong length for w64 files. The actual length is 3:13 and SoX is reporting as 0:28. There was a known issue with 24 bit depth and length reporting that was supposedly fixed in latest version. So I re-rendered w64 to 16 bits and now SoX reports 1:09 length.

[Selur]

On a probably unrelated note, SoX also is reporting the wrong length for w64 files.
don't forget to report this to the SoX bug tracker (http://sourceforge.net/tracker/?group_id=10706&atid=110706) if it's not already in there.

[geminigod]

don't forget to report this to the SoX bug tracker (http://sourceforge.net/tracker/?group_id=10706&atid=110706) if it's not already in there.

Done.

[TFM_TheMask]

Is it possible to create a dll also instead of only an exe?

[LoRd_MuldeR]

Is it possible to create a dll also instead of only an exe?

Sure. The command-line front-end internally just calls the encoder library.

Though in the current Visual Studio solution, the front-end and the library are not in separate projects yet - for sake of simplicity.

Wouldn't be that hard to do though ;)

[TFM_TheMask]

Sure. The command-line front-end internally just calls the encoder library.

Though in the current Visual Studio solution, the front-end and the library are not in separate projects yet - for sake of simplicity.

Wouldn't be that hard to do though ;)

That is good to hear :cool:.

The only thing is that my C programming skills are limited and also compiling with Visual Studio (I'm more a Delphi guy). So if anyone has the skills and wants to create the dll version then I am here to test it if needed.

[Qaq]

Just made few 2.0 44/16 DTS: 1500-3000 kbps, with and without -e, packed into mka. Decoding seems no problem (no matter of -e is used or not) by LAV/Arcsoft, but I couldn't bitstream to avr no matter of splitter/decoder :devil:
ffdshow shows bitstream, but there are no sound and incoming indication in AVR. There is no problem with regular DTS-WAVs.

[Midzuki]

^ @ Qaq :

I suppose your AVR "expects" 44.1kHz DTS to have a very-specific bitrate (1411.2kbps).

[LoRd_MuldeR]

That is good to hear :cool:.

The only thing is that my C programming skills are limited and also compiling with Visual Studio (I'm more a Delphi guy). So if anyone has the skills and wants to create the dll version then I am here to test it if needed.

Okay, I moved the actual encoder "core" into a separate project within the MSVC solution. It is now linked into the CLI encoder as a static library.

I also added a third project to the solution, which builds dcaenc as a DLL file. The DLL is still untested though ;)

You should be able to call dcaenc from your application just like it is done in 'main.c' of the CLI encoder. But make sure to link against 'dcadll_vc2010_imp.lib' to use the DLL.

For Delphi you will have to create your own "header" (.pas) file with the required DLL imports. Shouldn't be too hard to translate 'dcaenc.h' to Delphi...

Details:
http://gitorious.org/~mulder/dtsenc/mulders-dtsenc/commit/3c700dccdc5d160623baae67922757cff6123bb4

[Qaq]

I suppose your AVR "expects" 44.1kHz DTS to have a very-specific bitrate (1411.2kbps).
Thats possible. The main goal is to get as close to a source (lossless) as possible. I'll see if I can do anything here. Strange that Arcsoft is not touchy at all about bitrates and endians.
I am not sure whether ffdshow or LAV Audio support "SPDIFing" other bitrates than 1509kbps or other channel layouts than 5.1
I tried ffdshow with 2.0 96/24 DTS MA. No problem.

[TFM_TheMask]

Okay, I moved the actual encoder "core" into a separate project within the MSVC solution. It is now linked into the CLI encoder as a static library.

I also added a third project to the solution, which builds dcaenc as a DLL file. The DLL is still untested though ;)

You should be able to call dcaenc from your application just like it is done in 'main.c' of the CLI encoder. But make sure to link against 'dcadll_vc2010_imp.lib' to use the DLL.

For Delphi you will have to create your own "header" (.pas) file with the required DLL imports. Shouldn't be too hard to translate 'dcaenc.h' to Delphi...

Details:
http://gitorious.org/~mulder/dtsenc/mulders-dtsenc/commit/3c700dccdc5d160623baae67922757cff6123bb4

Thanks LoRd_MuldeR. Super. I will translate the header to pas for delphi.

[Kurtnoise]

To whom this may interest :)

what do you mean by open, VBR, Lossless ?

[LoRd_MuldeR]

I will translate the header to pas for delphi.

Feel free to post your result ;)

In the meantime, here is an updated DLL that has the dependency on MSVCR100.DLL removed.

(Now using the MSVCRT.DLL that is part of Windows)

Please use updated DLL with updated file name, as suggested by dcaenc original author.

[Midzuki]

what do you mean by open, VBR, Lossless ?

In the page 13 of the document "ETSI TS 102 114 V1.2.1 (2002-12)":

RATE specifies the targeted transmission data rate for the current frame of audio (see table 5.7). The open mode allows for bit rates not defined by the table. Variable and loss-less modes imply that the data rate changes from frame to frame.

Table 5.7: RATE parameter vs. targeted bit-rate

0b00000 32
0b00001 56
0b00010 64
0b00011 96
0b00100 112
0b00101 128
0b00110 192
0b00111 224
0b01000 256
0b01001 320
0b01010 384
0b01011 448
0b01100 512
0b01101 576
0b01110 640
0b01111 768
0b10000 960
0b10001 1 024
0b10010 1 152
0b10011 1 280
0b10100 1 344
0b10101 1 408
0b10110 1 411,2 (sic)
0b10111 1 472
0b11000 1 536
0b11001 1 920
0b11010 2 048
0b11011 3 072
0b11100 3 840
0b11101 open
0b11110 Variable
0b11111 Loss-less (sic)


See also:

http://wiki.multimedia.cx/index.php?title=DTS#Frame_format

[Midzuki]

Thats possible. The main goal is to get as close to a source (lossless) as possible. I'll see if I can do anything here. Strange that Arcsoft is not touchy at all about bitrates and endians.

Speaking in general, for 48kHz, 256kbps per (full-range) channel should sound "transparent" to most people's ears
( but YMMV of course :) )

...
Many people think/say 5.1 DTS @ 44.1kHz @ 1234.8kbps is [ place your favorite superlative here :) ]. However, that's mathemagically-equivalent to 1344kbps @ 48kHz. In other words, 1509kbps has been overkill since the very-beginning :p

Regarding Arcsoft, or even libavcodec, a software decoder is not required to save 1 cent per 100,000 manufactured units :rolleyes:

[TFM_TheMask]

Feel free to post your result ;)

In the meantime, here is an updated DLL that has the dependency on MSVCR100.DLL removed.

(Now using the MSVCRT.DLL that is part of Windows)

Please use updated DLL with updated file name, as suggested by dcaenc original author.

I will, only one question. How do I translate the following to Pascal? Should I just initialize a pointer?

typedef struct dcaenc_context_s *dcaenc_context;

[LoRd_MuldeR]

Yeah, I think the calling app doesn't need to know how the struct is defined internally - it might even change in future versions.

Just store the pointer you get when creating the dcaenc context and then pass it back into dcaenc when calling the dcaenc_convert_s32() function :)

[Midzuki]

...
48kHz 2 Channel works with: 320 384 448 512 576 640 (I would recommend 576 since at least my receiver doesn't like 640 ;))

Hummm, what about trying 639kbps ???

Because, if I set "-b 640", both eac3to and foobar2000 indicate an effective bitrate of 642kbps, and this might be the reason why your receiver didn't like it :confused:

Whereas if I choose "-b 639", eac3to says the effective bitrate really is 639kbps http://forum.doom9.org/images/icons/icon3.gif

(Possibly the firmware "expects" the actual bitrate is never greater than the targeted bitrate,
but this is just a wild guess of course)

[Kurtnoise]

In the page 13 of the document "ETSI TS 102 114 V1.2.1 (2002-12)":

So...what's the point ? these values are somewhere in the code or available through the interface ?

[Midzuki]

So...what's the point ? these values are somewhere in the code or available through the interface ?


Long answer:

=>dcaenc -i input.wav -o output.dts -b vbr

ERROR: Bitrate must be between 32 and 6144 kbps!

Apparently dcaenc is less stupid than I thought :rolleyes:

Short answer:

*yawns*

[geminigod]

Speaking in general, for 48kHz, 256kbps per (full-range) channel should sound "transparent" to most people's ears
( but YMMV of course :) )

I mostly agree with this. Under ideal listening conditions with the right song I could nitpick a bit higher maybe to 320 kbps before I lose the ability to discern between the lossy and lossless version.

The 48kHz is a big deal though in my opinion and an unfortunate problem with CD. Increasing bitrate may yield a mathematical equivalence between 44.1 & 48 but that doesn't mean there is a sonic equivalence (assuming it isn't an up-convert). I find there to be more value in sampling size than in each sample's description. Its like getting driving directions from somebody. Would you rather have very detailed directions but with a couple turns missing or simpler directions with a brief description of every turn? The number of letters used are mathematically equivalent.

I was just ripping some records today and contemplating the misconception that analogue lovers have about digital. Most of the richness that Vinyl collectors such as myself love has less to do with the digital format and more to do with dynamic range compression applied to digital in the mastering process.

[geminigod]

Long answer:

=>dcaenc -i input.wav -o output.dts -b vbr

ERROR: Bitrate must be between 32 and 6144 kbps!

Apparently dcaenc is less stupid than I thought :rolleyes:

Short answer:

*yawns*

Lol

:goodpost:

[Midzuki]

^
^

Bottom line is, you'd better "dca-encode" your CDDA-tracks and your vinyl rips @ either 639kbps or 754kbps. BTW, 640kbps is not the only "potentially-problematic" bitrate for dcaenc --- 1.0 + 44.1kHz @ 192kbps actually gives a 193kbps output :confused:

[Kurtnoise]

Long answer:

=>dcaenc -i input.wav -o output.dts -b vbr

ERROR: Bitrate must be between 32 and 6144 kbps!

Apparently dcaenc is less stupid than I thought :rolleyes:

So, vbr mode, open & lossless are not available...So, no need to specify this in the help.

[Midzuki]

So, vbr mode, open & lossless are not available...So, no need to specify this in the help.

No problem. Anyone can edit the main.c according to their personal preferences. Lord Mulder is surely a very-busy person, and I could not convince him that my ideas are better than his :p I am not forcing anyone to download or to use my MinGW builds of dcaenc. :)

[Selur]

here a bit about what the encoder accepts atm. (tested by try&error)

mono@8kHz 32-2048
mono@12kHz 48-3072
mono@16kHz 48-3842 (didn't check higher)
mono@22.05kHz 65-3842 (didn't check higher)
mono@24kHz 71-3842 (didn't check higher)
mono@32kHz 95-3842 (didn't check higher)
mono@44.1kHz 130-3842 (didn't check higher)
mono@48kHz 142-3842 (didn't check higher)

stereo@8kHz 96-2048
stereo@12kHz 96-3842 (didn't check higher)
stereo@16kHz 96-3842 (didn't check higher)
stereo@22.05kHz 128-3842 (didn't check higher)
stereo@24kHz 192-3842 (didn't check higher)
stereo@32kHz 192-3842 (didn't check higher)
stereo@44.1kHz 256-3842 (didn't check higher)
stereo@48kHz 271-3842 (didn't check higher)

5.1@8kHz 112-2048
5.1@12kHz 168-3072 (didn't check higher)
5.1@16kHz 224-3842 (didn't check higher)
5.1@22.05kHz 308-3842 (didn't check higher)
5.1@32kHz 447-3842 (didn't check higher)
5.1@44.1kHz 615-3842 (didn't check higher)
5.1@48kHz 670-3842 (didn't check higher)

Cu Selur

[geminigod]

Thanks Selur. That is very helpful.

[Midzuki]

@ Selur: many many :thanks: for being less lazy than I :o :D

P.S.: Ooops, I have already found 1 incorrection in your list :(

stereo@48kHz 271 — ???

@ Lord Mulder: couldn't those limits be calculated directly thru the dcaenc library and then conveniently output by a command-line switch ???

:confused: :confused: :confused:

+++++++++

P.P.S.: Definitely there should be an easier way than finding/creating 6 (channel layouts) x 9 (frequencies) = 54 .WAV files, and then trying every integer "kbps" between 32 and 6144 :scared: Even with the help from a well-crafted batch-file or script, that would not be quite sane :(

[LoRd_MuldeR]

Well, the CLI front-end simply tries to initialize the dcaenc library with the given parameters. That either fails or succeeds :scared:

Internally dcaenc_create() does a number of calculations to determine "frame_bits" and "min_frame_bits".

It then will fail if either "frame_bits < min_frame_bits" or "frame_bits > 131072" or "(flags & DCAENC_FLAG_IEC_WRAP) && frame_bits > 16320" evaluates to TRUE.

So what exactly do you want to output on the manpage? ;)

[Selur]

Ooops, I have already found 1 incorrection in your list

stereo@48kHz 271 — ???
damn,.. :/ fixed it,..

[geminigod]

Sigh... :(

Anyone care to compile a development version of SoX for me?? I have been coordinating with Uklauer privately and via the bug tracker regarding SoX's length reporting with w64 files.

His response:
Do you have a chance to compile and try a current development version from
the git repository? Your description is consistent with the file length
being reduced modulo 2^32, and this is supposed to be fixed now (after
14.3.2). If you can't try the development version, a 14.4.0 release
candidate will be out in about two weeks' time.

Here the calculations: actual file length in bytes for 16 bit:
3.22*3600*48000*6*2 = 6676992000, for 24 bit: 3.22*3600*48000*6*3 =
10015488000; back to time in hours, for 16 bit:
(6676992000%2^32)/2/6/48000/3600 = 1.15 (1h09m); for 24 bit:
(10015488000%2^32)/3/6/48000/3600 = 0.46 (0h27m).


Apparently he can't compile for windows and neither can I :(.

Info I shared with him on my project:



Here is a bit more feedback. I cannot seem to find a workaround on the
length issue. The --ignore-length command doesn't change the outcome at
all.

Using the following command line:

sox -V4 --ignore-length "large file test.w64" -t wavpcm - | dcaenc-DEBUG -i - -o "large file test.dts" -l
-b 1440


on a w64 file that is 16bit, 48kHz, 6 channels, & 3:13:49.076 (558 195 638
samples) in length, I get the following results:


dcaenc-1 [Jan 6 2012]
Copyright (c) 2008-2011 Alexander E. Patrakov <patrakov@gmail.com>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License
<http://www.gnu.org/>.
Note that this program is distributed with ABSOLUTELY NO WARRANTY.

Source: -
Output:large file test.dts
KBit/s: 1440

sox: SoX v14.3.2
time: Feb 27 2011 16:03:50
gcc: 4.5.0 20100414 (Fedora MinGW 4.5.0-1.fc14)
arch: 1248 48 44 L OMP
sox DBUG sndfile: `large file test.w64': Length : 2403380640
sox DBUG sndfile: `large file test.w64': riff : 6698347936 (should be
2403380640)
sox DBUG sndfile: `large file test.w64': wave
sox DBUG sndfile: `large file test.w64': fmt : 64
sox DBUG sndfile: `large file test.w64': Format : 0xFFFE =>
WAVE_FORMAT_EXTENSIBLE
sox DBUG sndfile: `large file test.w64': Channels : 6
sox DBUG sndfile: `large file test.w64': Sample Rate : 48000
sox DBUG sndfile: `large file test': Block Align : 12
sox DBUG sndfile: `large file test.w64': Bit Width : 16
sox DBUG sndfile: `large file test.w64': Bytes/sec : 576000
sox DBUG sndfile: `large file test.w64': Valid Bits : 16
sox DBUG sndfile: large file test.w64': Channel Mask : 0x3F
sox DBUG sndfile: `large file test.w64': Subformat
sox DBUG sndfile: `large file test.w64': esf_field1 : 0x1
sox DBUG sndfile: `large file test.w64': esf_field2 : 0x0
sox DBUG sndfile: `large file test.w64': esf_field3 : 0x10
sox DBUG sndfile: `large file test.w64': esf_field4 : 0x80 0x0 0x0 0xAA
0x0 0x38 0x9B 0x71
sox DBUG sndfile: `large file test.w64': format : pcm
sox DBUG sndfile: `large file test.w64': data : 6698347680
sox DBUG sndfile: `large file test.w64': *** Unknown chunk marker : 189194.
Exiting parser.

Input File : large file test.w64'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:09:32.54 = 200281709 samples ~ 312940 CDDA sectors
File Size : 6.70G
Bit Rate : 12.8M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no

sox DBUG wav: Writing Wave file: Microsoft PCM format, 6 channels, 48000
samp/sec
sox DBUG wav: 576000 byte/sec, 12 block align, 16 bits/samp

Output File : '-' (wav)
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:09:32.54 = 200281709 samples ~ 312940 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'

sox INFO sox: effects chain: input 48000Hz 6 channels 16 bits (multi)
sox INFO sox: effects chain: output 48000Hz 6 channels 16 bits (multi)
Encoding... 69:32 [100.0%]
Done.


The resulting outputted file is " " & 1:09:32.555 (200 282 624 samples) in
length.

Sorry for over-complicating a bit with the piping into another program, but
it is irrelevant. The problem is on the SoX end of things.