Clipping microphone?
Check which volume control reaches the recording.
Turning down headphones is not the same as turning down the microphone signal being recorded. Before another take, identify the recording input and test whether the control changes the saved audio, only the monitor path, or both. To prevent overload at a particular stage, the reduction must reach that stage before it overloads; a quieter downstream signal is not proof that it did.
This page answers the control-routing question before you record a melody for transcription. It is not a microphone shopping guide, a hardware clipping benchmark or a repair recipe for an existing take.
Download the recording-versus-monitor worksheet (CSV)
One source, two destinations, four control positions
Collected and repeated October 12, 2026, on a Windows test machine. We sent the same generated tone through an actual FFmpeg filter graph with separate recording and monitor branches, encoding each branch as WAV. This is a software routing model: no microphone, physical input gain, speaker playback or clipping was tested. The monitor output below is a rendered branch file, not sound captured from headphones.
| Changed control | Record peak | Monitor-model peak | Record PCM versus baseline | Monitor PCM versus baseline |
|---|---|---|---|---|
| Baseline · all gains ×1 | 24,576 | 24,576 | Identical | Identical |
| Monitor branch only · ×0.25 | 24,576 | 6,144 | Identical | Different |
| Record branch only · ×0.25 | 6,144 | 24,576 | Different | Identical |
| Shared gain before split · ×0.25 | 6,144 | 6,144 | Different | Different |
Swipe sideways for every column. With a keyboard, focus the table and use the arrow keys.
The monitor-only change left the recording WAV byte-for-byte identical to baseline. Its quieter monitor-model output did not establish any change in what was saved. The record-only change did the reverse. Reducing the shared stage changed both destinations. These are measured responses to known routes, not a claim that a knob with a particular label always occupies one of those positions.
On our explicit sample scale, 24,576 ÷ 32,768 = 0.75, or −2.498775 dBFS; 6,144 ÷ 32,768 = 0.1875, or −14.539975 dBFS. Multiplying by 0.25 changed the sample peak by −12.041200 dB. These values are test settings, not recommended microphone targets. None of the files reaches either integer rail. We deliberately did not inject clipping: this experiment isolates routing, not damage or recovery.
Test the control, not its label
A recorder may separate input gain, track processing, export level, software monitoring and hardware direct monitoring. Find the selected input and the point from which that track records before choosing a control. The editor's recording and playback meter documentation, for example, distinguishes its recording-level control from its speaker-volume control. Its playback-volume reference explicitly separates listening level from exported audio. These are documented examples, not applications tested in our model.
- Write down the route. Note the actual device, channel, recording mode, control name and any automatic processing. Confirm that the track records the intended microphone rather than a different device or a mixed output. Do not assume every track fader changes incoming recording samples.
- Keep a baseline take. Record a short, comfortable phrase and save it without normalization or repair. Use a new filename for the comparison. Do not make yourself shout or monitor at an unsafe level.
- Change one control for a new take. Keep the source, position and other settings as consistent as practical. A repeated human performance is not sample-identical; note that uncertainty. A calibrated repeatable source is needed for precise gain comparisons, not merely repeating a sentence.
- Inspect the saved audio separately. Compare the actual recorded channel over corresponding passages, with the same analysis settings. Check whether the recording's level changed; separately note what happened in the monitor path. Do not normalize both files first: that would obscure the level change you wanted to observe.
- Choose the next investigation from both observations. Use the table below. Linked controls, automatic gain, effects and different recording taps can produce similar responses, so the result narrows the route rather than proving a failed component.
| What changes? | What to check next | Do not conclude |
|---|---|---|
| Monitor only | Look for a listening/output-only control; identify the actual record-level control. | Quieter headphones do not establish a safer recorded input. |
| Saved take only | Check a record-only path or independent hardware monitoring. | This does not locate an analog overload or prove a particular knob is before the converter. |
| Both | Check a shared upstream stage, linked controls and automatic processing. | The same response does not prove the entire signal chain is clean. |
| Neither | Check device/channel selection, recording mode, whether the control is effective and automatic gain. | No response alone does not prove that the microphone is faulty. |
If the recorder already receives damaged audio, establish where the overload occurs before treating another downstream slider as prevention. A software level change cannot demonstrate that an earlier microphone or input stage avoided overload. This worksheet does not diagnose analog stages from exported peaks. If the recording is already clipped, use the separate repair-versus-rerecord decision; if your only evidence is a meter number, use the peak-evidence check.
Download and compare the exact files
- Control-response worksheet (CSV) · recommendations, four measured cases and a blank observation row are explicitly separated.
- Generated source WAV
- Baseline: record WAV · monitor-model WAV
- Monitor-only reduction: record WAV · monitor-model WAV
- Record-only reduction: record WAV · monitor-model WAV
- Shared reduction: record WAV · monitor-model WAV
- Full measurements, filter graphs and hashes · Reproduction script
Every WAV is 192,044 bytes: mono, 48,000 Hz, signed 16-bit PCM, 96,000 frames and exactly two seconds. Size alone cannot distinguish the routes. Baseline and monitor-only recording PCM both have SHA-256 6a9fe5b01a587fde96e237334c6b6eab3731c9498653fa0e0d877748250cdbef. The quarter-level PCM has e47d3d9509ea9b6d18ec0c21d470db846f17286ef563d121d9815d21a9be87c2. Hash equality verifies these exact sample bytes, not sound quality.
Method and boundaries
The source is a generated 1,000 Hz sine with 10 ms linear edges and a peak of 24,576 integer counts before routing. FFmpeg build N-92722-gf22fcd4483 decoded that WAV, applied double-precision volume filters, split the signal, and encoded both mapped outputs as signed 16-bit WAV with bit-exact flags. The official split-filter documentation describes branching; its volume-filter reference documents gain and precision. All four actual filter graphs are retained in the JSON.
The script parses each output's format and data chunks, measures sample peak and RMS, counts samples equal to +32,767 or −32,768, and hashes the exact PCM payload and complete file separately. All nine WAVs and measurements matched on a same-day repeat. Run the downloadable Node script with FFMPEG_BIN pointing to an installed FFmpeg executable, using a fresh output directory set through ROUTING_OUT; rerun with --check to verify the existing results without replacing them. It generates test files, not a microphone recording.
No hardware microphone, preamp, ADC, direct-monitor circuit, operating-system input control, browser recorder, speaker output, listening judgment, actual clipping, repair or MIDI performance was tested. A routing model does not establish where your real device clips. The new contribution is the dated paired-output comparison and observation worksheet—not the general discovery that playback volume differs from input gain, and not a claim of worldwide exclusivity.
Once your actual saved take is checked, use a short isolated melody in the file-based converter and verify the notes against it. This site does not record your microphone. Correct input routing and an unclipped source do not guarantee accurate MIDI; the note-and-file check remains a separate step.