[Five]

after briefly reading this thread, here's what I can tell you...

when a FLAC file is created, the ffp for that file is stored in the header at the time the audio is compressed.

creating a ffp merely copies this checksum to a .txt file (using FLAC frontend) or a .ffp (using TLH). the .ffp file is just like the .txt file, just with a different extension.

when a .ffp (or ffp.txt) file is verified using TLH, it takes the .ffp file and compares the checksum associated with each file with the checksum stored in the header. it doesn't actually look further than that. That's why it takes such a short time to do this function.

FLAC frontend can't verify .ffp files this way.

when you use the "test" function on FLAC frontend, it decompresses the audio to a temp file, generates a checksum and compares this with the checksum which was stored in the header at the time the file was created. TLH can also do this, using the "test encoded files" function.

okay, here's the tricky part:

when you use TLH (or shntool) to verify an .st5 file, TLH decompresses the audio to a temp file, generates fresh checksums and compares these with the checksums contained in the .st5 file and doesn't check the headers of the FLAC files at all.

also, when you fix a SBE, the file is decompressed, altered, then re-encoded to FLAC and therefore a fresh checksum is generated and inserted into the header.

so the error from flac frontend "MD5 signature mismatch" should also be reported from TLH when you use the "test encoded files" function, and it means that the checksums contained in the headers of those files don't match the checksums generated on the spot from the WAV audio decompressed to a temp file.

when you made the new .ffp it took all the checksums from the headers just like the seeder did, therefore they are the same.

then you make an .st5 and it shows the true checksums for the files, some of which have incorrect checksums stored in their headers at the original time of compression.

the files you fixed were re-encoded and new headers were written which you tested as being accurate.

so, to fully verify a FLAC file, you have to do a couple things:

1) check that the checksums contained in the headers match the checksums of the audio contained within. you can do this using either TLH "test encoded..." or FLAC frontend verify/test.

2) if there is a .ffp file, check that it matches what is contained in the headers using TLH "verify checksum" or by generating a fresh fingerprint using FLAC frontend and comparing by eye.

3) if there is a .st5 file, verify it using TLH "verify checksum file". If you want to do the same using only FLAC frontend, run a test to make sure the headers match the files, generate a ffp.txt, then compare the checksums by eye with the .st5 checksums.

is that confusing enough?

remember, I'm only on coffee #1...