I am pleased to report I have had a lot of success at solving this problem. Here is a link to my first paper on the subject which I'll be presenting at the CBMI conference in London in June:
Basically you can play a fragment of a reel or a jig on the flute or whistle and the program will tell you what it is. It may work with other instruments. You will need a working version of Java installed to run it. Best to read the instructions in the readme.txt file
Wow, congratulations on the work guys!
Truly a boon to those 'hard of memory' like myself - "where's the tape I've got that tune on, wish I could remember how the second part goes, what was it called again?"
A useful tool indeed though I can't wondering if we'll now have endless and acrimonious debates about what the 'proper' name for a tune is, its provenance and so on.
I suppose the next step would be to identify particular playing styles of individual musicians and overlay that onto the bare bones as it were. This is how Bobby Casey would play it...
I can almost hear hands being thrown up in horror - the loss of individuality, the machine takes over.
And of course, the ultimate horror, of tune generation by machine.
Question: Do traditional musicians have a Frankenstein complex when it comes to 'technology' and it's works?
I gave it a shot, but no joy. I unzipped the files, double-clicked Phd.jar, and Java started up--but I only get unlabeled colored blocks, and no action. (Well, I can move the cursor from Log to ABC and type something, but that's all.) I updated java recently--two weeks ago, maybe.
Live Query (Play a bit of a tune when it says Recording)
Transcribe
Find
Best
Ive only tested it on Windows BTW. It should work on Mac/Linux etc but you may have to edit the matt.properties file. Full instructions in the readme.txt file in the ZIP
No joy for me on a Mac OSX. I just get lots of errors starting with:
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass2(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:719)
etc etc.
I also haven't been able to get it to work on a Mac OSX.
Anyhow, I read the paper and have a couple of questions and corrections.
First, the tiny stuff. The reference [11] in the caption to Figure 1 should be [12], as the tune given there is from Norbek, not O'Neill's. In section 3.4, it says that the histogram for "Hunter's Purse" is in Figure 5, when it's really in Figure 4.
I had trouble understanding the first sentence of the second paragraph of section 3.6. It looks like there's a verb ('is'?) missing between 'Z' and 'then'. Am I reading it correctly to mean that for a particular transcribed string s and a particular string c from the corpus Z, you compute
eF(c)=min{ed(s,x)/length(s): x is a substring of c}?
That seems to be the right thing to compute, but it's not clear to me that the sentence says it clearly. Also (and this may be standard terminology that I don't know), does 'substring' mean all characters in the string between position i and position j, or does it mean 'subsequence', in the sense that the i+1st character in the substring can be any character occuring after the ith character in the string? (The distinction could have a significant effect on the running time of the algorithm, so I'm guessing it's the former.)
It's also not clear from the paper how you handle transposition and accidentals. Presumably, since you use 12 FIR comb filters to determine pitch, the transcription is potentially chromatic. However, ABC notation is diatonic, with only the accidentals explicitly modified by sharp and flat symbols. When you normalize the ABC, are all sharps or flats written explicitly? I assume they must be, since the transcribing algorithms wouldn't know the key signature. Furthermore, section 3.3 transcribes the tune as played into the diatonic scale with two sharps. How would it deal with accidentals that are midway between two notes in the D major scale?
The question above also led me to notice that equation (5) at the end of section 3.3 is not saying what you mean. pS(n) should be the k_i for which abs(f(n)-k_i) is minimized, i.e. the note in the D major scale that is nearest to the note played. Equation (5), as written, defines pS(n) to be the distance from the played note to the nearest note in the D major scale.
It looks like the current implementation pretends that everything is in the D major diatonic scale. Relaxing that might be a key step in making the program work well for chromatic instruments.
How does the program handle looking for a tune played in a different key from the version in the corpus? Is the transcription transposed into all 12 keys (or just the common ones) and then each of these compared to the corpus? Or is everything expressed in terms of the intervals between successive notes?
Another thing that confused me was the line:
bin.width<-(bin.width+note.duration)/2
in the pseudocode for the fuzzy histogram quaver length calculator. The last sentence of the first paragraph of section 3.4 says "The algorithm also updates the bin width each time a candidate is added to the bin, so that the bin widths contain the cumulative average lengths of the notes counted." But the line I quoted gives the candidate note being added increasing weight, as you add more and more notes to the bin. Shouldn't the line be:
bin.width<-(n*bin.width+note.duration)/(n+1), where the bin contains n notes prior to adding the new one? That way, each note in the bin would be weighted equally.
Well, that's about it for now. I hope these observations and questions can be of help.
Music Information Retrieval Update
Music Information Retrieval Update
Hi Guys,
You might remember a while back I posted a discussion about a music information retrieval system I have been developing as part of my PhD research:
http://www.thesession.org/discussions/display/16751
Well...
I am pleased to report I have had a lot of success at solving this problem. Here is a link to my first paper on the subject which I'll be presenting at the CBMI conference in London in June:
http://www.comp.dit.ie/bduggan/Research/Microsoft%20Word%20-%20A%20SYSTEM%20FOR%20AUTOMATICALLY%20ANNOTATING%20TRADITIONAL%20IRISH%20MUSIC%20FIELD%20RECORDINGS.pdf
And here is a link to a test program you can try out:
http://www.comp.dit.ie/bduggan/downloads/matt2.zip
Basically you can play a fragment of a reel or a jig on the flute or whistle and the program will tell you what it is. It may work with other instruments. You will need a working version of Java installed to run it. Best to read the instructions in the readme.txt file
Let me know what you think!
Bryan
# Posted on May 3rd 2008 by skooter500
Re: Music Information Retrieval Update
Wow, congratulations on the work guys!
Truly a boon to those 'hard of memory' like myself - "where's the tape I've got that tune on, wish I could remember how the second part goes, what was it called again?"
A useful tool indeed though I can't wondering if we'll now have endless and acrimonious debates about what the 'proper' name for a tune is, its provenance and so on.
I suppose the next step would be to identify particular playing styles of individual musicians and overlay that onto the bare bones as it were. This is how Bobby Casey would play it...
I can almost hear hands being thrown up in horror - the loss of individuality, the machine takes over.
And of course, the ultimate horror, of tune generation by machine.
Question: Do traditional musicians have a Frankenstein complex when it comes to 'technology' and it's works?
# Posted on May 3rd 2008 by john knoss
Re: Music Information Retrieval Update
I gave it a shot, but no joy. I unzipped the files, double-clicked Phd.jar, and Java started up--but I only get unlabeled colored blocks, and no action. (Well, I can move the cursor from Log to ABC and type something, but that's all.) I updated java recently--two weeks ago, maybe.
# Posted on May 3rd 2008 by mickray
Re: Music Information Retrieval Update
Worked fine for me using this version:
$ java -version
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)
# Posted on May 3rd 2008 by mcdevincabe
Re: Music Information Retrieval Update
Glad it works!
Try the following sequence of buttons:
Live Query (Play a bit of a tune when it says Recording)
Transcribe
Find
Best
Ive only tested it on Windows BTW. It should work on Mac/Linux etc but you may have to edit the matt.properties file. Full instructions in the readme.txt file in the ZIP
Bryan
# Posted on May 3rd 2008 by skooter500
Re: Music Information Retrieval Update
My version:
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java Hotspot(TM) Client VM (build 10.0-b19, mixed mode, sharing)
And that's about as much of this kind of thing I can stand, any more... developed quite an allergy to it, years ago...
I have to go play my fiddle now.
# Posted on May 3rd 2008 by mickray
Re: Music Information Retrieval Update
No joy for me on a Mac OSX. I just get lots of errors starting with:
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass2(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:719)
etc etc.
# Posted on May 4th 2008 by Wilf
Re: Music Information Retrieval Update
I also haven't been able to get it to work on a Mac OSX.
Anyhow, I read the paper and have a couple of questions and corrections.
First, the tiny stuff. The reference [11] in the caption to Figure 1 should be [12], as the tune given there is from Norbek, not O'Neill's. In section 3.4, it says that the histogram for "Hunter's Purse" is in Figure 5, when it's really in Figure 4.
I had trouble understanding the first sentence of the second paragraph of section 3.6. It looks like there's a verb ('is'?) missing between 'Z' and 'then'. Am I reading it correctly to mean that for a particular transcribed string s and a particular string c from the corpus Z, you compute
eF(c)=min{ed(s,x)/length(s): x is a substring of c}?
That seems to be the right thing to compute, but it's not clear to me that the sentence says it clearly. Also (and this may be standard terminology that I don't know), does 'substring' mean all characters in the string between position i and position j, or does it mean 'subsequence', in the sense that the i+1st character in the substring can be any character occuring after the ith character in the string? (The distinction could have a significant effect on the running time of the algorithm, so I'm guessing it's the former.)
It's also not clear from the paper how you handle transposition and accidentals. Presumably, since you use 12 FIR comb filters to determine pitch, the transcription is potentially chromatic. However, ABC notation is diatonic, with only the accidentals explicitly modified by sharp and flat symbols. When you normalize the ABC, are all sharps or flats written explicitly? I assume they must be, since the transcribing algorithms wouldn't know the key signature. Furthermore, section 3.3 transcribes the tune as played into the diatonic scale with two sharps. How would it deal with accidentals that are midway between two notes in the D major scale?
The question above also led me to notice that equation (5) at the end of section 3.3 is not saying what you mean. pS(n) should be the k_i for which abs(f(n)-k_i) is minimized, i.e. the note in the D major scale that is nearest to the note played. Equation (5), as written, defines pS(n) to be the distance from the played note to the nearest note in the D major scale.
It looks like the current implementation pretends that everything is in the D major diatonic scale. Relaxing that might be a key step in making the program work well for chromatic instruments.
How does the program handle looking for a tune played in a different key from the version in the corpus? Is the transcription transposed into all 12 keys (or just the common ones) and then each of these compared to the corpus? Or is everything expressed in terms of the intervals between successive notes?
Another thing that confused me was the line:
bin.width<-(bin.width+note.duration)/2
in the pseudocode for the fuzzy histogram quaver length calculator. The last sentence of the first paragraph of section 3.4 says "The algorithm also updates the bin width each time a candidate is added to the bin, so that the bin widths contain the cumulative average lengths of the notes counted." But the line I quoted gives the candidate note being added increasing weight, as you add more and more notes to the bin. Shouldn't the line be:
bin.width<-(n*bin.width+note.duration)/(n+1), where the bin contains n notes prior to adding the new one? That way, each note in the bin would be weighted equally.
Well, that's about it for now. I hope these observations and questions can be of help.
# Posted on May 4th 2008 by GaryAMartin
Re: Music Information Retrieval Update
Gary,
Thanks for your comments. I appreciate you taking the time to read my paper and give your feedback. I'll respond tomorrow. Been a busy few days!
Bryan
# Posted on May 7th 2008 by skooter500