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 boring on purpose. It gives production a quick read on shoot volume, gives editorial confidence that everything expected arrived, gives post supervisors a storage burn rate, and gives the DIT or lab a paper trail when camera cards are cleared. The exact layout can vary by show, but 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 the same thing as a camera report, sound report, continuity log, lab report, or daily production report, though it may overlap with all of them. Its job is to summarize 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 matters because the same shoot day can have very different counts depending on what you include. A camera may roll 148 OCF clips, but editorial may receive 146 synced proxy clips if your team intentionally withholds two clips as false starts, MOS plates, or technical tests from the viewing set. Both numbers can be correct, but they just 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 usually define this up front: base frame rate, audio sample rate, editorial deliverables, storage responsibilities, 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 usually 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, and the summary is what most people read. If someone asks why Camera B is 700 GB higher than yesterday, you need to be able to drill into the clip rows and see whether the difference came from long takes, higher codec data rate, off-speed material, additional cards, or 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. If you calculate duration only from human-readable timecode strings, you'll eventually get rounding errors, drop-frame confusion, or off-speed surprises. The safer approach is to store duration as a frame count or seconds value, then display it as timecode for readers. Your reporting system should know the base frame rate used for the production and the actual frame 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 your team uses the report for storage planning and labor forecasting, real clock time and playback time both matter. Long off-speed takes may not look long on set, but they can 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 you format the report to scale values automatically. For a daily summary, GB with one decimal place is usually readable. 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, 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

The takeaway is that you shouldn't hand-enter clip counts unless the shoot is tiny. Manual entry is fine for notes and exceptions, but it's a bad primary method for counting hundreds of clips across multiple cameras after a long day. If you're already using a tool like Silverstack, Resolve, Cortex, 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 for commercials, documentaries, unscripted, or smaller scripted shows. The key is to avoid making the spreadsheet 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, but those can live in the detailed tab. Spreadsheets break down when multiple people edit them at once, when exports arrive in different formats every day, or when you need to distribute reports automatically. At that point, keep the spreadsheet as the readable output, but move ingestion and calculation into a script.

A script version for repeatable reporting

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

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 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, the script should include that clip in the report with an exception note. A missing value is useful when it's visible, but it's 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 you need it to match both sides. The ingest count tells you what arrived, and the delivery count tells you what editorial or review actually received. Those are related, but 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. If you show the state of each group, it's much easier to explain that 212 clips were received, 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 should support 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 usually 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 usually 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 usually 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, 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, 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's polish: cleaner PDFs, 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?” That's the point of the dailies report: shared visibility while the day’s footage is still fresh.

FAQ

At minimum, a dailies report should include shoot date, camera ID, clip count, total running time, 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, audio files, proxies, synced clips, and delivered dailies can all have different totals. Avoid using 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.

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

Yes, if the spreadsheet imports clip-level metadata instead of relying on manual entry. A strong spreadsheet setup usually has a raw import tab, a normalized clip log, summary tabs, exceptions, and distribution notes. Pivot tables or formulas can 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.