Verify it yourself

Don't trust us either. Check the math.

A Meringo receipt makes a physical claim: every PCM byte that left the USB isochronous pipe for your DAC is identical to the file's own decoded audio. The receipt carries two SHA-256 hashes — one over what shipped, one over what the file decodes to. A claim like that is only worth something if you can check it with software we don't control. This page defines the byte stream precisely enough that you can recompute the hash on your own machine, from your own copy of the file, with tools that share no code with Meringo.

What a shared receipt carries

Long-press any entry in Settings → Audio diagnostics → Receipts and share it. The plain-text export includes these fields:

Format

Codec · sample rate · bit depth. The bit depth is the width of the USB slot the DAC opened for the session — usually the file's own depth, but see the 16→24 rule below.

Capture bytes

How many bytes actually shipped to the DAC and were hashed.

Source bytes

How many bytes of the re-decoded file were hashed against them. Equal to Capture bytes on a full capture.

Capture SHA-256

Hash over every byte the iso pipe shipped, in shipping order.

Source SHA-256

Hash over the same file re-decoded on-device and laid out in the identical byte format. On a BIT-IDENTICAL ✓ receipt the two hashes are the same value — and that value is what you can recompute here.

The byte stream, exactly

1. Decode the file to raw PCM. No resampling, no gain, no dither — the bit-perfect path does none of these, by definition.
2. Lay the samples out little-endian at the receipt's bit depth, channels interleaved (left, right, left, right…). At the file's native width this is simply the decoder's output, untouched.
3. One documented exception: a 16-bit file played into a 24-bit slot (some DACs only open 3-byte slots at certain rates). Each 16-bit sample becomes three bytes — 0x00, low byte, high byte — the sample value shifted left 8 bits over a zeroed pad. The receipt's Format line reads 24-bit in that case.
4. SHA-256 over the first Capture bytes of that stream. A capture that covered the whole track hashes the whole stream.

Recompute it with ffmpeg

Any recent ffmpeg build reproduces the layout directly. Receipt says 16-bit:

ffmpeg -i track.flac -f s16le - | sha256sum

Receipt says 24-bit — one command covers both a native 24-bit file and a 16-bit file in a 24-bit slot, because ffmpeg's own 16→24 conversion is the same zero-padded shift:

ffmpeg -i track.flac -f s24le - | sha256sum

A 32-bit slot is -f s32le. On Windows, write the raw stream to a file and hash it with PowerShell:

ffmpeg -i track.flac -f s16le pcm.raw
Get-FileHash pcm.raw -Algorithm SHA256

(PowerShell prints the digest in uppercase; the receipt is lowercase — compare case-insensitively.) Don't want to trust ffmpeg either? Xiph's own reference decoder produces the identical stream for a FLAC at its native width — a wholly separate decoder lineage:

flac -d -c --force-raw-format --endian=little --sign=signed track.flac | sha256sum

For a PARTIAL ◔ receipt, hash only the prefix the capture covered (the receipt's Source bytes count):

ffmpeg -i track.flac -f s16le - | head -c <source bytes> | sha256sum

The digest must equal the receipt's hashes, character for character. This works for anything lossless that ffmpeg can decode — FLAC, ALAC, WAV, AIFF.

Or run the checker script

meringo-verify.py is a single file — Python 3 plus your own ffmpeg install, nothing else. It picks the right layout from the receipt's bit depth, refuses the combinations that aren't bit-perfect routes, handles partial receipts, and prints MATCH or NO MATCH against the receipt's hash. It deliberately shares zero code with Meringo, and it's public domain (CC0) — short on purpose, so you can read it before you run it.

$ python meringo-verify.py track.flac --bit-depth 24 --expect 759dd46d…
  file         : track.flac
  layout       : 24-bit little-endian, channels interleaved
                 (16-bit source, zero-padded low byte)
  bytes hashed : 1,481,754 (of 1,481,754 decoded)
  SHA-256      : 759dd46d1a0d954bff9a04595cf8a29e…
  receipt says : 759dd46d1a0d954bff9a04595cf8a29e…
  VERDICT      : MATCH -- the receipt's hash is reproducible
                 outside Meringo, from your copy of the file

Cross-check the file itself

Every FLAC carries an MD5 of its own decoded audio, written by whatever encoder created it — long before any receipt existed. Compare the file's embedded signature against an independent decode at the file's native width:

# the signature the encoder wrote into the file
metaflac --show-md5sum track.flac
# an independent decode, hashed the same way (16-bit file shown)
ffmpeg -i track.flac -f s16le - | md5sum

If those agree, the PCM you just hashed is certified by the file's own encoder — a third implementation that has never heard of Meringo. The in-app verify pass holds itself to the same standard: on FLAC it recomputes this embedded signature while it decodes, and only a decode certified that way is allowed to condemn a capture as NOT BIT-IDENTICAL ✗.

What this proves — and what it can't

If you find a receipt this method can't reproduce, that's a bug in the proof and we want it: support@meringo.app.