Author: Well, of course I think the idea of finding music by tapping is great. It is surprising how specific one can actually be that way, and entering a tapped query is not as embarrassing as singing into one's computer microphone. Also, it does not require as much musical talent.
Of course, it does not work for every kind of music, therefore I find it even better if one can also use pitch for narrowing down searches.
About Songtapper in particular: It does not work in my Firefox 2.0.0.13 for Linux (64bit), so I don't know how well it currently performs. If it still uses the technique from the original paper, this would, if I remember correctly, involve editing distances for strings and therefore probably some quantization.
The algorithm which is currently used on Musipedia avoids quantization (it uses the Manhattan norm on sequences of non-quantized onset times - or, to be really specific: almost non-quantized since they still need to be represented with the finitely many bits used for representing floating point numbers). Those onset times are calculated from the MIDI files which result from the Lilypond or abc snippets in the database.
Avoiding quantization can be good for n-tuplets, for example the triplets in Bizet's "Carmen":
http://www.musipedia.org/search.0.html?sourceid=melody-url&tx_mpsearch_pi1%5bsubmit_button%5d=Search&tx_mpsearch_pi1%5bpc%5d=hum%201.303-0-1/1.764-0-1/2.214-0-1/2.539-0-1/2.797-0-1/3.106-0-1/3.562-0-1/4.002-0-1/4.265-0-1/4.503-0-1/4.782-0-1/5.228-0-1/5.683-0-1&filtertext=&coll=r&onlymatchfrom=0
I don't have an example for higher n on my mind, but the higher you go, the better it is if you don't have to approximate the onset times by using multiples of, say, 16th notes.
Of course, it does not work for every kind of music, therefore I find it even better if one can also use pitch for narrowing down searches.
About Songtapper in particular: It does not work in my Firefox 2.0.0.13 for Linux (64bit), so I don't know how well it currently performs. If it still uses the technique from the original paper, this would, if I remember correctly, involve editing distances for strings and therefore probably some quantization.
The algorithm which is currently used on Musipedia avoids quantization (it uses the Manhattan norm on sequences of non-quantized onset times - or, to be really specific: almost non-quantized since they still need to be represented with the finitely many bits used for representing floating point numbers). Those onset times are calculated from the MIDI files which result from the Lilypond or abc snippets in the database.
Avoiding quantization can be good for n-tuplets, for example the triplets in Bizet's "Carmen":
http://www.musipedia.org/search.0.html?sourceid=melody-url&tx_mpsearch_pi1%5bsubmit_button%5d=Search&tx_mpsearch_pi1%5bpc%5d=hum%201.303-0-1/1.764-0-1/2.214-0-1/2.539-0-1/2.797-0-1/3.106-0-1/3.562-0-1/4.002-0-1/4.265-0-1/4.503-0-1/4.782-0-1/5.228-0-1/5.683-0-1&filtertext=&coll=r&onlymatchfrom=0
I don't have an example for higher n on my mind, but the higher you go, the better it is if you don't have to approximate the onset times by using multiples of, say, 16th notes.
aim