workflow

Logging an archive nobody wrote notes for

Inherited footage arrives with no log, no naming convention, and nobody left to ask. A working order for making a drive searchable when you were not there.

Someone hands you a drive. It holds four years of footage from a team that has moved on, in folders named by date, or by camera, or by a job number that meant something to a person who left. There is no log. There is nobody to ask.

This is a different problem from logging your own shoot. On your own shoot you are recording what you already know. Here you are recovering what nobody wrote down, and the recovery has to be cheap enough to be worth doing across thousands of clips.

Start by deciding what "findable" means for this drive

You are not going to describe every clip. Decide what question the archive has to answer, and log only what answers it.

An archive of client work usually has to answer "which job was this". An archive of b-roll has to answer "what is in the frame". An archive of interviews has to answer "who is speaking and what did they say". Those three need almost no fields in common.

Pick one. Logging for all three at once is how these projects stall at 8% complete.

Read the folder structure before you read any clips

The folder names are the only surviving log. They were written by someone who understood the material, which makes them better evidence than anything you will infer from a thumbnail.

Walk the tree and write down what each level appears to mean. A path like 2023/1104_ACME/A_CAM/ is telling you a date, a client, and a camera position. That is three fields recovered before a single clip is opened, and they apply to everything underneath.

Where a level is ambiguous, open two clips from different branches and compare. You are looking for the rule, not the meaning of one folder.

Pull what the files already carry

Camera files record more than people expect. Creation date, camera model, lens, focal length, shutter, ISO, frame rate, and often a reel or clip identifier are sitting in the file already.

None of that needs a human, and none of it needs a model. Extract it first, because it is free and it is exactly correct. It also gives you a spine to hang everything else on: once every clip has a real date and a camera, "which job was this" is often already answered by the folder plus the date.

Then propose, and confirm

What is left is the part that needs judgement: what is in the shot, who is in it, whether it is usable.

This is where ClipLogger's cloud analysis (Rush) earns its keep on an inherited drive. It looks at the clip and proposes values for your fields. It also groups the same face across clips, so once you identify a person once, the other clips they appear in come with you. It does not tell you who they are. It tells you these are the same person, and you supply the name.

The proposal is not the record. You confirm it. On an archive this matters more than on your own footage, because you have no memory to check the proposal against and a wrong value you accepted will look exactly like a right one in six months.

Rush is the paid path and it is there to make a large archive finish this decade rather than to unlock a feature. Local analysis runs on the machine and costs nothing. On four years of footage the difference is measured in days.

Write it where it survives

Whatever you recover has to end up somewhere that outlives the tool you used.

ClipLogger writes confirmed metadata into open format sidecar files next to the media, and composes the important fields into the file name itself. That second part is the one that matters for an inherited drive, because the next person to receive it may not run any of your software. A file called 2023-11-04_ACME_interview_dana_A001.mov is legible to a human, to the Finder, and to every application that lists files.

The sidecar carries the full record. The name carries the part that has to survive being copied to a stranger's drive.

A realistic order of work

  1. Map the folder structure and write down what each level means.
  2. Extract embedded file metadata across the whole drive.
  3. Decide your one question and the three or four fields that answer it.
  4. Run analysis on one folder, confirm it, and check whether the fields were the right ones.
  5. Only then run the rest.

Step four is the one people skip. Logging 4,000 clips against a field schema you have not tested is how you find out on clip 3,000 that you needed a field you never made.

What you cannot recover

Intent does not survive. Whether a take was the good one, why a shot was framed that way, what the client rejected: none of that is in the file, and no analysis proposes it.

If any of that still exists in someone's head, a fifteen-minute call recovers more than a week of processing. Make that call before you start, because the window on it closes.

ClipLogger needs Apple silicon and macOS 15 Sequoia or later.

← All articles