--verify flag
Closed this issue · 4 comments
Flac allows to verify the encoding via the -V, --verify flag.
Is this a feature worthwhile adding to reflac?
It seems to be an additional level of paranoia with the flac encoder, and my guess is that it might have been more useful in its early pre-1.0 stages of development. Mind, that decoding errors are already caught (flac, and thus reflac, will exit immediately if a file cannot be decoded successfully).
I have never known flac to encode a file incorrectly, although a little bit of safety might be harmless. If I do add it, I don't think it'd be worth being a command-line flag, but just be always-on.
Testing a few different albums, at most I see a couple seconds difference (flac --verify being slower). The speed difference seems to be acceptable, though I still wonder, do you know of documented cases where modern-day flac fails to encode a file correctly?
I'm also unsure, even if there are cases, that the flac->rf64->flac roundtrip this program does would exhibit the same problems.
Testing a few different albums, at most I see a couple seconds difference (
flac --verifybeing slower). The speed difference seems to be acceptable, though I still wonder, do you know of documented cases where modern-day flac fails to encode a file correctly?
I don't think I know any case where flac fails to encode, however in the README the usecases mention recompressing a very large library. I can see normal cases where terrabytes worth of data are being processed. Flac itself might not have a problem encoding but there might be a drive failure, or some other kind of mistake or error which would be caught by this flag. However I might be paranoid there.
May I suggest it be a flag anyway, however always on by default?
Flac itself might not have a problem encoding but there might be a drive failure, or some other kind of mistake or error which would be caught by this flag.
It is difficult to envision a scenario where flac actually returns an error code for reasons outside of flac's own control (ie, its own bugs). From what I read, --verify does an in-memory decoding of the FLAC encoded data to make sure it matches the input stream, it will not catch silent corruption introduced by a disk on write. If you want to be really secure here, use both a checksumed file system (eg, zfs or btrfs) and ECC memory; the file system is a lot easier to obtain and probably has the biggest gain compared to ECC memory that could be a very costly hardware upgrade.
I am still not opposed to this feature, but even my own anecdotal tests showing a couple seconds slower per album could add up to many hours of difference on very large worksets (terabytes you say? I can hardly imagine a collection that large...). It would be worthwhile if it actually secures the correct re-encoding of files, but I am not presently convinced it really accomplishes anything, especially given the roundtrip nature of the script.
Perhaps I just need input from an actual FLAC developer about this feature.