Laurie wrote:
>The "spectral code" Sigge reported sounds good.
>The breachthnaqgh (how do you spell that?) scheme as
>outlined seems to require that one determine what key
>something is "really" in and where the beats "really" fall.
>As tunes can be written with wrong key signatures, wrong
>bar lines etc. I would like to modify that to say that you
>FIRST record the time spent measure on each note
>INCLUDING any accidentals (because I've seen a lot of
>modal tunes written in Dm with every single Bb then
>naturalised all through the tune.
>You probably need to restrict it to "nearest semitone" or
>it gets out of hand. You then try to identify the scale from
>the pattern of semitones that you get. (This step requires
>some research - I want an algorithm which always gives
>the same answer (doesn't matter if it's "right") for
>a. tunes will all notes of major scale and the *odd* accidental
>b. Gapped scales
As it happens, I've been playing around with an algorithm
which does exactly that. What I did was to first collect
some statistics; I wrote a program which takes a large
abc file (about 350 tunes) and for each tune calculates
the time spent on each note of the chromatic scale.
Using the tonic and mode given in the tune, these numbers
were then added to one of seven arrays (one for each mode),
and at the end of the process averaged by dividing each by
the number of instances of that mode. So I end up with
seven tables, each giving the average amount of time tunes
in a particular mode spend on each note. It turns out that
there are characteristic patterns of note useage for each
mode, which means that you can identify the mode and key
of an unknown tune by pattern matching against the seven
"typical" data sets. It works astonishingly well, even
for highly chromatic tunes (it successfully identified
Em as the key of the Bach bourree - better than me:-)
and C# as the key of "Entry of the Gladiators" which I'd
entered in Db) and for gapped scales. Where it makes
mistakes, the commonest is to confuse minor key tunes
with the relative phryian mode, and vice versa. I suspect
the problem here is that I have too few examples of Phrygian
mode tunes, and the statistics are therefore poor.
(In the original file there were about 200 major key tunes,
about 50 for each of minor, Mix and Dor, 6 Phry, 3 Lyd
and 1 Loc.)
>In fact a tune could be catalogued more than once i.e.
>"this is the spectral code that you'd get if you thought it was
>really in D and this is what you'd get if it was in A").
>
>You could squeeze into 32 bits a 4 bit precision for
>each of the seven degrees of the scale and 4 bits left over.
>pre-calculating and storing one 32 bit number for each tune
>should be OK.
You can probably afford to spread yourself out a bit more
and use a 64-bit number so you can take account of
accidentals: accidentals in a tune often contribute a
lot to it's characteristic sound, even though the tune
spends relatively little time on them.
>Next step is a fast algorithm for comparing closeness.
>Easy - just the distance in 7 dimensions.
>(a^2 +b^2 +c^2 +...+g^2).
>Getting through 100,000 of these and picking the
>nearest (say) 10 shouldn't take too long.
I rather suspect that too much information is being discarded
here, and that you will tend to end up with hundreds of hits,
all with very similar scores.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
