MP3 to MIDI: Why a 6/8 File Clicks Three Times a Bar
A converted file states its meter in one meta event of seven bytes, and two of its four numbers are almost never read. When a 6/8 recording clicks three times a bar instead of two, the click byte is 24 decimal where the specification's own 6/8 example puts 36.
Short answer
- Seven bytes, four numbers. The event is FF 58 04, then nn dd cc bb.
- A clock is not a tick. 24 clocks to a quarter note, whatever division says.
- 36, not 24. 36 clocks per click gives two clicks in a 6/8 bar; 24 gives three.
- The last byte counts notation. 08 means the 24-clock unit is drawn as a quarter note.
Seven bytes, four numbers
The event begins FF 58 04. The 04 is a length, and four single-byte numbers follow it. nn and dd are the meter as notated, and dd is not the denominator. The specification states the rule: "The denominator is a negative power of two: 2 represents a quarter-note, 3 represents an eighth-note." So 6/8 is stored as 06 03, and a writer that puts 08 there has declared a 256th note.
A clock is fixed; a tick is not
cc is "the number of MIDI clocks in a metronome click." A clock does not come from the file header: the protocol fixes 24 of them to a quarter note. That makes cc independent of division. At 96 ticks per quarter a clock is 4 ticks, so 36 clocks is tick 144; at 480 ticks per quarter a clock is 20 ticks, and the same 36 clocks is tick 720. The byte describes the music, the tick count describes the file.
Two numbers both written 24
The example line is FF 58 04 06 03 24 08, and the gloss beside it reads "36 MIDI clocks per dotted-quarter (24 hex!)". The same passage also says "there are 24 clocks per quarter-note, 72 to the bar." One 24 is decimal, the fixed clock count of a quarter note. The other is hex, the cc byte, which is 36. Read cc as decimal 24 and the click falls every two eighth notes. Nothing in the file flags the error.
Why the compound bar wants 36
Six eighths at 12 clocks each is 72 clocks, and 72 divided by 36 is exactly 2. That is the compound beat: the click falls on the first and the fourth eighth. With cc at 24 decimal, 72 divided by 24 is 3, and the clicks fall on eighths one, three and five. nn and dd still say 6/8. Only cc disagrees, and only cc can correct it.
The fourth byte counts notation, not time
bb is "the number of notated 32nd-notes in a MIDI quarter-note (24 MIDI clocks)." Eight thirty-seconds fill a quarter, so 08 says the 24-clock unit is drawn as a quarter note. Draw that unit as a dotted quarter and the same span holds 12 thirty-seconds, so bb reads 12; a half note would be 16. The specification gives the reason the byte exists: programs let a user specify that "what MIDI thinks of as a quarter-note (24 clocks) is to be notated as, or related to in terms of, something else."
6/8 and 3/4 spend the same clocks
A 6/8 bar is 72 clocks. A 3/4 bar is three quarter notes, also 72. Timing cannot separate them: the same clocks per bar, the same tempo value, the same tick count for the bar at any division. What separates them is nn, dd and cc. A file can therefore have correct bars and a wrong beat.
What to check in the file you downloaded
Search the bytes for FF 58 04 and read the four numbers after it. Treat dd as an exponent, cc as hex, and expect bb to be 08. songscription's cleanup guide lists the meter among the things to set inside the DAW — "set the correct tempo and time signature so the bars line up with the music" — and jukeblocks observes that "Material played to a click transcribes best." Both describe the session. Neither says the click is a byte with a fixed unit.