<br> <div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
 Smells like endianness, and<br>
remembering the state I was in before writing the sample loading code<br>
(before a gig) it's quite possible.<br><br></blockquote></div><br></div></blockquote><div><br>I looked again. To me it looks like no libsndfile is involved at all and instead there is a custom wav loader. Thus custom wav loader tries to make sure the file is a valid file but is a bit overly conservative about it, in that it only accepts the data portion of the file to have the wave's values and no other stuff like loops and other fancy elements set by fancy editors.<br>
<br>The issue I have seems caused by the loader determining "compression" solely  based on the length of the file and not based on whether it's actually compressed. Maybe you are right and it's a endian issue but at this stage of the code I could only see that happening if some bitwise operations were used, which I don't see happening. Then again; it's not clear how the file length or the "datastart" would be different as a result of either the OS or the CPU architecture otherwise.<br>
<br>I think I'll comment out the check, try a recompile, and see how that affects things. After all; I already determined these files are fine so maybe Fluxa doesn't need to check it for me.<br><br>Kas.<br></div></div>