[linux-audio-user] The Open Loop Library, a few questions

[Darren Landrum]

Okay, based upon some thinking, I am now ready to tackle a design of 
this system. There are some other things I would like to run by 
everyone, though.

In the course of all of these conversations, loops were discussed most 
prominently, at the expense of what to do about patches and sample 
sets, which are the areas I personally would be more interested in. (I 
have used Acid, but only casually. So I understand most of how it's 
supposed to work.)

Ogg appears to make it easy to track metadata for loop files, but what 
can be done about sample sets and patches? Do gzip and tar allow for 
embedded arbitrary metadata? If not, it seems that Matthew Yee-King's 
suggestion of using MD5 checksums to check against a server may be the 
best bet. and if we're doing this for patches and samples, why not for 
loops as well? The infrastructure would be in place.

But wait, there's more! :) This now brings us to the "prevention of 
upload of copyrighted sample sets / loops / patches" part of the design.

If we have a working checksum database to check against stored 
metadata, why not gather all of the checksums we can for every loop 
library for Acid, every sample set for Gigasampler / Unity Session / 
etc. that we can get our hands on (legally)? Remember, we're only 
running these through MD5 to get a checksum, then uploading the 
checksum to the server.

Here's the good part, although I'm sure most of you are ahead of me. 
Whenever a user uploads a loop or sample set, the server will first 
decompress the file, then run an MD5 on it, which will then be compared 
to the checksum database. Any matches are flagged for removal by an 
administrator.

And as an added bonus, if you call within the next five minutes (sorry, 
bad joke), this will also allow the server to catch duplicate uploads 
of otherwise legal files.

Now, here are the concerns.

First, this is going to take a lot of server processing power. So, I'm 
leaning toward setting up a separate server just for this function. 
Going this route would allow the system to be opened up for use by 
third party websites, other non-profit places that offer uploaded files 
for downloads. (In fact, it could be *any* such service, not even 
music-related, but that's a completely separate issue I don't want to 
think about right now.)

As an upshot, it seems this system would be fairly easy to put together 
with little more than a good OSS database and a few perl scripts. The 
web server software could also be quite minimal.

One more thing to mention, and that's the name. The Open Loop Library 
is a good name for focusing on just loops, but for something a little 
broader, I would like to propose the utilitarian (if boring) name of 
"The Open Music Resource Library". For one, it's more descriptive of 
the intended task, and two, omrl.org is available as a domain, when I 
last checked yesterday.

Any thoughts and opinions would be greatly appreciated. Thank you, and 
sorry for another long email.

Regards,
Darren Landrum