DCP Subtitles: SMPTE ST 428-7 vs Interop - Which Format to Request

💡 For modern DCP deliveries, use SMPTE ST 428-7 (2014): namespace http://www.smpte-ra.org/schemas/428-7/2014/DCST, XML wrapped in an MXF track file (SMPTE ST 429-5) with the font embedded as a UUID-named asset. Interop (CineCanvas) delivers a plain XML file with a separate .ttf font. When in doubt, ask the facility house which format their cinema server supports.

What actually changes between SMPTE and Interop at the XML level?

DCP subtitles come in two formats, and the difference starts at the root element. SMPTE ST 428-7 (2014) defines a SubtitleReel root with namespace http://www.smpte-ra.org/schemas/428-7/2014/DCST. Interop CineCanvas - a proprietary format originally developed by Texas Instruments - uses a DCSubtitle root with no formal namespace (or a digicine.com-based namespace in some implementations).

That namespace string is the first thing a cinema server checks. DCP-o-matic, OpenDCP, and facility-side QC tools all identify the DCP type from that string. Getting it wrong means your subtitles load as the wrong format, or fail to load at all.

SMPTE also adds metadata fields that Interop lacks: a formal <Language> element using BCP 47 codes (e.g. vi for Vietnamese, zh for Chinese), <ContentTitleText>, and <IssueDate>. Interop stores the movie title in <MovieTitle> and uses plain language names ("Vietnamese") rather than codes.

Format comparison at a glance

I keep this table as a reference for every DCP subtitle delivery. The key dividing line is the container: SMPTE is an MXF asset; Interop is a plain XML file.

How is the font packaged in each format?

This is the most practically significant difference I run into. In an Interop DCP, the font is a plain .ttf file sitting in a subfolder of the package, referenced by filename in the XML. In a SMPTE DCP, the font is embedded inside the MXF track file, referenced by a UUID declared in a <LoadFont> element.

That UUID-named font file has no extension. If the declared UUID is urn:uuid:b2c3d4e5-f6a7-8901-bcde-f12345678901, the font file is named exactly b2c3d4e5-f6a7-8901-bcde-f12345678901 with nothing after it. SeConv handles this automatically when you use DCinemaSmpte2014Mxf with the --dcinema-font flag.

Facility-side validators reject a SMPTE DCP whose font is delivered as a loose .ttf instead of embedded in the MXF. Wrong font embedding is one of the most common QC failures I see on DCP subtitle jobs.

What do EditRate and frame-count timecodes mean?

Both SMPTE and Interop use frame-count timecodes in the format HH:MM:SS:FF, where the last field counts frames rather than milliseconds. SMPTE declares the frame rate explicitly via two elements: <EditRate>24 1</EditRate> (meaning 24/1 = 24 fps) and <TimeCodeRate>24</TimeCodeRate>. These must match the DCP picture reel exactly.

Interop instead counts in 4 ms ticks (250 ticks per second), and may express times as decimal seconds (00:03:12.500). Most tools convert this automatically, but a timecode copy-pasted between formats can land on a slightly different frame if the conversion is done naively.

Always specify the frame rate when exporting. A 24 fps subtitle file loaded into a 25 fps reel will be subtly off. For 29.97 (drop-frame), the DCP picture is timed to drop-frame; a subtitle file exported as non-drop-frame will drift by about 3.6 seconds over an hour.

Producing a SMPTE ST 428-7:2014 subtitle file with SeConv

I use Subtitle Edit's SeConv for cinema subtitle exports. The DCinemaSmpte2014Mxf format produces the deliverable MXF asset. The --dcinema-font flag embeds the font; --reel-duration sets the picture reel length in frames so the asset reports the correct duration to the DCP server.

# Plain XML for review (no MXF wrapping - useful before the DCP facility step):
seconv.exe "in.srt" "DCinemaSmpte2014" --fps 24 --output-folder "out/" --overwrite

# Deliverable SMPTE DCP asset (XML wrapped in MXF with font embedded):
seconv.exe "in.srt" "DCinemaSmpte2014Mxf" --fps 24 --dcinema-font "Arial.ttf" --reel-duration 172800 --output-folder "out/" --overwrite

# Interop CineCanvas XML (for older venues that require it):
seconv.exe "in.srt" "DCinemaInterop" --fps 24 --output-folder "out/" --overwrite

• DCinemaSmpte2014: plain XML with correct 2014 namespace, useful for review or manual MXF wrapping.
• DCinemaSmpte2014Mxf: wraps the XML and embeds the font into an MXF track file - the actual deliverable form.
• --dcinema-font: the .ttf file to embed; required for the Mxf variant.
• --reel-duration: picture length in frames (172800 = 2 hours at 24 fps, since 2 x 3600 x 24 = 172800).
• DCinemaInterop: produces the CineCanvas-dialect plain XML file, still required by some venues.

A minimal SMPTE ST 428-7:2014 XML file, before MXF wrapping, looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<SubtitleReel xmlns="http://www.smpte-ra.org/schemas/428-7/2014/DCST">
  <Id>urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890</Id>
  <ContentTitleText>My Feature Film</ContentTitleText>
  <IssueDate>2026-11-06T00:00:00</IssueDate>
  <ReelNumber>1</ReelNumber>
  <Language>vi</Language>
  <EditRate>24 1</EditRate>
  <TimeCodeRate>24</TimeCodeRate>
  <StartTime>00:00:00:00</StartTime>
  <LoadFont ID="Arial">urn:uuid:b2c3d4e5-f6a7-8901-bcde-f12345678901</LoadFont>
  <SubtitleList>
    <Font ID="Arial" Color="FFFFFFFF" Size="42">
      <Subtitle SpotNumber="1"
                TimeIn="00:03:12:00"
                TimeOut="00:03:14:12"
                FadeUpTime="00:00:00:00"
                FadeDownTime="00:00:00:00">
        <Text VAlign="bottom" VPosition="8.0" HAlign="center">
          Chào mừng đến với Hội An.
        </Text>
      </Subtitle>
    </Font>
  </SubtitleList>
</SubtitleReel>

• xmlns: the 2014 namespace is mandatory; 2007 and 2010 versions still exist in the wild but some QC validators reject them.
• Id: a fresh UUID per file - never reuse across deliveries.
• EditRate / TimeCodeRate: must match the picture reel frame rate exactly.
• Language: BCP 47 / ISO 639-1 code (e.g. vi for Vietnamese).
• VAlign="bottom" VPosition="8.0": places text near the bottom image edge, minimizing cross-server rendering variance (the 2014 vertical positioning baseline is more consistent than 2010).

What can I handle myself, and when does a DCP facility make sense?

For subtitle-only DCPs - a short film, a festival premiere, one or two reels - SeConv plus the SMPTE MXF export covers the subtitle asset itself. What it cannot do is wrap that asset into a full DCP package (CPL, PKL, ASSETMAP), test playback on a Dolby or Barco server, or issue Key Delivery Messages (KDMs) for encrypted deliveries. That part requires DCP creation software (DCP-o-matic is free and open-source) or a dedicated post-production facility.

If the client is a studio or streaming platform requiring encrypted subtitle tracks, full multi-reel SMPTE DCP handling, or facility-tested playback, bringing in a DCP house is the right call. The subtitle translation and timed-text work - converting scripts, timing to picture, checking CPS, verifying that all glyphs render correctly - is what I do. The DCP wrapping is packaging, and most facilities charge a flat fee for it once you hand them a clean SMPTE XML or MXF.

See my DCP subtitle service for how I handle the translation and timed-text step of a cinema subtitle delivery.

FAQ

Official Sources

• Subtitle Edit (nikse.dk) - SeConv command-line formats including DCinemaSmpte2014Mxf and DCinemaInterop, --dcinema-font and --reel-duration flags. Verified November 2026.
• SMPTE-RA - ST 428-7:2014/DCST namespace - official namespace reference and XSD schema for SMPTE ST 428-7:2014. Verified November 2026.
• Cinepedia - Timed Text Track Files - SMPTE ST 428-7 and Interop CineCanvas structure, font handling, and language tagging. Verified November 2026.
• Cinepedia - Interop DCP and SMPTE DCP - format incompatibilities, encryption, CPL differences. Verified November 2026.
• Knut Erik Evensen - Converting SRT to SMPTE XML in Subtitle Edit - UUID handling, 2014 namespace, font delivery rules. Verified November 2026.