3

I am building an application that allows authenticated users to use a Web browser to upload MP3 audio files (of speeches) to a server, for distributing the audio on a network. The audio files need to use a specific bit rate (32kbps or less) to ensure efficient use of bandwidth, and an approved sampling rate (22.050 or 44.100) to maximize compatibility. Rather than validate these requirements following the upload using a server-side script, I was hoping to use HTML5 FileReader to determine this information prior to the upload. If the browser detects an invalid bit rate and/or sampling rate, the user can be advised of this, and the upload attempt can be blocked, until necessary revisions are made to the audio file.

Is this possible using HTML5? Please note that the question is regarding HTML5, not about my application's approach. Can HTML5 detect the sampling rate and/or bit rate of an MP3 audio file?

FYI note: I am using an FTP java applet to perform the upload. The applet is set up to automatically forward the user to a URL of my choosing following a successful upload. This puts the heavy lifting on the client, rather than on the server. It's also necessary because the final destination of each uploaded file is different; they can be on different servers and different domains, possibly supporting different scripting languages on the server. Any one server would quickly exceed its storage space otherwise, or if the server-side script did an FTP transfer, the server's performance would quickly degrade as a single point of failure. So for my application, which stores uploaded audio files on multiple servers and multiple domains, validation of the bit rate and sampling rate must take place on the client side.

Mikko Ohtamaa
  • 82,057
  • 50
  • 264
  • 435
vrtjason
  • 523
  • 5
  • 12
  • 1
    Probably easier and a better user experience to just convert them to the desired specs on the server. – steveax Oct 03 '12 at 01:38

2 Answers2

1

You can use FileReader API and Javascript built audio codecs to extract this information from the audio files.

One library providing base code for pure JS codecs is Aurora.js - then the actual codec code is built upon it

https://github.com/audiocogs/aurora.js/wiki/Known-Uses

Naturally the browser must support FileReader API.

I didn't understand from your use case why you need Java applet or FTP. HTTP uploads work fine for multiple big files if done properly using async badckend (like Node.js, Python Twisted) and scalable storage (Amazon S3). Similar use case is resizing incoming images which is far more demanding application than extracting audio metadata out from the file. The only benefit on the client side is to reduce the number of unnecessary uploads by not-so-technically-aware users.

sean
  • 188
  • 3
Mikko Ohtamaa
  • 82,057
  • 50
  • 264
  • 435
  • Thanks, I will check out Aurora.js. Re: my use case, the reason for this setup is this: HTTP uploads are not practical in my situation, because a script would have to be on each and every destination server to reassemble the uploaded chunks. There's no guarantee that each destination server would support the necessary scripting language, or have the necessary computing power to stitch together the uploaded chunks while maintaining performance. As for storage, the reason I don't use Amazon S3 is cost, not only the total cost but also my client's need to distribute financial responsibility. – vrtjason Oct 03 '12 at 18:38
  • You need to script only on one server which writes audio metadata to DB and then pushes the raw data forward to the final server or persistent storage like S3. Because the operation is mostly IO bound if your scripts are async and properly written it won't tax the server CPU, only bandwidth. – Mikko Ohtamaa Oct 03 '12 at 18:53
0

Given that any user can change your script/markup to bypass this or even re-purpose it, I wouldn't even consider it.

If someone can change your validation script with a bit of knowledge of HTML/Javascript, don't use HTML/Javascript. It's easier to make sure that it is validated, and validated correctly by validating it on the server.

Polyov
  • 2,281
  • 2
  • 26
  • 36
  • 3
    The point is not to prevent malicious users from uploading prohibited content. Rather it is to prevent people who don't know what they're doing from uploading audio files that won't play properly, or will take too long for end users to download. – vrtjason Oct 03 '12 at 01:29