Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26429-3:2008 Digital Cinema Packaging — Sound and Picture Track File
MXF OP-ATOM track file specification for single-essence D-Cinema sound and picture distribution
1. MXF Track File Specification for D-Cinema
ISO 26429-3 specifies the common features of Sound and Picture Track Files for digital cinema distribution using the MXF (Material Exchange Format) file format. The standard is an application specification based on SMPTE 390M OP-ATOM (Operational Pattern Atom), which simplifies representation of a single item. Each Track File contains exactly one type of essence either sound or picture, never both interleaved. This design principle, called OP-ATOM, was specifically developed for the digital cinema distribution model where each essence component is managed independently.
The importance of the single-essence-per-file constraint becomes clear when considering real-world cinema operations. A typical feature film requires one picture track file and multiple language audio track files (English, French, Spanish, etc.). With the OP-ATOM structure, replacing the French audio with a new dub requires swapping only the French track file without touching the picture file or other language tracks. This modularity dramatically simplifies content management for distributors and exhibitors.
The OP-ATOM constraint means each D-cinema composition consists of multiple Track Files (one per essence track), linked together by a Composition Playlist. This modular design simplifies versioning, replacement of individual language tracks, and partial content updates without regenerating the entire package.
2. Core Structural Constraints
| Component | Requirement | Engineering Rationale |
|---|---|---|
| Partitions | Exactly 3: Header, Body, Footer | Clean separation of metadata, essence, and indexing |
| Operational Pattern | OP-ATOM (SMPTE 390M) | Single-item simplification for distribution |
| Essence per File | Single type only | No interleaving of picture and sound in one file |
| Index Tables | Required, in Footer Partition | Enables random access and efficient seeking |
| KAG Size | 1 (default alignment grid) | Standard KLV alignment |
| MIME Type | application/mxf | Standardized media type identification |
3. Header Metadata and Synchronization Engineering
The standard mandates that Track Files be Closed and Complete meaning all header metadata is present in the Header Partition, and no other partition contains copies. Each Track File contains one Top-level File Package and one Material Package. The Material Package is not used for playback but represents offset and duration of the intended reproduction segment. This architecture enables a clean separation between the stored essence and the playback intent, allowing a single stored file to serve multiple playback configurations.
Time code in Track Files is synthetic and informational only it consists of continuously incrementing numbers from a starting point (customarily 01:00:00:00). Do not rely on Track File time codes for frame-accurate synchronization between separate Track Files; this is handled at the Composition Playlist level which coordinates multiple track files during playback.
Asset identity is established through the Package UID a 32-byte UMID (Universal Material Identifier) per SMPTE 330M. The first 16 bytes follow a specific pattern: 060a2b34h 01010105h 01010f20h 13000000h. File names must never be used for identity determination, since filenames can be changed arbitrarily during transport. The UUID portion (bytes 17-32) provides unique identification across all assets worldwide using a universally unique identifier that is statistically guaranteed to be non-conflicting.
When implementing D-cinema playback servers, the three-partition structure enables efficient partial file access. The Header Partition metadata can be read quickly without scanning the entire file, and the Footer Partition index tables provide direct access to any frame position in the Body Partition enabling instantaneous seek operations.
Synchronization of multiple Track Files (one picture plus multiple language audio tracks) is beyond the scope of this standard. However, the standard specifies that all essence within a single Track File must share the same edit rate, and each Content Package contains exactly one picture or sound item. Frame-based wrapping is used, and sound channels for multi-channel formats (e.g., 16-channel theatrical) should be packed at the sample level within a single Track File rather than distributed across multiple files.
4. Frequently Asked Questions
Q: Why must sound and picture be in separate files?
A: This follows the OP-ATOM operational pattern, which simplifies individual essence management. Each file is self-contained with its own metadata, making replacement of specific language tracks or re-editing straightforward without modifying unrelated essence files.
A: This follows the OP-ATOM operational pattern, which simplifies individual essence management. Each file is self-contained with its own metadata, making replacement of specific language tracks or re-editing straightforward without modifying unrelated essence files.
Q: How is file identity verified if filenames should not be used?
A: Identity is verified by the Package UID a 32-byte UMID value embedded in the file header. Applications should parse this value and compare it against known UUIDs rather than relying on filenames which can be changed.
A: Identity is verified by the Package UID a 32-byte UMID value embedded in the file header. Applications should parse this value and compare it against known UUIDs rather than relying on filenames which can be changed.
Q: What is the purpose of the Material Package if it is not used for playback?
A: The Material Package can represent offset and duration information for the portion of the track intended for reproduction. It serves as a virtual editing layer without modifying the underlying essence, enabling flexible playback configurations.
A: The Material Package can represent offset and duration information for the portion of the track intended for reproduction. It serves as a virtual editing layer without modifying the underlying essence, enabling flexible playback configurations.
Q: Can encrypted essence be carried in Track Files?
A: Yes, Track Files may include encrypted essence containers. The essence container identifies that encryption has been applied, though the specific encryption process definition is beyond the scope of this standard and is defined in companion standards.
A: Yes, Track Files may include encrypted essence containers. The essence container identifies that encryption has been applied, though the specific encryption process definition is beyond the scope of this standard and is defined in companion standards.
