If it were really a problem with endian-ness, the file probably wouldn't play at all (header info having been screwed up by byte swapping, not to mention errors at every sample even if you could uncompress the file).

If it were a CRLF problem (as suggested above), the file sizes would not be right -- one version of a given upload file would be slightly bigger than the other -- UNLESS...

Could it be that the amount of uploaded data being written at the server is determined by something in the MIME header, rather than the amount of data actually received? Apologies if this is a stupid scenario -- I'm not that well versed in the conventions for upload transactions -- but if the header reports N bytes (based on the size of the client's disk file) and sends N+x bytes (because some LF's were converted to CRLF), or even N-x bytes (because CRLF byte pairs were converted to LF), would the server still write exactly N bytes (truncating or padded as needed)?

Are you absolutely sure that the file in question was stored correctly on the Vista box before being uploaded via a Vista browser? I've seen a number of cases where people went through tiresome cycles of debugging and testing, but failed to notice that the corruption really started before the data reached the system being tested.

(updated to simplify 2nd paragraph)