Audio to MIDI: Did the Notes Move, or Did the Bars Change?

A different bar number does not, by itself, prove that your converted notes moved. In our three locally constructed MIDI files, the same note starts at 1.500 seconds: in 4/4 it is bar 1, beat 4; in 3/4 it is bar 2, beat 1. All three files are 80 bytes. Their note events and tempo are identical; only time-signature metadata changes. Check seconds and ticks before dragging the notes to match a new bar label.

Separate the clock from the bar counter

After converting a recording, you may open its MIDI beside the source and notice a different measure number. There are several possible explanations. The project may have a different meter. The clip may be placed at a different origin. The receiving program may use a different tempo. Or the detected notes may actually be early or late. These are separate checks, and changing sensitivity cannot tell you which one happened after export.

This test isolates just the first question: can a different meter label coexist with unchanged note times? It is a byte-level handoff control, not a transcription-accuracy test. We did not submit recordings to a competitor, run a new detector, or open a DAW for this experiment.

Three files, one event timeline

We generated Standard MIDI Files in format 0, with one track, 480 ticks per quarter note, and a tempo of 500,000 microseconds per quarter note. Four note-ons occur at ticks 0, 480, 1440 and 1920. Their pitches are 60, 64, 67 and 72, and each note lasts 240 ticks with velocity 80. The time signature is written at tick zero and stays constant in each file.

The 6/8 row counts written eighth-note units, not the two dotted-quarter pulses a musician may conduct. It is an explicit coordinate convention for this table, not a claim about any application's beat display. A displayed “beat” needs its unit stated.

In this fixed-tempo fixture, seconds = ticks × 500,000 ÷ 480 ÷ 1,000,000. A 4/4 bar spans 1920 ticks. A 3/4 bar and a 6/8 bar each span 1440 ticks, although their notated beat units differ. The calculation changes the bar counter; it does not rewrite the note-on or note-off events.

Inspect the saved bytes, not just the labels

An independent Python reader decoded the files from disk, checked the track length and header, and compared every note event. All eight note-on/off tuples match across the three outputs. Relative to the 4/4 file, the 3/4 file differs at zero-based byte offset 33 only. The 6/8 file differs at offsets 33 and 34. Those are the numerator and denominator-exponent fields inside the time-signature event. File length alone would not establish this; equal lengths can contain different notes.

The time-signature event begins FF 58 04. Its denominator byte stores an exponent: 2 represents a denominator of 4, while 3 represents 8. The tempo event is separate, FF 51 03 07 A1 20, and is unchanged here. Do not interpret the denominator byte as a new tempo or assume that changing 4/4 to 6/8 makes the same events play twice as fast.

The MIDI Association's Standard MIDI Files overview describes time-stamped events and support for both tempo and time-signature information. The Mido project's time-signature documentation and tempo documentation describe separate metadata types. These sources establish the distinction; the downloadable files establish what this particular experiment wrote.

Use the distinction on a converted phrase

1. Keep the original audio and MIDI. Work on a copy and record the clip's placement, project tempo and meter before changing them.
2. Compare the same attacks in seconds. If the attack is still at the same time but its measure label changes, inspect the meter map before moving notes.
3. If seconds differ, check the clock and origin. A fixed shift suggests placement or crop origin; a growing difference calls for checking tempo handling as well as the performance. This fixture does not diagnose every cause of drift.
4. Check note detection separately. Missing pitches, extra notes and incorrect durations remain transcription problems even when the bar counter is correct. A meter change does not recover a missing note.

If you intentionally want to turn the performance into a new rhythmic arrangement, moving or stretching notes can be the right edit. That is different from repairing an apparent import error. First decide whether you want to preserve absolute time, preserve beat positions, or create a new arrangement.

For neighboring checks, see keeping an excerpt's source position, what quantization does to note ends, and octave labels versus numerical pitches. Those pages answer different first questions. This page isolates bar coordinates while the clock stays fixed.

Reproduce the result and keep its limits

Download the generator, the independent Python parser, the coordinate calculations, and the parsed event and byte comparison. Put them in one folder. Run node meter-experiment.mjs, then python inspect-meter.py. The generator writes only its three fixtures and JSON report in its own directory; the parser verifies the saved files. Neither script reads your music library or contacts a service.

Limits: these are constructed event files, not outputs measured from three converters. There is no audio input in this experiment, no automatic meter detection, no changing meter or tempo map, no pickup-bar convention, no listening and no DAW import test. We held the tempo and event ticks fixed; an editor that also transforms those values is a different case. The result proves a small, useful control: a changed measure coordinate alone is insufficient evidence that the underlying note time changed.

SHA-256 of the three exact files

four-four.mid: fe215370fd5c02299b5faabfa9e880215246ad6f683e3376ff1ce1d2c5999e2e

three-four.mid: 4dbf4243bcbb2b86ecae7da0a9605ef03d34a68bbddcf6602a1aea443f1b4707

six-eight.mid: 520d414b6858104906a62370dbb370ccd517a32161f5b8967689f875c36ebe04