Analysing music files online
June 23, 2007 3:30 AM Subscribe
Is it possible to analyse audio files in php/flash?
More specifically bitrate, tempo and conversion between media formats.
I have a client with a large music database. They want to allow artists to upload their own tracks through their website.
But they want the tempo automatically detected when the file is uploaded.
They also want to quality control the tracks so they want to restrict uploads to just wav files and then convert from wav to aiff and mp3.
Alternatively they would like to confirm the bitrate of an mp3 is whatever they'd like it to be.
Is this even going to be possible/at all practical? If so, any ideas who?
They want to increase the database to near 1 million tracks.
I have a client with a large music database. They want to allow artists to upload their own tracks through their website.
But they want the tempo automatically detected when the file is uploaded.
They also want to quality control the tracks so they want to restrict uploads to just wav files and then convert from wav to aiff and mp3.
Alternatively they would like to confirm the bitrate of an mp3 is whatever they'd like it to be.
Is this even going to be possible/at all practical? If so, any ideas who?
They want to increase the database to near 1 million tracks.
For example, if you install mp3info on your server, this bit of php code should return the bitrate:
posted by Jimbob at 4:44 AM on June 23, 2007
<?
$file = "whatever.mp3";
$bitrate = shell_exec("mp3info -p %r ".$file);
?>
posted by Jimbob at 4:44 AM on June 23, 2007
Response by poster: I'm sure there's something out there to analyse beats and determine temp in a non-GUI setting, but I haven't found it yet.
Me neither.
The bitrate is a secondary requirement - they would prefer the files to be converted to mp3 and aiff from wavs
posted by missmagenta at 4:54 AM on June 23, 2007
Me neither.
The bitrate is a secondary requirement - they would prefer the files to be converted to mp3 and aiff from wavs
posted by missmagenta at 4:54 AM on June 23, 2007
PHP could call LAME to encode mp3. But use of LAME in a commercial setting may violate mp3 licensing terms (IANAL and neither are the LAME developers. Seek professional legal advice before building business ventures on any particular software platform).
Using the v=2 parameter switch, it can produce nice Variable Bit Rate mp3 files that will center on 192 kps, but seamlessly bump to 320 kps when the complexity of the music demands it, or drop to as little as 32 kps, when silence prevails. Overall file sizes will typically be 2/3 of that encoded at a fixed 192 kps bit rate.
posted by paulsc at 7:11 AM on June 23, 2007
Using the v=2 parameter switch, it can produce nice Variable Bit Rate mp3 files that will center on 192 kps, but seamlessly bump to 320 kps when the complexity of the music demands it, or drop to as little as 32 kps, when silence prevails. Overall file sizes will typically be 2/3 of that encoded at a fixed 192 kps bit rate.
posted by paulsc at 7:11 AM on June 23, 2007
You might not want to do this on the fly as a file is uploaded, but rather upload files into a queue to be processed as they come in. This is particularly true if you're talking about multiple files... maybe just capture the basic data about the file on upload (location in file system, size, etc...) and just fill in the rest a little later.
This'll also allow you to offload the processing from the website itself, if the need arises.
From there, you've really got your pick of scripting languages to process the queue and do what you want. You could use PHP, bash, python, perl... you know, pretty much whatever. You're going to need something like this anyway at some point in the future, because the file output requirements will probably change and it'll be super handy to just have a script you can quickly modify and use to regenerate the entire set of target audio files from a bunch of database entries.
posted by ph00dz at 8:14 AM on June 23, 2007
This'll also allow you to offload the processing from the website itself, if the need arises.
From there, you've really got your pick of scripting languages to process the queue and do what you want. You could use PHP, bash, python, perl... you know, pretty much whatever. You're going to need something like this anyway at some point in the future, because the file output requirements will probably change and it'll be super handy to just have a script you can quickly modify and use to regenerate the entire set of target audio files from a bunch of database entries.
posted by ph00dz at 8:14 AM on June 23, 2007
"...They want to increase the database to near 1 million tracks."
If they are accepting 1 million .wav files, of the approximate length and complexity of the average 80's rock tune, and then encoding them as both .mp3 and .aiff files, they're talking about an online file system of tens of terabytes. Practically speaking, that investment of hardware and the technical resources necessary to put it together and manage it reliably would argue for a custom software solution, perhaps using modular tools like AudioCommander to do the file compression to .mp3 and .aiff on a dedicated Windows node in a larger system running a high performance journaled file system. But for a project of this size, they may need a custom database solution integrated to manage it all.
Lots of ways to go on a project of this size, depending on budget and other constraints. Some, much better technically than others.
posted by paulsc at 10:52 AM on June 23, 2007
If they are accepting 1 million .wav files, of the approximate length and complexity of the average 80's rock tune, and then encoding them as both .mp3 and .aiff files, they're talking about an online file system of tens of terabytes. Practically speaking, that investment of hardware and the technical resources necessary to put it together and manage it reliably would argue for a custom software solution, perhaps using modular tools like AudioCommander to do the file compression to .mp3 and .aiff on a dedicated Windows node in a larger system running a high performance journaled file system. But for a project of this size, they may need a custom database solution integrated to manage it all.
Lots of ways to go on a project of this size, depending on budget and other constraints. Some, much better technically than others.
posted by paulsc at 10:52 AM on June 23, 2007
Response by poster: You might not want to do this on the fly as a file is uploaded, but rather upload files into a queue to be processed as they come in. This is particularly true if you're talking about multiple files... maybe just capture the basic data about the file on upload (location in file system, size, etc...) and just fill in the rest a little later.
Thats exactly what I told them - they didnt seem too happy about it though. But theres still the issue of finding any linux software/scripts which will get the required information and that isnt all gui equaliser graphs and pretty images.
posted by missmagenta at 10:55 AM on June 23, 2007
Thats exactly what I told them - they didnt seem too happy about it though. But theres still the issue of finding any linux software/scripts which will get the required information and that isnt all gui equaliser graphs and pretty images.
posted by missmagenta at 10:55 AM on June 23, 2007
Response by poster: Good point about the license - not really my concern, I'm just the contract coder but I'll mention it, client probably hasnt considered it.
posted by missmagenta at 11:01 AM on June 23, 2007
posted by missmagenta at 11:01 AM on June 23, 2007
« Older How not to be anal about finding a good career | What's the name of the French pig ad? Newer »
This thread is closed to new comments.
posted by Jimbob at 4:36 AM on June 23, 2007