How to Calculate How Many Cards You Need for a Shoot Day

Camera Stops at 4pm

A 1st AC on a low-budget feature arrives at location with four 256GB CFast 2.0 cards for an ARRI ALEXA Mini shoot. The plan: offload at lunch via a single USB-C card reader. At 12:30 PM craft services runs 45 minutes late. The DIT starts offloading at 1:15 PM instead of noon. Two cards are confirmed copied and reformatted by 2:45 PM. The other two are still cloning when camera is called back to set at 3:00 PM. By 4:00 PM both remaining cards are full. Camera stops for 40 minutes.

That production lost nearly a page of coverage -- not because they had the wrong number of cards, but because they calculated cards as a storage problem instead of a workflow problem.

This post explains the complete card count calculation: raw data volume, offload window, reader speed, and safety margin. Bitrate figures draw from manufacturer codec specifications for ARRI, Blackmagic, RED, and Sony acquisition formats, and from Apple's official ProRes whitepaper for ProRes bitrate targets.

The Two Questions a Card Count Must Answer

A card count calculation requires answering two separate questions, not one.

Question 1: How much raw data will you record on a single shoot day?

This is the data capacity question. Formula:

Raw data (GB) = bitrate (MB/s) x recording seconds x shooting ratio / 1,024

For ARRI ALEXA Mini LF at 4.5K ARRIRAW LT (approximately 100MB/s), a 6-hour scheduled recording window (from 12 hours of shooting with a 2:1 setup-to-recording ratio) at a 10:1 shooting ratio: 100 x 21,600 / 1,024 = 2,109GB. You need cards to hold that data.

Question 2: Can you offload and reuse cards during the day, or must cards hold all data until end of day?

This is the workflow question. If you can offload at a midday break, the card pool is reused and your physical card requirement may be much lower than the raw data volume suggests. If you cannot offload until wrap -- either because the DIT is not on set, the offload hardware is too slow, or the shoot is remote with no downtime -- your physical cards must hold all data for the full day.

The formula for the number of cards when you cannot reuse:

Cards needed (no reuse) = ceil(raw data GB / card capacity GB) + 2 (safety margin)

The formula when you can reuse with a midday offload:

Cards needed (with reuse) = cards filled before offload + 2 (safety)

where cards filled before offload = ceil(data from call to offload window / card capacity).

Three Real-World Card Count Calculations

Example 1: ARRI ALEXA Mini LF, ARRIRAW LT, CFast 2.0 512GB Cards, No Midday Offload

A 10-day remote landscape documentary shoot has no midday downtime. Cards must hold a full day's data. Bitrate: 100MB/s. Recording estimate: 5 hours of actual recorded footage per 12-hour day. Raw data: 100 x 18,000 / 1,024 = 1,758GB = approximately 1.76TB.

Cards needed: ceil(1,758 / 512) = 4 cards, plus 2 safety = 6 cards per camera per day. For a 10-day shoot with no offload to reuse: 6 cards needed total per camera if cards are all offloaded each evening. If the DIT cannot offload each evening (wilderness location, generator-only), you need cards for two or three consecutive days before a confirmed offload window: 6 x 3 = 18 cards minimum.

Example 2: Sony FX9 in XAVC-I 4K, XQD 256GB Cards, Midday Offload Available

A commercial shoot on Sony FX9 in XAVC-I 4K 50Mbps (approximately 6.25MB/s). Shooting 4 hours of actual footage per day. Raw data: 6.25 x 14,400 / 1,024 = 88GB. Cards needed (no reuse): ceil(88 / 256) = 1 card -- easily fits on a single 256GB card. But with slow-motion inserts in XAVC-I 120fps (25MB/s), data per day rises to approximately 180GB -- still under one card. Minimum: 2 cards per camera (one working, one backup-in-use). Add 1 safety card. Total: 3 cards, all reusable at the midday offload.

Example 3: RED V-RAPTOR 8K, REDCODE 8:1, CFexpress 2TB Cards, Midday Offload, Two Bodies

Two RED V-RAPTOR cameras shoot a music video. REDCODE 8K HQ approximately 500MB/s each. Estimated 3 hours recording per camera per day. Raw per camera: 500 x 10,800 / 1,024 = 5,273GB = 5.3TB. This exceeds any single card. With 2TB CFexpress cards: 3 cards per camera needed to hold one day's data. Plus 1 safety card per camera. Total for two cameras: 8 cards, or 4 if midday offload reliably frees half the cards by early afternoon. The DIT uses a Media Offload Time Calculator to confirm that a 2TB card can be fully cloned in the available 90-minute lunch window -- and it cannot (a 2TB card at 1,000MB/s read speed takes about 34 minutes to copy, but verification adds 30 more, making two simultaneous copies barely achievable in 90 minutes). The production rents one additional cloning station for the day.

Card Count Reference by Codec and Card Size

The table below shows minimum cards needed per camera for a 4-hour recording day at each codec and card format. These are no-reuse figures -- they assume no midday offload. Add 2 safety cards to each figure.

RAW and high-bitrate codecs require substantially more cards than compressed formats. REDCODE at 8K HQ with a card-only strategy requires 28 256GB cards for a 4-hour day -- operationally impractical. Any production shooting high-bitrate RAW at this resolution must plan around near-continuous offload or an on-camera RAID solution, sizing cards to cover only the offload interval rather than the full day.

How to Calculate Your Card Count Before the Shoot: Step by Step

Step 1: Confirm the codec, resolution, and frame rate for every scheduled setup. If the shoot includes both standard-speed and overcranked setups, list them separately. Note the bitrate for each.

Step 2: Estimate daily recording hours per camera. Use the Shooting Ratio Calculator to convert your planned shooting ratio and scheduled production hours into an estimated recording time.

Step 3: Calculate raw data per camera per day using: data (GB) = bitrate (MB/s) x recording seconds / 1,024. Use the Storage and Footage Calculator for this step -- it handles the conversion and displays results in GB and TB.

Step 4: Determine whether midday offload is operationally reliable. If yes, calculate cards needed from call to the offload window. If no, calculate cards needed for the full day.

Step 5: Add a safety margin of 2 cards per camera above the calculated minimum. This covers unexpected takes, a delayed offload, a corrupted card that must be retired, and any change to the shooting schedule that extends recording time.

At the end of this process you have a card count per camera, per day, with a defined safety margin, ready for the rental order.

Pro Tips and Common Mistakes

Pro Tip: Run the Media Offload Time Calculator before confirming your card strategy. A 1TB CFexpress Type B card at 1,700MB/s native read speed takes approximately 10 minutes to copy. The same card through a USB-C 3.2 Gen 1 reader capped at 500MB/s takes 34 minutes. That 24-minute difference determines whether one lunch break clears your entire card pool or whether you need overnight to recover. Always verify the actual reader speed that will be on set, not the theoretical maximum.

Pro Tip: For multi-day remote shoots where cards cannot be offloaded between days, calculate total cards for the entire run of the shoot -- not per day. If four days must accumulate before the first offload opportunity, you need four days' worth of cards in the field. Running the Storage and Footage Calculator for the full unbroken stretch gives you the correct card order.

Pro Tip: Keep a card log on a physical call sheet attachment during production. Every card that goes into a camera gets a number, a timestamp in, and a timestamp out. This tells the DIT exactly which cards are full and which are available, prevents duplicate card use, and creates an auditable record for any data loss investigation. A blank spreadsheet printed daily is sufficient -- the log does not need to be digital.

Common Mistake: Using the labelled card capacity instead of the usable capacity in the calculation. File system overhead means most cards deliver 5 to 8% less space than their labelled size after formatting. A labelled 256GB CFast 2.0 card typically provides 238 to 245GB of usable space. Using 256GB in your calculation means the card runs out 10 to 18GB earlier than expected -- potentially mid-take on a long scene.

Common Mistake: Calculating cards for one codec and having the DP change modes on the day. A Sony FX9 switching from XAVC-I (6.25MB/s) to XAVC-HS RAW via the XDCA-FX9 extension unit jumps to approximately 19MB/s -- three times the data rate. Any codec change after the card order is placed creates a capacity shortfall that can't be solved quickly. Require written confirmation of the final codec from the DP before placing the card order.

Frequently Asked Questions

Should I use fewer, larger cards or more, smaller cards?

Larger cards reduce the number of times you stop to change media, which matters on long continuous takes. Smaller cards limit the amount of irreplaceable footage on any single card -- if a 512GB card fails, you lose 512GB; if two 256GB cards fail, you still have the other 256GB intact. For documentaries with continuous coverage, larger cards win. For narrative productions where each take is individually important, smaller cards with more frequent changes reduce risk.

What happens to the card calculation if the shooting ratio changes on set?

Recalculate immediately. If the director calls for significantly more coverage than planned, the 1st AC or DIT should update the running data total and flag if the remaining card capacity cannot cover the afternoon. Keeping a running data log (estimated data recorded vs. cards remaining) during the shoot day prevents the surprise of running out at 4pm.

Is it worth buying cards for the production or always renting?

For productions shooting the same camera system repeatedly, ownership is almost always cheaper after the second or third use of a card set. For one-off productions or rental cameras, renting cards with the camera package keeps the cost within the production's equipment budget and eliminates the depreciation liability on unused cards.

Can I use a recorder like an Atomos or Shogun to bypass the card calculation?

An external recorder with a RAID or SSD solution changes the card calculation substantially -- you are now calculating SSD capacity rather than card capacity, with typically higher capacity per unit and different offload workflows. The underlying math is the same: data rate multiplied by recording time equals storage needed. The Storage and Footage Calculator handles SSD capacity estimates the same way it handles card estimates.

Related Tools

The Storage and Footage Calculator computes raw acquisition data from codec, bitrate, and recording hours. The Media Offload Time Calculator confirms whether your reader speed can clear cards within the available offload window. The Shooting Ratio Calculator translates your planned shooting ratio into estimated daily recording time, which feeds directly into the card count calculation.

For the full context of production storage planning -- including backup strategy, archive, and why acquisition data is only a fraction of the total storage requirement -- Why Your Storage Estimate Was Wrong: The Variables Most Calculators Ignore covers the complete picture. For codec-specific data rates, Video Codecs Explained covers every major acquisition format with verified bitrates.

Cards Are a Risk Management Decision, Not a Budget Line

A card running out mid-take is a production stop. A corrupted card without a verified backup is permanent data loss. Neither outcome is recoverable with money after the fact. The card calculation sets the risk floor for the shooting day before it happens. Run it against the specific codec, the actual offload window, and the realistic shoot length -- then add two cards per camera as a non-negotiable floor.

This post covers single-operator and DIT-managed productions. Large studio productions with dedicated data workflow departments use different card management systems and rotation protocols that fall outside this scope.

What is your standard safety margin on shoot days -- two extra cards, three, or a percentage-based buffer -- and what was the production situation that set that rule for you?