3 ms·

Yep, that's a smart feature. It had actually uncovered bugs in FFmpeg's FLAC encoder multiple times. [1][2] (why they didn't just use the reference implementati

Yep, that's a smart feature. It had actually uncovered bugs in FFmpeg's FLAC encoder multiple times. [1][2] (why they didn't just use the reference implementation is beyond me...) 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 https://trac.ffmpeg.org/ticket/4628 [2] https://trac.ffmpeg.org/ticket/4421 https://trac.ffmpeg.org/ticket/4421

mustache_kimono 4y ago
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 http://underpop.online.fr/f/ffmpeg/help/hash.htm.gz [1]: Language corrected. See comment.
- aaaaaaaaaaab 4y ago
  >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.
  - crtasm 4y ago
    > It doesn't make sense to decode the data you've just encoded. Unless you're also writing to disk and reading it back before decoding - I'm not sure which tool you're referring to.

mustache_kimono 4y ago

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 http://underpop.online.fr/f/ffmpeg/help/hash.htm.gz [1]: Language corrected. See comment.

aaaaaaaaaaab 4y ago
>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.
- crtasm 4y ago
  > It doesn't make sense to decode the data you've just encoded. Unless you're also writing to disk and reading it back before decoding - I'm not sure which tool you're referring to.