MIDI: key signature event metadata displayed incorrectly (FF 59 02 scale type byte)

[PitchSlap]

After a long night with the MIDI spec, staring into a hex editor, and ChatGPT I finally figured out why the Media Explorer's key metadata for MIDI files is so often incorrect.

TLDR
The key signature and scale type bytes are read by the ME, but the type is not displayed causing minor keys to display as the parallel major which has different notes. When the scale type byte is incorrectly written the relative major key is shown which has the correct notes, but wrong root. This also means Reaper is using only 12 values to represent 24 keys.
---------------------------------

Long version
I first noticed this a year ago when exported a bunch of MIDI files I created with Hooktheory. Since even commercial MIDI files seem more likely to have wrong meta data than any at all I assumed it was Hooktheory's error, but after noticing not a single MIDI file from any source correctly shows a minor key I suspect a Reaper issue as well (both turned out to be correct).

After checking some files using "peculiar" values representing the key signature according to ChatGPT, I figured I'd create a simple MIDI file myself with standard values.

I exported a basic chord progression in Em with HookTheory which showed as G. The hex below shows the scale type byte was major so Reaper was correctly interpreting incorrect information.

FF 59 02 is the location of the key signature, 01 represents 1 sharp (Em/G), and 00 represents a major scale. I changed the scale type byte to minor (01), and ChatGPT said the new file has the correct key signature for Em. This caused Reaper to display the key as E which is the expected root, but without the scale type users would interpret it as EM, which unlike GM doesn't match the notes in the file.

The desired result is Em, however without a correct scale type byte the best Reaper can do from the meta alone is display the relative major which is less wrong. But when the scale type is minor this needs to be shown in addition to the root note otherwise it breaks metadata searches and key sorting causing files with harmonically incompatible keys to be grouped together.

Original and corrected example files attached:

[schwa]

I'm not sure I follow.

When I import "Em MIDI Test.mid" into REAPER and open the event view in the MIDI editor, I see a G major key signature event, which afaik is correct because the sharp/flat byte is 1 meaning 1 sharp, and the scale type byte is 0 meaning major.

When I import "Em MIDI Test3.mid", I see an E natural minor key signature event, which afaik is correct because the sharp/flat byte is 1 meaning 1 sharp, and the scale type byte is 1 meaning minor.

Maybe I'm not understanding where in REAPER you are seeing a different key signature display, if not in the event view?

[Sid]

Originally Posted by schwa

I see an E natural minor key signature event,

Under Key in the Media Explorer, it is listed as E, not E minor.

[schwa]

Oh, so the issue is just adding "minor" where appropriate in the media explorer?

[PitchSlap]

Originally Posted by schwa

Oh, so the issue is just adding "minor" where appropriate in the media explorer?

Yes! That's exactly it. Just add m after any key with a minor flag in the Media Explorer in the key column.

There's a few similar ME issues related to MIDI:
(in case fixing is easier when already in that section of code.)

-The most obvious is the tempo is nearly always wrong regardless of the metadata or filename. Here it shows 200bpm, another time the same file could say "maybe 100bpm". The only time it seems to match the metadata is by coincidence. (*note many MIDIs incorrectly have 100 in the bpm tag which is likely the default in whatever exported them.)

-Some files show a 7.999 bar length when it should obviously be 8. It likely wasn't rounded correctly before being written in the MIDI file, but when that close Reaper should round it (the media information box shows.

-The media information box for this shows 171 events, Length: 16 quarter notes @ 9600 tick per quarter. Including the key/tempo metadata in the information box would be helpful for list view when it's otherwise hidden.

-Media Explorer: MIDI display scaling issue, wasted vertical space (LICEcap), not related to metadata, but the my most prevalent daily issue with MIDI in the ME.

[schwa]

Originally Posted by PitchSlap

The most obvious is the tempo is nearly always wrong regardless of the metadata or filename. Here it shows 200bpm, another time the same file could say "maybe 100bpm".

If the MIDI file is currently being previewed, I think the tempo displayed at the lower right will be whatever the project tempo is. That's because the only way to preview MIDI is via a track in the project.

[PitchSlap]

Originally Posted by schwa

If the MIDI file is currently being previewed, I think the tempo displayed at the lower right will be whatever the project tempo is. That's because the only way to preview MIDI is via a track in the project.

Thanks for clarifying.
Since the project tempo is always known and fixed while previewing, showing it in the preview area doesn't really have much informational value compared to the original tempo in my opinion.

Also I've noticed when it says "Maybe xBPM" it continues to show maybe for other files, but when it doesn't show maybe initially other files don't either.

The practical difference is "Maybe" BPMs change based on the time selection.
This can be useful for making more precise selections since selecting exactly 1/4 or 1/2 of the file will have the same "maybe" value, and a difference from the original value can be used to refine the selection to 2 or 4 bars of an 8 bar loop etc.

However, a much preferred way to do this would be to (also) show the selection length and start/end in beats/bars when the timebase is Beats.
A selection length of 0:05:373s isn't really helpful when trying to select 4 of 8 bars. The user must first divide a total length of 0:10:666s to know 0:05:333 = 4 bars @90BPM.
With values in Beats time-selection snapping also makes a lot of sense whereas it doesn't with time values which are arbitrary in relation to the project tempo.

[PitchSlap]

*EDIT*
I didn't notice anything in the changelog, but it appears minor keys display correctly in the newest pre.

Thanks!

Originally Posted by schwa

Oh, so the issue is just adding "minor" where appropriate in the media explorer?

Back to the original issue, the media information box in the ME and item properties when the item is on the timeline correctly show minor keys, it's just the Key column that doesn't.
This means when sorting by the Key column major keys will be grouped with their parallel minor (A major with A minor etc.)

[schwa]

Originally Posted by PitchSlap

the media information box in the ME and item properties when the item is on the timeline correctly show minor keys, it's just the Key column that doesn't.

If the media was previously loaded into the media explorer with an earlier version of REAPER, you will need to select the file, right-click and run "re-read metadata from media".

[PitchSlap]

Originally Posted by schwa

If the media was previously loaded into the media explorer with an earlier version of REAPER, you will need to select the file, right-click and run "re-read metadata from media".

I only saw improved display of length in the changelog so thought the KEY column may have been missed so bumped the thread before realizing it'd already been fixed.
Key is displaying as expected now.

MIDI 1.0 files don't define any modes other than 0 = major and 1 = minor.
Key signature is a message rather than meta-event in MIDI 2.0 (see section 7.5.7), and you can represent all 7 modes by specifying the correct tonic key, but it'll likely be a while before there's (m)any files taking advantage of this feature.