Subject: Re: [linux-audio-user] The Open Loop Library, a few questions
From: Darren Landrum (consul_AT_studioconsul.net)
Date: Sat Dec 21 2002 - 18:42:21 EET
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
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
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.
This archive was generated by hypermail 2b28 : Sat Dec 21 2002 - 18:41:43 EET