DC Offset: Fix the Bias, Not Every Click

DC offset is a persistent shift of an audio waveform's average away from zero. To check your file, measure the mean sample value separately for each channel across comparable regions, including recorded silence where available; record the selection and units rather than judging unequal peaks by eye. A nonzero average in a short musical selection alone does not establish persistent constant offset.

Remove confirmed constant DC offset on a copy before cutting or joining audio. Leaving it untreated can reduce available headroom and contribute to clicks at boundaries. But an uneven-looking waveform alone does not establish the diagnosis, and correction will not necessarily fix a clicking edit or playback-dependent noise. It cannot restore peaks already lost during recording.

Download the DC-offset decision table (CSV)

Check the average, not the tallest peak

Constant-offset correction subtracts the selection's mean sample value. Making the highest positive peak and lowest negative peak equally tall is a different operation. Before treating a lopsided picture, establish whether the selection has a displaced average rather than assuming that unequal peaks prove it.

The decision table below separates recommendations from the measured illustrations in its conversion column. For this signed 16-bit test, normalized FS = mean integer sample value ÷ 32768, and percent FS = normalized FS × 100. These are digital sample scales, not physical voltage measurements.

Why correcting the whole file can move its silence

Consider a displaced passage surrounded by inserted silence that already sits at zero. A correction calculated across the entire selection applies the same shift to both. The passage moves toward the centre; the formerly centred silence moves away. That result can reflect the selected material rather than a broken correction tool.

Inspect the start, the main passage, and the ending separately. Keep unaffected sections outside the correction where appropriate, then inspect the joins. The selection boundary is part of the treatment, not just a way to highlight audio. A slowly changing bias also needs different consideration from one constant shift. Do not keep repeating a whole-file correction merely because different sections still look different.

Dated comparison: constant correction, joins and changing bias

Measurements collected and repeated on October 9, 2026, on a Windows test machine. Both runs produced the same PCM hashes and measurements. These are synthetic, code-level tests, not microphone recordings or listening tests.

The reference was an existing two-second mono 440 Hz tone, decoded from signed 16-bit WAV at 44,100 frames per second. I added 6,554 integer sample counts without reaching either PCM rail. I measured the new mean, rounded it to an integer sample count, and passed the WAV through FFmpeg dcshift. The correction setting was shift=-0.20001220703125, calculated from the measured rounded mean, not selected as a recommended setting for other recordings.

As a separate tool check on the same date, the installed FFmpeg build N-92722-gf22fcd4483 displayed DC offset 0.200018 for the biased WAV with astats=metadata=0:reset=0. Its integer-input statistic uses 32767 as the denominator, giving 6554.001292517 ÷ 32767 = 0.200018350551 before display rounding. Our PCM-to-FS table uses 32768 instead. The two readings describe the same samples on different scales; do not copy a displayed offset into a correction setting without checking the scale.

The biased region measured +0.200012246476 FS before correction and +0.0000000394445 FS afterward. Its corrected PCM hash matched the clean reference exactly. A separate run through this site's unchanged Balanced detector returned one pitch-69 note from each version, but velocity changed from 118 before correction to 62 afterward; the clean reference also returned 62. This is a detector-output observation, not a loudness or sound-restoration score.

For the splice comparison, I placed the same biased region between two newly generated 0.1-second blocks of digital silence. The complete file then lasted 2.2 seconds. Its entry and exit jumps were +6,554 and -6,554 counts. Correcting that complete file with shift=-0.18182373046875 reduced the overall mean to +0.000005584509 FS, but left both jumps unchanged. Its originally zero silence became -0.181823730469 FS, while the tone retained +0.018188516007 FS mean.

Correcting only the tone before inserting the same silence kept the silence at zero and produced zero jumps at both joins. The whole file then measured +0.0000000358586 FS. The improvement measured here is the removal of those sample discontinuities; I did not listen or establish a perceptual click threshold.

A final stress case put positive bias in the first second and negative bias in the second. The whole-file mean was only +0.0000000394445 FS, yet the two halves measured +0.199997661011 and -0.199997582122 FS. Rounding that global mean gave a zero shift, leaving the PCM unchanged and the central jump at -13,026 counts. This case is changing bias, not one constant offset. Its near-zero global mean must not be treated as proof that every region is centred.

In these fixtures, the global residual of the incorrectly corrected splice was much smaller than either local residual, and the changing-bias file looked clean by its global mean alone. Therefore the result record needs regional means and join measurements beside the whole-file mean. None of the measured offsets, residuals or jumps is a universal pass/fail threshold.

If the edit still clicks, test the edit

Correcting offset is not a certificate that a splice is clean. If a pasted patch still clicks after correction and zero-crossing selection, compare its join treatment rather than assuming the remaining click proves that offset removal failed.

Keep the troublesome join and make a comparison copy. Hold the audio and correction settings fixed while changing the crossfade treatment. Listen to the boundary, not just the middle of the passage. Do not turn a successful fix for one recording into a diagnosis for the next.

If correction seems to add noise, hold the file still

Before applying another repair, play the same saved result through another available playback path. Keep the amplifier and headphones unchanged where possible, so the comparison changes fewer things. If the hiss follows one playback route rather than appearing on both, investigate that route before processing the file again. That observation narrows the problem; it does not identify a defective driver or component.

Instead of asking which effect removes the new hiss, first ask whether the hiss follows the file or the playback route. Keep processing settings unchanged while making that comparison.

Stop recurring bias at the input

If a USB recording is displaced but another input is centred, compare those input paths before blaming every recording or replacing equipment. A path-specific difference narrows the investigation; it does not identify the failed component.

Keep the unprocessed take and note which input produced it. Correcting a saved copy may help the edit, but it does not demonstrate that the next recording will be centred. Recheck the source before the next take.

The stopping rule

Approve the repair against the problem you actually had: the measured displacement, the audible join, or the playback-dependent noise. These are separate checks. If only the waveform looks neater, the listening problem is still unresolved.

Comparison scope and limits

The comparison covers previously reviewed public article text, not unread attachments or embedded videos. During the October 9 recheck, one comparison page returned HTTP 403 and another a verification screen; a fresh complete reread of every comparison page was not achieved. The new contribution is this dated test record, not a claim of worldwide exclusivity.

For a different failure, compare the clipped-audio repair decision table or the sample-rate-label check. These do not diagnose constant bias.