How to Build Dailies Reports for Clip Counts, Duration, Storage

Your dailies report should answer three questions before anyone opens a drive: how many clips were shot, how much screen time exists, and how much storage each camera created. A production report answers those cleanly by shoot day, camera, card or roll, and media type. The useful version is plain on purpose. Production gets a quick read on shoot volume. Editorial gets confidence that everything expected arrived. Post supervisors get a storage burn rate. The DIT or lab gets a paper trail for when camera cards are cleared. The exact layout can vary by show. The logic shouldn't: start with metadata you already have, normalize it once, calculate the summary, and distribute the same report to the same people every day.

Decide what the report is allowed to be responsible for

A dailies report isn't a camera report or a sound report, a continuity log, or a lab report. It isn't the daily production report either, though it may overlap with all of them. Its job is to summarize the media that entered the dailies workflow and make that summary usable downstream. Before building the template, decide whether the report describes:

Original camera files only
Original audio files only
Proxies or editorial transcodes only
Both source media and generated dailies deliverables
Archive copies, including RAID, shuttle drive, LTO, or cloud transfer status

That decision changes the numbers. The same shoot day produces very different counts depending on what you include. A camera may roll 148 OCF clips while editorial receives 146 synced proxy clips, because your team held two out of the viewing set as false starts, MOS plates, or technical tests. Both numbers are correct. They can't live under one vague column called “clips.”

Keep source-media counts and delivered-media counts separate, even when both are correct.

Productions with formal workflow memos define this up front. The memo sets base frame rate and audio sample rate, editorial deliverables, and storage responsibilities. It also covers color management, data management, and the process for clearing camera and sound cards. Your report should match that memo instead of inventing a parallel system.

Build the report around the grain of the workflow

The most common reporting mistake is summarizing too early. If you only keep a top-line total, you lose the ability to explain mismatches later. Keep the row-level detail at the clip level, then generate summaries from it. A solid dailies report has two layers:

A clip log, with one row per source clip or delivered asset
A summary tab or page, grouped by shoot day, camera, and sometimes unit

The clip log is the source of truth. The summary is what most people read. If someone asks why Camera B is 700 GB higher than yesterday, you drill into the clip rows. The difference may come from long takes or a higher codec data rate, from off-speed material, or from additional cards and duplicate media. For each clip row, capture the fields you need for count, duration, and storage calculations:

A dailies report starts with clip-level metadata that can be grouped and calculated later.

Production name or code
Shoot date
Unit, if there's more than one
Camera ID, such as A, B, C, Drone, Crash, Bodycam, or VFX witness
Card, mag, or roll name
Clip name exactly as recorded
File path or volume name
Start timecode and end timecode
Duration
Frame rate
Codec or format
Resolution
File size
Audio presence or linked sound roll, if relevant
Status, such as ingested, verified, transcoded, synced, delivered, held, or excluded
Notes for anomalies

You don't need to show every field to production every day. You do need to preserve enough information that editorial and post can reconcile the numbers without asking the DIT to manually inspect drives.

Normalize camera IDs before calculating anything

Camera naming gets messy fast. One system may call the same body “A Cam,” “A-CAM,” “CAM_A,” “A001,” or the serial number. If your report groups those as separate cameras, your totals are already wrong. Pick a normalized camera ID for reporting and keep the original value in a separate field. For example, “A” can be the report camera, while “A004C013_250814” remains the clip name. If you're receiving camera reports from set, use the naming convention agreed in the workflow memo. If the show has a loader or DIT, align with their roll naming rather than inventing a post-side abbreviation. This is especially important when a camera body changes cards, a second unit joins, or a drone and crash camera are added mid-shoot. The goal is that anyone reading the report can tell which camera generated which media without decoding filenames.

Calculate duration in frames, then display it in timecode

Duration looks simple until mixed frame rates enter the show. Calculate it only from human-readable timecode strings and you'll eventually hit rounding errors, drop-frame confusion, or off-speed surprises. Store duration as a frame count or a seconds value instead, then display it as timecode for readers. Your reporting system should know two frame rates: the base rate used for the production, and the actual rate of the clip.

Store duration in a calculable form first, then display it in a readable time format.

A useful set of duration columns looks like this:

Source start timecode
Source end timecode
Duration frames
Duration seconds
Display duration as HH:MM:SS:FF
Base frame rate
Recorded frame rate, if different

For most production summaries, “total running time” means real-time playback duration at the project base frame rate. For off-speed clips, confirm whether the report should show recorded duration, playback duration, or both. A 120 fps shot intended to play at 24 fps can create confusion if production sees one duration and editorial experiences another. If the report feeds storage planning and labor forecasting, track real clock time and playback time. Long off-speed takes don't look long on set, and they still inflate storage and transcode time.

Treat storage as measured data, not estimated data

Use actual file sizes for storage whenever possible. Camera spec sheets and codec calculators are useful before the shoot, but a dailies report should reflect what your team actually copied, verified, transcoded, and delivered. At minimum, show source storage per camera. If your dailies team creates proxies or editorial media, show those separately so nobody confuses OCF volume with deliverable volume.

Show storage totals per camera so production can see which units are generating the most media.

Group the storage section of the report like this:

OCF size per camera
OAF size per sound roll or shoot day
Proxy size per camera or delivery batch
Total verified source media
Total generated dailies media
Total archive copy size, if archive is in scope

Keep units consistent. Don't mix MB, GB, and TB in the same table unless the report scales the values automatically. For a daily summary, GB with one decimal place reads well. For long-term storage planning, TB totals by week or episode are more useful. Also be clear about decimal versus binary units if your environment cares. Drives, operating systems, and transfer tools may display different values for the same files. Use one convention consistently.

Pull metadata from the earliest reliable source

The best metadata source is the one closest to ingest that your team can trust. On many sets, that means a media management tool used by the DIT or data manager. In other workflows, it may be Resolve or a lab system, camera card folder scans, or an exported CSV from the dailies application. Common input sources include:

Camera card directory scans
DIT or lab software reports
ALE, EDL, XML, CSV, or JSON exports
Sound reports
Transcode job logs

Don't hand-enter clip counts unless the shoot is tiny. Manual entry is fine for notes and exceptions. It is a poor primary method for counting hundreds of clips across multiple cameras after a long day. If you already run Silverstack or Resolve, Cortex or Baselight, or an in-house dailies system, start with its export. Dedicated on-set tools are built around media asset reporting and verification, which is exactly the metadata you need. If the tool can export clip-level CSVs, the spreadsheet or script can do the aggregation.

A spreadsheet version that actually holds up

A spreadsheet is often the fastest way to start, especially on commercials and documentaries, unscripted, or smaller scripted shows. Just don't let the spreadsheet become the place where humans retype everything. Use one tab for imported clip-level data and another tab for the summary. Don't edit the imported tab except to add controlled fields that your source export doesn't include, such as normalized camera ID or inclusion status. A basic workbook can use these tabs:

Raw import
Normalized clip log
Daily summary
Camera summary
Exceptions
Distribution notes

The raw import stays close to the source export. The normalized clip log maps inconsistent fields into your reporting schema. The summary tabs use pivot tables, queries, or formulas to group by shoot day and camera. For example, the daily summary might show:

Shoot date	Camera	Clips	Runtime	OCF GB	Proxy GB	Cards	Exceptions
2026-08-14	A	86	01:42:18:12	742.6	38.4	4	1
2026-08-14	B	79	01:35:44:03	698.2	36.9	4	0
2026-08-14	Drone	24	00:18:12:00	112.8	5.1	2	2

That table is enough for most producers and post supervisors. Editorial may also want clip names, timecode ranges, scene/take, audio sync status, and delivery batch details. Those can live in the detailed tab. Spreadsheets break down in three situations: several people editing at once, exports arriving in a different format every day, or reports that have to go out automatically. At that point, keep the spreadsheet as the readable output and move ingestion and calculation into a script.

A script version for repeatable reporting

A simple script can scan a folder and read media metadata, combine it with CSV exports, and generate a daily report without anyone touching every row. Python is common, because it handles CSV and JSON, filesystem scans, and media tool output well. Many teams use shell scripts or Node instead, or whatever fits the facility. A script-based flow runs in this order:

Read the day’s media inventory from a folder scan or exported report.
Extract file size, path, clip name, and modification data.
Pull duration, frame rate, resolution, and codec from media metadata.
Map camera IDs from naming rules or a lookup table.
Join with camera reports or sound reports if needed.
Write the clip-level CSV.
Generate a summary CSV, spreadsheet, PDF, or HTML report.
Save the report into the project folder and send it to the distribution list.

For media metadata, many teams rely on command-line tools that can inspect containers and streams. The script doesn't need to decode the media. It just needs enough metadata to count clips, calculate durations, and total file sizes. Configure the script to flag exceptions instead of silently skipping them. If it can't read duration from a file, it should still put that clip in the report with an exception note. A missing value is useful when it's visible. It is dangerous when it disappears from the totals. Good exceptions to surface include:

File has no readable duration
Clip name doesn't match expected naming pattern
Camera ID can't be mapped
File size is zero or unusually small
Duplicate clip name appears in multiple locations
Media exists on drive but not in the DIT export
DIT export references media not found on the drive
Proxy exists without source media in the current inventory
Source exists but transcode or sync is incomplete

These flags help your team find problems while the card, drive, and crew memory still exist.

Reconcile counts against ingest and delivery

A dailies report sits between ingest and editorial handoff, so it has to match both sides. The ingest count tells you what arrived. The delivery count tells you what editorial or review actually received. Those two numbers are related, and they are not identical.

Count state	Count this	Why it matters
Received source clips	All source clips entering the dailies workflow from cards, drives, or transfers	Shows what arrived from set before QC or processing
Verified source clips	Source clips that passed copy or checksum verification	Supports confidence that source media can move forward in the workflow
Transcoded clips	Source clips that produced editorial or review media	Shows transcode progress and helps explain processing delays
Synced clips	Clips linked to production sound where sync is required	Shows editorial readiness for dialogue and scene work
Delivered clips	Assets handed to editorial, review, production, or another recipient	Defines what recipients should expect to see
Held or excluded clips	Media intentionally withheld, failed QC, missing metadata, or outside delivery scope	Explains why received and delivered totals do not match

For each shoot day, keep separate totals for:

Received source clips
Verified source clips
Transcoded clips
Synced clips
Delivered clips
Held or excluded clips

If all you show is “total clips,” a mismatch becomes a mystery. Show the state of each group and the explanation writes itself. 212 clips were received and 212 were verified. 208 were transcoded, 204 were synced, and 4 were MOS or held for review. This is also where card clearance becomes safer. Many productions require a precise, unambiguous process before camera or sound cards are reformatted. Your report supports that process by showing that the responsible team has copied, verified, and, if required, archived the source media. Don't let a daily summary imply that a card is safe to clear unless your workflow actually makes that determination.

Make the report readable for each audience

One report can serve multiple teams, but not if it dumps every field on the first page. Put the high-level production summary first, then the detail. Production wants:

Total clips by camera
Total running time by camera
Total data shot
Any missing, damaged, delayed, or held media
Whether the day is complete

Those fields make the report usable as a completion snapshot instead of a data dump. Editorial wants:

Delivered clip count
Sync status
Reel, roll, scene, take, and timecode metadata
Proxy specs
Any clips that need attention

Those fields let editorial reconcile what was delivered against what was expected. Post supervisors want:

Storage burn rate
Transcode volume
Delivery status
Archive status
Exceptions that affect schedule or cost

Keep the first page or first tab short enough to read on a phone. The detailed clip log can be as long as your team needs, as long as it's structured and sortable.

Automate distribution, but keep ownership clear

Send the report at the same point in the workflow every day. That might be after ingest verification or after transcodes finish, after editorial delivery, or after archive confirmation. Pick the moment that matches the purpose of the report. If production needs storage burn during lunch, send a preliminary ingest summary. If editorial needs confidence before cutting, send the final delivery report after dailies are posted or transferred. If both groups need reports, label them clearly as preliminary and final. A normal distribution group might include:

DIT or data manager
Dailies colorist or lab producer
Post supervisor
Assistant editor
Editorial producer
Production office
VFX producer, when applicable
Studio or network post contact, when required

Store the report in the same project location every day, using a consistent filename such as PROJECT_DailiesReport_YYYYMMDD_v001. If revisions are possible, version the report instead of overwriting it. A corrected report with a clear note is better than a silent replacement.

Use the report to spot trends

Daily reports become much more valuable after a week. Clip counts, runtime, and storage volume reveal how the shoot is behaving. If Camera C suddenly doubles its data volume, maybe a setting changed. If proxy storage grows faster than expected, maybe editorial deliverables are heavier than planned. If delivered clip counts keep lagging behind verified source counts, the bottleneck is probably transcode, sync, or review. Useful trend summaries include:

Storage by shoot day
Storage by camera
Average GB per hour of footage
Received versus delivered clip counts
Exception count by category

These trends help post supervisors forecast drive purchases and upload windows, assistant editor workload, and archive timing. They also give production a neutral way to discuss media volume without relying on anecdotes from a chaotic set day.

Keep the first version simple enough to survive

The best first draft of a dailies report is the one your team will actually produce every day. Start with clip count, duration, and storage per camera. Add status fields so your team can reconcile the numbers. Add exceptions so problems are visible. Then refine the formatting once the data is reliable. If you can get one clean report out every shoot day, with consistent camera grouping and trustworthy totals, you have already solved the hard part. Everything after that is polish: cleaner PDFs and automated email, archive summaries, and weekly rollups. The report earns its place when people stop asking, “Did we get everything?” and start asking better questions, like “Why did Camera B generate twice as much media today?” or “Can editorial start with the delivered set while your team investigates the held clips?” So build tomorrow's report from today's clip log, send it to the same list at the same hour, and let the totals do the arguing while the day’s footage is still fresh.

FAQ

At minimum, include shoot date and camera ID, clip count, and total running time. Add source media size, card or roll information, delivery status, and any exceptions. The most useful reports keep a clip-level log underneath the summary, so totals can be traced back to individual clips.

It can count either, but the report must label them separately. Source camera files and audio files, proxies and synced clips, and delivered dailies can all have different totals. Avoid one vague “total clips” column unless the report clearly defines what that total represents.

Duration should be calculated from frames or seconds, then displayed as timecode for readability. This is safer than relying only on timecode strings, especially when a show includes mixed frame rates, drop-frame timecode, or off-speed footage.

Counts differ because some source clips are false starts or MOS material, technical tests or held shots, damaged files, or unsynced items. A good report separates received, verified, and transcoded clips from synced, delivered, and excluded ones, so those differences are visible instead of confusing.

Yes, if the spreadsheet imports clip-level metadata instead of relying on manual entry. A strong setup has a raw import tab and a normalized clip log, summary tabs, and separate tabs for exceptions and distribution notes. Pivot tables or formulas then summarize clips, duration, and storage by shoot day and camera.

Treat the report like a controlled deliverable, not an email attachment that can be forwarded forever. Aspect lets teams share folders, reports, or review collections with specific access levels, passwords, and expiry dates, which helps production see the summary while editorial keeps deeper media access behind granular sharing permissions.