export const meta = { title: "How to Build Dailies Reports for Clip Counts, Duration, Storage", description: "Learn how to generate dailies reports that summarize clip counts, runtime, and storage by camera, using metadata, spreadsheets, scripts, and clear distribution.", tldr: "Build dailies reports from clip-level metadata, then summarize by shoot day, camera, card, and status so production can see clip counts, running time, and storage. Use spreadsheets or scripts to normalize camera IDs, calculate duration consistently, separate source from proxy totals, flag exceptions, and distribute a versioned report to the same people every day.", slug: "how-to-build-dailies-reports-for-clip-counts-duration-storage", publishedAt: "2026-08-26", readingTime: 10, thumbnail: "https://cdn.aspectlabs.dev/blog/how-to-build-dailies-reports-for-clip-counts-duration-storage/cover-49317afaa926.png", authors: ["edison"], primaryTopic: "post-production", topics: ["post-production"], tags: ["dailies"], faq: [ { "question": "What should a dailies report include at minimum?", "answer": "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." }, { "question": "Should a dailies report count source camera files or delivered editorial proxies?", "answer": "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." }, { "question": "How should duration be calculated for dailies reports?", "answer": "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." }, { "question": "Why do clip counts sometimes differ between camera reports and editorial delivery reports?", "answer": "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." }, { "question": "Can a spreadsheet be reliable enough for dailies reporting?", "answer": "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." }, { "question": "How should preliminary and final dailies reports be shared with different teams?", "answer": "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." } ], } 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](https://www.studiobinder.com/blog/daily-production-report-explained-free-template/) 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](https://support.appsflyer.com/hc/en-us/articles/115005600889-Troubleshooting-discrepancies-in-AppsFlyer-dashboards-and-reports) 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.” Productions with formal [workflow memo](https://partnerhelp.netflixstudios.com/hc/en-us/articles/4415931246995-Dailies-Best-Practices)s 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](https://www.toolsforfilm.com/blog/documentary-data-storage-breakdown), off-speed material, additional cards, or duplicate media. For each clip row, capture the fields you need for count, duration, and storage calculations: - 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. 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](https://docs.motorolasolutions.com/bundle/89303/page/112f343c.html)” 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. 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](https://pomfort.com/article/reports-in-silverstack-how-to-prepare-and-share-production-knowledge/) 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](https://docs.anyclip.com/en/articles/9193610-custom-reports) 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. Aspect gives dailies, editorial, and production one shared cloud storage location, so everyone points at the same source and delivery folders. That cuts down on mystery duplicates when you reconcile what was ingested, transcoded, and delivered. | 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. Aspect lets teams share folders and collections with specific permissions, passwords, and expiry controls. A dailies report or viewing batch can reach production without becoming a permanent forwardable link. 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](https://docs.cloud.google.com/compute/docs/logging/usage-export) 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.