Thought it was worth posting Monty's response, since the original anti-Ogg piece got a lot of discussion here a few months ago: https://hackernews.hn/item?id=1164161
He does a very good job of bringing the nerd rage but unfortunately reality doesn't back him up — even his own implementation doesn't support his design choices very well and the ones in larger systems basically ignore them.
Seeking is frequently broken, especially wherever OGG support has been added to a larger system as a plugin like with Quicktime or ffdshow. FLAC is much worse on this.
You can't actually use any non-Xiph codecs in an OGG container in the real world (except through the OGM hack that they repudiate), because they don't document any of it and nobody tests against it. You won't even get sensible errors. It's worse if they implement OGG support by just linking with liboggplay (the path of least resistance), so the container is implemented separately bundled with only its own codecs.
You can't actually use any non-Xiph codecs in an Ogg container in the real world [...] because they don't document any of it
He covers this in the article. If you want to say the the documentation is lacking, just say that, and they'll explain that they don't want to encourage mixing of open and non-open codecs. If you want to focus on the can't actually use non-Xiph codecs in an OGG container side, then you'd have to explain how Dirac and Flac managed to be put in the container without any change to Ogg.
One is a (unfounded?) criticism of the technology or API of Ogg, the other is criticism of a Xiph policy decision to promote open codecs. Don't just throw stuff at the wall to see what sticks.
Also, if seeking is broken in Quicktime for both Ogg and Flac, two containers with very different approaches, maybe blaming Ogg is illogical? There's no obvious reason to even mention Flac as, despite coming under the Xiph umbrella once it was a popular free codec, it was developed independently.
My point was not that using alternate codecs was technically impossible, but that it was de facto infeasible — nobody does it (because you'd only want to use it if you already wanted to use a free codec for it's freedom), as such nobody tests against it, so it won't be well supported by implementations, not even to necessarily give you a 'codec not found' error message.
You're right that OGG and native Flac are different containers, with differently stupid approaches (aiming too high and too low, respectively). The later Flac formats do specify OGG's broken metadata system, one of several reasons that nobody ever distributes Flac files with any internal metadata. I've never seen a Flac-in-OGG file in the wild, but I imagine that seeking is at least as broken there.
Seeking in Quicktime works just fine for all manner of esoteric codecs and containers — the problem is with the FOSS stuff where they decided that they'd do something inventive, and ended up with something pointlessly different — enough to make it annoying to integrate into any existing system — and no better than what everyone else does.
Sometimes what scratches your own itch and is fun to implement is no good for anyone else to actually use.
Quicktime works just fine for all manner of esoteric codecs and containers — the problem is with the FOSS stuff where they decided that they'd do something inventive, and ended up with something pointlessly different
So it works with all manner of esoteric stuff as long as it's not inventive, or different? That's a very limited definition of esoteric. And I've heard enough complaining about Quicktime over the years to not automatically give it the benefit of the doubt.
People have indeed put many things (some strange) into the Ogg format. I was once contracted to build MIDI + Vorbis support and I added a mapping for MIDI in Ogg fairly easily.
Granted, I was heavily involved with Xiph, but I am not Monty. It took a little digging and one or two questions I'm sure, but it wasn't rocket science.
> Seeking is frequently broken, especially wherever OGG support has been added to a larger system as a plugin like with Quicktime or ffdshow.
Surely, that's not really connected to the container design. If it's broken in the implementation, or in a plugin, that doesn't say much about the specification (unless you can prove everyone makes the same mistake because of something being underspecified).
You might say that everyone else who tries out your artifact is a moron if they can't use it correctly. They would just say that you're a terrible designer with no concern for usability. Even the parts that are well-specified don't line up with how everyone else thinks about the problem space.
Not sure what does "how everyone else thinks about the problem space" have to do with a description of an algorithm / data structure. You either implement it correctly, or you don't. It doesn't matter what other people think about it. Many clever algorithms are good, exactly because they don't line up with how you normally think about the problem space.
Why do you have to like the solution to implement it correctly?
Because it's weird in ways that provide no real benefit except towards the gratification of the designer for having done something novel, and uses those novelties as an excuse to willfully leave out the data that's normally used for that.
You do need to understand it to implement it correctly (or rather, as correctly as its design will allow you to), but there's a naive implementation right within grasp — so the people implementing it in a larger playback system will do that because they already have full support for everything else and aren't about to refactor everything for your fanciful shit. They just want to tick a checkbox on a feature list that their real users don't really care about.
Firefox is the only place I've seen it work reliably — but that's because they link directly and exclusively with liboggplay. They don't support any other codecs or containers (save for raw RIFF-encoded audio (WAV)), so there's no other model to be mismatched with.
This is awesome — finally someone released an implementation that's more reliable than liboggplay instead of just doing the minimum necessary to get basic playback. I guess when you won't support other containers (because noobs would think you supported other codecs (which you refuse to do on ideological grounds)), you have a really strong incentive to make OGG actually work.
Now to get everyone else using your implementation… :)
Sentence-by-sentence rebuttals are not very effective. And they're never the best you can do. Why are you wasting my time nitpicking on 'legend tells us'? It's silly to tell me I needn't bother with the original - and then take me in excruciating detail through it.
It's not explicit in the original or explained well in this rebuttal but the "legend tells us" is basically a way for the original author to call the current author a liar without actually coming out and saying so.
The line after that phrase is about Ogg being designed for Video codecs, something he clearly doesn't believe as later in the same document he suggests it was originally only intended for Vorbis audio.
See footnote 26 and the section that references it in the Monty document for a counter to this popular misconception.
You're right that those points are valid (as are the rest). Nits don't happen because some people like to dawdle. They happen because there's a lot of valid points to make. Which makes it particularly important to spend time finding the right ordering for them!
(and to prune the ones that don't flow. Which would you prefer, that 10% read everything or that 75% read the 10 most important points you want to make?)
