Recording Time Calculator — how long until your drive says no

The question sounds simple: "I have 500 GB free, how long can I record?" The answer is simple too — once you accept the arithmetic that hides behind it. Bitrate times duration equals file size, and everything else in this page is variations on that one equation. What makes the difference between a confident session and a 2 a.m. panic is knowing the answer before you press Record, not discovering it when OBS stops writing.

This calculator answers three versions of the question: how long until your drive is completely full, how long until it hits 90 percent (where operating systems start misbehaving), and how long until it hits 80 percent (where you should already be thinking about the next drive). Enter free space and bitrate; the timeline does the rest.

Why 90 percent is the real finish line

Storage vendors sell you a number. Operating systems treat the last portion of that number as their own property. The practical ceiling of any drive is not its labeled capacity but the point where performance and reliability begin to degrade.

On macOS, APFS reserves space for snapshots, purgeable iCloud data, and swap. The "available" figure in Finder counts purgeable space as free until the moment you actually need it, which is precisely when it is least convenient. On Windows, NTFS slows noticeably past roughly 90 percent full as the master file table fragments and the system struggles to find contiguous runs. On both, and on Linux filesystems alike, swap pressure rises as free space shrinks, and an OS swapping under encode load drops frames.

The 80 and 90 percent thresholds in this tool are not arbitrary. Eighty percent is the planning threshold — the point to order the next drive or archive old sessions. Ninety percent is the operational threshold — the point where recording should stop, because the next gigabyte might be the one that corrupts a write. The calculator shows both as wall-clock times so you can set an alarm instead of watching a progress bar.

The math, made explicit

The formula the calculator runs is one line:

hours = (free GB − reserve GB) × threshold ÷ (total Mbps × 0.45)

The 0.45 constant converts megabits per second to gigabytes per hour: one megabit per second for one hour is 1,000,000 bits × 3,600 seconds ÷ 8 bits per byte ÷ 1,000,000,000 bytes per GB, which equals 0.45 GB. Total Mbps is video bitrate plus audio bitrate times track count — a six-track podcast layout at 160 kbps per track adds 0.96 Mbps that many people forget to count.

The thresholds are 1.0 for full, 0.9 for the pause point, and 0.8 for the planning point. Reserve is subtracted first because that space was never yours to fill — it belongs to the OS, to Time Machine local snapshots, to the swap file that grows when RAM pressure climbs.

Three worked scenarios

Note for recording-time-calculator: The following three scenarios are hypothetical examples (illustrative, not sourced case studies) for this specific tool — plausible sessions, not measurements from named machines.

Scenario A — the long interview day. A podcaster has 180 GB free on an external SSD and records three back-to-back 90-minute interviews at 1080p30, 6 Mbps video, 160 kbps audio, single track. Total bitrate is 6.16 Mbps, consuming 2.77 GB per hour. The 90-percent clock reads 58.4 hours of recording — three interviews totaling 4.5 hours use about 12.5 GB. The drive is nowhere near pressure; the real constraint today is the guests' patience, not the storage.

Scenario B — the overnight subathon. A streamer starts a charity broadcast at 8 p.m. with 250 GB free, recording 1080p60 gameplay at 12 Mbps plus two 160 kbps tracks. Total draw is 12.32 Mbps, or 5.54 GB per hour. Ninety percent of 250 GB is 225 GB, which buys 40.6 hours. The fill clock lands at roughly 12:30 p.m. two days later. With that number on screen, the crew schedules a drive swap at hour 36 instead of discovering the wall at hour 41.

Scenario C — the phone-storage squeeze. A course creator records talking-head segments on a laptop with only 40 GB free, at 1080p30, 4 Mbps, single 128 kbps track. Draw is 1.86 GB per hour. With a 10 GB reserve, the usable space is 30 GB: 16.1 hours to full, 14.5 hours to 90 percent. Plenty for the day's four hours of takes — but the math shows exactly why recording B-roll on the same drive the same afternoon would have been the moment to worry.

Edge cases worth knowing before they happen

Variable bitrate recordings drift from the estimate. CQP and VBR encoders spend bits where the scene demands them. A talking-head session lands near the estimate; a confetti cannon can double it. If your content swings wildly, treat the calculator's number as a floor and budget 20 percent extra.

Multi-track audio adds up quietly. Each 160 kbps track is 0.072 GB per hour. Six tracks over an 8-hour session is 3.5 GB — small next to the video, real enough to matter when the margin is thin. The calculator counts tracks explicitly for this reason.

Simultaneous recording and streaming halves nothing, but doubles writes. If OBS records and streams at once, the record path still consumes disk at its own bitrate. The stream's bitrate is irrelevant to the drive; the recording's is not.

Filesystem overhead is small but real. NTFS, APFS, and ext4 all spend a percent or two on metadata. For planning purposes the calculator ignores it; for a drive you are filling to the last gigabyte, that overhead is why the 90 percent threshold exists.

Drives slow down as they fill. A spinning disk filling past 80 percent writes to its slower outer-to-inner tracks — wait, inner tracks are slower, and writes proceed inward on most layouts, so sustained speed can drop 30 percent or more near full. SSDs throttle too when their over-provisioning shrinks. The 90 percent line protects performance as much as capacity.

Building a recording storage workflow

The calculator answers one session's question; a workflow answers the year's. Three habits separate people who never lose a take from people who do.

First, dedicate a recording drive. Recording onto the OS drive competes with swap, updates, and Spotlight indexing. A separate internal or external drive keeps writes sequential and predictable.

Second, rotate before you must. When the fill calculator says 80 percent lands Friday, archive Tuesday's sessions Thursday. The move is calm and verifiable; the move at 97 percent is neither.

Third, verify before deleting. A copied file is not a verified file. Byte count first, then a checksum if the footage matters. WeaverClip's helper does both automatically for every segment before it releases the local copy, which converts "I think it uploaded" into a checkable fact.

What to do with the number once you have it

The calculator gives you hours. The question is what you do with them, because the number is only useful if it changes a decision. Three concrete uses, each one different.

Use it to plan the session, not just the drive. If the answer says 14 hours at your current settings and the session is 3 hours, you are fine — but "fine" should be a calculation, not a feeling. If the answer says 5 hours and the session is 4, you have one hour of margin, which is not enough for a session that might overrun. The margin you want is at least 30 percent of the session length, because sessions overrun, because CQP spikes on complex scenes, and because the last thing you want is to be watching a progress bar while a guest is mid-story.

Use it to decide what to change. If the number is too small, you have four levers, and they are not equal. Lowering the bitrate is the most direct but costs quality. Lowering the resolution costs less quality than you fear and saves more than you think — going from 1080p60 to 1080p30 roughly halves the file size. Reducing the session length is not really a lever; it is the thing you are trying to protect. And moving to a bigger or emptier drive is the cleanest answer if you have one. The calculator lets you try each: change one input, watch the hours move. That is the point of having the number — to make the trade visible before you make it.

Use it to set the alarm. If the 90-percent clock lands at 3:42 a.m. and you are recording overnight, the answer is not to hope you wake up. It is to set a literal alarm for 3:00 a.m., at which point you stop, swap the drive or clear the old files, and resume. The calculator's wall-clock version (the hard-drive fill tool) gives you the exact time to set. A drive that fills at 4 a.m. while you sleep does not wake you politely — it just stops writing, and the last segment of the recording is the one you lose.

The arithmetic, walked through once by hand

The formula is short enough to do on paper, and doing it once by hand makes every future answer legible.

Take a 1080p30 podcast at 6 Mbps video, one 160 kbps audio track. Total bitrate is 6 + 0.16 = 6.16 Mbps. Multiply by the 0.45 constant: 6.16 × 0.45 = 2.77 GB per hour. Now take a drive with 200 GB free and a 20 GB reserve. Usable space is 180 GB. Divide: 180 ÷ 2.77 = 65 hours to full, 58.5 hours to the 90-percent mark. That is a lot of recording — but now change one variable. Add five more audio tracks for a six-track esports layout: that is 6 + 0.96 = 6.96 Mbps, or 3.13 GB per hour. The same 180 GB now buys 57.4 hours to full, 51.7 to 90. Six tracks cost you almost eight hours of recording on the same drive. That is the kind of number you cannot eyeball; you have to do the math.

The 0.45 constant is the whole trick. It converts any Mbps into GB per hour: one megabit per second for one hour is 1,000,000 bits × 3,600 seconds = 3.6 billion bits = 450 million bytes = 0.45 GB. Every bitrate you have ever set, multiplied by 0.45, is its disk cost per hour. You can carry that in your head and stop needing the calculator at all — but the calculator is faster, and it does the reserve and the thresholds for you.

When the drive is not the only constraint

The calculator assumes the drive is the binding limit. Sometimes it is not, and knowing which constraint is actually binding changes what you do.

The encoder can be the bottleneck before the disk is. If OBS is dropping frames because the CPU or GPU cannot keep up, the recording is already damaged before storage enters the picture. A file that is perfectly stored but was encoded under duress is not saved — it is preserved at reduced quality. The stats dock (View → Docks → Stats) shows skipped frames; if that number is climbing, the fix is not more disk space, it is a lighter encode setting. Check that first.

The upload can be the bottleneck if you are recording to a cloud-synced folder. Recording directly into a Dropbox, iCloud, or OneDrive folder means the sync client is reading the file while OBS is writing it. On a slow upload, the sync can fall behind, and on a crashed session the half-synced file is in the worst possible state — partially local, partially remote, fully confusing. Record to a local folder and sync afterward, or use a tool that uploads in verified segments after each minute closes.

The filesystem can cap you before the space does. FAT32 refuses any single file over 4 GB. A 90-minute 1080p recording at 6 Mbps is about 4.2 GB — just past the limit. If your external drive is formatted FAT32 (many are, out of the box, for cross-platform use), the recording will stop at 4 GB regardless of how much space remains. Check the format before the session: exFAT, NTFS, APFS, and ext4 all handle large files. The calculator's number is only valid if the filesystem can actually hold a file that size.

A note on the reserve, and why it is not optional

The reserve field defaults to 20 GB and some people will zero it out to squeeze more recording time. Do not. The reserve is not the calculator being cautious; it is the calculator knowing things you do not.

The operating system needs free space to function. Swap files grow under memory pressure. Filesystem metadata expands as files are written. Spotlight and search indexes rebuild. Time Machine makes local snapshots when the backup drive is not connected. On macOS, APFS reserves a portion of the disk for its own bookkeeping, and Finder's "available" figure counts purgeable iCloud space that will not actually be there when you need it. All of this consumes space that does not show up as "your files." Twenty gigabytes is a floor, not a ceiling; on a drive under 500 GB, ten percent of capacity is a better reserve.

The other reason the reserve matters is psychological. A drive at 98 percent full produces a low-grade background anxiety that shows up in the recording — you start watching the disk instead of the content, you rush the outro, you skip the second take. The reserve buys you the mental space to not think about the disk, which is the whole point of having done the math in advance.

Reading the three clocks

The tool prints three numbers, and they answer three different questions. Treating them as one number is how drives get filled.

The 100 percent figure is fiction in the operational sense. Nothing good happens in the last ten percent of a drive: the filesystem allocator fragments, the OS starts evicting caches, and if the encoder is mid-flush when the space runs out, the tail of the file is the part you lose. This number exists only so you can see how far away fiction is.

The 90 percent figure is the stopping rule. Above it, macOS begins reporting pressure, SSD write amplification climbs, and OBS itself can start dropping frames under the combined load of encoding and a struggling filesystem. When the 90 percent clock is the one you plan against, the 100 percent clock never becomes relevant.

The 80 percent figure is the planning bell. It answers "when do I start moving files," not "when do I stop recording." The gap between 80 and 90 percent is your archival window — long enough to copy, verify, and delete without rushing, short enough that the math has not changed underneath you. On a busy recording schedule, check the 80 percent date the way you check a calendar appointment, because that is what it is.

For multi-day shoots, run the calculator once per day with the updated free space rather than extrapolating. Sessions rarely match their planned length, and CQP recordings drift above the nominal bitrate on complex days; the error compounds. Re-running costs ten seconds and resets the compounding to zero.

Troubleshooting the numbers

The calculator says 20 hours but my last session used more space than predicted. Check three suspects: the encoder was CQP rather than CBR (bitrate exceeded the nominal), audio tracks were more or higher-bitrate than entered, or the session ran longer than remembered. The arithmetic never lies; one of the inputs did.

Finder shows free space the calculator doesn't believe. On macOS, About This Mac → Storage counts purgeable space as available until the system needs it. Use df -h in Terminal for the conservative number, or subtract the purgeable figure before entering it here.

My drive is huge but recording still stops. Check the filesystem format. FAT32 caps individual files at 4 GB regardless of free space — a 90-minute 1080p recording busts that limit. exFAT and NTFS remove it; APFS and ext4 never had it.

Two drives, same free space, different answers. The answer only depends on free space and bitrate. If two drives give different results, their free-space numbers differ — one is counting purgeable or reserved space the other is not.

How this connects to WeaverClip — without bullshit

The calculator tells you when the drive fills. That is a fact about your local disk, and it is correct as far as it goes. But the fact it is really telling you is that your recording's safety depends on a countdown — and countdowns end. WeaverClip's answer to the countdown is to make the recording leave the disk before the disk fills: one-minute segments upload while the next minute records, each verified before the local copy is released. The drive holds a few minutes of footage at any moment, not the whole session. The 90-percent clock stops being the thing that decides whether your recording survives. That is not a feature pitch; it is a different relationship to the same math. The calculator is still useful — for planning, for choosing bitrate, for knowing your disk. But the anxiety it exists to prevent is the anxiety the segmented upload removes entirely.

FAQ

Does this work for streaming bitrate too? The math is identical, but the constraint differs. Streaming caps at your upload bandwidth minus overhead; recording caps at disk. Use this tool for disk; use your upload speed minus 30 percent as the ceiling for stream bitrate.

What if I record in a codec I can't name? Find the bitrate anyway — OBS shows it in Settings → Output, and any file can be inspected with ffprobe. The calculator only needs the number, not the codec's name.

Should I reserve more than the default 20 GB? On a drive under 500 GB, yes — reserve 10 percent of capacity. On a 4 TB archive drive, 20 GB is fine. The reserve covers swap growth, filesystem metadata, and the breathing room every filesystem wants.

Why decimal GB instead of GiB? Drive makers, cloud providers, and this calculator all use decimal (1 GB = 1,000,000,000 bytes). Operating systems report in binary (1 GiB = 1,073,741,824 bytes), which is why a "1 TB" drive shows about 931 GB in Finder. Mixing the two systems understates every answer here by 7 percent.

Does audio really matter at these sizes? One 160 kbps track is 0.072 GB per hour — trivial alone. Six tracks over a 10-hour day is 4.3 GB, which is the difference between fitting and not fitting on a tight drive. The calculator counts every track because the disk does.

How accurate is this estimate? For CBR, within 2 percent. For CQP and VBR, within 15–20 percent for typical content. The estimate is for planning, not for billing; treat the 90-percent clock as the plan and the 100-percent number as fiction. Can I just record until the drive is full? Technically yes, practically no. The last gigabytes of a drive are the least reliable place to write: allocation slows, snapshots get pruned, and a crash during final index writes is exactly when MP4 files become unrecoverable. Stop at the 90 percent mark the tool gives you.

What if my recording uses CQP instead of CBR? Then the estimate is a midpoint, not a ceiling. Static scenes will undershoot and busy scenes will overshoot. Budget using the calculator's number plus 15–20 percent, or record a ten-minute sample of your actual content and extrapolate from its real size.

Does the reserve include space for the operating system? It includes whatever your OS quietly claims — swap growth, local snapshots, indexing databases. Twenty gigabytes is a sensible floor on a big drive; use ten percent of capacity on smaller drives.

Should I record straight to an external drive? Yes, if it is a fast USB or Thunderbolt SSD formatted exFAT, APFS, or NTFS. Avoid FAT32 drives entirely — they cap single files at 4 GB and will silently truncate a long session. Avoid network mounts for the active recording; a momentary disconnect can corrupt the file mid-write.