> I don’t understand the use case. You go through the trouble of generating checksums when copying videos, but don’t want to regenerate the checksums when modifying the metadata?
Appreciate the Q, but I suppose I really don't understand it. Could be the hour?
I don't want to regenerate checksums once I know the underlying bitstream checksums are correct. I want to know the audio/video/whatever is the same as the day I received it, and I want to perform the exact same check to confirm. If I change the metadata, and I need to regenerate a checksum, I don't know that.
> If you are this concerned about data corruption why not check the metadata also?
One should of course. Please use ZFS, etc. There is perhaps no greater ZFS fan than me. See: https://github.com/kimono-koans/httm
But now imagine rewriting a stream to a different container. For instance, MP4 to MKV, or ALAC to FLAC. Wouldn't it be nice to know the bitstreams are the same?
I notice that LLM releases will include md5/sha256 for the binary data, while excluding the json metadata. I really wanted MKV to have this functionality.
Edit: I see the metadata benefit in the README, just curious if there's some additionally pessimistic perspective.
This allows you to change metadata or the container entirely, while still being able to check if e.g. the H.264 video stream is okay.
I've always thought it would be simpler if we used different files for the stream and the meta data, but that's probably just because I never looked more closely into it.
--only=<ONLY>
hash the an input file container's first audio or video stream only, if available. dano will fall back to default behavior, if no stream is available. [possible values: audio, video]