A delivery spec usually arrives as a paragraph in an email. ProRes 422, 25 fps, 1920×1080 or better, thirty seconds exactly, stereo at 48 kHz, programme loudness −23 LUFS, true peak no higher than −1 dBTP.
Then thirty files arrive from four suppliers, and somebody has to decide whether they match. The usual method is to open them one at a time, read numbers off an inspector, and remember what the paragraph said. It works for five files. At thirty it stops working, and the failure mode is not that you check them badly — it is that you check the first eight properly and skim the rest.
Where the checking actually goes wrong
Three things break down, and none of them are about attention.
The spec lives in prose. “ProRes 422” is ambiguous the moment a file reports Apple ProRes 422 LT. Is that acceptable? The email does not say, because the person who wrote it did not think of it. Every ambiguity becomes a judgement call made differently by different people on different days.
Some fields cannot be seen without opening the file properly. Codec and resolution are in the container header. Start timecode is in a separate track. Loudness is not written down anywhere — it has to be measured over every sample. A visual check catches the first, sometimes the second, and never the third.
The result is not portable. You end up with a mental list of six problem files and no artefact. When the supplier asks which ones and why, you go back through them.
Writing the spec down once
The alternative is to state the spec in a form the machine can apply. In FileLister this is a filter set: a scope, and a list of requirements.
The scope decides which files the set has an opinion about. “Is a video” is the common one. A folder holding video, stills and a PDF should not produce three failures for the PDF not being ProRes; it should produce no verdict at all, because the set does not cover it.
The requirements are field, comparison, value. Video codec equals Apple ProRes 422. Frame rate equals 25. Pixel width at least 1920. Duration at least 30. True peak at most −1. Each one is a line, and the set is the whole list.
Two properties of this are worth understanding before you write one.
Sets combine as alternatives, not as a single list
A file passes if it satisfies every requirement of at least one enabled set. This matters because a delivery folder often legitimately holds two different things — a full-frame version and a ribbon-board version, say, with completely different dimensions. You do not write one impossible set that describes both. You write two, enable both, and a file is fine if it matches either.
The consequence to watch: an enabled set with no requirements passes everything in its scope, which then suppresses failures from every other set. It is the empty-rule problem that shows up in firewall configs and permission systems too.
“Not measured” is not the same as “failed”
If the extended media probe is switched off, no file has a codec recorded. A naive checker would report that every video fails the codec requirement, which is both wrong and the kind of wrong that destroys trust in the tool within about a minute.
A requirement on a value that was never read should come back as unjudged, with a note explaining why, and the same applies to anything measured on demand. A key-frame requirement cannot be evaluated until the key-frame analysis has run. A loudness requirement cannot be evaluated until loudness has been measured. Saying so is more useful than guessing in either direction.
Learning a set from a file that is already right
Writing requirements by hand is fine when you know the spec. Often you do not — what you have is one file everybody agrees is correct, and thirty that may or may not match it.
Right-clicking a known-good file and asking for a set drafts one from that file's own metadata: its codec, its dimensions, its frame rate, its audio configuration. The draft opens for editing rather than saving straight away, which is the important part. The file you accepted is 1920×1080, but the requirement you want is probably “at least 1920 wide”. It is 30.0 seconds, but you may want “at least 30”. The draft gets you the fields and the values; you supply the intent.
Three ways to look at the answer
Once a set is enabled, every file in the listing carries a verdict, and there are three useful views of that.
- Flag in place. The whole folder stays visible, failures marked, and the specific column that failed marked too. Best when you want context — is it one supplier, one batch, one day.
- Only failures. The listing narrows to what missed. The practical consequence is that every export taken from that listing is the flagged list, so exporting to CSV in this mode gives you the problem files and nothing else.
- Export the failing list with reasons. A tab-separated file with the file name, what it does not meet, and the path. This is the artefact you send back.
That last one is the difference between “some of these are wrong” and a message a supplier can act on without a phone call:
Name Does not meet
Sponsor_A_30s.mov Broadcast HD: ProRes 422, At least 1920 wide
Sponsor_B_15s.mov Broadcast HD: Duration at least 30
Scope the check to what you are actually looking at
One detail that decides whether the output is usable: the failing list should follow the source and filters you have selected, not the whole catalogue. If you have narrowed to one supplier's folder, the export should contain that supplier's failures. A list that quietly includes files from folders you were not looking at gets sent to the wrong person.
Where this fits in a working week
The realistic shape of it:
- Write the spec down once, as one or two filter sets, when the campaign or series starts.
- Point FileLister at the incoming folder. The check runs as the listing builds.
- Run loudness and key-frame analysis on the video selection if the spec constrains either.
- Switch to failures only. If it is empty, you are done.
- If it is not, export the list with reasons and send it on.
Steps two to five take a couple of minutes on a folder of thirty. The value is entirely in step one, and the reason it works is that the spec stops being something a person has to hold in their head while scrolling.
What this does not do
A filter set checks properties, not content. It will tell you a file is ProRes 422 at 25 fps with the right duration and the right loudness. It will not tell you the wrong cut was exported, the logo is out of date, or the audio is out of sync. Those need a person watching.
What it removes is the part of the job that a person is genuinely bad at: comparing twelve numbers per file, across thirty files, without drifting. That part is worth automating precisely because getting it wrong is so undramatic — nothing crashes, nothing looks broken, the file just quietly fails somewhere downstream where it costs a great deal more to fix.