Checksums and fingerprints
What FFP, MD5 and ST5 prove, and when Trellis checks them.
Most shows arrive with a checksum file. Trellis reads it and matches the entries to your tracks.
The formats
FFP is the MD5 that FLAC keeps in its own header, computed over the decoded audio. Retagging or renaming never changes it, and it reads back instantly.
MD5 hashes the whole file, tags included. Any tag edit changes it, including Write Tags to Files.
ST5 is shntool’s checksum, which should hold the same value as an FFP.
When each is checked
In the Add Recordings queue, FFP and ST5 are verified as the folder is read. MD5 entries are parsed and matched, and their tracks sit at awaiting deep check until you press Verify MD5 now on the Fingerprints tab, which reads every byte of every file.
Confirming the ingest verifies every checksum file that came with the show against the copied audio, MD5 included. A count of failures comes back with the result.
Where the answer shows up
The Fingerprints tab gives a line per track: verified, MISMATCH, awaiting deep check, or no checksum listed. Failures also show in the row’s concerns line.
Once a show is in the library, its Checksums pane reads Match, Mismatch or Unverified per track. Re-validate re-checks the files on disk, and picks up any checksum file in the folder that was never read.
Matching a list to your tracks
Entries match on filename, ignoring case. Leftover entries are reported as listed files that are not present, and tracks with no entry as having none. With no filenames at all, Trellis matches in file order, and only if the counts are equal.
Last reviewed