WV File Documentation

---

Technical details

Feature	Value
Full name	WavPack Audio
File extension	.wv (correction file .wvc)
MIME type	audio/x-wavpack
Format type	Lossless / hybrid-lossless audio codec (binary)
Developer	David Bryant
Introduced	1998; current WavPack 5.x (5.8.0, Jan 2025)
Compression	Lossless (default); optional hybrid lossy + correction
Typical ratio	~40–60% of source WAV size
Sample formats	Up to 32-bit integer and 32-bit float
Channels	Mono to multichannel / surround
Byte order	Little-endian
Magic number (hex)	77 76 70 6B (“wvpk”)
Block header size	32 bytes
Metadata / tags	APEv2 (preferred) and ID3v1
Correction file	.wvc — restores lossless quality in hybrid mode
Open standard	Yes — open-source (BSD-style licence)
Reference tools	wavpack (encode), wvunpack (decode)
Related extensions	.wvc, .flac, .ape, .wav, .m4a
Specification	wavpack.com/WavPack5FileFormat.pdf

What is a WV file?

WV is the file extension of WavPack, an open-source audio compression format created by David Bryant in 1998 and still actively maintained (version 5.8.0 was released in January 2025). Its defining property is lossless compression: a .wv decodes to audio bit-for-bit identical to the original WAV, while occupying roughly 40–60% of the space. It competes with FLAC and Monkey’s Audio (APE) and supports up to 32-bit integer and float samples, high sample rates and multichannel surround.

WavPack’s unusual feature is a hybrid mode. Instead of one lossless file, it can produce a small lossy .wv that plays on its own, plus an optional correction file with the .wvc extension. Play the .wv alone and you get a smaller lossy track; keep the matching .wvc beside it and a decoder reconstructs the full lossless audio. The rest of this article describes how the bytes are organised, block by block.

A stream of wvpk blocks, not one monolithic file

A WavPack file is not a single header followed by one data blob. It is a sequence of independent blocks, each beginning with the ASCII id wvpk (77 76 70 6B). Every block is self-describing and carries a short run of audio for a subset of the channels, so a decoder can start on any block boundary and multichannel audio can be split across parallel blocks. All multi-byte fields in the header are little-endian.

This block design is what lets WavPack stream, seek and support surround: a stereo file is a run of two-channel blocks, while a 5.1 file interleaves blocks that each carry one or two of the six channels, flagged so the decoder knows which channels a block holds and whether it is the first or last block of a set.

The 32-byte block header, field by field

Each block opens with a fixed 32-byte header. The fields tell a decoder where the block sits in the overall stream, how many samples it carries, and how to interpret them:

Offset  Size  Field           Meaning
------  ----  --------------  ------------------------------------------
  0      4    ckID            'wvpk' (magic)
  4      4    ckSize          block size in bytes, minus 8
  8      2    version         format version (e.g. 0x0410 for WavPack 5)
 10      1    block_index_u8  high 8 bits of the 40-bit first-sample index
 11      1    total_samples_u8 high 8 bits of the 40-bit total sample count
 12      4    total_samples   low 32 bits: samples in the whole file
 16      4    block_index     low 32 bits: first sample index of this block
 20      4    block_samples   number of samples in this block
 24      4    flags           bit depth, mono/stereo, hybrid, endianness ...
 28      4    crc             CRC of the decoded samples in this block

The ckSize field follows the RIFF convention of excluding the first eight bytes, so the true block length is ckSize + 8. total_samples and block_index are 40-bit values in WavPack 5: the low 32 bits sit in the header body and the high 8 bits ride in block_index_u8 and total_samples_u8, which extends the addressable length far beyond the 4-billion-sample limit of a bare 32-bit counter. block_samples is the count of samples decoded from this specific block, and it is zero for metadata-only blocks. The flags word packs the sample resolution (bytes per sample), whether the block is mono or stereo, whether hybrid lossy mode is active, whether floating-point data is present, and the sample byte order.

The per-block CRC and lossless verification

The final header field, crc, is a 32-bit checksum computed over the decoded samples of the block, not over the compressed bytes. This is a deliberate integrity mechanism: after a decoder decompresses a block, it recomputes the CRC of the reconstructed samples and compares it with the stored value. A match proves the decode was bit-perfect, which is how WavPack guarantees its lossless claim and how tools verify that a compressed archive still round-trips exactly to the original PCM. A CRC mismatch flags corruption or a decoder bug rather than merely a damaged container.

The block body: decorrelation terms, sub-blocks and tags

After the 32-byte header, the block body is a series of metadata sub-blocks, each with its own small id-and-size prefix. These sub-blocks carry the actual coding parameters and data: the decorrelation terms and weights that WavPack uses to predict each sample from previous ones, the entropy-coder state, the residual bitstream of prediction errors, and, in hybrid mode, the parameters that split the signal between the lossy .wv and the correction .wvc. WavPack’s compression is built on this cascade of decorrelation passes followed by an adaptive Rice-style entropy coder, which is why it reaches FLAC-class ratios while remaining fast to decode.

Tags are appended after the audio blocks rather than in the header. WavPack prefers APEv2 tags (the same tagging scheme used by Monkey’s Audio) for title, artist, album and embedded cover art, and also reads legacy ID3v1 tags. Because tags live at the end, adding or editing metadata does not require rewriting the audio blocks.

The .wvc correction file and hybrid mode

Hybrid mode is the feature that most often confuses users who find two files. When you encode in hybrid mode, WavPack writes a lossy .wv at a chosen bitrate plus a .wvc that stores only the difference between that lossy approximation and the true lossless signal. The .wvc uses the same wvpk block format and its blocks are paired with the .wv blocks by sample index. Play the .wv alone and a decoder produces the smaller lossy track; supply both and it adds the correction data back to recover the exact original. The two files must be kept together and share the same base name. A common cause of a .wv that “plays but sounds wrong” or that a tool refuses as non-lossless is a hybrid stream whose .wvc went missing.

WavPack and FLAC: same goal, different reach

WavPack and FLAC are both free lossless codecs with broadly similar file sizes, and both decode to the same PCM as the source WAV. The practical difference is support: FLAC is decoded by a huge range of hardware players, phones and car stereos, whereas WavPack is more common among desktop audio enthusiasts and is favoured for its hybrid lossy-plus-correction mode, its 32-bit float support and its self-verifying per-block CRC. WavPack is decoded natively by foobar2000, VLC, Audacious, DeaDBeeF and Cog, and is built into FFmpeg and GStreamer, so most Linux systems handle .wv with no extra setup. If a target device only speaks FLAC, converting .wv to FLAC is lossless-to-lossless and keeps full quality.

References

• WavPack 5 Binary File / Block Format specification (David Bryant)
• WavPack — official site and reference tools
• WavPack source and releases (GitHub)

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.