Re:FLAC – Format overview
by giantrobot on Monday September 05, 2022 @06:22PM
(#32730198)
Checksumming in media container formats is tricky because different media formats have different features. So each codec and combination of track/codec needs its own special case on how and when a checksum is performed.
In the case of FLAC the situation is straight forward, you've got uncompressed audio and a codec that's performing lossless compression. You want to know what was encoded losslessly matches the input. It's no different from a checksum in a compressed archive.
It's less straightforward with a lossy compressed codec. Are we just checksumming the compressed bitstream? Where in the handling of the bitstream are we doing the checksum? In MOV/MP4 a media track can have arbitrary start and end times. It makes doing in/out cuts super fast. But when it comes to checksumming the track do we checksum all the samples in the track or only the samples that will play? If a file if flattened and a track has all the samples out of the playable region discarded do we now have to recalculate the checksum?
Media tracks can also have header tags that indicate stuff like display color space, displayed size, or even track level metadata. Are we checksumming the track bitstream and important track headers? A video needing to render in a particular color space will be materially affected if it's bitstream is preserved but color space tags are dropped.
If you want to hack in checksums for track bitstreams both MOV/MP4 and Matroska can accept arbitrary tags for tracks so you can just write a checksum to a track header tag if you really want to. You really need a table of rules for doing the checksum otherwise it's a wasted effort.
In the case of FLAC the situation is straight forward, you've got uncompressed audio and a codec that's performing lossless compression. You want to know what was encoded losslessly matches the input. It's no different from a checksum in a compressed archive.
It's less straightforward with a lossy compressed codec. Are we just checksumming the compressed bitstream? Where in the handling of the bitstream are we doing the checksum? In MOV/MP4 a media track can have arbitrary start and end times. It makes doing in/out cuts super fast. But when it comes to checksumming the track do we checksum all the samples in the track or only the samples that will play? If a file if flattened and a track has all the samples out of the playable region discarded do we now have to recalculate the checksum?
Media tracks can also have header tags that indicate stuff like display color space, displayed size, or even track level metadata. Are we checksumming the track bitstream and important track headers? A video needing to render in a particular color space will be materially affected if it's bitstream is preserved but color space tags are dropped.
If you want to hack in checksums for track bitstreams both MOV/MP4 and Matroska can accept arbitrary tags for tracks so you can just write a checksum to a track header tag if you really want to. You really need a table of rules for doing the checksum otherwise it's a wasted effort.