Subject: Re: [linux-audio-user] The Open Loop Library, a few questions
From: Mark Knecht (markknecht_AT_attbi.com)
Date: Sat Dec 21 2002 - 22:24:16 EET
Excellent ideas. A couple of things to keep in mind:
1) Someone could provide you with a library of 99% legal stuff and 1%
copied loops. They may not even know they are doing this if they get the
loop from the web and are told it's not copied, but it is. To that end,
I think your meta-data idea needs to take chack sums for each and every
2) To get around that sort of problem, I'd have to provide you with MD5
check sums of each and every loop on it's own, but not provide you with
the loops themselves. Looking at George Pendergast alt.rockdrums as an
example, the disk has 662 entries. 99.9% of them are audio. I need a
very automated way to handle this. I have a few loop libraries, so you
can see the problem. Actually, this IS the problem I originally brought
up. With 662 drum loops, I can't find the right group of loops to make
3) None of these loops contain all the meta-data you are interested in.
If someone provides a loop, then where do they get the data? And if
THEIR data isn't accurate, the quality of YOUR library suffers. How will
4) When this thing gets popular, and it will, it will use a lot of
broadband bandwidth. Worra's Place constantly gets maxed out and there
are days when you can't get through because he's exceeded bandwidth.
Granted, this is a GOOD problem to have, but plan for it because it will
I'm sure you'll get more comments. Very interesting problem.
FYI - I'd love to see something like this grow for all the Linux soft
synths. A patch library for Open Source soft synths would be immediately
On Sat, 2002-12-21 at 08:42, Darren Landrum wrote:
> 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
> 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.
> Darren Landrum
This archive was generated by hypermail 2b28 : Sat Dec 21 2002 - 22:19:30 EET