| |||||||||||||
Improving ext4: bigalloc, inline data, and metadata checksumsImproving ext4: bigalloc, inline data, and metadata checksumsPosted Dec 1, 2011 3:17 UTC (Thu) by quotemstr (subscriber, #45331)In reply to: Improving ext4: bigalloc, inline data, and metadata checksums by rillian Parent article: Improving ext4: bigalloc, inline data, and metadata checksums
Maybe ogg's block-level checksums aren't such a good idea after all. Most likely, a few wrong bits won't affect the sound output much, and a 100ms skip sounds much worse than just playing a single wrong sample. Checksums make sense for things that must stay intact, but I don't think most multimedia benefits from this kind of robustness.
(Log in to post comments)
Improving ext4: bigalloc, inline data, and metadata checksums Posted Dec 1, 2011 10:07 UTC (Thu) by mpr22 (subscriber, #60784) [Link] A few wrong bits in a Vorbis stream seem likely to give you more than just "one wrong sample".
Improving ext4: bigalloc, inline data, and metadata checksums Posted Dec 1, 2011 18:25 UTC (Thu) by rillian (subscriber, #11344) [Link]
Indeed. A few corrupt bits in a compressed format can result in a whole block of nasty noise in the output.
The idea with the Ogg checksums was to protect the listener's ears (and possibly speakers) from corrupt output. It's also nice to have a built-in check for data corruption in your archives, which is working as designed here.
What you said is valid for video, because we're more tolerant of high frequency visual noise, and because the extra data dimensions and longer prediction intervals mean you can get more useful information from a corrupt frame than you do with audio. Making the checksum optional for the packet data is one of the things we'd do if we ever revised the Ogg format.
|
|||||||||||||