20 Dec
2002
20 Dec
'02
1:11 a.m.
After some considerable thought as to the best way to organize such a
library, as well as what a project such as this will do to my free
time, I have a few ideas and questions to present to the list.
I'll start with the easy one first.
1) What exactly would this library hold? There's no need for this to be
restricted to loops. It could also contain other "musical raw
material", such as sample sets and softsynth patches. In that case,
calling it the Open Loop Library makes little sense. What else do you
think would work? Open Music Library? Sounds like it's a repository for
music, not for raw components. The upshot to the Open Loop Library name
is that the domain openloops.org is available. It also makes a good
working name for now.
Really, that was the main question, and it brings part of the proposal
with it. I would like to design and build a web service to act as a
library for loops, sample sets, and patches. Here are some thought on
the overall design.
1) The top level hierarchy would be (obviously enough) "Samples",
"Loops", and "Patches".
2) Below "Samples", the categorization would go something like
"Keyboards", "Brass", "Woodwinds", "Synth Leads",
"Pads", "Strings"...
Well, you get the idea.
3) Below "Patches", would basically be the same kind of broad
categories as with samples.
Now, "Loops" is where things get fun. I've been thinking about Mr.
Knecht's comments on building an elegant organization system, which is
something that Acid itself apparently lacks. I think an extensive
metadata system is the best way to accomplish this.
Every loop would have attached to it:
a) Time signature
b) Tempo
c) Key (If applicable. Drum loops, for example, would not need this.)
d) Creator's name
e) Instrument(s) (This one is tricky, since there are so many
instruments in the world. It would need to be a free-text field, which
means misspellings could be a problem. Possible solutions?)
f) Loop or one-shot (Not everything meant for a loop-based composition
program need be an actual loop. Drum fills and cymbal hits come
immediately to mind.)
g) Style (This one creates some issues, due to how subjective it can
be.)
h) Comments (A free text field the creator of the loop can use to
attach whatever additional info they feel it needs.)
i) A million other things I can't think of at the moment. :)
One problem that needs to be solved is how to attach these kinds of
metadata to a loop. Also, another thing to consider are loop sets.
Thinking about the architecture for the web app itself led me to think
about how CPAN works, at least from a user perspective. I would set up
a central index server, which could then redirect clients to the
appropriate mirror to grab a file when a request is made. This also
brings up the idea of a client that could be built that would talk to
the servers from the user's machine. This client could be used to
maintain the organization of all the loops the user chooses to
download. This can be thought about after the main system is up and
running, though.
As for hosting, I have a good lead on a local colo facility. I have
some other projects I need to host anyway.
I apologize for the long email. Hopefully, this will start the ball
rolling, and if all goes well, it won't crush me when I try to catch it.
Regards,
Darren Landrum
who is hoping this hair-brained scheme doesn't spawn another mailing
list. ;)
20 Dec
20 Dec
3:31 a.m.
On Thu, Dec 19, 2002 at 10:06:05PM -0700, Darren Landrum wrote:
Thinking about the architecture for the web app itself
led me to think
about how CPAN works, at least from a user perspective. I would set up
a central index server, which could then redirect clients to the
appropriate mirror to grab a file when a request is made. This also
brings up the idea of a client that could be built that would talk to
the servers from the user's machine. This client could be used to
maintain the organization of all the loops the user chooses to
download. This can be thought about after the main system is up and
running, though.
check out Twisted! it's meant for this kind of thing.
http://www.twistedmatrix.com
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's MINIATURE NOSE HIGH PRIEST!
(courtesy of isometric.spaceninja.com)
9:59 a.m.
On Friday, December 20, 2002, at 12:26 AM, Paul Winkler wrote:
check out Twisted! it's meant for this kind of
thing.
http://www.twistedmatrix.com
Oh, I had forgotten about those guys. I actually had a working Twisted
web site up and running once upon a time. You're right, this may be the
ideal solution.
Another thing I had thought about with the client is possibly
integrating it into whatever program that makes Acid redundant, whether
that turns out to be Ardour or if someone starts the Alkali Project (I
would, but I'm a lousy C coder). That way, you can browse, download,
and organize all of your loops, and then put them together into a song,
and then maybe even record a guitar solo and some vocals. All from
within one program.
Regards,
Darren Landrum
6:11 a.m.
On Thu, Dec 19, 2002 at 10:06:05PM -0700, Darren Landrum wrote:
After some considerable thought as to the best way to
organize such a
library, as well as what a project such as this will do to my free
time, I have a few ideas and questions to present to the list.
Hi, this sounds like an excellent idea, and a wonderful way to use up
all your spare time :))
Every loop would have attached to it:
a) Time signature
b) Tempo
c) Key (If applicable. Drum loops, for example, would not need this.)
d) Creator's name
e) Instrument(s) (This one is tricky, since there are so many
instruments in the world. It would need to be a free-text field, which
means misspellings could be a problem. Possible solutions?)
f) Loop or one-shot (Not everything meant for a loop-based composition
program need be an actual loop. Drum fills and cymbal hits come
immediately to mind.)
g) Style (This one creates some issues, due to how subjective it can
be.)
h) Comments (A free text field the creator of the loop can use to
attach whatever additional info they feel it needs.)
i) A million other things I can't think of at the moment. :)
One problem that needs to be solved is how to attach these kinds of
metadata to a loop.
info on generic metadata for audio formats is at:
http://www.vergenet.net/~conrad/sounds/textual_data.txt
I've just now corrected that document for Ogg Vorbis, and added Speex; if
anyone has any additions or corrections, please let me know.
It would be possible to store all this information in the comments
packet of Ogg Vorbis or Ogg FLAC encoded loops; the vorbiscomment spec
is open enough to allow this. Of course much of this information can
also be stored in WAV chunks, as is done for ACID.
Conrad.
9:50 a.m.
On Friday, December 20, 2002, at 03:06 AM, Conrad Parker wrote:
info on generic metadata for audio formats is at:
http://www.vergenet.net/~conrad/sounds/textual_data.txt
Thank you. That's some useful information.
It would be possible to store all this information in
the comments
packet of Ogg Vorbis or Ogg FLAC encoded loops; the vorbiscomment spec
is open enough to allow this. Of course much of this information can
also be stored in WAV chunks, as is done for ACID.
I hadn't thought too much about what format the loops/sample sets would
be stored as yet, but Ogg FLAC sounds like a good way to go. It would
be lossless, and still give good compression. Otherwise, I suppose some
folks would prefer to post their work as Ogg Vorbis. This could be
arranged as well.
Something else I've been thinking about is a low-quality "preview" that
can work inside a browser, so folks can listen to the contents of a
loop before they download. This would be another good reason for a
dedicated client, since the preview function could be built-in. The
hard part would be generating the preview to begin with. Could this be
a server-side function (i.e., when you upload the file, it makes the
preview file as a 24kbps Ogg or somesuch)? Any thoughts?
Regards,
Darren Landrum
10:23 a.m.
On Fri, Dec 20, 2002 at 06:45:27 -0700, Darren Landrum wrote:
Something else I've been thinking about is a
low-quality "preview" that
can work inside a browser, so folks can listen to the contents of a
loop before they download. This would be another good reason for a
dedicated client, since the preview function could be built-in. The
hard part would be generating the preview to begin with. Could this be
a server-side function (i.e., when you upload the file, it makes the
preview file as a 24kbps Ogg or somesuch)? Any thoughts?
Dedicated clients are bad, this can be made to work in a browser easily.
It wouldn't be hard to add a script to the server to make it produce
preview versions of the file.
I can donate bandwidth, server space, metadata and/or database experience,
but not much time :(
- Steve
10:49 a.m.
On Friday, December 20, 2002, at 07:18 AM, Steve Harris wrote:
Dedicated clients are bad, this can be made to work in
a browser
easily.
Thank you for the reply.
That's one vote for a browser instead of a client. Like I said
previously, it would be best to make all of this work server-side
before really starting on a client. However, like I also said
previously, it seems to me that a client could really be a killer app,
if it's done correctly. It would, however, not be required.
It wouldn't be hard to add a script to the server
to make it produce
preview versions of the file.
That was my thought as well. Best to do as much as possible on the
server side, I think.
I can donate bandwidth, server space, metadata and/or
database
experience,
but not much time :(
That's the second offer to help. :) Thank you.
Since this is in planning, I think database and metadata experience
would be valuable. We can worry about bandwidth and server space for
mirrors when there's a beta of the system ready to deploy.
I have a two-week shutdown at work that I have to make my way through,
starting on Monday. I had hoped to spend that time in Michigan with
family, but if for some reason (involving the recent purchase of a
home) that doesn't happen, I'll have plenty of time to work on this.
I would also like to thank everyone for their support and ideas. This
is something that could really take off. Exciting, isn't it? :)
Regards,
Darren Landrum
21 Dec
21 Dec
11:53 p.m.
On Fri, Dec 20, 2002 at 07:44:29AM -0700, Darren Landrum wrote:
On Friday, December 20, 2002, at 07:18 AM, Steve Harris wrote:
how about:
* use an existing open protocol for searching and query, eg. LDAP
* make an LDAP schema that matches the Ogg metadata schema used
then ...
* any app can hook into the resource using a known protocol, reducing
the requirement for a specific standalone client (or, conversely, an
existing LDAP query tool can be used)
* the web frontend simply becomes a web interface to the LDAP querying
server architecture:
1. a web server full of files, which users can upload to
2. when files are uploaded, the Ogg metadata is scanned, and checked
for a valid license, eg. creative commons
3. if so, it is moved to a public area on the web server, thus giving
the file a static URL
4. an entry is stored in the LDAP database with the metadata and the
static URL of the file.
this way the components of the system -- storage, query, web frontend,
and any number of clients -- would be fairly independent, and nothing
would need to be reinvented.
I'd be willing to work on the random bits of C coding required, eg.
scanning Ogg metadata.
The upshot of this is that an app, eg. a loop sequencing app, could
query the server directly for loops matching the tempo, pitch and
style etc. of the project being worked on ...
Conrad.
Dedicated clients are bad, this can be made to
work in a browser
easily.
Thank you for the reply.
That's one vote for a browser instead of a client. Like I said
previously, it would be best to make all of this work server-side
before really starting on a client. However, like I also said
previously, it seems to me that a client could really be a killer app,
if it's done correctly. It would, however, not be required.
23 Dec
23 Dec
10:08 a.m.
On Sun, Dec 22, 2002 at 02:48:05 +1100, Conrad Parker wrote:
how about:
* use an existing open protocol for searching and query, eg. LDAP
* make an LDAP schema that matches the Ogg metadata schema used
Good idea, but OAI (Open Archive Initiave) query qouldbe more useful:
http://www.openarchives.org/
There are quite a few OAI clients allready. And there is some metadata
mirroring software.
- Steve
11:03 a.m.
On Monday, December 23, 2002, at 07:02 AM, Steve Harris wrote:\
Good idea, but OAI (Open Archive Initiave) query
qouldbe more useful:
http://www.openarchives.org/
I remember reading about this once upon a time. This looks like it
could be very useable. Thanks for the link. :)
Regards,
Darren Landrum
20 Dec
20 Dec
10:07 a.m.
> a) Time signature
> b) Tempo
> c) Key (If applicable. Drum loops, for example, would not need
> this.) d) Creator's name
> e) Instrument(s) (This one is tricky, since there are so many
> instruments in the world. It would need to be a free-text field,
> which means misspellings could be a problem. Possible solutions?)
you could use the same categories for instruments that you have in your
samples section...
> f) Loop or one-shot (Not everything meant for a
loop-based
> composition program need be an actual loop. Drum fills and cymbal
> hits come immediately to mind.)
I think that might be confusing - maybe one shot samples could go into
the samples section? drum fills will generally loop - many great drum
tracks have been programmed entirely from drum fills :) . What i'm
trying to say is that its a fine line between a drum fill and a drum
beat, so fills could go in loops.
> g) Style (This one creates some issues, due to
how subjective it can
> be.)
> h) Comments (A free text field the creator of the loop can use to
> attach whatever additional info they feel it needs.)
> i) A million other things I can't think of at the moment. :)
One problem
that needs to be solved is how to attach these kinds of
metadata to a loop.
10:37 a.m.
On Friday, December 20, 2002, at 07:00 AM, matthew yee-king wrote:
you could use the same categories for instruments that
you have in your
samples section...
Thank you very much for your reply.
I think the instrument or instruments used in a loop would need to be
more specific. You can't just say that the loop was made with a
woodwind. You would need to specify that it was a recorder, or a
piccolo, or an oboe.
However, this does give a good place to start. This data field could be
hierarchical, where a person selects the general category (like
woodwind), then types in a specific instrument. That brings with it its
own problem, though: someone can select woodwind then type "marimba",
because they accidently selected the wrong category.
I think that might be confusing - maybe one shot
samples could go into
the samples section? drum fills will generally loop - many great drum
tracks have been programmed entirely from drum fills :) . What i'm
trying to say is that its a fine line between a drum fill and a drum
beat, so fills could go in loops.
Good point. I thought about this a little more, and I think the person
using this Acid clone will be smart enough to know that you don't
actually have to loop a loop. :)
Maybe the database could store a checksum of the file
and link the
metadata to this. This could work in a similar way to the cddb - you
could look up the data for your file. I can help with the database if
you want ...
This is cool. I have an offer to help already. :) Thank you.
There was a previous email on how Ogg can store a lot of different
metadata as key/value pairs. That would be the ideal solution, but if
it doesn't pan out for some reason, checksums would be a good way to go.
And of course, this brings us to more discussion on the client for this
system, which seems to me to be the killer part of the entire app.
(Don't worry, I still plan to make the system usable only with a
browser.)
It seems to me that the easy way to embed metadata into each loop would
be with the client (in fact, the client can even act as a front end to
the Vorbis/FLAC encoder). When a person makes a loop, they would load
it into the client, add the data via a form, and then the client can
automatically upload it to the appropriate place.
Which brings up the question on how to do all of the same things
without a client.
It seems to me that a person could upload a file, and the server can
check it to see if there's any metadata. If not, then it could put the
file in a holding area and forward the user to a form where they can
enter the data. The server could then embed the data, and shuffle it
off to the appropriate mirror.
This is going to be *a lot* of work. There goes all of my free time. :)
Regards,
Darren Landrum
21 Dec
21 Dec
3:55 p.m.
don't know if i've mentioned this before, but I'd really
like to see this project succeed. I could donate all kinds
of odd little homemade loops :)
I just thought of some other useful metadata:
j) length in seconds (should be able to extract this from the file)
k) length in beats (should be able to compute this from a, b, and b1)
l) no. of channels (typically 1 or 2) (extract from file)
m) sample rate (extract from file)
n) bit depth (extract from file)
o) license (public domain? bsd-ish? dsl? etc)
p) creation date
q) revision date (what if you tweak your loop and re-release it?)
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's THE COATED WARRIOR!
(courtesy of isometric.spaceninja.com)
Every loop
would have attached to it:
a) Time signature
b) Tempo
c) Key (If applicable. Drum loops, for example, would not need this.)
> d) Creator's name
> e) Instrument(s) (This one is tricky, since there are so many
> instruments in the world. It would need to be a free-text field, which
> means misspellings could be a problem. Possible solutions?)
> f) Loop or one-shot (Not everything meant for a loop-based composition
> program need be an actual loop. Drum fills and cymbal hits come
> immediately to mind.)
> g) Style (This one creates some issues, due to how subjective it can
> be.)
> h) Comments (A free text field the creator of the loop can use to
> attach whatever additional info they feel it needs.)
> i) A million other things I can't think of at the moment. :)
22 Dec
22 Dec
2:02 a.m.
All very good suggestions. I'll add them to the master list currently
being maintained on a small whiteboard. :)
Regards,
Darren Landrum
On Saturday, December 21, 2002, at 12:50 PM, Paul Winkler wrote:
don't know if i've mentioned this before, but
I'd really
like to see this project succeed. I could donate all kinds
of odd little homemade loops :)
I just thought of some other useful metadata:
j) length in seconds (should be able to extract this from the file)
k) length in beats (should be able to compute this from a, b, and b1)
l) no. of channels (typically 1 or 2) (extract from file)
m) sample rate (extract from file)
n) bit depth (extract from file)
o) license (public domain? bsd-ish? dsl? etc)
p) creation date
q) revision date (what if you tweak your loop and re-release it?)
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's THE COATED WARRIOR!
(courtesy of isometric.spaceninja.com)
23 Dec
23 Dec
9:49 a.m.
On Sat, Dec 21, 2002 at 11:50:00 -0800, Paul Winkler wrote:
o) license (public domain? bsd-ish? dsl? etc)
I think it would make sense to limit the archive to one license, it makes
things much less complex.
p) creation date
q) revision date (what if you tweak your loop and re-release it?)
And the ID of the source sample (if its in the achive).
- Steve
10:36 a.m.
On Monday 23 December 2002 1:44 pm, Steve Harris wrote:
On Sat, Dec 21, 2002 at 11:50:00 -0800, Paul Winkler
wrote:
Careful, you might start a license war :)
Seriously, there are many different conditions people might want to put on
the use of their samples: Should they be free for use for any purpose, or
restricted for use in commercial projects? Can they be used without
crediting their creator? Can they be re-distributed in a modified form? As
part of a song? Should the liecense be copyleft? I'm sure there are more.
You could argue that some of these are not "free", but there is no direct
analogy between audio and source code and so, to me at least, there is no
real definition of free audio like there is for software. So if you do go
for a single license, it'll need a lot of thought about which one.
o) license (public domain? bsd-ish? dsl? etc)
I think it would make sense to limit the archive to one license, it makes
things much less complex. 
10:48 a.m.
On Mon, Dec 23, 2002 at 02:34:55PM +0000, Nathaniel Virgo wrote:
(cut)
You could argue that some of these are not
"free", but there is no direct
analogy between audio and source code and so, to me at least, there is no
real definition of free audio like there is for software. So if you do go
for a single license, it'll need a lot of thought about which one.
(cut)
The Creative Commons website is devoted to this.
Check it out.
v
10:58 a.m.
On Mon, Dec 23, 2002 at 02:34:55 +0000, Nathaniel Virgo wrote:
On Monday 23 December 2002 1:44 pm, Steve Harris
wrote:
Right, so to avoid licence hell I think its neccesary to limit to one
licence. Views aren't entrenched enough yet to make this really
contraversial.
As long as the licence is not too wierd and does what people want you will
get people to use it.
I dont want to have to read a huge, complex licence every time I want to
download a sample. If you allow a variety of licences you will get it ;)
- Steve
On Sat, Dec 21, 2002 at 11:50:00 -0800, Paul
Winkler wrote:
Careful, you might start a license war :)
Seriously, there are many different conditions people might want to put on
the use of their samples: Should they be free for use for any purpose, or
restricted for use in commercial projects? Can they be used without
crediting their creator? Can they be re-distributed in a modified form? As
part of a song? Should the liecense be copyleft? I'm sure there are more. o) license (public domain? bsd-ish? dsl? etc)
I think it would make sense to limit the archive to one license, it makes
things much less complex. 
20 Dec
20 Dec
11:34 a.m.
Darren,
I'm glad to see someone interested in taking up this area of operation.
The use of prerecorded sounds, whether one-shots or loops will, I think, be
of a lot of value. I'm also glad to see that you're getting lots of
responses. That's pretty key also.
I've read through the other responses that have come in so far. Let me
add a couple of things that I don't think have been covered yet.
1) There are lots of places on the web today that offer samples and loops
for sale. You might want to look at some of them just to see how they
present their offerings. Your #2 below reminds me a lot of WizooSounds.
(http://www.wizoosounds.com/cgi-bin/WebObjects/wizoosounds) Note the menus
on the left side of the page. You can buy for GigaSampler, Halion, etc. or
just loop libraries, based on what you're looking for. Yu can play small
bits of the sounds. I've purchased stuff here and been pretty happy with
their service. Obviously we're not talking about a Linux for-sale site in
your case, but they have a pretty good presentation model, I think. I can
provide you with other sites if you need them. A less sophisticated model
might be something like the free site Worra's Place (www.worrasplace.com)
Worra offers nice (and free!) gig files for the GigaSampler and GigaStudio
communities. The web site offers very little in terms of understanding the
sound before you download it.
2) In my experience in Acid, the hard part is not finding 'Drum loops at the
right tempo', but rather finding the right loops that can go together a make
a natural sounding piece of music. Taking drums as an example, if I'm
working at 142BPM, it's not difficult to find loops that are drums at
142BPM. What's difficult is figuring out how to use them. Which loops are
main rhythms? Which loops are fills? Which loops are breaks? Which loops are
best for intros or endings? When you start listening to these loops, do the
kick patterns, or the beat the snare is used on, actually stay consistent
from loop to loop and work together?
It's very easy to become a loop packrat, but then not be able to figure
out where the right loop is to actually do the music.
Along these lines I long for an app that can take rhythm loops and
somehow arrange them, under my guidance, into a song. The more you work with
loops, the more you'll understand this problem. (If you don't already.) I
was pretty attracted (in concept anyway) to a rhythm generator in the Jazz
sequencer. In that tool you could tell it you wanted a kick on 2 and 4, and
how to build fills and what not, but I get to bogged down in programming and
don't do music when I use it. Too bad.
This idea is attractive to me though. Can you do something new in terms
of how loops are categorized? Can you understand where the kick is? Where
the snare is? Can you then 'suggest' loops that might work together for
preview? This is where I think the next step in using this stuff has got to
go.
3) As for loop storage format, something standard and natively usable in
whatever app is preferable. Wave probably works for the most apps today, but
anything that's common should suffice.
4) Last, it's really important that the library doesn't get corrupted with
stuff that shouldn't be there. Worra has had problems with people submitting
for-sale gig files and saying they were free and open. I could supply you
with lots of loops that I've purchased and corrupt your library. This might
also put you at risk of some liability or suit. I wouldn't want to see that.
Anyway, I'll be here to talk about is and use it as you develop your
ideas. Good luck!
Cheers,
Mark
-----Original Message-----
From: linux-audio-user-admin(a)music.columbia.edu
[mailto:linux-audio-user-admin@music.columbia.edu]On Behalf Of Darren
Landrum
Sent: Thursday, December 19, 2002 9:06 PM
To: linux-audio-user(a)music.columbia.edu
Subject: [linux-audio-user] The Open Loop Library, a few questions
After some considerable thought as to the best way to organize such a
library, as well as what a project such as this will do to my free
time, I have a few ideas and questions to present to the list.
I'll start with the easy one first.
1) What exactly would this library hold? There's no need for this to be
restricted to loops. It could also contain other "musical raw
material", such as sample sets and softsynth patches. In that case,
calling it the Open Loop Library makes little sense. What else do you
think would work? Open Music Library? Sounds like it's a repository for
music, not for raw components. The upshot to the Open Loop Library name
is that the domain openloops.org is available. It also makes a good
working name for now.
Really, that was the main question, and it brings part of the proposal
with it. I would like to design and build a web service to act as a
library for loops, sample sets, and patches. Here are some thought on
the overall design.
1) The top level hierarchy would be (obviously enough) "Samples",
"Loops", and "Patches".
2) Below "Samples", the categorization would go something like
"Keyboards", "Brass", "Woodwinds", "Synth Leads",
"Pads", "Strings"...
Well, you get the idea.
3) Below "Patches", would basically be the same kind of broad
categories as with samples.
Now, "Loops" is where things get fun. I've been thinking about Mr.
Knecht's comments on building an elegant organization system, which is
something that Acid itself apparently lacks. I think an extensive
metadata system is the best way to accomplish this.
Every loop would have attached to it:
a) Time signature
b) Tempo
c) Key (If applicable. Drum loops, for example, would not need this.)
d) Creator's name
e) Instrument(s) (This one is tricky, since there are so many
instruments in the world. It would need to be a free-text field, which
means misspellings could be a problem. Possible solutions?)
f) Loop or one-shot (Not everything meant for a loop-based composition
program need be an actual loop. Drum fills and cymbal hits come
immediately to mind.)
g) Style (This one creates some issues, due to how subjective it can
be.)
h) Comments (A free text field the creator of the loop can use to
attach whatever additional info they feel it needs.)
i) A million other things I can't think of at the moment. :)
One problem that needs to be solved is how to attach these kinds of
metadata to a loop. Also, another thing to consider are loop sets.
Thinking about the architecture for the web app itself led me to think
about how CPAN works, at least from a user perspective. I would set up
a central index server, which could then redirect clients to the
appropriate mirror to grab a file when a request is made. This also
brings up the idea of a client that could be built that would talk to
the servers from the user's machine. This client could be used to
maintain the organization of all the loops the user chooses to
download. This can be thought about after the main system is up and
running, though.
As for hosting, I have a good lead on a local colo facility. I have
some other projects I need to host anyway.
I apologize for the long email. Hopefully, this will start the ball
rolling, and if all goes well, it won't crush me when I try to catch it.
Regards,
Darren Landrum
who is hoping this hair-brained scheme doesn't spawn another mailing
list. ;)
4:18 p.m.
On Friday, December 20, 2002, at 08:29 AM, Mark Knecht wrote:
Darren,
I'm glad to see someone interested in taking up this area of
operation.
The use of prerecorded sounds, whether one-shots or loops will, I
think, be
of a lot of value. I'm also glad to see that you're getting lots of
responses. That's pretty key also.
Thank you. I'm glad that my first posts to this email list are
productive ones. I really would like to get this project off the
ground, and do it in such a way that we solve some problems that Sonic
Foundry never did.
1) There are lots of places on the web today that
offer samples and
loops
for sale. You might want to look at some of them just to see how they
present their offerings. Your #2 below reminds me a lot of WizooSounds.
(http://www.wizoosounds.com/cgi-bin/WebObjects/wizoosounds) Note the
menus
on the left side of the page. *** <snip> *** A less sophisticated model
might be something like the free site Worra's Place
(www.worrasplace.com)
Worra offers nice (and free!) gig files for the GigaSampler and
GigaStudio
communities. The web site offers very little in terms of understanding
the
sound before you download it.
Thanks for the URLs. I'm in the process of fixing up and moving into my
new house, but I will go look at these as soon as I can. Fortunately, I
can keep my cable modem in the new place.
2) In my experience in Acid, the hard part is not
finding 'Drum loops
at the
right tempo', but rather finding the right loops that can go together
a make
a natural sounding piece of music. Taking drums as an example, if I'm
working at 142BPM, it's not difficult to find loops that are drums at
142BPM. What's difficult is figuring out how to use them. Which loops
are
main rhythms? Which loops are fills? Which loops are breaks? Which
loops are
best for intros or endings? When you start listening to these loops,
do the
kick patterns, or the beat the snare is used on, actually stay
consistent
from loop to loop and work together?
This presents an interesting challenge. The client I mentioned earlier
can be used to download and organize your loops. Since their metadata
would be intact, you could search for any aspect of this metadata.
It's very easy to become a loop packrat, but
then not be able to
figure
out where the right loop is to actually do the music.
Well, the tool could help keep your loops organized, but it would still
be up to you to keep good organization, and to have a general idea of
what you have. Then the search utility becomes useful. ("Well, I can't
remember which loop that was I found, but I remember it was 125 BPM and
the creator's name was...")
Suddenly, you can narrow it down to a few possibilities.
This idea is attractive to me though. Can you do
something new in
terms
of how loops are categorized? Can you understand where the kick is?
Where
the snare is? Can you then 'suggest' loops that might work together for
preview? This is where I think the next step in using this stuff has
got to
go.
I will have to think on this one a lot more, because this sounds like
it would require coding skills beyond what I have. I'm really just a
web developer. I've never used C, C++, or even Java for that matter.
Most of my experience is in Perl, and some Python (and HTML/XML, of
course).
4) Last, it's really important that the library
doesn't get corrupted
with
stuff that shouldn't be there. Worra has had problems with people
submitting
for-sale gig files and saying they were free and open. I could supply
you
with lots of loops that I've purchased and corrupt your library. This
might
also put you at risk of some liability or suit. I wouldn't want to see
that.
I have an idea here, involving the checksum idea that Matthew presented
a few emails back. I want to think on it a little more, and then
present it to everyone. That email will also present a metadata
tracking idea.
Anyway, I'll be here to talk about is and use
it as you develop your
ideas. Good luck!
Thank you! I look forward to creating something that's actually useful
for a change. :)
Regards,
Darren Landrum
21 Dec
21 Dec
12:48 p.m.
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
4:27 p.m.
Darren,
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
loop. (Bummer!)
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
good music!!
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
you check?
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
happen.
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
helpful too.
Cheers,
Mark
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
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
22 Dec
22 Dec
2:27 a.m.
This is starting to get interesting. :)
My responses are embedded below. Thanks.
On Saturday, December 21, 2002, at 01:24 PM, Mark Knecht wrote:
Darren,
Excellent ideas. A couple of things to keep in mind:
Thank you. There' still a lot of basic groundwork to lay out, but I
think we're getting somewhere.
Unfortunately, I can't really comment on every one of your points at
the moment, as there are some other threads of thought going in those
directions. That, and it's getting late for me. :)
There is, however, one point I can address immediately...
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
happen.
I have a line with a local colocation facility that will afford me
upwards of 400GB of bandwidth for a reasonable cost (the
back-of-the-envelope calculation was around $105 US). I also asked
questions about their building, and the backbone connections they have
(dual DS3s to two different backbones). I would have to buy parts and
build a server, but that's not a big deal.
Also, I was going to model this system roughly after CPAN, where there
are many mirrors with a central index. You query the index, and it
knows where to go get the file (or where to put it). You never have to
know where the file is actually coming from. I don't think this would
be too difficult to put together.
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
helpful too.
As would I. I guess that's why I started this whole thing. :) I just
hope I didn't bite off too much, what with moving and all.
By the way, just to let everyone know, I may be incommunicado for a few
days next week while the move occurs. Just FYI. Thanks!
Regards,
Darren Landrum
23 Dec
23 Dec
9:58 a.m.
On Sat, Dec 21, 2002 at 12:24:16 -0800, Mark Knecht wrote:
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
good music!!
Thats a good point, using checksums to spot "illegal" loops wont work,
just converting it to 256kbit ogg and back will change the checksum, and
it it came of an audio sample CD you have no chance.
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
happen.
At this point it will require real cash to run it. My website costs around
$400 a year for around 10 Gbytes a month with a reputable ISP. A sample
archive will most likly be a lot heavier.
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
helpful too.
I think Dave of SSM fame has started one, but its hosted off one of the
not-so-good mailing list providers IIRC. This would be a good thing to
integrate with a sample archive.
I used to run the Nord Modular patch archive, so I know a bit about this.
The way that worked was that there was a mailing list and whenever someone
posted a patch as an attchment to the list it got archived, and and linked
to the list discussion.
In reverse that might be a really good way of annotating samples and
patches:
When someone uploads a patch it creates a mail to a mailing list and the
discussion cna be linked to the achive entry. You could also allow later,
web based discussion to be added.
- Steve
21 Dec
21 Dec
6:49 p.m.
On Sat, 21 Dec 2002, Darren Landrum wrote:
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.
This might not be good enough. Modifying a file in the slightest way will
change the MD5 enought to get past a filter, but not a lawyer. It'll only
guard against innocent uploading, not malecious.
Taybin
--
http://www.piratesvsninjas.com
22 Dec
22 Dec
2:05 a.m.
I was afraid of this, given my lack of knowledge of how MD5 checksums
work.
The fact is, though, is we need a way to nip possible piracy in the
bud. This seems like a good idea, but maybe MD5 isn't the way to go.
Are there any other ways we can "profile" a piece of audio?
Regards,
Darren Landrum
On Saturday, December 21, 2002, at 03:44 PM, Taybin Rutkin wrote:
This might not be good enough. Modifying a file in
the slightest way
will
change the MD5 enought to get past a filter, but not a lawyer. It'll
only
guard against innocent uploading, not malecious.
Taybin
--
http://www.piratesvsninjas.com
2:10 a.m.
On Sat, 21 Dec 2002, Darren Landrum wrote:
The fact is, though, is we need a way to nip possible
piracy in the
bud. This seems like a good idea, but maybe MD5 isn't the way to go.
Are there any other ways we can "profile" a piece of audio?
I believe the RIAA are working on audio identification algorithms. That
seems like a very theoritical area currently though.
The most practical thing I can think of is to use "lazy evaluation" and
just wait for someone to complain about a piece and then take it down.
Taybin
--
http://www.piratesvsninjas.com
2:42 a.m.
It's really more a political problem than a technical one, isn't it? MD5
checksums may still be useful as part of a strategy of making it clear
to all interested parties that one is doing what one can to keep
materials that are not legitimately publicly distributable out of the
library. Anyone who demands more than that has clearly abandoned
reasonableness and can only be dealt with by unreasonable means.
On Sunday 22 December 2002 12:59 am, Darren Landrum wrote:
I was afraid of this, given my lack of knowledge of
how MD5 checksums
work.
The fact is, though, is we need a way to nip possible piracy in the
bud. This seems like a good idea, but maybe MD5 isn't the way to go.
Are there any other ways we can "profile" a piece of audio?
Regards,
Darren Landrum
On Saturday, December 21, 2002, at 03:44 PM, Taybin Rutkin wrote:
> This might not be good enough. Modifying a file in the slightest
> way will
> change the MD5 enought to get past a filter, but not a lawyer.
> It'll only
> guard against innocent uploading, not malecious.
>
> Taybin
> --
> http://www.piratesvsninjas.com
--
"Can you remember the future? Forget it!"
10:22 a.m.
I think this is a good point. A company which will deal with that
situation only by lawsuits and demands to shut down the system is
clearly out to destroy, and nothing you do will stop that goal.
I guess it all depends on the company. Most of the loop-makers and
sample-makers are small companies, specializing in only their areas.
Would a company like that be unreasonable, or would they be willing to
accept that we are doing all we can to keep our library uncorrupted?
Regards,
Darren Landrum
On Saturday, December 21, 2002, at 11:35 PM, Speaker to Vegetables
wrote:
It's really more a political problem than a
technical one, isn't it?
MD5
checksums may still be useful as part of a strategy of making it clear
to all interested parties that one is doing what one can to keep
materials that are not legitimately publicly distributable out of the
library. Anyone who demands more than that has clearly abandoned
reasonableness and can only be dealt with by unreasonable means.
10:35 a.m.
Often, for legal reasons, the owner of the copyrighted loop would have
to come after you to protect their copyrights. If a loops company
chooses to let someone distribute their loops without proper licensing,
even in small amounts, then when a big company comes along and does the
same thing, the big company can say the loop manufacturer has
demonstrated that they don't care about their copyrights.
However, I think that this isn't where you want to be anyway, since
you're not interested in distributing copyrighted loops. (Right?)
I'd think you'd want to get in touch with a couple of loop owners and
find out how you could keep your library clean and also keep them happy.
Maybe if you put the onus on them to provide the loop information, so
that you can keep the library clean, then if they don't you can say they
didn't care.
On Sun, 2002-12-22 at 06:17, Darren Landrum wrote:
I think this is a good point. A company which will
deal with that
situation only by lawsuits and demands to shut down the system is
clearly out to destroy, and nothing you do will stop that goal.
I guess it all depends on the company. Most of the loop-makers and
sample-makers are small companies, specializing in only their areas.
Would a company like that be unreasonable, or would they be willing to
accept that we are doing all we can to keep our library uncorrupted?
Regards,
Darren Landrum
On Saturday, December 21, 2002, at 11:35 PM, Speaker to Vegetables
wrote:
It's really more a political problem than a
technical one, isn't it?
MD5
checksums may still be useful as part of a strategy of making it clear
to all interested parties that one is doing what one can to keep
materials that are not legitimately publicly distributable out of the
library. Anyone who demands more than that has clearly abandoned
reasonableness and can only be dealt with by unreasonable means.
10:46 a.m.
On Sun, Dec 22, 2002 at 06:31:26AM -0800, Mark Knecht wrote:
(cut)
However, I think that this isn't where you want to
be anyway, since
you're not interested in distributing copyrighted loops. (Right?)
(cut)
Good point.
Maybe we should only serve loops that fall under
a usable creative commons license
[http://www.creativecommons.org/].
Its not interesting to serve loops on which
the original owner wants to exercise copyright
on anyway, because then its not exactly an
open loop library anymore.
v
11:14 a.m.
On Sunday, December 22, 2002, at 07:42 AM, Vincent Touquet wrote:
Good point.
Maybe we should only serve loops that fall under
a usable creative commons license
[http://www.creativecommons.org/].
Its not interesting to serve loops on which
the original owner wants to exercise copyright
on anyway, because then its not exactly an
open loop library anymore.
Oh, I see what you're saying now. I still need to have my morning cup
of coffee, so I'm a little slow. :)
Indeed, part of the metadata should contain the license (which was
added to the list by Paul in a previous post), and the license should
meet a minimum "openness" standard before it can be accepted.
I've actually been keeping a close eye on the Creative Commons in
relation to another project I've been involved with (but not at liberty
yet to speak about, because I didn't start it). I think creating a
selection of CC licenses and having them available to choose from would
be the way to go, the same way SourceForge allows you to choose from a
list of licenses (or at least, that's how I understand it works).
Regards,
Darren Landrum
11:27 a.m.
On Sun, 2002-12-22 at 06:42, Vincent Touquet wrote:
Its not interesting to serve loops on which
the original owner wants to exercise copyright
on anyway, because then its not exactly an
open loop library anymore.
v
Certainly true, but the problem arises when a user puts a copyrighted
loop in the library, and I think Darren is looking for ways to help
ensure this doesn't happen. I agree that he should at least think about
this.
4:20 p.m.
i do think its worrying though if we end up stooping to the depths of
DRM strategies when we're trying to create something that will
*encourage* freedom and not destroy it as everyone else seems to be doing...
m~
Mark Knecht wrote:
Certainly true, but the problem arises when a user
puts a copyrighted
loop in the library, and I think Darren is looking for ways to help
ensure this doesn't happen. I agree that he should at least think about
this.
--
iriXx
www.iriXx.org
copyleft: creativity, technology and freedom?
info(a)copyleftmedia.org.uk
www.copyleftmedia.org.uk
_
( ) ascii ribbon against html email
X
/ \ cat /dev/sda1 > /dev/dsp
*** stopping make sense ***
6:45 p.m.
Yes, it is regrettable. It is regrettable that there are people out
there that are not to be trusted. It is regrettable that many of those
self-same people would stoop to such actions as uploading a loop or a
sample set that they have no rights to *because* they want to damage
such open initiatives.
I very highly doubt that anyone I've talked to on this list would ever
be the cause of such problems.
And yet, there are people out there who are malicious because they like
to cause trouble, or sometimes even because someone is paying them.
Then all it takes is a pack of attack lawyers. It's happened before,
and it can happen to us.
I do not want to implement any DRM measures. I simply want to catch
people trying to do such things as I described above and be able to
deal with them, quietly if possible.
Personally, I think a web of trust is the best way to go. If we make
accounts difficult to get, and to spoof, then users uploading illegal
materials will (hopefully, anyway) leave behind an audit trail that can
lead us to them.
Remember, we aren't just talking about audio loops and samples, here.
You could gzip up some illicit jpegs featuring some activities that
would make your stomach turn, not to mention attract the authorities to
the ones running the system. Unfortunately, file shares like this one
are ripe for that kind of abuse if proper steps aren't taken. (As a
side note, we had already figured out a way to deal with this kind of
activity, but I leave it here as an example.)
Sorry if I rambled on my soapbox a little too long, but this is a sore
point of mine. You just can't automatically trust everyone. You need
some checks and balances in the system.
Regards,
Darren Landrum
On Sunday, December 22, 2002, at 01:13 PM, iriXx wrote:
i do think its worrying though if we end up stooping
to the depths of
DRM strategies when we're trying to create something that will
*encourage* freedom and not destroy it as everyone else seems to be
doing...
m~
Mark Knecht wrote:
Certainly true, but the problem arises when a
user puts a copyrighted
loop in the library, and I think Darren is looking for ways to help
ensure this doesn't happen. I agree that he should at least think
about
this.
--
iriXx
www.iriXx.org
copyleft: creativity, technology and freedom?
info(a)copyleftmedia.org.uk
www.copyleftmedia.org.uk
_
( ) ascii ribbon against html email
X
/ \ cat /dev/sda1 > /dev/dsp
*** stopping make sense ***
6:55 p.m.
On Sun, Dec 22, 2002 at 03:39:58PM -0700, Darren Landrum wrote:
(cut)
Sorry if I rambled on my soapbox a little too long, but
this is a sore
point of mine. You just can't automatically trust everyone. You need
some checks and balances in the system
(cut)
Check the trust system on advogato.org.
I don't know the details, just that
they worked hard to make it right and robust.
regards
v
7:04 p.m.
Thank you, Vincent.
They have some pages that describe how the "trust metric" works, and it
looks like some useful information.
Regards,
Darren Landrum
On Sunday, December 22, 2002, at 03:51 PM, Vincent Touquet wrote:
On Sun, Dec 22, 2002 at 03:39:58PM -0700, Darren
Landrum wrote:
(cut)
Sorry if I rambled on my soapbox a little too
long, but this is a sore
point of mine. You just can't automatically trust everyone. You need
some checks and balances in the system
(cut)
Check the trust system on advogato.org.
I don't know the details, just that
they worked hard to make it right and robust.
regards
v
7:15 p.m.
New subject: [linux-audio-user] The Open Music Resource Library, a few questions
Okay, I feel like I should apologize to the list for this diatribe. I
am sorry if I offended anyone or broke any rules.
I just want to make it clear that the Open Music Resource Library is
not a napster for Acid loops. That's all. (You know, I should change
the topic to reflect the new name of the library.) (... And done.) :)
Also, I would like to thank everyone for your input, feedback, and
offers for help. I feel that this library site will be built, and will
be successful, and it will be because of the community, and all of us
here.
And with that, I need to go back to prepping my new house for painting.
I'll be back on later tonight.
Regards,
Darren Landrum
On Sunday, December 22, 2002, at 03:39 PM, Darren Landrum wrote:
Yes, it is regrettable. It is regrettable that there
are people out
there that are not to be trusted. It is regrettable that many of those
self-same people would stoop to such actions as uploading a loop or a
sample set that they have no rights to *because* they want to damage
such open initiatives.
I very highly doubt that anyone I've talked to on this list would ever
be the cause of such problems.
And yet, there are people out there who are malicious because they
like to cause trouble, or sometimes even because someone is paying
them. Then all it takes is a pack of attack lawyers. It's happened
before, and it can happen to us.
I do not want to implement any DRM measures. I simply want to catch
people trying to do such things as I described above and be able to
deal with them, quietly if possible.
Personally, I think a web of trust is the best way to go. If we make
accounts difficult to get, and to spoof, then users uploading illegal
materials will (hopefully, anyway) leave behind an audit trail that
can lead us to them.
Remember, we aren't just talking about audio loops and samples, here.
You could gzip up some illicit jpegs featuring some activities that
would make your stomach turn, not to mention attract the authorities
to the ones running the system. Unfortunately, file shares like this
one are ripe for that kind of abuse if proper steps aren't taken. (As
a side note, we had already figured out a way to deal with this kind
of activity, but I leave it here as an example.)
Sorry if I rambled on my soapbox a little too long, but this is a sore
point of mine. You just can't automatically trust everyone. You need
some checks and balances in the system.
Regards,
Darren Landrum
7:31 p.m.
New subject: [linux-audio-user] The Open Music Resource Library, a few questions
hey, no, dont apologise.
this raises important and interesting questions.... especially given
that we all know certain groups, no names mentioned, who have gone to
some fairly extreme lengths to discredit the GPL. i think your concerns
about security are valid and often overlooked.
i've taken the liberty of dropping you a line privately (rather than get
further OT with a plug for my book!) but i'd be really interested in
discussing this with you further.
best
m~ (miriam)
Darren Landrum wrote:
Okay, I feel like I should apologize to the list for
this diatribe. I am
sorry if I offended anyone or broke any rules.
I just want to make it clear that the Open Music Resource Library is not
a napster for Acid loops. That's all. (You know, I should change the
topic to reflect the new name of the library.) (... And done.) :)
Also, I would like to thank everyone for your input, feedback, and
offers for help. I feel that this library site will be built, and will
be successful, and it will be because of the community, and all of us here.
And with that, I need to go back to prepping my new house for painting.
I'll be back on later tonight.
Regards,
Darren Landrum
On Sunday, December 22, 2002, at 03:39 PM, Darren Landrum wrote:
--
iriXx
www.iriXx.org
copyleft: creativity, technology and freedom?
info(a)copyleftmedia.org.uk
www.copyleftmedia.org.uk
_
( ) ascii ribbon against html email
X
/ \ cat /dev/sda1 > /dev/dsp
*** stopping make sense ***
Yes, it is regrettable. It is regrettable that
there are people out
there that are not to be trusted. It is regrettable that many of those
self-same people would stoop to such actions as uploading a loop or a
sample set that they have no rights to *because* they want to damage
such open initiatives.
I very highly doubt that anyone I've talked to on this list would ever
be the cause of such problems.
And yet, there are people out there who are malicious because they
like to cause trouble, or sometimes even because someone is paying
them. Then all it takes is a pack of attack lawyers. It's happened
before, and it can happen to us.
I do not want to implement any DRM measures. I simply want to catch
people trying to do such things as I described above and be able to
deal with them, quietly if possible.
Personally, I think a web of trust is the best way to go. If we make
accounts difficult to get, and to spoof, then users uploading illegal
materials will (hopefully, anyway) leave behind an audit trail that
can lead us to them.
Remember, we aren't just talking about audio loops and samples, here.
You could gzip up some illicit jpegs featuring some activities that
would make your stomach turn, not to mention attract the authorities
to the ones running the system. Unfortunately, file shares like this
one are ripe for that kind of abuse if proper steps aren't taken. (As
a side note, we had already figured out a way to deal with this kind
of activity, but I leave it here as an example.)
Sorry if I rambled on my soapbox a little too long, but this is a sore
point of mine. You just can't automatically trust everyone. You need
some checks and balances in the system.
Regards,
Darren Landrum
23 Dec
23 Dec
7:41 a.m.
Maybe we should only serve loops that fall under
a usable creative commons license
There are quite a few open audio licences.
Here's one I wrote which permits sharing but prohibits resale:
http://mondodesigno.com/music/pml.html
Might be good for someone who wants to share loops but reserve the right to
sell them. The way I figure it, if anybody is selling music it should be the
original artist.
Its not interesting to serve loops on which
the original owner wants to exercise copyright
on anyway, because then its not exactly an
open loop library anymore.
One of the pillars of free software licences is that the author retains
copyright - but uses it in a creative way. Copyright gives you the power to
say "I want this loop to remain free". Put it in the public domain and it
could end up part of a proprietary product - and then the creator could be
sued for 'ripping off' their own work.
Cheers
Daniel
10 a.m.
On Sun, Dec 22, 2002 at 01:35:48 -0500, Speaker to Vegetables wrote:
It's really more a political problem than a
technical one, isn't it? MD5
checksums may still be useful as part of a strategy of making it clear
to all interested parties that one is doing what one can to keep
materials that are not legitimately publicly distributable out of the
library. Anyone who demands more than that has clearly abandoned
reasonableness and can only be dealt with by unreasonable means.
The the MD5's are still useful for "where did this come from again?"
queries.
- Steve
22 Dec
22 Dec
5:31 a.m.
On Sat, Dec 21, 2002 at 10:59:29PM -0700, Darren Landrum wrote:
(cut)
The fact is, though, is we need a way to nip possible
piracy in the
bud. This seems like a good idea, but maybe MD5 isn't the way to go.
Are there any other ways we can "profile" a piece of audio?
(cut)
We won't find what DRM researches have been unable to find.
I think some kind of registration for users,
which is impossible or very hard to automate,
maybe along with some trust metric should
get us a long way to a right solution.
v
10:28 a.m.
On Sunday, December 22, 2002, at 02:27 AM, Vincent Touquet wrote:
We won't find what DRM researches have been unable
to find.
I think some kind of registration for users,
which is impossible or very hard to automate,
maybe along with some trust metric should
get us a long way to a right solution.
Hrm...
1) Only one registration per email address.
2) No free email accounts are allowed to be used. (There aren't too
many of those around anymore anyway.)
3) Registration happens on the web, and must be confirmed by email
before the account can be used.
4) An account must be registered before users can submit any files.
That is somewhat restrictive for a so-called open library, but
unfortunately, it may be necessary.
Thank you for the reply, Mr. Touquet.
Any other thoughts?
Regards,
Darren Landrum
10:43 a.m.
On Sun, Dec 22, 2002 at 07:23:27AM -0700, Darren Landrum wrote:
(cut)
1) Only one registration per email address.
2) No free email accounts are allowed to be used. (There aren't too
many of those around anymore anyway.)
3) Registration happens on the web, and must be confirmed by email
before the account can be used.
4) An account must be registered before users can submit any files.
(cut)
That is somewhat restrictive for a so-called open
library, but
unfortunately, it may be necessary.
I don't know if we should rule out free mailboxes.
If the process is such that it can't be automated
(for instance you have to type in 4 numbers
out of an image), I don't think free mailboxes
are an issue anymore.
The major problem for these kind of services
is people using automated tools to distribute
pirated software and music.
Simply using `file` on the submitted files
can also weed out .zip .rar and other
unwanted files, should their be anyone
trying to put anything else than a loop online.
Thank you for the reply, Mr. Touquet.
Call me
Vincent :)
regards,
vincent
11:05 a.m.
On Sunday, December 22, 2002, at 07:38 AM, Vincent Touquet wrote:
I don't know if we should rule out free
mailboxes.
If the process is such that it can't be automated
(for instance you have to type in 4 numbers
out of an image), I don't think free mailboxes
are an issue anymore.
I'm actually inclined to agree. Okay, we won't worry about free
mailboxes, and thus we eliminate a major development headache. :)
The major problem for these kind of services
is people using automated tools to distribute
pirated software and music.
Generating an image on the fly and having them write the contents of
the image into a form field? While it would still be possible to
automate that, it would be much more difficult. Does anyone object or
have any other ideas?
Simply using `file` on the submitted files
can also weed out .zip .rar and other
unwanted files, should their be anyone
trying to put anything else than a loop online.
Good point, but another issue is the way many people will prefer to
distribute their loops. Ogg Vorbis and Ogg FLAC came up as the single
best options for loops, but when it comes to sample libraries and patch
files, a gzipped (or bzipped) tarball would probably work best. The
server would then need to open compressed files to see if they contain
what they should. That probably wouldn't be too hard to do, though.
Wouldn't it really suck if people started using this to distribute
compressed files containing certain highly illegal items that shall
remain nameless here...
On a side note, I'm very pleased with the enthusiasm received with this
basic idea. After I finish moving, hopefully very soon, I will need to
start on the design in earnest and present it. Would this list still be
an acceptable place for that, or would one of the dev lists be better?
I can also see this project spawning its own mailing list...
Regards,
Darren Landrum
11:28 a.m.
On Sun, 2002-12-22 at 07:00, Darren Landrum wrote:
Wouldn't it really suck if people started using this to distribute
compressed files containing certain highly illegal items that shall
remain nameless here...
They submit files and you check that they are wave or whatever, so that
this doesn't happen. Nothing goes online for distribution until you know
it's a loop.
7:13 p.m.
On Sun, 22 Dec 2002, Darren Landrum wrote:
Generating an image on the fly and having them write
the contents of
the image into a form field? While it would still be possible to
automate that, it would be much more difficult. Does anyone object or
have any other ideas?
I just want to point out, without starting a language war, that I know
that such a thing is trivial in PHP.
> Simply using `file` on the submitted files
> can also weed out .zip .rar and other
> unwanted files, should their be anyone
> trying to put anything else than a loop online.
This is to be totally automated? It seems that some sort of administrator
is necessary to say yay or nay to uploads.
Taybin
--
http://www.piratesvsninjas.com
7:20 p.m.
On Sunday, December 22, 2002, at 04:08 PM, Taybin Rutkin wrote:
That's part of the design I'm trying to decide upon now. I know I won't
have the time to be a full-time moderator of this system, so it seems
to me that we'll have to program as many reasonable checks as possible
into the system, and then intervene when we have to.
Regards,
Darren Landrum
On Sun, 22 Dec 2002, Darren Landrum wrote:
Okay, one last post. :)
I was not referring to how hard it would be to automate the server-side
part of this function. I was saying that it would still be possible,
perhaps using an OCR program, to automate making new accounts on the
client side, even when they have to type in what a generated image
says. Sorry for the confusion.
Generating an image on the fly and having them
write the contents of
the image into a form field? While it would still be possible to
automate that, it would be much more difficult. Does anyone object or
have any other ideas?
I just want to point out, without starting a language war, that I know
that such a thing is trivial in PHP. > Simply using `file` on the submitted files
> can also weed out .zip .rar and other
> unwanted files, should their be anyone
> trying to put anything else than a loop online.
This is to be totally automated? It seems that some sort of
administrator
is necessary to say yay or nay to uploads.
7:22 p.m.
On Sun, Dec 22, 2002 at 06:08:26PM -0500, Taybin Rutkin wrote:
(cut)
I just want to point out, without starting a language
war, that I know
that such a thing is trivial in PHP.
(cut)
Yes, the code should be out there (TM) :)
This is to be totally automated? It seems that some
sort of administrator
is necessary to say yay or nay to uploads.
Running 'file' on an uploaded file can be automated.
Administration should be kept at a minimum I think.
It should be easy to run file and check if the file
is indeed say a .wav PCM file instead of a mp3 file
or any other unwanted format
So first we also have to define what constitues an
accepted format and what not.
regards,
v
8:14 p.m.
On Sun, Dec 22, 2002 at 08:00:04AM -0700, Darren Landrum wrote:
Generating an image on the fly and having them write
the contents of
the image into a form field? While it would still be possible to
automate that, it would be much more difficult. Does anyone object or
have any other ideas?
That's not too hard to implement, and it seems to help. Paypal uses this
to help reduce fraud, and they saw something like a 90% decrease
after instituting this system. The tricky thing about what paypal
does is that they make their images rather nasty looking on purpose,
to make it harder to use OCR on them, but they are
still human-readable. I don't know what the algorithm for
making them look gunky is.
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's PACIFIST MATHEMATICIAN OF DESPAIR!
(courtesy of isometric.spaceninja.com)
23 Dec
23 Dec
10:04 a.m.
On Sun, Dec 22, 2002 at 04:09:08 -0800, Paul Winkler wrote:
On Sun, Dec 22, 2002 at 08:00:04AM -0700, Darren
Landrum wrote:
2 questions, what do blind users do, and what if you /want/ to bulk upload
samples?
- Steve
Generating an image on the fly and having them
write the contents of
the image into a form field? While it would still be possible to
automate that, it would be much more difficult. Does anyone object or
have any other ideas?
That's not too hard to implement, and it seems to help. Paypal uses this
to help reduce fraud, and they saw something like a 90% decrease
after instituting this system. The tricky thing about what paypal
does is that they make their images rather nasty looking on purpose,
to make it harder to use OCR on them, but they are
still human-readable. I don't know what the algorithm for
making them look gunky is.
6 Jan
6 Jan
3:03 a.m.
On Mon, Dec 23, 2002 at 01:59:13PM +0000, Steve Harris wrote:
2 questions, what do blind users do,
Yeeks! I didn't think of that. I have no idea. Is it really
possible that paypal doesn't care? I guess it is. :(
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's INTRA- BUSTY PUNK!
(courtesy of isometric.spaceninja.com)
27 Dec
27 Dec
1:59 a.m.
You'd want to use soundfonts
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
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
11:02 a.m.
Can Soundfonts handle samples at any bit widths and sample rates other
than 16/48?
Then again, the vast majority of hardware synths are still just 16/48,
although I believe Roland is making a series of keyboards that have
24/96 sample sets within them.
Also, I believe that Soundfonts were designed specifically with the
SoundBlaster cards in mind, so is there a proprietary issue with using
these for our library?
Thank you for the reply, Mr. Redfern.
Regards,
Darren Landrum
On Thursday, December 26, 2002, at 10:13 PM, Brian Redfern wrote:
You'd want to use soundfonts
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.)
8:17 p.m.
Sound fonts really serve a different purpose than loops. Sound fonts are
not necessarily cut to be looped at all.
On Fri, 2002-12-27 at 06:56, Darren Landrum wrote:
Can Soundfonts handle samples at any bit widths and
sample rates other
than 16/48?
Then again, the vast majority of hardware synths are still just 16/48,
although I believe Roland is making a series of keyboards that have
24/96 sample sets within them.
Also, I believe that Soundfonts were designed specifically with the
SoundBlaster cards in mind, so is there a proprietary issue with using
these for our library?
Thank you for the reply, Mr. Redfern.
Regards,
Darren Landrum
On Thursday, December 26, 2002, at 10:13 PM, Brian Redfern wrote:
You'd want to use soundfonts
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.)
10:14 p.m.
New subject: [linux-audio-user] The Open Music Resource Library (was: The Open Loop Library)
Remember, there's more to this library than just loops. In fact, the
subject line of this thread has been outdated for quite some time. I'm
changing that as of this email.
As for distributing sample sets (as in sampled instruments to be used
by a sequencer or somesuch), Soundfonts represent a reasonable option
for 16/48-quality samples.
As for the name, I think I've decided on calling this "The Open Music
Resource Library" (or OMRL). A very prosaic name, to be sure, but also
very descriptive. As an added bonus, omrl.org is an available domain
name. Keep in mind, though, that this is not set in stone as of yet,
and if anyone has any other name suggestions, feel free to pitch in.
Just to let everyone know, I will be incommunicado from Sunday until
Thursday while I wait for the cable modem installation at my new house.
I'm doing the bulk of the moving this weekend. Work on the OMRL will
continue, since I'll have a lot of time that I can't take up with
playing around on the web. :) With any luck, I will have a final design
by then, and also some code worked out.
But until then, here's something that's been occupying my time: what
language/dev platform should I use? Here are my immediate options:
1) Perl - A language I'm competent at, if not reasonably good.
Everything I need the Library to do can be accomplished in Perl, but it
would take me some time to learn some of the features I will need
(sockets come to mind). Also, Perl seems has zero issues executing and
grabbing output from external apps.
2) PHP - The single language I am best at. As of version 4.3 (released
today), they're claiming better socket support, which means the
possibility of a custom client interfacing with the web app is there,
even though I would have to figure out how to work it. I also have a
great deal of experience with relational databases. PHP seems to have
issues with executing external apps, although this is something I
haven't tried lately.
3) Zope/Python - I'm relatively new to Python, but not to Zope. Zope is
my single favorite way to play around with new ideas, although I
haven't deployed anything with it yet. However, with the server I will
be buying for this and other projects, I will finally be able to do so.
The issue here is how well Zope can be used to jockey files around a
set of mirrors. We don't want to require the mirrors to be running Zope
as well.
And now that I've written another novel's worth of an email with
several threads of thought being bandied about, I think I will stop
here. Everyone, please chip in your thoughts and ideas if you would
like, and hopefully, I can get to them before my Internet starvation
begins. :)
Regards,
Darren Landrum
On Friday, December 27, 2002, at 05:13 PM, Mark Knecht wrote:
Sound fonts really serve a different purpose than
loops. Sound fonts
are
not necessarily cut to be looped at all.
10:48 p.m.
New subject: [linux-audio-user] The Open Music Resource Library (was: The Open Loop Library)
Point well taken. I've been traveling for the last week and just sort of
came back to this. Sorry I didn't notice the subject change.
That said, I hope you can keep this focused enough to make it happen!
Good luck,
Mark
On Fri, 2002-12-27 at 18:08, Darren Landrum wrote:
Remember, there's more to this library than just
loops. In fact, the
subject line of this thread has been outdated for quite some time. I'm
changing that as of this email.
<SNIP>
On Friday, December 27, 2002, at 05:13 PM, Mark Knecht wrote:
Sound fonts really serve a different purpose than
loops. Sound fonts
are
not necessarily cut to be looped at all.
29 Dec
29 Dec
2:02 a.m.
New subject: [linux-audio-user] The Open Music Resource Library (was: The Open Loop Library)
It's not a big deal. There's so much design work left, it doesn't
really matter what it's called yet. :) I hope you had fun with your
traveling.
Also, it looks like this will be my last email to this list until
Thursday sometime. The move is ready to happen now, and will probably
be finished tomorrow (Sunday).
I hope everyone had a good holiday season!
Regards,
Darren Landrum
On Friday, December 27, 2002, at 07:44 PM, Mark Knecht wrote:
Point well taken. I've been traveling for the last
week and just sort
of
came back to this. Sorry I didn't notice the subject change.
That said, I hope you can keep this focused enough to make it happen!
Good luck,
Mark
27 Dec
27 Dec
11:40 p.m.
There are really several formats of interest. Aiff is nice for loops as
most smaplers handle it and it comes with a header with the loop info
embedded. Soundfonts are usually more like synth pathches, but using
software like Swami its easy to build them. I think even mod is an
interesting format since it contains both samplers and triggering
information as well. I think the ogg vorbis group has also developed a
lossless compression format, which might be good for this use, as all of
the sounds could be losslessly compressed for easy download, and then
the end user can convert it to an aiff or wav without losing any sound
quality.
On Fri, 2002-12-27 at 16:13, Mark Knecht wrote:
Sound fonts really serve a different purpose than
loops. Sound fonts are
not necessarily cut to be looped at all.
On Fri, 2002-12-27 at 06:56, Darren Landrum wrote:
Can Soundfonts handle samples at any bit widths
and sample rates other
than 16/48?
Then again, the vast majority of hardware synths are still just 16/48,
although I believe Roland is making a series of keyboards that have
24/96 sample sets within them.
Also, I believe that Soundfonts were designed specifically with the
SoundBlaster cards in mind, so is there a proprietary issue with using
these for our library?
Thank you for the reply, Mr. Redfern.
Regards,
Darren Landrum
On Thursday, December 26, 2002, at 10:13 PM, Brian Redfern wrote:
You'd want to use soundfonts
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.)
28 Dec
28 Dec
1:09 a.m.
On 27 Dec 2002 19:33:04 -0800
Brian Redfern <bredfern(a)calarts.edu> wrote:
There are really several formats of interest. Aiff is
nice for loops as
most smaplers handle it and it comes with a header with the loop info
embedded.
The same is true for WAV, and SVX. I am currently working on adding
loop support for these file formats to libsndfile.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"... the industrial-capitalist mode of software production
was doomed to be outcompeted from the moment capitalism
began to create enough of a wealth surplus for many
programmers to live in a post-scarcity gift culture."
-- Eric S. Raymond
14 Jan
14 Jan
2:19 p.m.
New subject: [linux-audio-user] Classical music searching
http://sd.znet.com/~iwamura/kbdif/kbdif.html
This is a search engine where you type in a rough rendition of the melody
in your head and it finds the classical pieces that sounds like it.
Pretty neat. I typed in "Old McDonald Had a Farm" and it found me:
45 % match
Composer: SCHUMANN, Robert Alexander (1810-56)
Title: Waldscenen, Op.82 6.Herberge
Which, I've got to admit, does share some similarities to Old McDonald,
especially in the second part.
Pretty neat,
Taybin
--
http://www.piratesvsninjas.com
2:58 p.m.
New subject: [linux-audio-user] Classical music searching
>>>> Taybin Rutkin
<trutkin(a)physics.clarku.edu> writes:
Very cool. It does seem to have a pretty complete database of
popular works earlier than the 20th century.
I typed in "Old McDonald Had a Farm" and it
found me...
Waldscenen, Op.82 6.Herberge
Just try typing the themes from some of Andrew Lloyd Webber's
better-known pieces ;-)
--
Roger Williams <raw(a)qux.com>
Qux Tool & Die, Middleborough, Massachusetts
// Omne tulit punctum qui misquit utile dulci //
10:49 p.m.
New subject: [linux-audio-user] Classical music searching
On Tue, 2003-01-14 at 18:13, Taybin Rutkin wrote:
http://sd.znet.com/~iwamura/kbdif/kbdif.html
This is a search engine where you type in a rough rendition of the melody
in your head and it finds the classical pieces that sounds like it.
Pretty neat. I typed in "Old McDonald Had a Farm" and it found me:
45 % match
Composer: SCHUMANN, Robert Alexander (1810-56)
Title: Waldscenen, Op.82 6.Herberge
Which, I've got to admit, does share some similarities to Old McDonald,
especially in the second part.
Well, this finally proved once and for all that java is not set up
correctly on my machine. One more thing to work on...
7771
days inactive
7796
days old
linux-audio-user@lists.linuxaudio.org
62 comments
16 participants
participants (16)
-
Brian Redfern -
Conrad Parker -
Daniel James -
Darren Landrum -
Erik de Castro Lopo -
iriXx -
Mark Knecht -
Mark Knecht -
matthew yee-king -
Nathaniel Virgo -
Paul Winkler -
Roger Williams -
Speaker to Vegetables -
Steve Harris -
Taybin Rutkin -
Vincent Touquet