MP3 to MIDI: The Number Behind Forte, Mezzo-Forte and Piano
A converted file carries no dynamic markings, only a 0–127 velocity byte. Two documents in the same family fill that byte differently: the MIDI 1.0 specification's own example writes forte as 96, while MusicXML treats 90 as the default forte. Neither number is wrong, and neither is a curve.
Short answer
- Forte is 96 in the specification's example. Its four Note On events are annotated forte, forte, mezzo-forte and piano.
- The three values are 96, 64 and 32. Equal steps of 32, which is a ratio of 3:2:1.
- MusicXML puts the baseline at 90. Percentages are taken from it, so 100% is 90, not 127.
- The two baselines differ by 6.7%. 96 is 106.7% of 90; 32 is 35.6% of it.
The field has a range, not a scale
Velocity is seven bits, so 0 to 127, and the specification never says what any single value means. The words do appear in it — forte, mezzo-forte and piano — but only as comments on four Note On events in the example file, never as definitions. The words dynamics and crescendo appear zero times in the whole document. A converter therefore has a range to write into and nothing that tells it where loudness sits inside that range, and nothing that separates a value chosen for loudness from one chosen for accent.
Three words, three numbers
The example's event list reads 92 48 96, annotated "Ch.3 Note On C3, forte"; 92 60 96, "C4, forte"; 91 67 64, "G4, mezzo-forte"; and 90 76 32, "E5, piano". The velocities are 96, 64 and 32 — 0x60, 0x40 and 0x20. They are equally spaced: 96 minus 64 is 32, and 64 minus 32 is 32. The ratio between the three words is 3:2:1.
MusicXML puts the baseline at 90
MusicXML defines a percentage scale for the same field: "Dynamics (or MIDI velocity) are expressed as a percentage of the default forte value (90 for MIDI 1.0)." That is the only place in either document where a percentage and a velocity are tied together, and it names 90 — not the example's 96, and not the field's ceiling of 127.
The two baselines are 6.7% apart
Divide the example's values by 90 and they stop looking like dynamics. 96 is 106.7%, 64 is 71.1%, 32 is 35.6%. On that scale a score marked 100% is velocity 90, and one marked 50% is 45. The top of the field, 127, is 141.1%, because the baseline is not the ceiling: the percentage is allowed to run past 100.
Neither number is a curve
Nothing in either document says how to interpolate between the words. The example supplies three points and no slope; MusicXML supplies one point and a multiplier. A converter that writes 96 for a loud note and 64 for a softer one is reproducing an example, not following a rule. A rule would need a slope, a reference point and a unit; these two documents supply one of the three at most. Any decibel figure attached to velocity comes from somewhere other than these two specifications.
What this means in a converted file
If every note carries the same velocity, the file has no dynamics at all, only a constant. If 96, 64 and 32 keep recurring, you are looking at the vocabulary of the specification's example. If 90 recurs, the program adopted MusicXML's baseline. A value of 0 is the exception that proves the point: the format 1 example releases E5 with 4C 00, annotated "note on, vel=0", so a score asking for 0% has no sounding value to land on.
What to check
Read the velocity byte of two or three Note On events before concluding the conversion flattened your dynamics. songscription lists velocity among the four things a transcription extracts — "pitch, start time, duration, velocity" — and jukeblocks says you can "adjust notes, timing, velocity, and instrument" afterwards. Both treat the number as meaningful. Neither says what it is measured against.