J.B. Nicholson-Owens:> I'm not sure what you're asking forI have a huge archive of FLAC files and want auto- matically to check the integrity thereof, so as if some file be reported as corrupted I can restore it from a mirror backup.> I should have mentioned before that apparently the > MD5 hash is computed on the uncompressed raw sam- > ple data and the easiest way to check the FLAC > file is with > > flac --verify audio.flac >This doesn't work, and the official FLAC focumenta- tion says this option is only applicable to WAV files: -V, --verify Verify the encoding process. With this option, flac will create a parallel decoder that decodes the output of the encoder and compares the result against the original. It will abort immediately with an error if a mismatch occurs. -V increases the total encoding time but is guaranteed to catch any unforseen bug in the encoding process. It seems to have nothing to do with the MD5 hash. The procedure you have described in your previous reply is quite complicated for an automatic check- ing. Why does FLAC calculate MD5 on the RAW uncom- pressed data? If it were using compressed data instead the checking wouldn't require decompression and would be quicker: just calculate the hash on the binary file and compare it against the stored value... Anton
flac -t audio.flac -d, --decodeDecode (flac encodes by default). flac will exit with an exit code of 1 (and print a message, even in silent mode) if there were any errors during decoding, including when the MD5 checksum does not match the decoded output. Otherwise the exit code will be 0. -t, --test Test (same as -d except no decoded file is written). The exit codes are the same as in decode mode. On Sun, Apr 24, 2011 at 5:43 AM, Anton Shepelev <anton.txt at gmail.com> wrote:> J.B. Nicholson-Owens: > > > I'm not sure what you're asking for > > I have a huge archive of FLAC files and want auto- > matically to check the integrity thereof, so as if > some file be reported as corrupted I can restore it > from a mirror backup. > > > I should have mentioned before that apparently the > > MD5 hash is computed on the uncompressed raw sam- > > ple data and the easiest way to check the FLAC > > file is with > > > > flac --verify audio.flac > > > > This doesn't work, and the official FLAC focumenta- > tion says this option is only applicable to WAV > files: > > -V, --verify > Verify the encoding process. With this > option, flac will create a parallel > decoder that decodes the output of the > encoder and compares the result against > the original. It will abort immediately > with an error if a mismatch occurs. -V > increases the total encoding time but is > guaranteed to catch any unforseen bug in > the encoding process. > > It seems to have nothing to do with the MD5 hash. > > The procedure you have described in your previous > reply is quite complicated for an automatic check- > ing. Why does FLAC calculate MD5 on the RAW uncom- > pressed data? If it were using compressed data > instead the checking wouldn't require decompression > and would be quicker: just calculate the hash on the > binary file and compare it against the stored > value... > > Anton > _______________________________________________ > Flac mailing list > Flac at xiph.org > http://lists.xiph.org/mailman/listinfo/flac >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac/attachments/20110424/f033c2b0/attachment.htm
On Apr 24, 2011, at 02:43, Anton Shepelev wrote:> The procedure you have described in your previous > reply is quite complicated for an automatic check- > ing. Why does FLAC calculate MD5 on the RAW uncom- > pressed data? If it were using compressed data > instead the checking wouldn't require decompression > and would be quicker: just calculate the hash on the > binary file and compare it against the stored > value...An MD5 on the compressed data would be different for every compression level, and potentially for every revision of the libFLAC coder. In this case, the quicker solution is not the best. There is only one MD5 hash for the uncompressed data, and it proves that you got back the original data without any loss, which is the whole point of FLAC. In fact, the way it is implemented provides two features: It ensures that your FLAC file has not been corrupted, and it also ensures that you actually get back the original data without any loss. p.s. scott has already provided the -t solution. Brian Willoughby Sound Consulting
I thank everybody for their replies. Brian Willoughby:> An MD5 on the compressed data would be different > for every compression level, and potentially for > every revision of the libFLAC coder. In this > case, the quicker solution is not the best.That's what I wanted to hear. To test a file's integrity is one thing, and to test the correctness of the compression by ensuring reversibility is another. Anton