Make a Cinema Review Copy of a Film Pitch Sample With DCP-o-matic

Somewhere in the venue's email is a line like "please send a DCP." It is easy to read that as "send a video file, but fancier." It isn't. A DCP is a folder of picture and sound assets plus the metadata that says how they belong together, and the cinema's server ingests that folder. DCP-o-matic can build one from your finished proof-of-concept sample. What it cannot do is tell you the venue's projector will show it correctly, and it cannot tell you that you are finished — because the saved authoring project and the generated cinema package are two different objects, and only one of them screens.

This is the difference the whole job turns on. DCP-o-matic's own manual makes a version of it: the thing you create first is a film — a working project — and producing the DCP is a separate, subsequent step. CalArts' 2pop technical-support page starts its workflow from a prepared export and the recipient's requirements, then configures content and output, and notes that the receiving server's compatibility shapes which standard you choose. Both are worth having in mind. Neither replaces a conversation with the person who runs the room.

Confirm the receiving venue before choosing settings

The requirements come first, not the settings. A DCP's picture and sound are constrained by what the projector and server can actually do, so getting the answers before you open the software saves you from rebuilding a package late.

Ask for, in writing if you can get it:

• Picture container. Flat or scope, and 2K or 4K. The two 2K containers you will hear named are 1998×1080 (flat) and 2048×858 (scope); 4K is the same pair of shapes at double size. Flat and scope are different shapes, so this is a question about the screen the venue will use, not a preference.
• Frame rate. A cinema package runs at one of a short list of rates — 24, 25, 30, 48, 50 or 60 — and your sample probably is not on that list exactly.
• Sound layout. How many discrete channels, and in which arrangement. Five-point-one means left, right, center, LFE, left surround, right surround. Seven-point-one adds more surround positions. A stereo sample is not a problem, but it becomes a different kind of package.
• Standard. SMPTE or Interop, which is a server-compatibility question rather than a taste question. The CalArts page treats that choice as dependent on the receiving system. Ask; do not infer it from what worked for someone else.
• Delivery. What medium, how files should be named, and who performs the ingest. This article deliberately does not cover drive formatting or transfer procedures — those are venue-specific, so they belong in the venue's instructions, not in a guess.
• A test. Ask whether there is a slot to ingest and play before the actual review, and who to call if something is wrong that day.

Now write your sample's actual properties next to those answers: the resolution and shape it was finished at, its frame rate, its duration, and how its audio is arranged. Two columns. Where they disagree, that is the work.

When they disagree, the decision belongs to whoever owns the affected element. Changing the frame rate or the channel arrangement of someone's finished mix is not a rename; it alters what plays and how long it takes. Get the picture owner's and the sound owner's agreement, write down what was agreed, and keep it with the project. That note is what lets you tell a venue later that the two-frame difference they are seeing was a decision, not a mistake.

One more thing to hold: keep the ordinary review movie. A normal file is the fallback if the package does not survive the venue's server, and it is useful for anyone who needs to watch the sample on a laptop. It is not a discreet substitute for the DCP. Sending a video file to a room that asked for a package, without saying so, moves the failure from your desk to their screening.

Check what DCP-o-matic thinks the sample contains

Create a project with a name you will recognize in three months, and add the approved source. Before generating anything, look at what the software believes about it. The interesting word is interpretation: the application reads properties from the file's container, and a container does not always describe its contents the way you remember. A rate near but not equal to a cinema rate, a six-channel file read as several separate streams, a file whose first frame is not the frame you think — all of these show up here, before you have built anything.

Check four things on the content settings:

Duration. Does it match the finished sample to the frame? A mismatch usually means the rate is being read differently than it was written.

Frame-rate interpretation. This is the one that catches people. If your sample is at 23.976 or 29.97 — the fractional rates cameras and edit systems produce constantly — it does not map one-to-one onto any rate a cinema package uses. Nothing here is a filename edit. Changing the interpretation changes how long the piece runs and whether the audio stays with the picture.

Framing. Does the picture sit in the container the way you expect, with the same edges you saw when you finished it? Note what you actually see rather than what you assume the file contains.

Audio channels. How many are present, and is each one landing where you intend? A stereo sample mapping to left and right, with center and surrounds left silent, is normal and fine — but the venue should know, and you should know before they discover it. A six-channel source is where mistakes hide: if only some of the source channels are assigned to outputs, the unassigned ones go out silent. The package will look complete and half the mix will be missing.

Any conversion — a rate change, a channel rearrangement — should be attributable: who approved it, on what date, based on what. If you cannot name that person, you are not ready to generate.

Build an identification fixture first

Before you spend a session on the valuable sample, make a short original fixture and put it through the workflow. It is a purpose-built thing and worth designing properly, because it tests the parts that a normal film hides: the edges, the count, and each channel on its own.

What the fixture should contain:

• Framing marks. Thin marked borders at both the flat edge and the scope edge, plus corner ticks and a center cross. If a mark that should be visible is cut off, you have learned that the container being shown is not the one you built.
• Visible timing cues. A large frame counter or second counter, changing often enough that you can tell where you are, and a distinct final frame that reads unmistakably as the end. That last one matters more than it sounds: you want to see the composition finish rather than guess that it did.
• Separately identifiable channel signals. Not one tone across everything. A sequence that walks the channels — signal on the left, then center, then right, then the surrounds — with the picture showing which channel is being exercised at that moment. A silent channel is then obvious, and a swapped pair shows as a mismatch between the number on screen and the speaker it came out of. Use a low tone rather than speech for the LFE; that channel is band-limited, and a voice there proves less than you would like.

Match the fixture to the layout your sample will actually use. A stereo fixture cannot teach you anything about a center channel, so if the sample is going out as 5.1, the fixture should be too.

Keep the fixture. It is the thing you will reach for the next time a venue says the sound was strange.

Generate the DCP and identify the deliverable folder

With the interpretation confirmed, follow the generation workflow of the specific DCP-o-matic release you have installed. Control names shift between versions; the shape does not, and the version's own documentation is the authority on where each control sits. Do not work from a remembered screenshot.

Then find the thing you actually produced. The project you have been editing is a file that points at your source media by path. It is a working document. It is not portable, it is not ingestible, and if you hand it to a venue, what they receive is a small file describing materials they do not have — which is the project-only handoff failure in its purest form.

The generated DCP is a directory. Inside it you should expect the picture track file and the sound track file as separate assets, plus the metadata that ties them into a composition and lists what the package contains. In SMPTE packages you will see an asset map, a composition playlist, a packing list, and a volume index; naming of these files varies a little across standards and versions, but the roles do not: assets plus descriptive metadata, all of it belonging together.

Three habits keep this object usable:

Treat the folder as the deliverable. Not the picture asset, not the sound asset, not the project file. The whole directory travels.

Do not rename internal files. The metadata names them, and the package carries checksums so a verifying player can tell whether a file has changed since it was packaged. Renaming something inside is how you turn a package that plays into one that does not, and it makes the checksum record misleading rather than helpful.

Generate into a new folder rather than overwriting one. If you rebuild with different settings, you want to be able to say which package the venue tested. Two packages in two folders is a traceable situation. One package overwritten twice is not.

When you deliver, deliver the folder and say what is in it. The composition's name is what the server will show in a playlist, so make it something a projectionist can read and match to the right slot.

Check the package, then the presentation chain

There are two checks here, and the entire discipline of this article is keeping them apart.

The first check is on the package and on your computer. Open the generated directory and confirm that what the composition needs is present: both assets there, sizes that reflect real content rather than an empty file, and the metadata intact. Then use the playback and verification tools your release provides to open the DCP itself — not the source, and not the project. Watch the opening frames for the first frame you expect. Watch the ending, including the audio tail. Watch the framing marks. Listen for the channel sequence and note which channels produced sound. If there is a picture or sound position that was supposed to be silent, confirm that it was silent.

What you get from this is a software finding. If the software reports warnings, write them down and go find out what they mean. A message that the packaging job finished is not a message that the warnings have become untrue, and it is not evidence about any cinema. Those are different statements, and the difference is the whole point.

The second check is at the venue, and only the venue can do it. Ingestion into their server and playback on their projector are the steps that decide whether the package works in that room, and no desktop player substitutes for them. Ask for the ingest, ask to see the picture and hear the sound, and watch the same things you watched at home: the ends, the framing, the channels, the duration.

Watch, too, for the failures a cinema adds that your desk cannot show you. If the fixture walked the channels correctly on your computer and the center channel is silent in the room, you have not found a software fault; you have found a routing or server configuration question that belongs to the venue. That is a genuinely useful outcome, and it is the reason to bring the fixture to the test rather than only the finished sample.

Now record all of it, in one place, with the package. A working record looks like this:

Fill in the top rows when they happen and leave the bottom rows blank until they do. A blank is honest. A row marked done because you hope it is done is the kind of record that sends someone to a screening with a package nobody has listened to.

Generated, checked, confirmed — three different claims

At the end of this you should be able to point at a specific folder and say three separate things about it with three different levels of confidence.

Generated means the package exists, with its composition and assets, in a directory you can name. Software-checked means you opened the package itself in a player, watched the ends, the framing and each channel cue, and recorded what you saw — along with any warnings you have not resolved. Venue-confirmed means the cinema ingested it and played it in the room, and someone told you it worked, or told you precisely what did not.

Keep those words apart in your own notes and in anything you send. It is tempting to let a completed export stand in for the third claim, because the export is the moment the work feels done. But the room is the only place the question is actually answered, and a venue that finds out about an untested chain during the review is finding out at the worst possible time.

Alongside the package, keep the source, the settings, the conversion approvals, the fixture, and the record. If the sound turns out wrong in that room, you want to be able to trace it back through the mapping to the input in one sitting rather than rebuild the whole thing from memory and hope you land somewhere different.

That is the difference between a review copy and a hopeful one. Not the export button — the record of what you checked, where you checked it, and what is still waiting for the room.

Frequently asked questions

What is the difference between a DCP-o-matic project and a generated DCP?

The project is a working document that points at your source media by path. It is not portable, not ingestible, and not what you hand to a venue; doing so is the project-only handoff failure. The generated DCP is a directory containing picture and sound assets plus metadata that ties them into a composition and lists what the package contains. Only the generated package screens.

What should you ask the receiving venue before choosing DCP settings?

Ask for picture container, meaning flat or scope and 2K or 4K, with 2K flat at 1998x1080 and 2K scope at 2048x858. Ask for frame rate from the cinema list: 24, 25, 30, 48, 50 or 60. Ask for sound layout, including how many discrete channels and in which arrangement; 5.1 means left, right, center, LFE, left surround, right surround, while 7.1 adds more surround positions. Ask for standard, SMPTE or Interop, as a server-compatibility question rather than a taste question. Ask about delivery medium, naming, who performs ingest, and whether there is a test slot. This article deliberately does not cover drive formatting or transfer procedures.

Why build an identification fixture before generating the DCP?

A short original fixture tests the parts a normal film hides: the edges, the count, and each channel on its own. It should contain framing marks at both the flat edge and the scope edge, plus corner ticks and a center cross; visible timing cues with a large frame or second counter and a distinct final frame; and separately identifiable channel signals that walk through the channels with the picture showing which channel is being exercised. Use a low tone rather than speech for the LFE because that channel is band-limited. Match the fixture to the layout the sample will use: a stereo fixture cannot teach you anything about a center channel, so if the sample is going out as 5.1, the fixture should be too. Keep the fixture for later troubleshooting.

What are the two checks, and why should they stay apart?

The first check is on the package and your computer. Open the generated directory and confirm both assets are present, sizes reflect real content, and metadata is intact. Then open the DCP itself, not the source and not the project, using playback and verification tools, and watch the opening frames, the ending including audio tail, the framing marks, and the channel sequence. This produces a software finding; write down warnings and find out what they mean. The second check is at the venue: ingestion into their server and playback on their projector decide whether the package works in that room. No desktop player substitutes for it. A cinema may reveal a routing or server configuration question, which belongs to the venue.

What do generated, software-checked, and venue-confirmed mean?

Generated means the package exists, with its composition and assets, in a directory you can name. Software-checked means you opened the package itself in a player, watched the ends, the framing, and each channel cue, and recorded what you saw, along with any unresolved warnings. Venue-confirmed means the cinema ingested it and played it in the room, and someone told you it worked or precisely what did not. Keep those words apart in your notes and in anything you send.

Further reading

• The Voice Plays on One Side. Check the Source Channels Before Fixing the Mix — Before remapping a six-channel source for the package, use this to audition each channel alone and classify what the file actually holds before changing anything.