Determine if a score is in a major or minor key
I am using MuseScore for the creation of scores that will be exported to MusicXML and then transformed for display in my android application.
In the MusicXML export, minor keys are never correctly identified (keys are always tagged as being major).
So, during my transformation process, I need to "detect" if the score is in a major or minor key.
Note: at this point I will not be dealing with scores that change keys mid way through.
After what I have found during my research, I think I have a reasonable way of doing this.
However, I would really appreciate your comments / advice on the procedure that I intend to implement.
Here it is :
- Is the last note the root/tonic of the major or minor key
- Get the last played measure of the score (not necessarily the last one on the page)
- Check the last note of the first voice in the first stave
- Is the last played chord major or minor
- Get the last played measure of the score as before
- Check the last chord
- Is the frequency of the major tonic greater or less than the frequency of the minor tonic in the first voice of the first stave ?
I would then combine the results of these three tests to determine if the score is in a major key or its relative minor key.
What are your thoughts ?
Any further tests which should be done ?
Comments
Harmonically speaking (re: 'chords'), there may be familiar cadences.
For instance, in C major, you'll see the common progression: I - IV - V(7) - I ;
as C chord, F chord, G(7) chord, finally C chord.
In the relative minor (A minor) using the same key signature, the progression will use Am chords, Dm chords, with the V chord being Em for the natural minor scale, or E7 for harmonic minor (and others).
Also, regarding minor scales:
Melodically speaking, some minor scales may consistently use accidentals outside of the key signature - for example, in A harmonic minor (no sharps or flats in the key signature), the seventh scale degree (G) is sharped to give the strong half step motion to the tonic (A).
Regards.
Why do you need an answer? How would the display of your song differ based on whether this algorithm reported major or minor?
Except in the most simplistic of cases, there is never going to be a algorithm that would give the answer with any degree of confidence, as a good number of pieces would have expert human musicians disagreeing about the answer as well. After all, tons of pieces move back and forth between relative major and minor. So whatever decisions you made based on this global answer could well be wrong for 50% or more of the song.
So I really wouldn't invest too much effort in any sort of automatic detection. Instead, if there really is a reason you need a one-size-fits-all answer (trying and failing to imagine a scenario in which it would matter) that applies globally to the whole song, and just looking at the last note isn't doing it for you, then I'd just let the user specify it somehow in your Android app.
In reply to Why do you need an answer? by Marc Sabatella
Thanks for your answers.
My application is to assist musicians in protestant churches in France by replacing all their song books with an application and scores on an android tablet.
So, Marc, why do I need to do this ?
Well, I am needing to display the tonality of each of the songs a user will have on their tablet.
Thus enabling the user to find appropriate songs according to the tonality when building a time of worship.
As the vast majority of the songs are not very complicated, I was hoping to automate the detection of the tonality.
In reply to Why do it at all ? by Simon Giddings
In which case, I guess the simple check-last-chord option seems like it makes perfect sense.
If I were doing this, I'd prefer to attach this information as metadata somehow directly when creating the score. But I don't think MuseScore provides any good way to do that. I suppose you could repurpose "movement number" or something else from Edit / Metadata, but I don't really like that idea. 2.0 might provide additional options.
In reply to In which case, I guess the by Marc Sabatella
Yes, Marc, I agree with you.
To store the tonality within the original document appears to be the most optimum solution.
Will keep on exploring this aspect.
By the way, as you mentioned it, is there any form of a release date for v2.0 ?