> I wouldn't expect all codecs to come with their own container format!
Huh? That seems totally wrong to me.
I wouldn't expect a codec to develop their own, unique, incompatible container format, and I would hope very much that they would not (!!), but it's a real mistake to develop a codec and not specify at least some sort of preferred container format.
Otherwise, people are going to do what is often done with FLAC: not put it into a container format and just treat the raw output from the codec as a distribution format. And then complain that the whole thing sucks because there's no support for multiple streams, metadata, lyrics, subtitles, album covers, cuesheets, whatever.
The way to avoid that is not to set users up for failure by releasing the bare codec without some sort of preferred container format that's used by default. If the FLAC encoder had always used OGG containers (or Matroska or Quicktime or AVI or whatever) by default there'd be a whole lot fewer bare FLAC files floating around, convincing everyone that "FLAC sucks because there's no metadata".
That said, there are some issues with container formats as they are frequently implemented, which tends to drive users towards not using them and just exchanging bare codec output: if you separate the user from the codec with an intermediate container layer, you can create a ton of frustration when users get files that they think they can use, based on the file extension, but then get an error because they don't have the codec du jour... but there was no obvious way to tell that when they were looking at the file. The codec used is far more important to the average user than the type of container format, most of the time. (And yeah the ideal solution would be for filesystems to stop sucking so badly at metadata; MacOS and HFS was better at this stuff in 1996 than most modern computers are today -- at least it had the idea of both a file "type" and its "creator" as distinct things from the extension.) But in our world, the result is some containers being perceived as "unreliable" or "fussy" because they're used for a diversity of codecs that not all implementations have.
I don't have a great solution to that second problem, but at the very least I think that the file extension should follow the codec combination used inside the file, and not the container format. E.g. an AVI container with AVC compressed video inside shouldn't have the same file extension as an AVI container with Sorenson Video inside it; those two things are not interchangeable as far as a user is concerned. Since file extensions are the only metadata users get, they need to somehow represent the combination of both codec+container.
Huh? That seems totally wrong to me.
I wouldn't expect a codec to develop their own, unique, incompatible container format, and I would hope very much that they would not (!!), but it's a real mistake to develop a codec and not specify at least some sort of preferred container format.
Otherwise, people are going to do what is often done with FLAC: not put it into a container format and just treat the raw output from the codec as a distribution format. And then complain that the whole thing sucks because there's no support for multiple streams, metadata, lyrics, subtitles, album covers, cuesheets, whatever.
The way to avoid that is not to set users up for failure by releasing the bare codec without some sort of preferred container format that's used by default. If the FLAC encoder had always used OGG containers (or Matroska or Quicktime or AVI or whatever) by default there'd be a whole lot fewer bare FLAC files floating around, convincing everyone that "FLAC sucks because there's no metadata".
That said, there are some issues with container formats as they are frequently implemented, which tends to drive users towards not using them and just exchanging bare codec output: if you separate the user from the codec with an intermediate container layer, you can create a ton of frustration when users get files that they think they can use, based on the file extension, but then get an error because they don't have the codec du jour... but there was no obvious way to tell that when they were looking at the file. The codec used is far more important to the average user than the type of container format, most of the time. (And yeah the ideal solution would be for filesystems to stop sucking so badly at metadata; MacOS and HFS was better at this stuff in 1996 than most modern computers are today -- at least it had the idea of both a file "type" and its "creator" as distinct things from the extension.) But in our world, the result is some containers being perceived as "unreliable" or "fussy" because they're used for a diversity of codecs that not all implementations have.
I don't have a great solution to that second problem, but at the very least I think that the file extension should follow the codec combination used inside the file, and not the container format. E.g. an AVI container with AVC compressed video inside shouldn't have the same file extension as an AVI container with Sorenson Video inside it; those two things are not interchangeable as far as a user is concerned. Since file extensions are the only metadata users get, they need to somehow represent the combination of both codec+container.
reply