Qudelix 5K
BIT-IDENTICAL ✓
SHA-256 · capture = source847af9e41aebc5684ce36909f8417ed22d65bb1909b6de05428f160fe32cd4a7
★ Same file, same hash as the JM6 Pro entry below.
The receipt registry
Every entry here is a receipt, not a review.
This is the public ledger behind the claim. Meringo is a music player that proves bit-perfect USB DAC playback: on a verified capture, it hashes every PCM byte it ships to the DAC and hashes the same file re-decoded on-device — matching SHA-256s mean nothing touched the bits. Each entry below names the DAC, the USB class, the wire format, the exact build, and the full hash. Nothing here is a testimonial. Every value is a real device readout, and every one can be recomputed from your own copy of the same file with software we don't control — the method is published in full.
The proof path is USB-Direct lossless, and we state its edges before you
ask: FLAC receipts can be independently certified against the file's own encoder signature;
ALAC lacks an embedded reference, so a healthy ALAC capture reads
INCONCLUSIVE rather than borrowing a verdict it can't earn.
The first six entries are the maintainer's own, published since June 2026. The registry is
open for yours — how to add your chain is below.
★ Two DACs, one hash
On 2026-08-01 the same 96 kHz / 24-bit FLAC was played through two physically
different DACs — a Qudelix 5K and a Jcally JM6 Pro,
different chipsets, different USB timing. Both captures came out 7,895,040 bytes and hashed
to the same SHA-256, 847af9e4…32cd4a7. That is what
reproducible means: the bytes are the bytes, whatever is plugged in.
The registry
Jcally JM6 Pro
BIT-IDENTICAL ✓
SHA-256 · capture = source847af9e41aebc5684ce36909f8417ed22d65bb1909b6de05428f160fe32cd4a7
★ Same file, same hash as the Qudelix 5K entry above.
Fosi DS2
BIT-IDENTICAL ✓
SHA-256 · capture = sourced7eb00c6837375ca1f74c95efc2cea78e02331f66e7111a36b383c3861912538
Full track — 53.55 MB of PCM captured on its way to the DAC.
Qudelix 5K
BIT-IDENTICAL ✓
SHA-256 · capture = sourcecb459147698b75fe2b890229e4c1c66fe5425b31489b2c54efc68d04da295adf
The hi-res run — 118.23 MB hashed on both sides.
Jcally JM6 Pro
BIT-IDENTICAL ✓
SHA-256 · capture = sourceb896aa7f8fd97b1084585669214bac23f2392a77a4b1144cecba8f05b71001fe
Fosi DS2
BIT-IDENTICAL ✓
SHA-256 · capture = sourcea8c143422d8b644569cc4a36ab54822b0dfd1a370327fa95d844d8f92195642d
Verified twice on the same setup — the capture path is deterministic across runs.
Add your chain
Any Meringo owner with a USB DAC can put an entry here. Three steps, about three minutes:
- Play a FLAC over USB-Direct — pick one that carries its encoder
signature (
metaflac --show-md5sumprints it; all-zeros means absent) if you want a certifiable receipt. - Arm Verified Capture in
Settings → Audio diagnosticsand let it run the verify pass. - Share the receipt from the Receipts list and email the text to support@meringo.app with the subject Receipt registry.
What gets published is the receipt as your device produced it: DAC descriptor, wire format, build, byte counts, hashes, verdict. The only personal thing a receipt carries is the track's file name — say the word and we'll redact it.
Every verdict is welcome. A NOT BIT-IDENTICAL or
INCONCLUSIVE receipt is not an embarrassment, it's a data point — the
registry doubles as a map of how real DACs behave, and a receipt names its own reason line.
New DAC models are the most valuable submissions of all. And if you ever produce a receipt
the published method cannot reproduce, that's a bug in the proof and
we want it more than any success.
What a listed entry proves — and what it doesn't
An entry is a published artifact, not a certification of the person who sent it. What makes it worth publishing is that it's checkable: anyone with the same pressing of the same file can recompute the hash with ffmpeg and compare, character for character. Two owners of the same DAC and the same album should collide on identical values — the more entries the registry holds, the harder an invented one is to hide.
The deeper boundary is the same one the method page names: the source half of a receipt is honest math you can reproduce; the capture half is a witness statement from the code that shipped the bytes. We publish both, and we'd rather name that line precisely than pretend it isn't there.