Re:FLAC – Format overview
by mustache_kimono on Monday September 05, 2022 @05:11PM
(#32729531)
Agreed. FYI, ffmpeg's hash testing format [0], and therefore my utility dano, allows the use of CRC32, etc., though.
> But I'm afraid we'll have to live with this shortcoming forever now ¯\_(ツ)_/¯
I don't believe there is a fundamental reason why a later version of FLAC couldn't/wouldn't allow different algos as I think the raw decoded bitstream is checksum-ed and is just stored as a FLAC tag[1]. So they could just version that tag.
[0]: http://underpop.online.fr/f/ffmpeg/help/hash.htm.gz [1]: Language corrected. See comment.
Re:FLAC – Format overview
by aaaaaaaaaaab on Monday September 05, 2022 @05:23PM
(#32729660)
>I think the file is decoded and then checksum-ed and the checksum is just stored as a FLAC tag.
Sure, it's just metadata. It's just about backwards compatibility.
By the way, the checksum is calculated on the raw data fed into the encoder. It doesn't make sense to decode the data you've just encoded.
But I have one nitpick with FLAC in this regard: they chose MD5 as the checksum instead of something sensible like CRC32/CRC64... It makes no sense, because we're not doing cryptography here - we're doing an integrity check. Moreover it makes a parallelized FLAC encoder somewhat problematic to implement, as there's always going to be a serial bottleneck at the end for computing the MD5 hash. CRC on the other hand could easily be parallelized. But I'm afraid we'll have to live with this shortcoming forever now ¯\_(ツ)_/¯
[1] https://trac.ffmpeg.org/ticket/4628
[2] https://trac.ffmpeg.org/ticket/4421