Corante

About this Author
Ernest Miller Ernest Miller pursues research and writing on cyberlaw, intellectual property, and First Amendment issues. Mr. Miller attended the U.S. Naval Academy before attending Yale Law School, where he was president and co-founder of the Law and Technology Society, and founded the technology law and policy news site LawMeme. He is a fellow of the Information Society Project at Yale Law School. Ernest Miller's blog postings can also be found @
Copyfight
LawMeme

Listen to the weekly audio edition on IT Conversations:
The Importance Of ... Law and IT.

Feel free to contact me about articles, websites and etc. you think I may find of interest. I'm also available for consulting work and speaking engagements. Email: ernest.miller 8T gmail.com

Amazon Honor System Click Here to Pay Learn More

In the Pipeline: Don't miss Derek Lowe's excellent commentary on drug discovery and the pharma industry in general at In the Pipeline

The Importance of...

« MP3 Player Dreams | Main | Hey, Advertisers, Pay for My HDTV »

March 15, 2004

Client-Side Remixing Conundrums

Posted by Ernest Miller

Lucas Gonze, who has added client-side remixing to his RSS+SMIL format (Analysis of RSS+Time as a playlist format) discusses the strengths and weaknesses of such client-side remixing here: Client-side remixing is sloppy. His post is in response to a couple of posts I've done on the idea of remixing "recipes": A History Palette for Music and The Grey Album - No Copying Necessary. Gonze argues, rightfully, that RSS+Time and similar such formats are not well-suited to client-side remixes:

Geeks around these parts have done many experiments with client-side remixing in SMIL, and what we found was that it works reasonably well as long as you don't need precise synchronization. If you do need precise synchronization, you'll just make yourself unhappy.
What that means for Danger Mouse and other dance-type remixers is that they will not be doable on the client side. That kind of thing requires a really tight set of operations. You have to clip out segments of a few seconds at most, then line them up with a lot of other clips. Marking a beat is a picky process with no room for sloppiness, which is exactly what HTML is not.

Mike Linksvayer agrees and provides more analysis (Client-side remixing isn’t so loopy).

Their both right. However, my vision of client-side remixing is not of the RSS+Time type, which "is to precise syncrhonization as HTML is to precise layout. If you don’t need precision, enjoy." Actually, I imagine a rather robust client that can achieve the level of precision that the remixer used to create the remixing "recipe." As I noted, my comparison is to Photoshop's History Palette:

Imagine if someone edits a photo [with Photoshop] and sends me the history palette but not the original photo (for copyright reasons). If I already have the original photo the editor worked with, I could recreate the new version from the history palette.

In the case of music, I imagine the client having something like a copy of Apple's GarageBand software. If you save the "history palette" for GarageBand and send me both the history and the original sound files used, I should be able to recreate the exact same finished product you have.

Such a thing is not yet available, but I don't see why it couldn't be. See, Dangermouse, the Jay-Z Construction Set and the Videogame Content Creation Model.

Comments (2) + TrackBacks (0) | Category: Culture | File Sharing


COMMENTS

1. Lucas Gonze on March 15, 2004 09:55 PM writes...

Not to add to the main dialog, because you made your point well and I don't have anything to add, but this makes me think of mediAgora. Kevin Mark's idea there was to compensate sampled musicians by having listeners buy all the source works. If people listening to remixes had to get copies of the original sources, the problem of compensation for sampling would be solved.

Permalink to Comment

2. Scott Matthews on March 16, 2004 12:43 PM writes...

I'm surprised that anybody would argue that something like the Grey Album couldn't be exactly reproduced via recipe.

Assuming that all the source came from those two CDs, and that people could reliably use a different pair of the same CDs in place of ones used to make the original mix, I can't see any reason why it couldn't be reproduced exactly.

(obviously all bets are off if using vinyl)

The first thing that comes to mind are video Edit Decision Lists, from Adobe's site:

"An edit decision list (EDL) is a list of video edits made in a video-editing project and includes reel number, clip names, in and out points, and other editing information, such as transitions and split edits, depending on the EDL format. Adobe Premiere includes several EDL export options."

"If you plan to use a post-production facility for final editing, you will probably need an EDL. Post-production facilities use EDLs to automate the video-editing process. At the post-production facility, an edit controller uses the EDL file to make a master tape of the project."

So, in that scenario, the end-user is the post-production facility making a new master tape.

Furthermore, I'll cite Acid, popular looping software. I think it stores edits in a separate file from the source. So, if you ripped your CDs, created an Acid project, and then shared the project file with somebody who then supplied their own copies of the souce audio, that very well may work.

In any case, I can't see why it couldn't be done with software, though it certinly might require new software.

Permalink to Comment


EMAIL THIS ENTRY TO A FRIEND

Email this entry to:

Your email address:

Message (optional):




RELATED ENTRIES
Kitchen Academy - Course II - Day 23
Kitchen Academy - Course II - Day 22
Kitchen Academy - Course II - Day 21
Kitchen Academy - The Hollywood Cookbook and Guest Chef Michael Montilla - March 18th
Kitchen Academy - Course II - Day 20
Kitchen Academy - Course II - Day 19
Kitchen Academy - Course II - Day 18
Salsa Verde