What the verifier checks
The bounded parser distinguishes predecessor MHL 1.0 records from ASC MHL 2.0 records, preserves creation and process metadata, validates safe relative paths and digest syntax, and reconciles an optional ASC chain file. Selected generations are ordered by chain sequence when available, then by creation date and filename. Each path is resolved to its latest supported eligible record; ASC hashes marked failed are findings and are never accepted as baselines.
Streaming local hashes and folder reconciliation
MD5, SHA-1, legacy XXH64/XXH64BE, and ASC XXH64 use incremental local hashing so large media files are not assembled into one browser buffer. Exact paths and declared sizes are checked before reporting verified, mismatch, missing, case-only, or extra-file evidence. C4, XXH3, XXH128, and legacy XXH32 records are inventoried and syntax-checked, but this implementation does not claim to verify them.
ASC history and chain evidence
An ASC MHL history can distribute relevant file records across multiple manifest generations. Choosing the chain file makes ordering and absent-generation gaps visible. This page does not calculate the C4 digest of manifest files, directory content/structure hashes, root hashes, or nested-history references; their declared values remain documentary evidence for a full ASC MHL implementation.
Verification boundary
This is a local audit aid, not an ASC MHL conforming implementation or chain-of-custody certificate. Browser folder selection does not expose empty directories, filesystem identity, permissions, or all timestamp semantics. The verifier does not append a verification generation, validate against the full XSD, apply ignore rules to reconstruct an unseen filesystem, recursively follow nested histories, validate C4 chain digests, or prove source/destination copy operations. For critical DIT and preservation workflows, retain the originals and verify with the current ASC reference implementation or an approved production tool.
Frequently asked questions
Why do I need to select every manifest generation?
The effective history may depend on an earlier original hash, a rename, or a later verification. A chain file lists generations but does not contain their file records, so missing generations are reported rather than fetched.
Does the verifier upload camera originals?
No. The browser reads selected files only to compute supported hashes. It makes no media requests and does not send file content, names, paths, or reports to ToolQuill.
Why is a C4-only record unsupported?
C4 uses SHA-512 with a specified Base58 representation. This page deliberately avoids buffering very large media merely to use the browser's non-streaming Web Crypto digest. Use the ASC reference implementation for full algorithm coverage.
What is an extra file?
It is a selected media file that is not present in the effective records resolved from the supplied history. ASC support directories and selected MHL manifests are excluded from this comparison.
Primary format references
The implementation follows the ASC MHL 1.0 specification repository, its reference implementation and XSD, and the predecessor format examples and project resources at MediaHashList.org.
Validate a BagIt package · Audit an OTIO timeline · Browse video tools