aplonis has asked for the wisdom of the Perl Monks concerning the following question:

I have a CGI script for anonymous upload of MP3 files via a web page form to my own private NetBSD Unix running Apache.

When I upload via Firefox on a Unix box to the server all is well. The uploaded MP3 plays from the web page from Firefox on Unix as well as from either Firefox or MSIE on Vista.

When I upload via either Firefox or MSIE from Vista then the the MP3 on the Unix box does not play right. The file size is exactly right but playback is chirpy and awful sounding.

It never happens when I transfer back and forth using FTP, only via the CGI upload script written in Perl. Again, the same web page and same script work differently uploading from Vista versus NetBSD.

So I am wondering if this is an Endian-ness issue to do with Vista verus NetBSD? If so I suppose I can look into querying the CGI for the OS and re-endian-izing uploaded files. Or does anyone have a better way?

FYI: The upload needs to be anonymous. The uploaded files will be more-or-less temporary. The idea is to let me be a very lazy DJ in Second Life. Rather than work hard to search Limewire for people's requests, I want for them to send me songs from their own collection. I'll then play their request in-world for that event.

  • Comment on CGI Upload and MP3 Endianness on Unix versus Win32

Replies are listed 'Best First'.
Re: CGI Upload and MP3 Endianness on Unix versus Win32
by moritz (Cardinal) on Sep 14, 2008 at 20:58 UTC
    Somehow I don't think that it's the endianess that causes the problems; it's usually only bound to the underlying CPU, not to the operating system.

    What you can do is to keep a copy of the uploaded file on a server both from a working and from a non-working upload, pipe both through hexdump -C and look at the difference. It should give you some glue as to what went wrong.

Re: CGI Upload and MP3 Endianness on Unix versus Win32
by graff (Chancellor) on Sep 15, 2008 at 00:13 UTC
    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)

Re: CGI Upload and MP3 Endianness on Unix versus Win32
by ikegami (Patriarch) on Sep 15, 2008 at 00:54 UTC

    It never happens when I transfer back and forth using FTP

    Then do a file compare between the version uploaded by CGI and the version uploaded by FTP. Knowing how they are different will eliminate possible causes.

Re: CGI Upload and MP3 Endianness on Unix versus Win32
by hexcoder (Curate) on Sep 14, 2008 at 22:21 UTC
    I agree with moritz and could imagine that some transformation of line endings CR and/or LF is happening, which you probably don't want on binary files. Hope that helps.
Re: CGI Upload and MP3 Endianness on Unix versus Win32
by ikegami (Patriarch) on Sep 15, 2008 at 01:03 UTC

    If it is a CRLF⇒LF issue, I'd check the registry values for

    HKEY_CLASSES_ROOT\.mp3\Content Type HKEY_CLASSES_ROOT\.mp3\PerceivedType

    on the Vista machine. They should be "audio/mpeg" and "audio". I don't know if IE and FF use them, but they could.

Re: CGI Upload and MP3 Endianness on Unix versus Win32
by Anonymous Monk on Sep 15, 2008 at 08:11 UTC
    Show your code.