How to Verify Your Extraction Is Actually Lossless

You ran the extraction. The file’s sitting in your library labeled FLAC, DSF, or M4A/MKA with atmos. But how do you actually know it’s a bit-perfect copy of what was on the disc? Not “sounds fine to me” but actually, verifiably, provably identical to the source. This road is what led me to developing LExt, and why I ended up re-ripping my entire library that was originally ripped with DVD-Audio Extractor.

Most people never ask this question. They should. Dropped frames, silent read errors, added silence, and partial decrypts don’t announce themselves. A bad extraction usually plays back just fine — until you A/B it against the source, or until a click three minutes into track 7 tells you something went wrong five extractions ago and you never noticed.

This post covers how to actually confirm a lossless extraction is lossless, disc type by disc type, using free tools.

Why “It Plays Fine” Isn’t Proof

Lossless compression (FLAC, MKA, TrueHD, DTS-HD MA) means no data is thrown away during encoding. It says nothing about whether the data going into the encoder was read correctly off the disc in the first place. Two separate failure points exist, and they get conflated constantly:

Read errors at the disc level. Scratched CDs, bad Blu-ray sectors, drive firmware quirks, or a laser struggling with a scratched SACD layer can all produce silently substituted or interpolated data. The drive doesn’t always throw an error — some drives just return their best guess.

Encoding errors. Rare with modern tools, but interrupted processes, corrupted temp files, or running out of disk mid-extraction can produce a file that opens and plays but isn’t what you think it is.

A corrupted or error-concealed file will often play back without any audible glitch, especially through casual listening. The only way to know for sure is to check.

Method 1: MD5/SHA Checksums (Blu-ray, DVD-Audio, MKV)

There’s no AccurateRip-style community database for SACD, Blu-ray audio, or DVD-Audio extraction — the source files are too varied and the discs too numerous. Instead, the useful check is internal consistency: does the audio stream you extracted match a checksum you can independently confirm, and does re-extracting the same disc twice produce identical output?

The two-pass test:

1. Extract the audio track once. Generate a checksum:
   • macOS/Linux Terminal: shasum -a 256 Hotel-California.mka
   • Windows (PowerShell): Get-FileHash Hotel-California.mka -Algorithm SHA256
2. Eject the disc, reinsert it, and extract the same track again to a different filename.
3. Checksum the second file the same way.
4. Compare. Identical hashes mean your drive read the disc identically both times — strong evidence there’s no read-error variance happening.

This doesn’t prove the extraction matches the original studio master — nothing outside the label can prove that. What it proves is that your extraction is deterministic and repeatable, which rules out the most common failure mode: a drive silently mangling a few sectors on one pass.

If you maintain a library long-term, keep the checksums alongside the files (a simple .sha256 sidecar file per album) so you can periodically re-verify that nothing has degraded in storage — bit rot on old spinning drives is real, and checksums are the only way you’d catch it.

Comparing directly against the source (not just against yourself)

The two-pass test above proves your drive read the disc consistently. It doesn’t prove the extraction logic — the step where audio gets pulled out of the disc structure and written to a file — didn’t introduce an error of its own. A tool could consistently make the same mistake every time (wrong stream mapped, a few frames trimmed at a splice point) and the two-pass test would never catch it, because it’s just comparing the tool against itself.

To actually check against the source, you compare your extracted file against a second copy pulled by a completely different tool. This sounds intimidating but it’s really just four steps. You’ll only need to do this once or twice, ever — to confirm a drive and workflow you trust, not on every disc.

What you’ll need first:

• ffmpeg — a free command-line tool that can pull audio streams directly off a disc image. Install it with brew install ffmpeg on a Mac (via Homebrew), or on Windows, run winget install ffmpeg in PowerShell (or download it from ffmpeg.org if winget isn’t available).
• A way to open a terminal: on Mac, open the Terminal app (search for it with Spotlight). On Windows, search for PowerShell in the Start menu.

Step 1 — Make a raw copy of the disc.

Before extracting anything, make an exact copy of the disc’s file structure — not the audio file, the whole disc. For Blu-ray or DVD-Audio, this means creating an ISO (a single file that’s an exact image of everything on the disc). Most disc-burning or ripping utilities have a “create ISO” or “backup disc” option — this is the same kind of image you’d use to burn a copy of the disc later. Set this ISO aside; it’s now your untouched reference copy, separate from whatever Lossless Extract or any other tool does with it.

Step 2 — Pull the same audio track a second way, using a different tool.

The goal here is to grab the identical audio stream using a different program than the one you used for your main extraction, so any mistake specific to one tool doesn’t get hidden.

Open your ISO in a media info program like MediaInfo or VLC first and note two things: the name of the specific track file inside the disc (for Blu-ray this is usually a .mpls playlist file, something like 00001.mpls), and which audio track number you want (usually track 0 if there’s only one).

Then open your terminal, navigate to the folder with your ISO (type cd followed by dragging the folder into the terminal window, then hit Enter), and run:

ffmpeg -i 00001.mpls -map 0:a:0 -c copy reference.mka

A quick breakdown of what this does, so it’s not a magic spell:

• -i 00001.mpls — tells ffmpeg which file to read from (swap in the actual playlist filename you found)
• -map 0:a:0 — grab the first audio track from that file
• -c copy — copy the audio exactly as-is, with zero re-encoding
• reference.mka — the name of the new file it creates

If you’re working from an MKV file instead of a Blu-ray ISO, use MKVToolNix (a free app with a simple drag-and-drop interface) and its “Extract tracks” feature instead — no terminal needed.

Step 3 — Checksum both files.

Run the same checksum command from the two-pass test above, once on your original extraction and once on this new reference.mka file:

shasum -a 256 Hotel-California.mka
shasum -a 256 reference.mka


(On Windows, use Get-FileHash filename -Algorithm SHA256 for each file instead.)

Step 4 — Compare the two long strings of letters and numbers it prints out.

If they match exactly, your extraction tool pulled the identical audio data as an independent tool did — confirming the extraction is correct against the source, not just repeatable against itself.

This is more setup than the two-pass test, and you don’t need to do it routinely — save it for validating a new extraction workflow or drive for the first time, or for anything you’re archiving that you’d genuinely be upset to lose. Once you’ve confirmed a given setup (drive + tool + settings) produces matching results on a handful of discs, you can trust the quicker two-pass test for day-to-day verification after that.

For CD, this is effectively what AccurateRip is already doing for you — the community database is a giant crowd-sourced version of “compare against an independent extraction of the same source,” which is why it doesn’t need a manual second-pass equivalent.

Method 2: AccurateRip and CUETools (CD)

For CD extraction, this is a solved problem — use it.

AccurateRip is on the roadmap for the LExt CD extraction path, and it works by comparing a checksum of your rip against a database of checksums submitted by everyone else who’s ripped that exact pressing. If your rip’s checksum matches the community database, your rip is confirmed byte-for-byte identical to a known-good rip of that disc.

CUETools (Windows, also runs under Wine) is the standard for this. Point it at your ripped WAV/FLAC files and cue sheet, and it checks against both AccurateRip and its own CTDB database.

• A match reads as “Accurately ripped” with a confidence number. Higher confidence means more people have submitted the exact same result.
• No match doesn’t automatically mean your rip is bad — it can mean nobody’s submitted that specific pressing yet, especially for rare or regional CDs. But a match is a strong positive signal, and repeated mismatches on a disc that should be common is a sign to re-rip it, ideally with a different drive.

If Lossless Extract’s CD ripping module you used doesn’t handle AccurateRip lookups natively, running CUETools as a second pass on the output folder takes a couple of minutes and is worth doing for anything going into a permanent archive.

Method 3: Spectrogram Inspection (All Formats)

A spectrogram won’t tell you if a rip is byte-identical to the source, but it will catch several categories of extraction damage that checksums can’t contextualize on their own:

Truncated tracks. Open the file in Audacity or a spectrogram viewer and check that the waveform runs the expected duration with no abrupt cutoff.

Dropouts. A read error during extraction sometimes produces a brief moment of silence or noise rather than a hard failure. These show up as visible gaps or artifacts in a spectrogram, distinct from anything in the mastering.

Sample rate mismatches. If a DSD-to-PCM or SACD extraction was configured incorrectly, the resulting frequency ceiling in the spectrogram will be lower than expected for the stated resolution — a 24/96 file that only has content up to 22kHz was probably upsampled from a CD-quality source somewhere in the chain, not extracted from the actual hi-res layer.

This is the same technique covered in more depth in the mastering post for spotting clipping — it’s equally useful for spotting extraction damage, since both show up as visible anomalies against an otherwise clean waveform.

Method 4: Bitstream Verification for TrueHD/DTS-HD MA

For Atmos and DTS-HD MA extractions specifically, there’s a format-level check worth running: confirming the extracted stream still contains the full object-based metadata and isn’t silently falling back to the lossy core.

Both TrueHD and DTS-HD MA carry a lossy “core” stream embedded alongside the lossless data for backward compatibility. If an extraction tool mishandles the stream, you can end up with a file that plays audio just fine — but it’s actually just the lossy AC-3 or DTS core, with the lossless extension silently dropped.

• MediaInfo (free, Windows/Mac/Linux) will show you the actual codec and bitrate of the extracted stream. A genuine TrueHD Atmos extraction should show significantly higher bitrate than a Dolby Digital Plus core alone — if the numbers look closer to a lossy stream’s typical bitrate than a lossless one’s, the extension didn’t come through.
• Compare the reported channel count and object count against what you’d expect from the disc’s listed audio specs (usually printed on the case or listed on Blu-ray.com).

This matters more than it sounds like it should — a silently-degraded-to-lossy-core file will still say “TrueHD” in your file manager and still play in 7.1.4, just without the actual lossless bits behind it.

A Quick Reference

FAQ

Do I need to do this for every disc I rip?

No. For a casual library, spot-checking is enough — verify a handful of extractions when you’re first getting your workflow and drive dialed in, and check anything you’re archiving long-term or that’s rare/expensive to re-source. For CDs, running AccurateRip is fast enough that there’s little reason not to do it every time.

What if my rip doesn’t match AccurateRip and I can’t get a better result?

Try a different optical drive if you have one — read quality varies meaningfully between drives, especially on scratched or aging discs. If you’ve tried multiple drives and still get no match, it’s possible the disc is a pressing variant nobody’s submitted yet, which isn’t something you can fix.

Can bit rot actually happen to lossless files sitting on a hard drive?

Yes, though it’s rare on modern drives with good SMART health. It’s more of a concern for files that have sat untouched for years on older storage. This is the actual reason to keep checksums around — not to catch extraction errors after the fact, but to periodically confirm your archive hasn’t silently degraded in storage.

Does this apply to streaming rips too?

The same checksum and spectrogram principles apply, but there’s no AccurateRip-equivalent for streaming sources, and the streaming vs disc mastering post covers the bigger issue with streaming sources anyway — the master itself is often different from the disc, regardless of how cleanly it’s captured.

Download Lossless Extract