[Five]

Originally Posted by Beleaguered

Flac calculates the fingerprint as it doing the encoding and stores the md5 checksum in its metadata header. When you make an ffp it is simply retrieving that value (real quick). Shntool-md5 takes longer because it must decode the file and calculate the md5 of the decoded data.

This is correct... I like the extension .st5 but shntool-md5.txt is fine too so long as the same stuff is in the file. Same goes for the .ffp or ffp.txt extensions for FLAC fingerprints (I prefer .ffp). When you generate a .ffp with TLH or FLAC frontend, the output is simply copied from the headers, when you generate an .st5 the checksums are calculated on the spot from the audio data on the spot (and thus takes longer). The most tedious (and secure) thing to do is to create an .ffp, then an .st5, check that the two are the same (this verifies that the header checksum matches the audio), then you can even run the "test" function from FLAC frontend which also does the same thing (extracts the checksum from the header and compares a newly generated checksum from the audio data to this).

It is adequate to generate a .ffp (if there isn't one already) and drop the FLACs in FLAC frontend and run a test to make sure the data isn't corrupt.

So what you really need to do when you get a show is:

-run a test using FLAC frontend (or a batch file, etc )
-run a shntool len check (for SBEs, also to check the audio is 44.1kHz/16bit, etc.)
-have a peek at a couple of the files in a WAV editor like Audacity/Audition checking the fa and sa to see if the source looks suspicious (i.e. lossy-sourced).
-while you've got the files open in a WAV editor zoom in on the beginning and the end of the tracks to look for any TAO/SBE gaps printed into the audio that could not be detected by a shntool len check.
-generate a .ffp (if there isn't one already, works with FLAC only)
-generate a .st5 (manditory for SHN & APE, optional for FLAC)