We Analyzed 144 Hours of Creator Recordings. A Quarter of It Was Silence.

The 24.9% is a share of uploaded time: 129,914 seconds removed out of 520,913 seconds uploaded. It is not a per-recording average, and the distinction matters more here than it usually does.

If you line up the 822 recordings individually, the median job had less than 5% of its runtime removed. A time-weighted number and a job-weighted number can sit that far apart for one reason: the recordings with serious dead air are disproportionately the long ones, so they dominate the hours even though they are a minority of the files.

Both numbers are true. If you quote this post, quote it precisely: a quarter of uploaded recording time was silence. The typical uploaded recording was mostly fine.

Here is the share of runtime removed as silence, per recording, across all 822 jobs:

The two ends dwarf the middle.

On the left: 55% of recordings had less than 5% of their runtime removed. In fact, 241 recordings, 29% of the total, contained no detectable silence at all at the sensitivity the job ran with. People ran a silence remover on recordings with nothing to remove. Some of that is curiosity, testing the tool on whatever file is handy. Some of it is creators who already record tight.

On the right: 130 recordings, 16%, were more than 30% dead air. And 43 recordings, 1 in 20, were mostly silence: more than half of the runtime got cut.

One more cut of the data points the same direction. 22% of recordings had 50 or more separate silence gaps. That is the shape of the painful case: not one long pause you could trim by hand, but dozens of small ones scattered through the whole file.

The average upload in this dataset was 10.6 minutes long, but the mix is wide: short clips dominate the job count, and long recordings dominate the hours. Since the severely affected recordings skew long, they carry the time-weighted number up to that clean quarter.

The single biggest cut in the window: one recording had 2 hours and 36 minutes of silence removed. One file, 156 minutes of dead air.

That raises a fair question: is the 25% just an artifact of a few monster files? No. Remove that record-holder from the dataset entirely and the overall share drops by about one percentage point, to roughly 24%. The quarter survives its own outliers.

The same counters cover VidClean's other tools. Two numbers are worth a sidebar:

• Across all tools, 4,133 jobs ran in the same window. The transcription tool alone processed 438 recordings totalling 780,099 words in 26 languages. 71% were English.
• The video stabilizer asks users to pick an intensity: subtle, normal, or strong, with normal as the default. Of 801 stabilization jobs, 4% chose subtle and 29% chose strong. Among people who moved the setting off the default at all, strong outnumbered subtle nearly 7 to 1. Almost nobody believes their footage is only slightly shaky.

VidClean deletes uploaded files within an hour of processing and keeps no per-file records, so this analysis is built on deliberately blunt instruments: aggregate counters. When a job completes, the backend increments a handful of running totals (jobs, seconds uploaded, seconds removed) and coarse histogram buckets (share removed in 0-5%, 5-10%, and so on). No filenames, no user identifiers, no timestamps, and no per-recording rows exist anywhere. That design means no individual upload can be reconstructed from the data. It also means the analysis is limited to exactly the cuts shown above; I cannot slice by content type, source, or anything else, because that information was never stored.

What counts as silence: audio below -35 dB lasting at least half a second, detected with ffmpeg's silencedetect filter. Those are the defaults; the tool exposes both the sensitivity and the minimum gap length as sliders, and the numbers above reflect whatever settings each user chose. When cutting, the tool keeps a tenth of a second after speech ends and three tenths before it resumes, so natural breathing room survives.

"Removed time" is measured as input duration minus output duration of the finished job: what was actually cut at the settings the user chose, after padding. It is not a raw detector total.

The window is July 20 to August 4, 2026, which is simply when the counters shipped. One disclosure: VidClean's own automated production tests run through the same pipeline, so a small number of synthetic test files are in the counts. They are seconds long, so their effect on the time-weighted totals is negligible, but they slightly inflate the shortest-duration and lowest-percentage buckets.

This is VidClean's user base, not a random sample of creators. People who upload to a silence remover are more likely to suspect they have a silence problem, which biases the headline number up. On the other hand, nearly a third of uploads had nothing to cut, so plenty of people were clearly just trying the tool, which biases it down. I make no claim that this share generalizes to all recordings everywhere.

"Silence" here is an operational definition: what a -35 dB, half-second detector found and the user's chosen settings removed. A different threshold would give a different number.

And 822 recordings over two weeks is enough to publish a distribution, not enough to slice it further. The counters keep accumulating; I plan to re-run this analysis at a larger sample and link the update here.

If you edit your own recordings, the useful takeaway is the distribution, not the average. Half of creators can stop worrying about dead air; a sixth of them are losing real editing time to it, usually as dozens of scattered pauses in long recordings, which is the worst case to fix by hand.

Finding out which group you are in takes one file: run a recording through any silence detector and look at the share it flags. VidClean's silence remover is a free way to do that in the browser, no account needed, and it reports exactly how much it cut.

VidClean is a solo project. Questions about the data or the methodology are welcome at hello@vidclean.net.