MIDI editor: what you can fix after a conversion

The short answer: you cannot edit individual notes on this page — what you can change here is the conversion itself. Five controls (mode, sensitivity, shortest note, BPM and snap-to-grid) re-run a cheap segmentation pass over the same analysis, while a real MIDI editor edits the event list inside the downloaded .mid. The split is measurable. On this site's own engine, a 10.22-second clip takes 218.33 ms to analyse once but only 0.377 ms to re-segment — 579 times cheaper — which is why moving a slider feels instant. But across 1,152 control combinations, one chosen note kept the pitch 60, the start 0.0000 s, and a velocity of only 112 or 113. No control can retune it, shift it to an arbitrary time, or set its velocity. Snapping to a 1/16 grid at 120 BPM moved onsets by up to 47.21 ms, and the resulting four-note file is 91 bytes with zero program-change, zero pitch-bend and zero text events. So: fix note selection and grid placement here, then open an editor for anything that concerns one note or one added event. Both the analysis and the preview run entirely in your browser — no upload, no account, and the file is yours to edit wherever you like.

1. Two different things people call "editing"

Search for a MIDI editor after a conversion and you are usually looking for a piano roll: click a note, drag it, change its velocity, delete it. That is file editing — it changes a note-on / note-off pair in a Standard MIDI File. This page has no piano roll. It is an analysis editor: the audio is decoded and analysed exactly once, and every control re-runs only the step that groups analysis frames into notes. The two operations are not interchangeable, and knowing which one you need saves a wasted round trip.

That asymmetry is the whole reason the controls feel free: changing the grid does not touch the FFT work. It also explains the hard limit. Because every control funnels back into segment(), none of them can reach into a finished note and alter one attribute. For a byte-level description of the file those notes become, see what is actually inside a MIDI file; for the note list that sits between analysis and export, see audio to notes.

2. What the five controls can and cannot change

The converter exposes five inputs that affect the export: a mono/poly switch, a sensitivity slider, a shortest-note field, a BPM field, and a snap-to-grid checkbox with a 1/8, 1/16 or 1/32 grid. We ran each one against known synthesised clips using the site's real dsp.js and midi.js, so the numbers below are outputs, not estimates.

Read the third column as a group. Every control changes which notes exist or where the whole set sits in time. None of them takes a single note as an argument. That is the defining difference between a converter with settings and an editor with a selection.

3. Measured: snapping to the beat grid is a bulk rewrite of time

We built a 2.007-second clip with five deliberately off-grid notes (C4, D4, E4, G4, A4). Raw segmentation put their onsets at 0.1277, 0.4528, 0.7663, 1.1029 and 1.3816 s — exactly frames 11, 39, 66, 95 and 119 of the 11.609977 ms analysis grid. Then we swept all three grid values at six BPMs: 18 combinations, 90 note positions.

Three details are easy to miss. First, the five pitches and five velocities are identical in all 18 rows: snapping rewrites time only. Second, the file size moves between 93 and 101 B with the same five notes, because different onsets produce different delta-time byte widths — a reminder that MIDI file size follows the event bytes, not the audio length. Third, at 60 BPM and 1/8, notes three and four both land at 1.0 s: only four distinct onsets remain for five notes. The segmenter does not merge them. Resolving that collision is exactly the sort of job a piano roll exists for.

Snapping also changes note lengths. At 120 BPM and 1/16 the five durations became 0.25, 0.125, 0.25, 0.125 and 0.25 s; two notes came back at 0.125 s because their ends rounded to the neighbouring grid step. There is no strength control here — the rounding is all or nothing, applied to every note. How to clean up a converted MIDI explains why a partial-strength quantize in an editor is often the gentler choice.

The BPM field is coupled to the grid, and nothing else

This one surprises people, so we isolated it. With snapping off, the BPM field only converts seconds into ticks when the file is written; the note list is untouched. With snapping on, the grid step is (60 / BPM) × (4 / grid), so the BPM field becomes a timing edit.

With snapping on, all six CSVs are different. The first note sits on tick 120 — exactly one sixteenth — at every BPM from 60 to 173, then jumps to tick 240 at 200 BPM because 0.1277 s rounds to two 75 ms steps rather than one. That is a rounding decision, not a tempo detection. How accurate the tempo a converter writes is covers the other half: the BPM value is the one you typed, not a measurement of the audio. If you need it measured from the file, the BPM finder is a separate page.

4. The 1,152-combination check: what no control can do

A table of individual sweeps can always be argued around — maybe some combination of settings reaches the note you want to fix. So we enumerated the entire control space of this page: 2 modes × 6 sensitivity values (0, 20, 40, 60, 80, 100) × 4 shortest-note values (0, 60, 120, 200 ms) × 2 snap states × 3 grids × 4 BPM values (60, 120, 173, 200) = 1,152 combinations. For each, we ran segment() on the same analysis and tracked the C4 note that starts at 0.0000 s. It existed in 960 of them.

To be precise about the velocity claim: across a different clip, the full combination sweep produced velocity values of 87, 90, 93, 99, 111, 112 and 113 — but those came from notes that covered different sets of frames, not from an edit applied to one note. This matters for the honest conclusion: you can influence velocity indirectly by changing the audio or the grouping, but you cannot select a note and set its velocity. For why a flat velocity lane is worth fixing at all, see why converted MIDI sounds robotic.

There is also a resolution floor. With snapping off, every onset is an integer frame: on the four-note clip the raw starts were frames 0, 42, 85 and 129, with zero residual against the 11.609977 ms grid. At 120 BPM one MIDI tick is 1.0417 ms, so a piano roll can position a note about 11 times more finely than the analysis grid, and the 18 snapped grids above are coarser still (37.5–500 ms). If the timing you need is between two frames, no setting here will produce it.

The same boundary shows up when notes go missing: the order to fix dropped notes walks through format, mode, sensitivity and shortest-note checks — all of them re-segmentation decisions. It does not include "drag the missing note back in", because that step does not exist here.

5. What a real editor has to add, byte by byte

We exported four known notes (C4, D4, E4, G4) and parsed the file back with a running-status-aware reader. This is the complete event census:

Now the smallest possible edit. We changed the byte at offset 52 from 0x71 (113) to 0x40 (64). Exactly one byte of the 91 changed, the file stayed 91 B, and its SHA-256 prefix moved from 9156028a2ad6 to b95bcd01a07c. Parsing it back confirms the first note-on velocity is now 64 while the other three are still 113. No combination of the 1,152 settings above can produce that file, because the writer derives all four velocities from the audio. Note that this writer also puts the velocity in the note-off event at offset 57, so a consistent edit is a two-byte change (SHA-256 prefix 88d107d09976).

Adding something new is just as concrete. Inserting three bytes 00 C0 00 at the start of track 2 and raising that track's length from 42 to 45 bytes gives a 94-byte file which our parser reads as one program-change event with the same 4 note-on / 4 note-off events and the same three meta types (SHA-256 prefix 2ca6c739e220). That is the entire difference between "no instrument specified" and "instrument specified". It is a file edit, not an analysis setting. What playing a MIDI file back actually shows explains why the player, not the file, chooses the sound when that byte is missing; how to make a MIDI file shows that a hand-drawn or score-derived file has the same thin shape.

6. Should you stay here, or open an editor?

Three honest answers, each tied to a number above. The point of writing the "walk away" cases down is that the "stay here" case is only credible if the boundary is real.

Notice that all three rows still begin here: you convert once, download, then decide. The editor is downstream of the conversion, not a replacement for it.

7. A practical order of operations

1. Convert a clean, isolated source once. A single-line WAV or MP3 gives the detector a stable harmonic structure; mono vs poly explains which mode to start from, and what a bend does to guitar notes covers a common source of fragments.
2. Set mode and sensitivity first. They decide the note set. On the measured clip, sensitivity 0–30 gave 0 notes and 80–100 gave 4; choosing this before anything else avoids polishing notes you will delete.
3. Set the shortest-note filter next. It removes whole short candidates (400 ms removed all 3 notes in the sweep) but never shortens a surviving note.
4. Decide on snapping last, and set BPM before it. With snapping off, the BPM field leaves the 230-byte CSV identical across six values; with snapping on, it changes every onset. Doing these in the other order produces a file you will want to re-export.
5. Download both .mid and .csv. The CSV keeps seconds at four decimal places and is the better handoff when you intend to edit times yourself — audio to notes has the column-by-column comparison, including the 1.0417 ms tick grid the .mid uses.
6. Then edit the file. Fix individual pitches and velocities, resolve snapped collisions, add instrument and key, split tracks. The five cleanup passes give a working order for that stage, and how big the file can get explains why adding notes barely changes its size.

One last practical note: converting again does not lose anything except time. The analysis is done once per file, and re-segmenting costs 0.377 ms on a 10.22-second clip, so trying ten setting combinations is cheaper than one careful guess. Batch converting several files covers the case where the queue is longer than one clip.

Convert a file now — runs in your browser, nothing is uploaded, and both the .mid and the .csv are yours to take into any editor.

Related guides

• Clean up a converted MIDIThe five passes that turn a raw export into a usable part
• MIDI playerWhat playing a MIDI file back actually shows
• Audio to notesThe note list and CSV before it becomes a .mid
• MIDI converterWhat is actually inside a MIDI file
• Fix dropped notesThe order to check when a conversion misses something
• Mono vs polyWhat each detection mode misses
• Humanize robotic MIDIWhy converted velocity lanes sound flat
• How to make a MIDI fileThree routes, one two-track file
• MIDI file size limitsWhy size follows note events, not audio length
• Tempo detection accuracyWhat the BPM field writes, and what it does not measure