Why new file formats?
When you use the Cuisine system for more than just light file conversions, the core thing you're buying is the file formats. Cuisine also contains editors, analyzers, renderers, etc for its formats, but as those come and go, the formats should live on.
I'm very sad about introducing any new file format. I researched OMF, MXF, AAF, and other EDL and media description formats, but (among other complications) none of them are human-readable, which is high on my requirements list. Also, I needed to store all sorts of rich, quirky data (such as annotations and historical versions). Although some of the formats accepted blocks of "application-specific data", I'd have to layout all my complex data within that section, which is equivalent to another file format anyway.
We all have great ideas about how a file format should be built, but this isn't the time for new data format ideas. I set out to choose my structure from all the widely-implemented, human-readable, popular-enough-to-last-awhile formats that could hold a tree structure, which means it's XML.
The other part of my file format plan is that there should be very few limits and requirements on what can go into my data files. It sounds responsible to say that a clip must have a duration that's greater than zero, or that every video must have a width and height, but really: it doesn't matter to the file. The file doesn't care if it's incredibly degenerate, and we can't guarantee that the next tool used on the file will need any particular piece of data. So any guides or schemas for the data files will be purely to help direct data to the right places and format it in the standard way, never to require any data.
The clip description format
On disk are many files that contain: sequences of DV frames, AVI format clips of DV frames, audio files, single images, image sequences stored as directories of single images, etc. I refer to these as media files, each of which contains one clip, with a variable number of components (audio, video, left-eye stereo, etc).
The goals of the clip description format are to normalize all the intrinsic info about the data (duration, rate, dimensions) and to provide a container for all data that users and tools might ever produce regarding the data.
I'm sick of programs forgetting that a video image is
upper-field-first interlaced, or that one clip has square pixels and
another doesn't. Or if I know that a clip has a lead-in that's ugly,
but might be needed in a dissolve cut or time blur. Or if I watched
a clip and found 4 frames with dust on them. Or that the files with
I didn't really mean "in the media files", though. Some of the industry metadata systems like to keep the "essence" (the actual data) in the same file as the metadata, but for flexibility reasons, I want separate files. These files probably have the same name as their essence files plus ".desc" at the end (after any existing extensions). Advantages of keeping the metadata in its own XML files:
The big disadvantage of separate files is that it's harder to keep the desc files with their video files. Fortunately, file systems are very visible to the user, mistakes should be pretty easy to correct, and it will be possible to add some "go find my lost data file" features to the tools (which edit suites have already been doing for a long time with their EDL files that reference clip files).
The exception I have in mind for "one desc per media file" is the case of a clip stored as many image files. A standalone image should have a desc file like normal, but a directory of sequentially-numbered images should probably be able to get by with one desc file (for the same reason an AVI file with a bunch of frames-- and audio-- has only a single desc file).
I imagine eventually having a real database that can quickly do certain queries over all the desc files, but it'll always be a secondary source to the easy-to-handle text files. So if you've got tens of thousands of desc files and you're querying them all day long, talk to me about ways of speeding that up.
How do you find a piece of data such as the duration of a clip? And more importantly, where should you add a new piece? I deliberately didn't start some committees and figure out all 300 bits of data that everyone will need to store to be compliant. Instead, I (and other authors)
The EDL format
The show files contain a different style of information than most EDL formats, and like my clip format, they can contain a lot more information that any of the fixed-field specs.
Show files may become part of clip files. In favor: