Forum: Musipedia Melody Search Engine

musipedia.org// ?

Deutsch ♦ English ♦ Français ♦ 中文

Logging in is required for posting.

log in

Register

Reset password.

Special forum features: inserting music notation, posting audio recordings.

watch thread

All Categories > Musipedia > Musipedia Features > Finally... new search algorithm

Total Posts: 12 - Pages (2): [1] 2

Author: rt
Posted: Feb 19 2006 - 12:15 AM
Subject: re: re: re: re: Finally... new search algorithm

Sorry about that. I played a bit with the Apache configuration (to redirect everything from http://musipedia.org to http://www.musipedia.org). The links should now work again.

Rainer

Author: AncientBrit
Posted: Feb 18 2006 - 11:34 PM
Subject: re: re: re: Finally... new search algorithm

Hmmm. Very strange. I haven't tried every single link, but the handful I've tried so far (Elgar, a few others, in both posts) yield errors - page cannot be displayed.

Any suggestions?

Best,

Peter

Author: AncientBrit
Posted: Feb 15 2006 - 03:58 PM
Subject: re: re: Finally... new search algorithm

Wow! That's quite an oeuvre! :) Thank you very much! I've copied the links over to Word so that I don't lose them. I'll keep you posted as to progress...

Peter

Author: rt
Posted: Feb 15 2006 - 11:27 AM
Subject: re: Finally... new search algorithm

Author: rt
Posted: Feb 15 2006 - 11:17 AM
Subject: re: Finally... new search algorithm

Author: AncientBrit
Posted: Feb 14 2006 - 10:29 PM
Subject: re: re: re: re: Finally... new search algorithm

Interesting if somewhat arcane :) But if I'm on the right track, it will solve a 100+ year old mystery.

The problem is that the musical rail fence encryption method (my term) is particularly robust; the only vulnerability arises when a series of consecutive notes (all the same) appear in the score, allowing the text to "show through". Of necessity, the number of such notes has to be fairly high in order to stand a chance of possessing some level of uniqueness.

(And there's also the problem of (i) the inherent possibility that the text that shows through might have been encrypted by another method previously and so what you're seeing is an artefact; (ii) the nature of the English language, in that apparent "real" words show up very regularly, if only because of the palindromic nature of many of our words; and (iii) the fact that this vulnerability doesn't necessarily benefit the intrepid decrypter in terms of Parsons Codes for the musical segment prior to the multi-note sequence (not a chord), since Parsons Code only helps identify a candidate piece - it doesn't help you to derive the correct decrypting notes prior to the section that matches the search sequence).

And to top all of that, there is no guarantee that Elgar used only the first N notes of a particular melody (assuming, always, that he did in fact indulge in musical rail fence encryption); if he used the last N notes (where N is the number of text characters in the encrypted string) or if he used a repeating sequence of say 16 notes (or some submultiple of 64) and if the database only holds the first 100 or so notes for every piece, then a match will never be found that way.

But it doesn't hurt to try :)

To be honest, even a list of 100+ candidate melodies would be easier to work through than trying to brute force create and review (!) all possible anagrams contained in 64 letters, so I'd certainly be interested in the results of a SQL query that looked for an RRRRR match, the caveats that you mentioned notwithstanding.

Author: rt
Posted: Feb 14 2006 - 11:44 AM
Subject: re: re: re: Finally... new search algorithm

This looks very interesting! It is nice to see that there are more applications to melody search engines than just identifying a melody.

The new search algorithm takes rhythm into account, so you can't find all pieces with RRRRR with just one query. It is tempo-invariant and transposition-invariant, though. If you enter a query with 6 repeated notes, you will get matches with the Parsons code RRRRR , but only those where the rhythm resembles your query.
Soon, the algorithm will also be available for searching large parts of the internet for MIDI files containing a given query, so you can do a wider search. Since the new algorithm works on polyphonic MIDI files, there generally is not one single Parsons code up to a given position in the piece (there is one for every voice, and when chords occur, it is even less clear), so you can use the algorithm only for finding matching pieces and the position in the piece where the match occurs.

The Parsons code search on Musipedia still does not allow you to search within the Parsons code strings - if that would also be possible, you would need much longer queries in order to avoid being swamped with irrelevant matches. So, for the usual task of retrieving a specific piece, it would not even be all that desirable for the algorithm to search within strings. For your particular application, I can just do an SQL query that searches within strings and give you the list of matches. Again, the question about the preceding Parsons code can not be directly answered, but this time because the Musipedia collection only contains short snippets (it is a collection of themes, not of whole pieces). So, in both cases, you would have to figure out the preceding Parsons code yourself after identifying a piece with the search algorithm.

Author: AncientBrit
Posted: Feb 14 2006 - 03:18 AM
Subject: re: re: Finally... new search algorithm

w0lfie wrote:

Great work! I tried a snippet from the middle of a piece, in a different key, with a different base note length, and it worked like a charm. Well done! I'll keep trying to stump it, but it looks like you've got a winner. :-)

I'm a late arrival to this resource, but it sounds as though I arrived at just the right time :)

All I have is a putative melodic fragment (a couple, actually) that is possibly between 4 and 6 notes long, in Parsons code they would be RRR to RRRRR , and I even have no idea what the melody is (that is, I have never knowingly heard it).

I'm in the process of decrypting (or attempting to decrypt) the Dorabella Cipher - Elgar's 100+ year old encrypted message to Dora Penny (as she then was). If you would like to view progress I have a hefty PDF detailing what I've found so far at http://www.story-lines.com/latestelgarwork.pdf. It's very much a work in progress and very rough and ready.

Now to my question. If the new search algorithm can retrieve matches based on matching a fragment against some point in a melody other than from the first note (so maybe at the 20th, or 200th), is it possible for fragmentary matches to also return either (i) the *notes* that precede the matched fragment (in Parsons code, ideally) all the way back to the first note, or (ii) failing that, the *number* of notes (a la Parsons) that precedes etc., etc, please?

The reason for needing to know how many Parsons codes precede a matching fragment will become clear if you wade through the PDF mentioned earlier (the Musical Rail Fence encryption section is the one you want).

Grateful for any input!

Author: w0lfie
Posted: Jan 16 2006 - 03:25 AM
Subject: re: Finally... new search algorithm

just found another great use for the new search feature. the theme from romeo and juliet was missing the first note, so the Parson's code was a bust. But the new search feature found it with no problems.

Author: rt
Posted: Jan 14 2006 - 07:53 PM
Subject: re: re: Finally... new search algorithm

w0lfie wrote:

Great! I have found the following problems so far:
- The new search algorithm of course ignores entries where the melody is not known, but only the contour. I addressed this with a link to an old-style Parsons code search. This link automatically appears with the search results if you have entered enough notes to get a meaningful contour.

- Since the new algorithm searches inside pieces, there are now situations where you don't see immediately why a piece is shown in the result list (because the query matches some notes close to the end of the piece, which is not visible in the result list). I am not sure how to handle this yet - it would be nice to somehow visualize the matching position within the piece, or maybe at least provide a little MIDI snippet that shows the matching bit, or at the very least show where in the piece the match is (maybe in minutes/seconds from the beginning). Any other ideas?

Total Posts: 12 - Pages (2): [1] 2

Click here for a complete list of threads

You must login to post a message to this conference.

How to insert music:

Add a bit of sheet music, along with a MIDI file, simply by entering note names in Lilypond syntax between the [L] and [/L] tags.
For example, you can try what happens if you enter: [l]g'4 g'4 d''4 d''4 e''4 e''4 d''2[/l] (use the Preview function if you don't actually want to post this).
You can create these lists of note names by clicking on piano keys here.

How to post an audio recording:

If you just want to sing, whistle, or play a melody so that other forum visitors can hear it, follow these steps:

Record your audio here.
You should notice a 32-character hash code, something like: 2a40281c5001c5a7d8c9f57fcdeccfaf
copy this hash code and paste it into a forum post, enclosed in the audio tags, for example: [audio]2a40281c5001c5a7d8c9f57fcdeccfaf[/audio]

How to mark a thread as solved:

If the original question in a thread is solved, please mark it as solved using the "solved" icon (or by just typing [solved] into your post). This makes life easier for people who are willing to identify melodies, since unsolved problems are easier to spot that way. If a problem turns out to not be solved after all, just write [/solved] in a new post, and the thread will be labeled accordingly.