<br><br><div class="gmail_quote">On Tue, Apr 2, 2013 at 3:12 PM, Paul Davis <span dir="ltr"><<a href="mailto:paul@linuxaudiosystems.com" target="_blank">paul@linuxaudiosystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Tue, Apr 2, 2013 at 2:35 PM, Monty Montgomery <span dir="ltr"><<a href="mailto:xiphmont@gmail.com" target="_blank">xiphmont@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Regular WAV at ~CD rate is limited to about 5 hours because the length<br>
encoding fields are 32 bit.  You need to generate an extended WAV with<br>
the WAVEFORMATEXTENSIBLE struct that allows a 16 exabyte data chunk.<br>
I'm a little surprised sox doesn't do that by default.<br></blockquote></div><div><br>I wasn't aware that WAVEFORMATEXTENSIBLE covered file sizes - the spec seems to be mostly about "higher resolution" sample formats. what did i miss?<br>
</div></div></blockquote><div><br>Specifically: <br><br>   "The <font color="#008000"><kbd>WAVE_FORMAT_EXTENSIBLE</kbd></font> format 
code indicates that there is an extension to the Format chunk. The extension has 
one field which declares the number of "valid" bits/sample (<font color="#008000"><kbd>wValidBitsPerSample</kbd></font>). 
Another field (<font color="#008000"><kbd>dwChannelMask</kbd></font>) contains a 
bits which indicate the mapping from channels to loudspeaker positions. The last 
field (<font color="#008000"><kbd>SubFormat</kbd></font>) is a 16-byte globally 
unique identifier (GUID)."<br><br>it does not change the size of the size field of the RIFF or data chunks, which is what matters here.<br></div></div>