Errors, suggestion, requests, etc. on midi files
(r1753 on Vista 64-bit)
After realizing that MuseScore uses quarternote=480 ticks in the midi files it produces while my old CakewalkExpress coarsens it to quarternote=120 ticks, I sat down and wrote a program to decode midi files into more readable form for humans. Having examined several midi files that MuseScore produces, here are a few observations, comments, error reports, and suggestions.
1. Question and suggestion: First of all, an apology to MDMilford. MS does use zero-velocity noteon instead of noteoff. This is being used with Running-Status to reduce the size of the midi file. A question comes to mind: Why then does MS choose QN=480 ticks rather than 120 or even 96, both of which are quite commonly used? Remember that a delta time of 128 or more would take 2 or 3 bytes instead of just 1 byte. With QN=480, this means that any event slightly later than a 32th note (120 ticks) after its predecessor will need extra byte(s). With QN=120, events up to a quarter note apart would still need only 1 byte for delta time. Unless one is using the midi files in conjunction with applications that requires very fine timing (videos maybe?), QN=120 and 96 yield 15 and 8 ticks for a 64th note, repectively, which seems very adequate for musical purposes alone.
2. Error report: In the file ChopinEtude11-r1753.mid, the noteoff (i.e., zero-vel. noteon) for note F7 shows up at offset 0xe9 while the actual noteon appears LATER at offset 0xf2. Looking at the delta times, the real noteon's for that chord (1st chord, 2nd measure, not counting the pickup) are all at the right places but the 3 noteoff's have wrong delta times: Relative to the first note of the chord, the tick offset should be 203; the value of 119 (0x3c+0x3b) is used. Same mistake also happens for the first chord in measure 3, wherein the noteoff's for G7 and A#6 show up at offsets 0x155 and 0x158, repectively, while the real noteon's are at 0x161 (A#6) and 0x164 (G7). Again it's the noteoff's that are out of place.
3. Error report (maybe) and suggestion: I noticed that MS uses Meta Event types 0x08, 0x09, 0x0a and 0x0c for title, subtitle, composer and lyricist, repectively. In RP19 (see http://www.midi.org/techspecs/rp19.php), type 0x08 and 0x09 are defined as 'PROGRAM NAME' AND 'DEVICE NAME', repectively, and intended for other purposes. As far as I know, types 0x0a and 0x0c are currently undefined, but that can change. So perhaps using them for title, subtitle, etc. may cause problems. Why not just use Meta Text event (0x01) and start the text with "Title: ", "Subtitle: ", etc.?
4. Feature request: Could lyrics be produced in the midi file, please? And when it's done, please implement RP26 (see http://www.midi.org/techspecs/rp26.php) so that all languages can be used. (Although only Latin and JP are defined code_set in that document dated 1999, I would expect more have been define by now.)
| Attachment | Size |
|---|---|
| ChopinEtude11.mscz | 2.53 KB |
| ChopinEtude11-r1753.mid | 1.04 KB |
Comments
(again, r1753 on Vista 64-bit)
4. (revisited): On second thought, the code_set idea suggested in RP26 (see previous post) doesn't seem practical here since MuseScore generally wouldn't know what language the score is in. So perhaps encode text in UTF-8 would be a better idea. And I would suggest that UTF-8 be used for ALL text output, including title, subtitle, etc. At this point, Chinese title, etc. all come out as a bunch of ???.
5. Feature request: How about adding a major/minor choice in 'Create New Score' section? True, it has no visual or audio consequences to the score, but it is a bit disconcerting to have a minor piece labeled as mjor in Key Signature Meta Event.
6. Error report: Currently in the Time Signature Meta Event, the cc field (number of MIDI Clocks per mentronome click) is always set to 24, meaning 1 quarter note per metronome click. Again, even though this has no real consequences in most applications, it is rather absurd to see the notion of a metronome clck per quarter note when it is in 3/8 time. I assume this field can be used to indicate divided or compounded beats, but I think just set this to correpond to the denominator (i.e., 12 for 8, 24 for 4, 48 for 2, etc.) would be fine.
7. Error report/Feature Request: BPM in tempo properties. Currently, this is really Quarter notes per minute, based on what I see in the Tempo Meta Events in the midi files. This should at least be pointed out in the manual. I would much perfer that the data in Tempo Meta Events be adjusted to reflect the current notion of a beat so that BPM is indeed Beat Per Measure. For example, if the current time signature is 3/8 and tempo is to be set at 72 BPM, then the value to be used in the tempo MetaEvent should be 60,000,000/(72/2) = 1666667.
In reply to Errors, suggestion, requests, etc. on midi files - Part 2 by yingdat
regarding 5. (major/minor time signature)
I already talked about this: http://n2.nabble.com/Ability-to-change-mode-of-key-signature-td2436604…
So you have one more argument.
Btw, if you can write code. I'm pretty sure patches are welcome !
In reply to regarding 5. (major/minor by [DELETED] 5
My last professional project was the NT device driver for SGI's RAD digital sound card. So it has been a while. Also I have never written a single line of GUI code.
But I will take a look at the source code and see whether there's some thing I could fit in.
In reply to Errors, suggestion, requests, etc. on midi files - Part 2 by yingdat
My preference would be to add options to the tempo properties dialogue box. To the right of the BPM text box there should be maybe a drop down menu box listing the different note types to select which note gets the beat. This should include everything from 1/16th to dotted whole note. This would give the user flexibility to define say 6/8 such that either the eighth (rare), quarter (rare), dotted-quarter (normal), or dotted-half would get the beat.
To take things a step further, below all that I'd like to see the text string (n=##) where n is the note type selected, and ## is the BPM entered. And a check box for "Append to tempo text" This would make it much easier to use that type of tempo notation.
Not to get too far off the subject, but eventually I'd like to see another check box for a swung tempo. (two eighths = triplet [quarter+eighth]) I know that would take a lot of thought and code to get right though.
Lyrics would be a good thing in the MIDI file. There is actually an event type for this although I don't recall what it is right now. Does anyone have any experience with using this type of event. It would be pretty cool if there were software out there that could read the lyrics and pitch and actually sing back. Does anyone know if such a beast exists? I haven't heard of one, but it doesn't seem like it would be a huge leap since there are already screen readers for the blind etc.
In reply to Re: #4 by MDMilford
Myriad has something. Don't sure it supports lyrics in midi. The name is Virtual Singer. It's not free at all ;)
In reply to Re: #4 by MDMilford
A lot of Karaoke files (.kar) are just midi files with lyrics (meta event type 5).
By the way, lyrics are also missing in Lilypond files that MS produces.
(using r1770 on Vista 64-bit. Everything mentioned so far seems the same as r1753.)
8. Feature request: Please add a 'Conductor Track' as Track 0 and put midi events that are not specific to any particular track in this track. This will include events and meta-events for key signature, time signature, tempo, and stuff for title, composer, copyright, etc. This makes the midi file neater. It also has the potential of reducing the file size because such events will not be in the regular tracks to interrupt the running-status of NoteOn.
9. Error report: Extra first measure, starting and end time of notes (A long discourse follows. Specific request/suggestion is in the last 'real' paragraph.)
Quoting from another thread (http://musescore.org/en/node/1436): "A midifile cannot start with a noteon. A lot of events are send first to initialize controller, set instruments. etc. Switch to GM mode and selecting an instrument is slow on some external instruments. ..."
Even if someone is still using such 'slow' instruments, the midi file players (software or hardware) can deal with it quite easily: Carry out the preparatory events, wait for them to take effect (that should usually take much less than a second), then and only then play the first note AND mark that as time 0, i.e., measure 1, beat 1, tick 0. No problem at all. The only requirement is that the preparatory events appear in the track before the first noteon, which everybody does anyway.
demoS-r1770.mid is produced by r1770 from the first 4 measures of the demo score (Promenade from Pictures at an Exhibition); demoS-r1770.mid.txt is its translation into text form. demoS-r1770C.mid and demoS-r1770C.mid.txt are their counterparts with a 'Conductor Track' and the first note starting at time 0. I would be very surprised if your player fails to play both midi files. (Apropos of item 1 in Part 1 of this thread, demoS-r1770Ct120.mid is demoS-r1770C.mid with quarter note= 120 ticks. Note the sizes of the 3 midi files.)
Whether you know it or not, many of the midi files you have probably contain noteon at time 0. Sibelius, for example, has been producing such midi files since ver. 3, if not earlier. I have not heard any complaints that their midi files cannot be played.
So I think it's safe to say that the extra first measure is unnecessary and should be eliminated.
This brings up another issue. If you look at demoS-r1770.mid carefully (or demoS-r1770.mid.txt for those of us who don't read midi), you will notice that even though the notes are shifted forward 1 measure, key signature and time signatures are not. So the 6 notes in the first measure (5/4) are now in the 6/4 second measure. Out of curiosity, I imported demoS-r1770.mid back into MuseScore. Much to my surprise, there is no extra first measure and all notes show up at their rightful places! A neat trick.
However, if you think a little bit more about it, this is rather disconcerting. In order for MuseScore's import facility to perform this trick, it must guess where the notes should begin and end instead of trusting what the midi files says. Now, since the primary function of a midi file is to indicate where the notes begin and end, this would seem like an odd way to import a midi file. Although this works well for (and clearly necessitated by) midi files MuseScore produces, guesses (no matter how well crafted) are bound to make mistakes in general applications. I tried Sibelius' song Illale and an arragement of mine and both came out wrong.
The solution is simple: Get rid of the extra first measure in midi export and there will be no need to guess during midi import. The simplest approach, and the most effective one, is to make the notes in the midi file begin and end where the score dictates, and vice versa, or at least make them correspond as closely as possible. (A note that begin at tick 7 and ends 2 ticks later should rightfully be discarded during midi import - there is just no way to represent such notes in a music score.) This will also make notes last their full duration instead of the current 85%(?). The current way produces music that sounds choppy to my ear, especially on legato instruments.
[I thank you for your patience if you have read this far!]