Blogarithms

Doug Kaye's thoughts on web services, web hosting and managed services.

Flash for Random-Access Audio It looks like using ActionScript it's possible to build a "virtual clip player" in Flash MX. The built-in HTTP GET functions won't support the Range: header, but there's a socket-level interface that should do the trick. Here's how I imagine it would work: A custom Flash player is embedded in a web page. The player is passed a URL that includes the MP3 file location and the start/stop offsets. The player reads the first few bytes of the MP3 file via an HTTP GET to get the encoding parameters. The player the reads the clip using hand-coded HTTP GETs (via sockets) and the HTTP Range: header. The player combines the header and the clip to create a legitimate MP3 fragment, now buffered within the Flash player. The player invokes its local MP3 player component to play the MP3 fragment. I haven't worked with Flash for many years, and that was before ActionScript was available. IOW, I don't know what I'm doing. So I need to find an ActionScript/Flash MX expert who can code this for me. If you know that person, let me know. I can't afford much, but I could spring for a few $$ to get this done. The resulting player will be placed in the public domain. Posted Tuesday, May 18, 2004 10:14:29 PM

More on Random-Access Audio Now that I've had an hour to think about it <~>, I would prefer not to modify my server. Many reasons, but one is that IT Conversations would not be able to deliver these "clips" from our worldwide content-delivery network provided by Limelight Networks. So that leaves out the new URL scheme, at least so far as requiring the server to understand start/stop inherently. I also don't want to start messin' with customizations to Winamp. It's not that common an app and it won't run on all platforms. So I'm back to a modified Plan A: a customized embedded player written in Flash. This little guy would understand how to play excerpts of MP3 files using the same random-access methods discovered by Jon Udell. That part is now solved thanks to Jon. The only other issues are (a) how to communicate the start/stop offesets to the player, (b) how users who want to "virtually create" clips determine and specify those start/stop points, and (c) how users add the virtual clips to their own web sites and blogs. Working backwards, (c) if we make the Flash player (with a small visual footprint) publicly available, then anyone can stick it anywhere with an <EMBED /> tag, etc. Easy, I think. (b) At the very least, an person wanting to create a virtual excerpt can obtain the start/stop offsets using their existing MP3 players. We could eventually support and simplify the process within the Flash player. (a) I don't know enough about Flash, but I would guess we can pass data to the player from the server in response to an HTTP GET. To put it together, we create a URL with start/stop arguments, but we don't expect the HTTP server to deal with it. Instead, we use PHP, Perl, etc., to process the arguments and return the file that loads the Flash player and communicates the arguments. That mechanism can vary site-by-site. There's no need to standardize it so long as the mechanism that communicates with the Flash player is consistent. (Gotta learn more about Flash!) Posted Tuesday, May 18, 2004 3:04:17 PM

Random Access Audio Leave it to Jon Udell to get down-and-dirty with HTTP! Running tests with Winamp, he determined that the application uses the HTTP "Range:" header to skip ahead when reading an MP3 file. Great digging, Jon. However, this solution requires a smart client, and here's why. When the app requests a random chunk of an MP3 file, it won't receive the MP3 headers for that file. That means the app must first read the start of the file to determine the encoding rates, etc., and *then* access the file randomly. If an app just requests a chunk out of the middle of the file, it won't know how to play it. Indeed, this solutions doesn't require any extension to the server, as Jon proved, but it does require that the start/stop positions be communicated to the *client*. One solution might be to pass the client a playlist: an .m3u or .pls file. As far as I know, there's no way to specify a portion of an MP3 file in a playlist, but if you can, then the problem is solved. [Aside: I ran some tests on the Windows Media Player, controlling it with an ASX file. The <STARTIME /> tag appears to support random access, but it doesn't work as you'd hope. The player reads the entire file sequentially up to the start point, then begins playback. If you use the <STARTTIME /> tag to reach 10 megabytes into a file over the 'Net, you'll sit there and wait. Not what we need.] If anyone knows how to specify a start point in a playlist file, we've been reinventing wheel and can all go home. Otherwise, we have two choices: (1) build smart players like Winamp, adding a mechanism to specify start/stop positions *to the player*. Such a solution would work with any web server; (2) use a scheme based on a modified server that can accept the start/stop position via URL. This solution would work with many existing players. Winamp has a somewhat extensible architecture (API), so it may be possible to use that app as the basis for a solution. But it would be unique to Winamp. I'm going back and forth as to whether I like (1) or (2). The answer for IT Conversations may not be the best for solving the problem more globally. Posted Tuesday, May 18, 2004 1:53:07 PM

May 2004
Sun	Mon	Tue	Wed	Thu	Fri	Sat
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31
Apr   Jun