<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 2 April 2013 21:29, 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><div class="h5">On Tue, Apr 2, 2013 at 3:24 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">
Huh, you're right.<br>
<br>
Oh, i see... we've been supporting >4GB wave files in the Xiph stuff<br>
by setting the length to 0xFFFFFFFF and assuming the data chunk is<br>
last (intuiting chunk length from file length).<br></blockquote></div></div><div><br>nothing about RIFF implies that the data chunk is last.  in fact, there is no ordering at all except that the RIFF chunk is first. there are several windows app that make this "mistake".<br>


<br>w64 is the format to use, and libsndfile handles it (and CAF) with distinction.<br></div></div></blockquote><div> </div></div>I guess this is a bug in sox then. If I use sndfile-concat (by first turning the first wave file into w64), a correct w64 is made, and if I use sndfile-salvage on the wave sox produced (the one with too much sound for the header to explain) a correct file is also made. Either way, success!<br>

<br></div><div class="gmail_extra">Thanks for the insight guys.<br></div></div>