EchoNest has basically taken the web API to a completely new level with their new Remix API.

The API allows not just the analysis of beats and musical characteristics that their basic API offered, it additionally allows coders to modify audio and video files based on the analysis information for programatic remixing.

To get a sense of the amazing results, check out these initial exploratory vids: http://musicmachinery.com/2009/06/21/wheres-the-pow/

More info: http://code.google.com/p/echo-nest-remix/

Does anyone know of any other multimedia API's that allow for the modification of audiovisual assets via API calls?
Any on your wishlist?

Personally, I'd love some good web-based speech to text and face recognition APIs.

(via O'Reilly Radar)

Here's something I recently presented at the DC Drupal Meetup:

You've already heard us prattle on about Hey!Watch — it's a great video transcoding service that we've gotten in the habit of using for several of our clients. As much fun as wrestling with ffmpeg is, sometimes it's more appealing to just bit then bullet, pay a dime per transcode and not have to worry about keeping your codecs up to date.

They offer some neat add-on features, too, like direct uploading of transcoded videos to your Amazon S3 account. Even more tantalizingly, there's this: a method for allowing your users to upload directly to Hey!Watch's servers, complete with fancy-pants AJAX progress indicator. There's no need to spend your server's bandwidth and CPU on videos at all — you can stick to running Drupal on your system, outsourcing all the heavy lifting. You can send along your own arbitrary variables with the video submission, then receive them back via a ping that Hey!Watch sends once transcoding is complete (allowing you to keep track of who uploaded what video). It's pretty slick.

But interested Drupal developers will click through to the Hey!Watch code and despair. First, the AJAX is written with Prototype, which won't play nicely with Drupal's preferred jQuery library. Sure, it'd be possible to rewrite it in jQuery — but I'd really rather not.

Second and more damningly (and unsurprisingly), the form that uploads to Hey!Watch needs to stand on its own. You won't be able to nest it in a Drupal form — Drupal understandably doesn't like nested forms.

Earlier this week Google Maps added Mapplets functionality. The feature lets third-party developers offer their GMaps mashups as toggleable layers that can be added to the GMaps interface.

In addition to my duties here at EchoDitto, I also do some work for DCist as a hobby — in fact, I'm pretty sure that my work on this Google Map of the DC subway system helped land me my job. That app has languished, though, functional but limited and still stuck in version 1 of the GMaps API.

So I took a stab at porting it over to the Mapplet format. It went pretty well — you can see the results by clicking here. There were a number of API changes to contend with, though.

First, there was the transition to the GMap2 object, which most of you have probably already done. The Mapplet interface makes initialization much easier — you can count on the map object to already be instantiated — but other parts were confusing. Most notably, Google appears to have finally un-switched the order of the latitude and longitude parameters in their function calls. That's a welcome change, but figuring out how to undo (or double down on) the kludgy solution I was using made things pretty complicated. The subway map was displaying in Antarctica for a little while.

The actual Mapplet is implemented as an XML file based on the Google Gadget spec. You can find an example here, in the Mapplet documentation. It's a pretty straightforward format to work with, although documentation on some of the Google Gadget metadata tags can be a little unclear.

The other day we were faced with a dilemma: one of our clients needed to be able to upload daily (and sometimes hourly) videos for posting on their site - videos that were encoded as MPEGs, but needed to be FLVs. Until recently, we had been encoding them manually, using command-line FFMpeg, which, while being fairly flexible, was a slow, unreliable, processor-intensive action.

Jason did some hunting, and found an article on TechCrunch about this new web-based encoding service called Hey!Watch.

Holy crap, it's awesome.

Marseilles-based Hey!Watch has developed a system that offloads the encoding work normally done by your local machine onto their servers, virtually eliminating server load due to vid encoding.

Besides being able to convert vids from virtually -any- format to any other format, they've also got fantastic integration via APIs, browser plugins and Amazon's S3(!).

Cool stuff, right? I thought so, too, at least in theory. Thing was, I had never done anything with HTTP_Request, ever, so it was time to dive in. I learn best when thrown into things, anyway. The end result wasn't too shabby, and since I figure some of you out there might be in the same boat I was in at some point, here's the code I used:

--Pastebin seems to be down, I'll post it up as soon as pastebin comes back--

In the meantime, you can see it here: http://wilcoding.xs4all.nl/Wilco/Pastecode/4545/showpaste.aspx