4 ms·
The problem with AAC is in the container format, as Marco explains in his podcast: While some important metadata like chapter marks which a podcast player might
by skrause 10y ago
The problem with AAC is in the container format, as Marco explains in his podcast: While some important metadata like chapter marks which a podcast player might want to display are within the first KB in an MP3 file, this same information is interleaved somewhere in the stream in AAC.
Which means that you can't have all features when streaming an AAC file, in a time when streaming podcasts is getting more popular every day. You first have to download the whole file before you can display e.g. chapter information.
Of course you could just embed that information in the RSS feed, but you could do the same with jump tables for VBR MP3s. So AAC does not solve all your problems, you just get a different set of problems.
- archagon 10y agoWeren't they talking about .mov files at the time?
- jsmthrowaway 10y agoThose are all problems with a specific, objectively crappy container, as you've noted. There are many alternative containers and no reason the podcasting community couldn't come up with its own, such as by extending Matroska. This obviously creates separate problems, but I'd like to see the podcasting community start to shape its own destiny a bit rather than expect others to innovate for them or kludge older formats to do things they weren't supposed to do. Why not a podcasting specific container that handles streaming and fixed cases, includes support for all the novel stuff podcasters want to do, and so on? Container development is one of the easier parts of multimedia, and there's too much thinking around a specific codec being tied to a specific container (just like your comment). Legacy support is of course the big elephant in the room, but I'd venture a well-founded guess that the average podcast listener is listening on a device that supports apps. (Maybe I'm wrong.) I can't think of a single good container format. They're all rubbish. Even Matroska is arcane and very poorly documented, and suffers from the end goals and types of media it is used for being encoded in the design. Containers are a giant space in which to innovate and have been that way for years. Unfortunately, open source multimedia development is largely tied up by a certain group of people with a certain background and very specific use cases in mind. That context from the podcast would have been awesome in this piece. Why wasn't it there?
- TD-Linux 10y agoOne of the OP's requirements is that this work in iTunes, which precludes making a new container format. I also think existing containers would meet the requirements - for example, Ogg meets the requirement of both being storable and easily streamable. Also, the Matroska spec is being updated to a new version, and being standardized in the IETF CELLAR working group. I'd highly suggest participating if you'd like to help improve both the format and the specification.
- okket 10y agoCodec Encoding for LossLess Archiving and Realtime transmission (cellar) documents: https://datatracker.ietf.org/wg/cellar/documents/ https://datatracker.ietf.org/wg/cellar/documents/ Matroska draft: https://datatracker.ietf.org/doc/draft-lhomme-cellar-matroska/ https://datatracker.ietf.org/doc/draft-lhomme-cellar-matrosk...
- anonova 10y agoNo, this is incorrect. It's up to the implementation of the muxer to determine where index information goes, which is typically at the end of the file. This is simply because writing a file is a single pass operation, and you don't know the contents of the atom until you've gone through the all the data for each stream. Many muxers provide an option to place it at the beginning of the file by adding padding and overwriting it afterward, which solves the progressive streaming problem.