GarageBand audio to MIDI: why the first note lands early

The short answer: silence at the front of a GarageBand bounce never deletes a note — across 15 different leading-silence lengths from 0 to 10 seconds, all four notes returned every time, at pitches 60,62,64,67, with velocity only moving between 112 and 113. What silence does change is the timestamp: the first onset comes back early, by up to 84.4 ms. And the drift is not proportional. With 0.1 s of silence the note is 4.5 ms late; at 0.25 s it is 29.4 ms early; at 1 s it is 82.8 ms early; beyond 3 s it settles to about 73–77 ms early and stays there. The cause is not a timing bug in the detector. The voice gate is computed from the quietest tenth of the whole file: silence drags that floor from 0.29586 to 0.00000, the gate collapses from 0.29941 to 0.04497, and the 2048-sample analysis window (92.88 ms, eight frames) already contains the attack before its true frame arrives — so faint pre-attack frames clear the lowered gate and claim the note's start. Export a tight region and the whole problem disappears: with 0.2 s or less of lead-in, all 15 measurements stayed within ±4.5 ms. Conversion runs entirely in your browser — no upload, no account, nothing to install.

1. Should you convert here, install something, or stay in GarageBand?

Before the numbers, the honest decision. Three situations, three answers, each pinned to a value measured on this converter rather than to an opinion about a host application.

Everything after this section assumes you are in the first case. That is the one where a browser converter is genuinely the fastest path.

2. The route, in three sentences

Export the region from GarageBand as one audio file, trimmed to start at or just before the first attack, with short auto-fades left alone. Drop it on this converter, download the .mid and the .csv, then drag the .mid back into your GarageBand project and load an instrument on the track. The rest of this page is about the one export choice left open — how much silence and fade surround the notes — and what those edges do to the reported times.

3. What we measured, and how

Every number below comes from running this site’s real dsp.js and midi.js in Node on synthesised material whose correct answer we already knew. No third-party tool was measured and no figure is estimated. The reference clip is four notes (C4 261.63 Hz, D4 293.66 Hz, E4 329.63 Hz, G4 392.00 Hz), 0.5 s each, with a mild harmonic series and 10 ms ramps, rendered at 22 050 Hz with a peak amplitude of 0.35. Unless stated: sensitivity 60, shortest note 60 ms, 120 BPM, quantize off, polyphonic mode. Leading silence was built by prepending an exact number of zero samples to the same array; nothing was recorded through a sound card.

The analysis grid is fixed by the converter, not by your GarageBand project: audio is resampled to 22 050 Hz, read with a 2048-point FFT stepped 256 samples at a time, so one frame is 11.610 ms (86.13 frames per second) and one window is 92.88 ms, or exactly eight frames. Monophonic search runs 55–1800 Hz; polyphonic peaks are read up to 4000 Hz with at most 6 peaks per frame. Your 44.1 kHz session and its time signature do not enter that arithmetic — we ran the same melody at 44.1k, 48k and 22.05k and the note list was identical every time.

Three neighbouring pages cover adjacent ground, and this one is deliberately narrower. How to prepare the input file explains that a note starting at exactly 0.000 s is analysed at almost no Hann-window weight, and advises a short lead-in so the first note is detected at all. Why a short region returns no notes measures the opposite failure — a region under 155 ms is too short to survive the window. Our four-DAW export overview has a five-row table showing that padded silence moves onsets, but it stops at “timestamps drift”. This page keeps one four-note phrase fixed, sweeps 15 silence lengths, and opens the segment() gate to show why the drift changes sign, where the cliff sits, what it does to the exported bytes, and which control actually fixes it. None of the tables below are reused from those pages; they are fresh runs made for this one.

4. Fifteen silence lengths: flat, then a cliff, then a plateau

The intuitive model is a straight line — more silence, more drift. That is not what the detector does. We prepended 0, 0.05, 0.1, 0.15, 0.2, 0.25, 0.3, 0.4, 0.5, 0.75, 1, 2, 3, 5 and 10 seconds of digital silence to the same clip and read back the first onset each time:

Three things are worth reading off that table. First, the sign flips: the 0.1 s and 0.15 s cases are late, not early, because with only a handful of silent frames the gate is still high and the onset is simply rounded to the nearest frame boundary (0.1 s is frame 9, which lands at 0.1045 s). Second, the cliff between 0.20 and 0.30 s is not gradual — the error jumps from −2.6 ms to −67.8 ms, a 26-fold change for 100 ms more silence. Third, the plateau is bounded: no measurement went beyond 84.4 ms early, which is under the 92.88 ms window length. That is the fingerprint of a window effect, not a scaling error.

Only the first note is hit this hard. In the 1 s case the four onsets were 0.9172, 1.4629, 1.9621, 2.4497 against true positions 1.0000, 1.4992, 1.9985, 2.4977 — offsets of −82.8, −36.4, −36.4 and −48.0 ms. Later notes drift too, but by roughly half as much, because the frames immediately before their attacks are already above the gate. The seven-column CSV is where these seconds are visible to four decimals.

5. Why: silence lowers a gate that belongs to the whole file

The mechanism is two lines of segment() in dsp.js. Before any note is grouped, the detector sorts the RMS of every frame in the file, takes the value at the 10th percentile as a noise floor, and interpolates between that floor and the loudest frame:

We first measured this whole-file gate on a different question — why padding a too-short region brings a note back, where the gate fell from 0.309651 to 0.044974. The gate values are clip-dependent, so the numbers below are for this four-note phrase. What is new here is the other side of the same mechanism: those lowered gates do not just rescue missing notes, they let pre-attack frames claim the start of notes that were never in danger, which is what produces the timestamp drift.

var floor = sorted[Math.floor(sorted.length * 0.10)] || 0;
var gate = floor + (an.rmsMax - floor) * (0.32 - 0.30 * sens);

At sensitivity 60 the multiplier is 0.32 − 0.30 × 0.6 = 0.14. On the unpadded 2 s clip almost every frame is loud, so the 10th percentile is nearly as loud as the peak: floor 0.29586, gate 0.29941. Once the silent prefix grows past about a tenth of the file, the 10th-percentile frame is silence, the floor goes to zero, and the gate collapses to 0.14 × rmsMax:

Now the second half. Each FFT frame reads a window of 2048 samples forward from its own start, so a frame beginning up to eight frames (92.88 ms) before the audible attack already contains that attack in its tail, at low but non-zero energy. With the unpadded clip those faint frames sit far below the 0.29941 gate and are discarded. With the gate at 0.04497 they clear it. Here is the exact boundary for the 1 s case, where the true attack is frame 86 at 1.0000 s:

Frame 79 is the whole story. Its RMS is 0.05540 — just above the collapsed gate, far below the original one — and because its 2048-sample window already includes the attack, it reports four spectral peaks including pitch 60. Grouping consecutive frames with the same pitch then declares the note's start at frame 79, seven frames = 81.3 ms before the true frame 86. The extra peaks at that frame (84, 88, 91) are transients that never survive the shortest-note gate, which is why the file still contains exactly four notes. Note also that those faint frames have salience between 0.0375 and 0.1851, below the monophonic threshold of 0.2000 — which is why monophonic mode barely drifts at all, as section 8 shows.

This is also why the error stops growing. A frame whose window does not overlap the attack has RMS exactly zero and cannot clear any positive gate no matter how much silence you add; the earliest possible claim is bounded by the eight-frame window. From 3 s to 10 s of silence the measured offset wanders only between −73.5 and −77.4 ms, changing by one frame as the attack lands at slightly different positions inside the hop grid. The four-step troubleshooting order puts format and mode ahead of sensitivity for a related reason: no slider rewrites a gate that was computed from the file as a whole.

6. It is not only the front: position, gaps and fades

If the cause is a whole-file percentile, then silence anywhere should lower the gate — not just a prefix. It does. We placed the same four-note phrase in seven export shapes:

Trailing silence does not leave the timing of later notes alone — a point worth stating plainly, because the common advice is that padding the end is harmless. It is harmless to the first note (still 0.0000 s) but lowers the same gate for the rest of the file, pulling notes 2–4 about 35–46 ms early. A silence gap in the middle does the same to the note that follows it: with a 0.5 s gap after the first note, note 2 was reported at 0.9172 s instead of 1.0000 s. The gate is global; the error is local to whatever attack sits after quiet frames.

Fades are the more surprising case, and they push the first onset in the opposite direction. GarageBand applies a short fade-in and fade-out to bounced regions by default. Our export overview measured that linear fades up to 100 ms leave note count, pitches and velocity untouched, but it did not measure onset times. We did, on the unpadded clip:

The fade case has its own gate signature. Because a fade does not add silent frames, the 10th-percentile floor stays high: 0.29586, 0.29555, 0.29505 and 0.29407 for fades of 0, 20, 50 and 100 ms, with the gate holding near 0.298–0.299. The opening frames are now attenuated below that high gate, so the first qualifying frame moves from 0 to 1, 3 and 6 — exactly the +11.6, +34.8 and +69.7 ms in the table. Only past 200 ms does the floor finally start to fall (0.22485) and velocities begin to drop. So the practical advice is asymmetric: a normal short auto-fade is safe for pitch and velocity, but it is not invisible to timing, and a long fade is a different problem from long silence.

7. What the exported file actually records

A drift in seconds becomes a drift in ticks. The writer in midi.js converts each onset with round(start × 480 × bpm / 60), so at 120 BPM one second is 960 ticks and the padded first note lands at 881 instead of 960:

Two details matter if you are aligning to a DAW grid. The .mid grows from 89 to 90 bytes once the first delta-time needs a two-byte variable-length quantity — a one-byte change that encodes the entire timing error. And the note becomes longer, not just earlier: on the bare clip the first note ran 0.0000–0.4180 s (0.4180 s), while with 1 s of lead-in it ran 0.9172–1.4512 s (0.5341 s), because the trailing end of the note also finds frames above the lowered gate. Trimming silence is therefore a timing fix and a note-length fix.

The BPM box is not a fix, and its arithmetic is worth seeing. The CSV writer has no BPM argument at all — the same padded note list produced the identical first CSV row at 60, 90, 120, 140, 173 and 200 BPM. But the .mid tick grows with the tempo you typed, so the error measured in ticks grows with it:

How accurate the written tempo is measures the other half: the BPM is written verbatim and moves no notes. Here the notes are already displaced, and a higher BPM simply expresses the same 82.8 ms as more ticks. If you want the exact seconds, the CSV is the closer record of what the analyser saw; what a MIDI file is explains why it holds instructions rather than a timeline.

8. What actually fixes the timing

The obvious controls mostly do not. We took the 1 s padded clip — first onset 0.9172 s, 82.8 ms early — and changed one setting at a time:

Monophonic mode is the real fix for a single-line part, and the frame table in section 5 explains why. It requires both the RMS gate and a harmonic-salience score above 0.35 − 0.25 × sens = 0.2000; the faint pre-attack frames score only 0.0375–0.1851, so the first accepted frame is 85 at 0.9868 s, just 13.2 ms early. The trade is that monophonic mode collapses chords — why the two modes fail differently measures that. Quantizing to 1/4 or 1/8 happens to snap this particular 1.0000 s onset back exactly, but it is a bulk rewrite of every onset in the file, and 1/16 demonstrably makes it worse; what the browser controls can and cannot change covers the general case. The reliable, no-side-effect fix is the one available in GarageBand before you export: trim the region so it starts within 0.2 s of the first attack.

9. GarageBand export checklist, in order

1. Trim to the attack. With 0.2 s or less of lead-in, all five measured short cases stayed within ±4.5 ms and returned 4 of 4 notes at velocity 113. This single step removes the cliff, the tick error and the stretched note length.
2. Do not leave a long tail either. 1 s of trailing silence left the first onset exact but pulled notes 2–4 about 35–46 ms early, because the floor is computed over the whole file.
3. Keep short auto-fades, but know what they cost. Fades of 20, 50 and 100 ms kept all 4 notes and velocity 113, yet moved the first onset +11.6, +34.8 and +69.7 ms late. A 400 ms fade moved it +139.3 ms and dropped velocity to 109.
4. Do not re-bounce to fix velocity. Across the 15 silence lengths velocity moved only between 112 and 113; the drift is timing, not loudness. Why export level changes velocity and not pitches gives the separate formula for that ladder.
5. Use monophonic mode for one clean line. On the 1 s padded clip it cut the onset error from 82.8 ms to 13.2 ms without losing a note. For chords, stay in polyphonic and trim instead.
6. Check the region is long enough. Silence will not delete a note, but a tightly trimmed short region can — a region under 155 ms returns none.
7. Check the CSV before the piano roll. If pitches are right and the first start_sec is earlier than the waveform, suspect the bounce's edges, not the sensitivity slider. The CSV columns explained shows which ones come straight from the frame grid.
8. Choose the file format on its own merits. One .m4a can be lossless ALAC or 32 kbps AAC; that choice has a measured effect of its own, separate from the timing here.

If you are bouncing several parts, do them one file at a time; why there is no folder-drop batch button explains the workflow. On a phone the same page works with a file from the share sheet; mobile audio to MIDI covers the input differences. And if the notes themselves look wrong rather than early, the cleanup passes are the next step.

Convert an exported file now — runs in your browser, nothing is uploaded.

Related guides

• Other DAWs audio to MIDIWhich export settings change the notes: length, level, channels, silence and fades
• WAV to MIDIThe two edges of the file, the Hann window and why a short lead-in helps detection
• Reaper audio to MIDIWhy a region under 155 ms returns no notes
• Cubase audio to MIDIDoes export level change which notes come back: the 16-bit -58 dB threshold
• Studio One audio to MIDIWhat stereo and hard pan cost the notes: the (L + R) / 2 sum and one-frame delay wall
• Audio to notesThe 7-column CSV and the exact seconds behind every onset
• Tempo accuracyWhy the written BPM is your input and does not move the notes
• What is a MIDI fileInstructions not audio: format, tracks, channels and bytes
• How to make a MIDI fileThree routes, one 2-track file, compared byte by byte
• MIDI editorWhat the browser controls can and cannot change after conversion
• Mono vs polyWhy the two detection modes fail differently on the same clip
• Fix dropped notesThe order to fix it: format, mode, sensitivity, shortest note
• Clean up a converted MIDIThe passes that remove ghost notes and split objects
• Sample rate & MIDIWhy 44.1k, 48k and 22.05k return the same note list
• Humanize robotic MIDIWhy the export is grid-locked and velocity-flat
• Drum transcription limitsThe 55 Hz floor, the 4000 Hz ceiling and the 11.61 ms grid
• Pitch bend detectionWhat a glide adds to your MIDI, and when it matters
• Audio to MIDI pluginWhen to install one, and when the browser is enough
• M4A and FLAC to MIDIOne .m4a can be lossless ALAC or 32 kbps AAC
• Batch convert audioWhy there is no folder-drop button, and what one file at a time costs
• Mobile audio to MIDIWhat works on iPhone or Android, and what differs
• MIDI converterAnatomy of the file this converter writes