Quick answer
FLAC can preserve the same integer PCM audio as WAV while storing it differently. Our 16 WAV-to-FLAC checks matched the original samples exactly, despite different file sizes. That does not guarantee identical container bytes or metadata. Converting a lossy MP3 to FLAC preserves what the MP3 decodes to; it does not reconstruct the original recording.
Contents
- What we compared
- Same samples, different sizes
- A file hash and an audio hash answer different questions
- What happened when we converted MP3 to FLAC
- Choosing between the formats
- Method and evidence
A smaller audio file does not necessarily mean missing audio data. We converted eight original WAV fixtures to FLAC at two compression settings and compared the decoded integer samples with the originals. All 16 conversions preserved them exactly.
File size told a less uniform story. Our silence fixtures shrank dramatically. Our noise fixtures became larger in FLAC than in WAV. Converting an MP3 to FLAC also preserved the MP3’s decoded samples, but it did not restore the non-silent source audio we had encoded into that MP3.
What we compared
We generated four two-second mono signals at 48 kHz: silence, a 440 Hz sine wave, a mix of two tones and seeded random noise. Each was represented as 16-bit and 24-bit integer PCM, giving eight original inputs with 96,000 samples each.
We encoded each WAV as FLAC at compression levels 0 and 8 using FFmpeg 6.1.1, then decoded it into the original integer sample format. Comparing those PCM bytes avoids confusing a container header with audio data. We also checked sample counts, rate, channels and a deliberately seeded title tag.
Xiph’s FLAC documentation describes FLAC (Free Lossless Audio Codec) as lossless audio compression. The files and conversion checks below show what we compared and how to repeat it.
Same samples, different sizes
These are complete file sizes in bytes, including their containers and metadata. Every FLAC in this table decoded to the original PCM exactly.
| Signal | Bits | WAV bytes | FLAC 0 bytes | FLAC 8 bytes | PCM match |
|---|---|---|---|---|---|
| silence | 16 | 192110 | 9247 | 8554 | Exact |
| silence | 24 | 288134 | 9331 | 8575 | Exact |
| sine | 16 | 192110 | 57631 | 38233 | Exact |
| sine | 24 | 288134 | 153307 | 123801 | Exact |
| mix | 16 | 192110 | 101084 | 40717 | Exact |
| mix | 24 | 288134 | 197129 | 128502 | Exact |
| noise | 16 | 192110 | 201079 | 200512 | Exact |
| noise | 24 | 288134 | 297079 | 296512 | Exact |
The sine and mixed-tone inputs gave the compressor useful structure. Random noise was a different case: both FLAC settings produced files larger than the corresponding WAVs. These short fixtures include non-audio overhead, so their exact size ratios are not predictions for a music collection.
Level 8 produced a smaller file than level 0 for every fixture in this matrix. Both were sample-exact. We did not measure encoding speed, battery use or playback performance, and a higher compression setting is not an upgrade to the audio samples.
A file hash and an audio hash answer different questions
The WAV and FLAC file bytes differ because they package the audio differently. Comparing their whole-file hashes would therefore not establish whether their decoded samples match.
Our PCM comparison used the same sample format, rate and channel count on both sides. It checked equality of the actual integer values. A conversion that changes bit depth, sample rate or channels asks a different question and needs a comparison that accounts for those changes.
We seeded the WAV title with Fictional audio fixture and found it in the tested FLAC outputs. That is evidence about this tag and conversion recipe. We did not populate every WAV metadata chunk, cover-art field or application-specific tag. Xiph also distinguishes preserving audio from preserving an entire WAVE container, including non-audio information.
What happened when we converted MP3 to FLAC
For each 16-bit fixture, we made a 128 kbps MP3 and decoded that MP3 to PCM16. We then encoded the MP3 as FLAC with an explicit 16-bit sample format and decoded the FLAC the same way.
All four FLAC outputs matched their respective decoded MP3 samples. For the sine, mixed-tone and noise fixtures, those samples differed from the original PCM. Silence was the exception: after the MP3 round trip, its samples still matched the original exactly. Every non-silent fixture in this set changed.
The useful distinction is which source you are preserving. A FLAC made from an MP3 can preserve that MP3’s decoded audio. The lossless destination format cannot supply information absent from those decoded samples.
An initial conversion also exposed a sample-format problem. When we allowed the intermediate conversion to select its format automatically, the sine check found one-unit PCM16 rounding differences on 47,963 samples. We retained that failed preflight and then used explicitly matched PCM16 for the final comparison. It was a conversion-format issue, not evidence that FLAC compression itself discarded integer samples.
Choosing between the formats
For an integer-PCM source, decide which files your intended software accepts, what metadata you need and whether reduced storage is useful. Our test cannot establish compatibility with a particular player, editing application or device because we did not run those workflows.
Keep a source copy before bulk conversion. If exact preservation matters, verify the decoded samples with matched settings and inspect the fields you need in the output. A file opening successfully is a narrower check than proving sample and metadata preservation.
There was no listening test here. We measured bytes and integer values, without asking people to rate sound quality or testing Bluetooth, streaming services, stereo recordings or real music.
Method and evidence
The matrix was run twice on 13 Oct 2026 with Python 3.12.14, numpy 2.3.5 and FFmpeg 6.1.1. Logical results matched between runs, and the saved audio files were checked against their hashes. Independent WAV frame inspection confirmed the 16-bit sample data, counts and format. The encoder and decoder share the FFmpeg implementation, which remains a verification limit.
The study package includes original fictional signals, conversion outputs, exact commands, sample hashes and the retained sample-format caveat. It lets readers check a modest but useful distinction: lossless audio preservation is about the decoded samples, while file size and container details still depend on the conversion.
Download the study files and results (ZIP).
Original fixtures, scripts and study results are available under CC0 1.0; third-party software retains its own licenses.