To my knowledge, RIFF is comparable to the lowest levels of the QuickTime container format in that it’s made up of chunks with a tag and a size. Lots of file fo

To my knowledge, RIFF is comparable to the lowest levels of the QuickTime container format in that it’s made up of chunks with a tag and a size. Lots of file formats have done that back into the 1960s and probably even before, it’s one of the most basic ways to represent typed records in streams. (I think a lot of people forget that data processing started with fixed-sized records, and that streams and variable-sized records were innovations.) What the QuickTime format supports that makes it appropriate for representing tape data—and for receiving Emmy and Oscar awards, among others, for its classical uses—is provide a bunch of additional abstractions atop its low-level implementation to represent typed and subtyped streams of data that (accurately!) span time intervals using arbitrary timebases. One of the reasons some other formats are less appropriate is that they don’t have that separation between type and subtype (track and track media, in QuickTime terminology), don’t allow arbitrary tracks, don’t support media with different native timebases, etc. This means you can’t easily write code that’s agnostic of the sample representation and CODEC details. (This was my issue with Ogg a couple decades ago—it’s a playback format for finished artifacts, not a format for authoring and editing.) I figure instead of reinventing all of the stuff that’s already been done the past 30+ years for getting that sort of layering right, it’s much easier to just come up with some new track types and CODECs and fit them into an architecture that already supports most of what the problem requires.