WavPack: Difference between revisions

From Hydrogenaudio Knowledgebase
(→‎History: "recently")
(New Mediawiki wasn't as forgiving about tags unclosed, fixed. Added some wording about playing.)
 
(45 intermediate revisions by 7 users not shown)
Line 5: Line 5:
| caption = Hybrid Lossless Audio Compression
| caption = Hybrid Lossless Audio Compression
| maintainer = David Bryant
| maintainer = David Bryant
| stable_release = 4.80.0 (28. March 2016)
| stable_release = 5.7.0 (2024-02-29)
| preview_release = [https://hydrogenaud.io/index.php/topic,111822.0.html 5.0.0] (4. May 2016)
| operating_system = Windows, MacOSX, Linux/BSD/Unix, ...
| operating_system = Windows, Mac OS/X, Linux/BSD/Unix
| use = Encoder/Decoder
| use = Encoder/Decoder
| license = BSD license
| license = BSD license
Line 13: Line 12:
}}
}}


'''WavPack''' is a royalty-free, open source and [[lossless]] or high-quality lossy (in "hybrid" mode) audio compression format developed by David Bryant.
'''WavPack''' (pronounced "wave-pack") is a [[lossless]] audio [[codec]], also offering optionally a [[hybrid codec| hybrid lossless/lossy]] mode.  It is distributed as a free open-source encoder/decoder with a library and a large number of tools, including a Windows GUI and a range of plugins for both audio players and other software.  Third party implementations are available, including ffmpeg.  WavPack supports and/or can be played back on a large number of platforms/OSes including mobile (Android, iOS), portable ([[Rockbox]]) and even web apps.  


== Description ==
WavPack is arguably the most feature-rich lossless compressor, supporting a unique range of audio signals including [https://en.wikipedia.org/wiki/Direct_Stream_Digital Direct-Stream Digital].  Everyday use is supported by a wide range of players and taggers, but ''conversion'' is likely safest done with applications that invoke the official tools (rather than e.g. ffmpeg's implementation) – and special features might require the user to apply the WavPack executable directly, for example with drag+drop, see the [[#Using WavPack]] section below.
WavPack (pronounced "wave-pack") allows users to compress (and restore) all [[PCM]] audio formats including 8, 16, and 24-bit ints; 32-bit floats; [[mono]], [[stereo]], and [[multichannel]]; [[sampling rate]]s from 6 to 192 kHz. Like other lossless compression schemes the data reduction varies with the source, but it is generally between 25 % and 50 % for typical popular music and somewhat better than that for classical music and other sources with greater dynamic range.


WavPack also incorporates a unique "hybrid" mode that provides all the advantages of lossless compression with an additional bonus. Instead of creating a single file, this mode creates both a relatively small, high-quality lossy file that can be used all by itself, and a "correction" file that (when combined with the lossy file) provides full lossless restoration. For some users this means never having to choose between lossless and lossy compression!
Performance-wise, WavPack defaults to a fast codec &ndash; less CPU intensive than [[ALAC]], but typically not as fast as [[FLAC]] or [[TAK]], especially in decoding CPU usage.<ref>[http://www.audiograaf.nl/losslesstest Martijn van Beurden: <em>Lossless audio codec comparison archive</em>], all comparisons in this wiki article consistent with CDDA results up to revision 6, 2023, using WavPack 5.6.0.</ref> In the age of low-power portable Rockbox-equipped players, WavPack could be seen as a reasonable middle ground between FLAC's low CPU footprint and long battery life, and the smaller files but more CPU-intensive [[Monkey's Audio]]<ref>[https://www.rockbox.org/wiki/CodecPerformanceComparison CodecPerformanceComparison] at the Rockbox wiki</ref> &ndash; invoking WavPacks high mode and extra compression that would compress to smaller sizes than FLAC.


== Feature Summary ==
WavPack has inspired other codecs<ref>Monkey's Audio historical FAQ {{webarchive|http://web.archive.org/web/20001017210206/http://www.monkeysaudio.com/faq.html|2000-10-17}}</ref> and their features<ref>[http://losslessaudio.org/DualStream.php OptimFROG's "DualStream"] hybrid encoding &ndash; apparently WavPack coined this phrase</ref>.  For more on WavPack, including on its history and technology, see the [https://en.wikipedia.org/wiki/WavPack Wikipedia entry].
* Fast and efficient encoding and decoding
* [[Open source]], released under a BSDish license
* Multiplatform
* Hardware support
* Error robustness
* Streaming support
* Supports multichannel audio and high resolutions
* Hybrid/lossy mode
* Tagging support ([[ID3v1]], [[APE tags]])
* Supports [[RIFF]] chunks
* Supports embedded CUE sheets
* Includes MD5 hashes for quick integrity checking
* Ability to create self extracting files for Win32 platform
* [[ReplayGain]] compatible


== History ==
David Bryant started development on WavPack in mid-1998, with the release of version 1.0. This first version compressed and decompressed audio losslessly, nothing else, but by then it already featured one of the best efficiency versus speed ratio among lossless encoders.


Very soon after the release of version 1.0, Bryant released v. 2.0, which featured lossy encoding (using only quantization for data reduction – no psychoacoustic process was applied to the stream).
= Features =
For an end-user considering WavPack as audio format, its feature-richness might be the big selling point. WavPack supports pretty much all the more common features noted at [[Lossless_comparison| HA Wiki's Lossless Codec Comparison]] as in the following first list, but several users might consider the more unique features listed under the subsequent headline.


In 1999, the developer released version 3.0, which featured novelties such as a fast mode (with reduced compression ratio), compression of RAW files and error detection using CRC checksums.
* Seekable and streaming playback.
* Error handling: upon playback, it will detect and report corrupted frames, mute to protect against static/noise output, and continue playback.  Since version 5, WavPack can also check for corruption without decoding, hence quicker than any decoding format.  Optional MD5 audio checksum can also be added upon encoding for file fingerprinting.
* High-resolution audio support (see next headline).
* Multichannel support: currently capped at 256 channels, supports [https://docs.microsoft.com/en-us/windows/win32/api/mmreg/ns-mmreg-waveformatextensible WAVEFORMATEXTENSIBLE] channel masks.
* Piping support for encoding, and support for RAW PCM input/output.
* Non-audio chunks (RIFF and similar) stored; by default, WavPack will not only encode/decode the audio losslessly, but store the non-audio chunks and restore them into a file bit-identical to the original.
* Tagging: APEv2. (ID3v1 is possible, but not advisable.)  
* Cuesheet support. In practice, some applications handle ''embedded'' cuesheets better in WavPack than in some other formats.
* Unicode support.
* Can be used in the [[Matroska]] container.
* Windows GUI available.
* Multithreading (from version 5.7.0).


WavPack development is still going on, and a major feature added in late 3.x versions is the hybrid mode, where the encoder generates a lossy file + a correction file, so that both can be decompressed back to the original PCM stream.
WavPack also handles bit depths not divisible by 8, e.g. 20-bit audio (found on some DVDs).


WavPack 4 has been released in 2004. It included important changes, such as fast seeking, multichannel support, high resolution audio support, etc. turning it into one of the most full featured and modern lossless audio compressors.
== Special/unique features ==
Most of these features are shared with only a few if any notable codecs, or extend to signal types or file types others do not support (comparisons given).
* DSD support: can losslessly compress Philips DSDIFF and Sony DSF files (see "Using WavPack" below; no other end-user codec compresses DSD.) ID3v2.3/2.4 tags can be imported.  wvunpack can select between DSDIFF and DSF out (i.e. 'convert between the two').  wvunpack can also convert DSD to PCM, but not the other way around. (Lossy, as conversion between PCM and DSD necessarily is.)
* High-resolution support for bit depth 1-bit to 32-bit integer and sampling rates up to ''giga''herz range radio frequencies, in integer steps. (2 GHz works although only 1 GHz is officially supported; for more UHF, Monkey's Audio, OptimFROG and MPEG-4 ALS support the entire WAVE range up to 4 GiHz.) Can also compress ''non-integer sampling rates'' in AIFF/AIFC/CAF (signals the WAVE format cannot contain). 
* 32-bit ''floating-point'' supported &ndash; also including CoolEdit/Adobe Audition's own float format (use the <code>-a</code> option ''only if'' the .wav was generated by CoolEdit/Audition).  (This line like OptimFROG.)
* As much as 256 channels currently supported (from version 5.5.0 on; [https://github.com/dbry/WavPack/issues/117 can be extended to the thousands] &ndash; more than any codec except MPEG-4 ALS (which is capped at 66536).)
* Hybrid lossy/lossless mode (can also be used as lossy &ndash; OptimFROG also has such a mode.)
* For LPCM it can read and output to WAVE (including the RF64 format extension used for large files and from 5.70 also BW64), to Sony's Wave64, AIFF/AIFC (both endiannesses) and CAF (ditto) &ndash; with full restore of also non-audio parts to bit-by-bit the original file in the original format.  (Monkey's/OptimFROG/TAK do the same to the input formats they support.)  Also WavPack can handle too large noncompliant "WAVE" files (by default, those will be restored to bit-identical the same as the flawed input file &ndash; optionally one can force output to compliant RF64/W64 files).
* Recompression: Can recompress .wv files in place, with tag transfer.  (Like FLAC on .flac files.)
* Drag and drop support: Dropping a file on to wavpack.exe/wvunpack.exe will encode/decode it to source directory. (Similar to FLAC.)  From 5.5.0, one can also apply options to drag and drop by renaming the executable, and drop several files.


== Software support ==
Like FLAC/TAK/OptimFROG, WavPack employs a "wasted bits" strategy to handle cases of ''n "actual bits of signal" zero-padded and stored as N bits''; such signals can be found in certain DVDs, but also as "fake high resolution" where a 16-bit signal is merely put in a 24-bit file to look impressive.  WavPack handles more "fake high resolution" cases than just zero-padding.  5.7.0 introduces an further improvement to capture similar patterns in 32-bit integer files generated by "naively converting from 32-bit float".  That particular mode is disabled by default and is arguably best left to power users (invoking it with <code>--optimize-int32</code>) as only 5.7.0 can decode as lossless; to earlier versions and players they will be presented as lossy without correction file (and will indeed be lossy with differences around -138 dB down).
=== Players ===
 
== Limitations ==
The following bullet item list is hardly of interest except for special purposes; WavPack supports nearly every input format that any competing codec handles. One exception is the legacy AU/SND, apparently supported only by Monkey's Audio.
* DSD: Will reject DST-compressed DSDIFF (which are already compressed heavier than WavPack does) and Wideband Single-bit Data files (apparently, the Tascam and Korg devices which can produce these, can also export to other DSD formats).<br/> Also, DSD files cannot be encoded as hybrid with correction files.
* 64-bit float is not supported.  (Apparently no other lossless audio compressor can support it either.)
* wvunpack can ''force output'' to a different format than input, and for AIFF/CAF also select endianness, but it cannot force output to different versions of big-endian AIFF (it will avoid AIFC as long as the signal can be fit in the original AIFF container) nor BW64 &ndash; nor select between WAVE_FORMAT_PCM and WAVE_FORMAT_EXTENSIBLE.  Few other formats do allow for such output selection; reference FLAC can from 1.4.3 offer some wider choices than wvunpack can.
* Although all non-audio will be stored, <code>--import-id3</code> can not ''import'' every type of ID3 tag to APEv2. (5.70 imports more tag types than previous versions, yet some users might want use use e.g. [[Mp3tag]] to copy over more tags from the original.) Also, unless <code>--allow-huge-tags</code> is specified, size is limited to 1 MB; older software might not read larger tagsets (but no known ''playback'' incompatibilities are known).
* Some file formats have features stored in file headers (like loop points, or for AIFF possibly non-integer sampling rates) which will not be ''visible'' to the end-user when trying to play back the .wv file in a typical player. They are nevertheless available to certain audio editing software plugins, and will in any case be restored upon decoding.
* Some features are unsupported by several applications: in particular, support for correction files is only found in a few players.
* The most significant third-party implementation (ffmpeg as of version 7.0) has bugs waiting to be fixed.
 
As of 5.5.0 and above, MacOS versions must be built with e.g. HomeBrew, and Windows XP is only supported through a special executable (available in version 5.6.0 at wavpack.com, upgrade from previous unofficial build posted at HA is strongly advised).  WavPack version 5 discontinues some features, but version 4.80 is still available to convert any version 3.x files that might still exist.
 
WavPack has traditionally had less hardware support than FLAC ([[Rockbox]] having been the most notable platform, others listed at https://www.wavpack.com/index.html#Hardware ), but with WavPack playback through Android and iOS players, the distinction between "hardware" and "software" is arguably blurred. The Android OS does not ''natively'' support other lossless audio formats than WAVE and FLAC, so there have been issues getting certain Android solutions to recognize other media files including WavPack.<ref>[https://hydrogenaud.io/index.php/topic,122768 HA thread with link to Android bug report by the Monkey's Audio author]</ref>
 
== Information for users of other codecs (and older WavPack) ==
Parts of this section will be less relevant to users who primarily decode and convert through player software, rather than directly invoking the executables.  WavPack is the only "major" lossless encoder with separate executables for encoding (<code>wavpack</code>) and decoding/info (<code>wvunpack</code>).
 
Even for features that are comparable between codecs, they may behave different &ndash; or default to different behaviour &ndash; out of the purpose they were designed to address, their development, or other design choices.
 
* WavPack is designed as a ''file compressor'' for audio files &ndash; this like Monkey's, TAK and OptimFROG, but in contrast to FLAC and ALAC which are ''audio compressors''. The difference is in the ambition to store all non-audio information (and in the correct order).  Using reference FLAC one might "opt in" on non-audio parts by giving options; using WavPack one can "opt out" and discard this information. 
** ''Note: This difference is irrelevant for CD ripping.'' Contrary to a common misconception, CD audio is ''not'' stored as WAVE &ndash; nor in any sort of file.  Thus, using a file compressor gives no more "true" copy of a CD.  (WavPack's support for embedded cuesheets might &ndash; depending on player application &ndash; give a better user experience for those who prefer to store one file per CD, but that is not due to how CDs work.)
* MD5 is opt-in (the <code>-m</code> switch) &ndash; even if verification is requested and the MD5 is calculated, it is only written to file if specifically requested. TAK and OptimFROG work similarly in that they also require the user to opt-in on MD5. FLAC, ALAC and Monkey's all work different: FLAC includes MD5 (though some encoders make exceptions under some circumstance), ALAC has nothing such &ndash; and Monkey's MD5s are not comparable with others, as it hashes the encoded bitstream. 
** Also, WavPack computes MD5 using the source's endianness (endianness is like the distinction between "4th of July" and "July 4th"), and so MD5s may differ between WAVE source and AIFF/CAF source for the same audio.  (At least a recent foobar2000 will handle them without giving false warnings.)
* Like Monkey's/TAK/OptimFROG &ndash; but unlike FLAC and ALAC-in-MP4 &ndash; tags are at the end of the file.  Consequences for users are that retagging will not trigger full file rewrite, but sometimes applications may spend longer time displaying art and viewing tags.
* Users of "older WavPack" might take note that version 5 discontinues some features, like <code>-p</code>, and also the <code>-e</code> for self-extracting files &ndash; those and other older files can still be converted, but the ancient WavPack 3 with .wav extension requires version 4.80.0 (still available).
** See the [[#File formats, versions, decoding and transcoding support]] section for more details.
 
=== Performance &ndash; file size, CPU load ===
Rewind twenty years, to 2004 hardware costs, compression ratios did matter much more &ndash; also, several formats would be too heavy to even ''play'' on portable devices, and the official WavPack site would warn against the <code>-hh</code> mode for that use even if it were not heavier than the fastest Monkey's Audio mode.
Fast forward to now, enthusiasts will still compare performance even if ordinary users may take note that impact on cost is often negligible. Different considerations may apply when a drive is near full. 
The HA wiki's [[lossless comparison]] article compares speed and compression ratio on CDDA on the respective codecs' ''default'' setting, taken from van Beurden's comparison studies.  The test corpus is chosen to be a "wide" selection, and most music collections are biased in one direction or another genre-wise; users who are concerned about compression might look up the individual sources in the study and/or make a test sample from their own collection.  By and large, the following observations can be made:
* WavPack defaults to a fast codec, between FLAC and Monkey's; is not so heavy on decoding CPU as to cause actual practical problems, although it officially recommends against <code>-hh</code> "for use on vintage portable devices" &ndash; it should be fine on anything modern.  Even <code>-hh</code> seems to decode lighter than Monkey's fastest mode.
** The "between FLAC and Monkey's" hold for "default encoding and all decoding".  Like most modern codecs, WavPack can be set to exert more encoding effort without affecting decoding load: the <code>-x</code> switch. Thus, decoding for e.g. ReplayGain tagging will be slower than e.g. FLAC in all modes, but faster than Monkey's &ndash; and recompressing with a slow <code>-x</code> setting (which can be done in the background) will not make the files any heavier to process later.  (Indeed, <code>-x</code> sometimes makes decoding lighter, although unlikely to be noticed except by measuring it.)
** Playback on Android might be less battery efficient than FLAC, which can take advantage of the OS' native support.  The difference is likely small for power-hungry players (like VLC).
** On the other hand, ''integrity verification'' can be done lightening-fast, without decoding (presuming WavPack 5 file format and WavPack 5 decoder).
* Compressing CDDA: WavPack can compress to slightly smaller files than (reference) FLAC; the difference has diminished with the most recent FLAC releases, but "in return", modern CPU speeds might have made the more expensive WavPack settings more tempting, especially when one can re-encode in the background.
* Compressing high resolution signals and multi-channel: The "extra" resolution might be a mixed bag of upsampling artefacts, tape hiss, sometimes geniune overtones (and for bat enthusiasts, actual interesting audio).  There are different kinds of samples one might call "fake high resolution", and different properties of such &ndash; upsampling or bit depth &ndash; are handled different by the codecs.  WavPack is known to handle some properties exceptionally well ("wasted bits" are exploited also by FLAC and TAK, but WavPack and OptimFROG are capable of detecting more "wasteful" patterns; Monkey's and ALAC cannot exploit wasted bits at all) &ndash; and others lesser.  Several codecs benefit from spending more effort on high resolution signals, and WavPack users might consider to (re-) compress high resolution and multi-channel with as slow setting as <code>-hx4</code>, presuming it can be done as background recompression where time is not much of an object; decoding load is largely unaffected (sometimes slightly improved) by the high <code>-x</code>.
** For 32-bit float, there is not much competition, and WavPack might be the natural choice for compatibility; it does outcompress Monkey's recently-added float mode.  Those files are not very common in the wild, and users with a sizeable collection of 32-bit files for audio processing will likely choose codec for compatibility with their DAW software.  WavPack 5.7.0's special setting for 32-bit integer converted from 32-bit float might be an option in such situations. 
* Users who compare nearly tied compression levels between codecs, should take into account how metadata storage affect total file size.  WavPack defaults to storing the source's metadata, which may include big album art; on the other hand, FLAC defaults to leaving some kilobytes padding in the file. 
 
 
= Using WavPack =
For everyday use in what other lossless codecs can do, just play it back in a supported player &ndash; many of which support tagging, and so do several tagging software.  Several of these players can also encode to WavPack, invoking the official tools. 
 
Certain more advanced uses are not accessible through player software &ndash; not even if they invoke the official tools &ndash; and are best invoked through the WavPack executables directly.  For example, you cannot expect non-audio data (for full file restore) to be preserved when encoding/decoding through ''players'', as they usually pass on only the audio; this is not particular to WavPack, but must be expected if you want to store non-audio chunks in other formats that support it.  Also, WavPack supports input formats that might exceed the player's internal decoding; e.g. trying to convert DSD with foobar2000 will yield a warning that it will not be lossless (also, converting DSD to PCM leads to files many times the size, being inherently different formats), and the same will 32-bit integer in 32-bit foobar2000 (which uses float internally).
 
== Encoding/decoding by drag and drop (Windows) ==
The simplest encoding/decoding might be ''dragging and dropping'' a (supported) file to wavpack.exe (/wvunpack.exe).  Then the file will be encoded/decoded with the default options.  Dropping a .wv file onto wavpack.exe will recompress it, prompting before overwrite (again, using default settings &ndash; possibly a bad deal if it was encoded with high <code>-x</code> switches).  Drag and drop also works on a shortcut to the executable. It is not possible to drop a folder, but from version 5.5.0, there is a way to drag and drop ''several'' files.
 
From version 5.5.0, drag and drop supports ''options'' by renaming the wavpack/wvunpack executable.  The user can rename a copy of the executable according to preferred settings, which will be applied to the process upon drag and drop.  The example given by the developer in [https://hydrogenaud.io/index.php/topic,122626.msg1012159.html#msg1012159 in this HA forum post]<ref>[https://hydrogenaud.io/index.php/topic,122626.msg1012159.html#msg1012159 HA forum post on how to rename executable for drag and drop]</ref> uses encoding options that many WavPack users will recommend (better compression than default, verification and MD5 fingerprinting), and novice users can choose to copy that filename for the executable.  For fine-tuning performance or for more specialized tasks, more options are described below.
 
== Basic command line encoding/decoding [[Windows_command_line_tips|(for Windows: command-line hints here)]] ==
The basic ''encoding'' usage is <code>wavpack filename</code> (which creates <code>filename.wv</code>) &ndash; this is what drag and drop accomplishes.  Wildcards are supported, e.g. <code>wavpack *.wav</code> (but not simply <code>wavpack *</code>).  For a ''single'' input file, one can specify output like e.g. <code>wavpack infilename.wav -o outfilename.wv</code> (on Windows, the <code>-o</code> can be omitted).  Input file extension ".wav" can be dropped, and output ".wv" extension as well &ndash; but <code>wavpack foo</code> will only find foo.wav, not e.g. foo.w64 &ndash; and not a "foo" with no file extension.  (Power users may take note that for <code>--raw-pcm</code> input, the encoder will not look for foo.wav but rather for foo.raw.)
 
The basic ''decoding'' usage &ndash; as will be accomplished by drag and drop &ndash; is <code>wvunpack filename.wv</code>.  By default, wvunpack will restore the exact same file (metadata and file structure and all; it will know the original file name extension but not the rest of the file name &ndash; timestamp can be stored by using <code>-t</code>.) If only audio was encoded (conversion from a ''player'' would usually work this way), output defaults to filename.wav.  Output filename can be specified, and just like for the wavpack encoder, file extensions can be dropped; e.g., <code>wvunpack foo -o bar</code> (or on Windows, dropping the <code>-o</code>) will decode foo.wv to bar.<original file's extension>.  This is arguably advisable: wvunpack will not ''override output format'' by setting file extension.  E.g. if the input was a CAF file, <code>wvunpack foo -o bar.w64</code> is still a CAF file, and the user has only managed to mislead themselves.  To force output format, see the [[#Decoding options]] paragraph. 
 
=== Several input files ===
To give several filenames as input to wavpack/wvunpack, other than through wildcards, there are (for historical reasons) slight differences between the Windows version and the *n*xes:
Windows (requires WavPack 5.5.0): use the <code>--drop</code> option as in the above example given by the developer.  It is intended for drag and drop (hence the name of the option) and will write the output to same directory as source.  However it can also be used with command-line:  <code>wavpack --drop firstfile secondfile</code> will compress firstfile.wav to firstfile.wv and secondfile.wav to secondfile.wv.  Note that without the <code>--drop</code>, the command <code>wavpack firstfile secondfile</code> will compress firstfile.wav to secondfile.wv, as <code>-o</code> is optional on Windows &ndash; indeed that is why the <code>--drop</code> had to be introduced.  An arbitrary number of files can be processed, e.g. <code>wvunpack --drop firstfile secondfile thirdfile fourthfile fifthfile</code> will decode firstfile.wv, ..., fifthfile.wv.
For *n*x, one can omit the <code>--drop</code>.
 
== Applying options ==
For tuning performance or other settings, one might want to apply command-line options.  Some external applications can apply options without the user having to type &ndash; e.g. encoding with [[foobar2000]], there are two compression sliders, one for the fast-to-extra-high and one for the <code>-x</code> settings (see below) &ndash; but for command-line one will have to type them, and also in the Windows GUI.  Options can be concatenated for short, like for example writing <code>-hh -x2 -m -v -y</code> as <code>-hhx2mvy</code>. 
 
The user should beware that the wavpack encoder and the wvunpack decoder (and wvtag/wvgain) have to "re-use letters".  While some do the same in the wvunpack and wavpack (like <code>-d</code> for delete input file, <code>-y</code> for "yes to all", <code>-t</code> to preserve timestamp, and <code>-l</code> for (Windows only) "run with low priority") and others cover the same purpose in both executables (like <code>-m</code> and <code>-v</code>), the user may be warned that certain letters do not.  E.g. <code>-b</code>, <code>-c</code>, <code>-n</code> cover completely urelated functions upon decoding vs upon encoding. 
 
5.7.0 introduces multi-threading options for both encoding and decoding, invoked with <code>--threads=<number 1 to 12></code>, or simply <code>--threads</code> to let WavPack choose.  Multithreading does not reduce overall CPU load, but unless the CPU is already working at max, it will do one or a few files in fewer seconds; thus it is invoked by default for the CoolEdit plugin.  For encoding, it leads to slightly different files, with usually very small size impact.
 
=== Encoding options (lossless) ===
Encoding using <code>-hxm</code> seems a sensible trade-off between compression and CPU load.  Some selected options are described as follows; for an exhaustive refence, see the manual (online, or included as wavpack_doc.html in the distribution).
* Compression.  WavPack has four compression modes that affect compression as well as encoding ''and'' decoding time: fast (<code>-f</code>), default, high (<code>-h</code>) and very high (<code>-hh</code>).  The CPU load of <code>-hh</code> is measured to around twice that of <code>-f</code> (and could in the early 2000s be too heavy for portable players, although it does decode faster than any Monkey's).  On top these modes, the optional extra processing <code>-x1</code> to <code>-x6</code> settings will apply extra compression effort that does not increase ''decoding'' CPU load. <code>-x</code> without number is synonymous to <code>-x1</code>, which is often recommended (in all modes, fast/normal/high/extra high).  The official manual calls <code>-x4</code> to <code>-x6</code> "extremely slow", but the size gains might be significant for high resolution audio in particular (van Beurden's revision 5, testing <code>-x4</code>). 
** 5.5.0 introduces optional switches for the default compression: <code>-g</code> for normal mode and <code>-x0</code> for "no <code>-x</code>".  These are redundant for basic use, but can be used to switch off options already given (e.g. in renamed executables, or custom builds): <code>-x6 -x0</code> will switch off the extra processing, and <code>-h -f -g</code> will encode as normal, whereas previous versions would abort with an error.
** With DSD files, there are only two compression settings, normal and high; the option <code>-f</code> will select normal, <code>-h</code>/<code>-hh</code> will both select high, and the <code>-x</code> switches are silently ignored.
* Guarding against errors upon encoding: The "<code>-m</code>" switch will compute an audio MD5 sum (like FLAC does by default) and store it for later verification.  The "<code>-v</code>" switch will verify by decoding the file after it has been written to disk<ref>[https://hydrogenaud.io/index.php?topic=121714.msg1008108#msg1008108 HA forum comment:] verification checks the written file after closing and reopening</ref>. <code>-vm</code> will do both &ndash; that is, calculate the MD5s to verify, and store it.  Using the corresponding switches in wvunpack will check without producing output file, however wvunpack also has a faster corruption check for WavPack 5-encoded files: <code>-vv</code>.
* <code>--import-id3</code> will import ID3v2.3/2.4 tags present in the source file &ndash; typically in Sony DSF files &ndash; and convert them to WavPack's preferred APE tags.  (Not all tags are supported, but the full tags chunk will be kept for restoring the original file.)  By default, importing is limited to 1 MB; for more, use <code>--allow-huge-tags</code>.  Same option works in wvtag; indeed, one can encode first and then afterwards "import" the tags from the WavPack file using <code>wvtag --import-id3 wavpackfile.wv</code>; this provided that these data have not been deleted by the following <code>-r</code> option:
* <code>-r</code>: remove non-audio chunks.  By default, WavPack will store these in the .wv file for later bit-by-bit restoration of everything, not only the audio. Use <code>-r</code> to throw them away and encode audio only &ndash; like encoding through most players appear to do.
* <code>-t</code>: copy input file's time stamp.  (To restore the file with the original time stamp, use <code>-t</code> both when encoding and when decoding.)
* <code>--pause</code>: (Windows only!) waits for keypress at the end.  Useful for reading output before exit when calling wavpack/wvunpack in a separate window (which both drag-and-drop the Windows front-end do).
* <code>-y</code>: "yes" to everything.  Use with caution, will overwrite.  From 5.5.0 there is also a <code>--no-overwrite</code> that will skip instead of asking to overwrite.
* <code>-d</code>: delete source file upon successful completion.  Again, use with caution.
* <code>-l</code> will force WavPack to run at low priority (Windows only)
* <code>-c</code>: this is for hybrid lossless, see below.
 
WavPack can recompress .wv files in place (using a temporary file until done).  For example, <code>wavpack -hx4mvy wavpackfile.wv</code> will compress wavpackfile.wv in high mode using <code>-x4</code> extra processing, writing everything (and an audio MD5 checksum) to a temporary file with tags transferred; close and then re-open the temp file to re-read for verification &ndash; and only once verified, replace the old wavpackfile.wv. <code>wavpack -hx4rlmvy wavpackfile.wv</code> will also run with low priority (assuming the Windows platform), and will discard non-audio chunks &ndash; that is, the ones used to restore the original file's metadata; the .wv file's APE tags will still be copied.  Some operations do require recompression even if the user would not demand it; For example, wavpack cannot add MD5 sum to a .wv file without recompressing it. Also, if the user wants to discard the original file's headers/footers, that can be done upon decompression or recompression &ndash; but not by simply removing them from the .wv file.
There is no out-of-the-box facility to recompress based on how heavy the original file was compressed, or to keep the smallest file.
 
=== (Incomplete:) hybrid lossless & lossy encoding ===
(Needs to be expanded. Notes: DSD can currently not be hybrid-encoded and floating-point files should not be.  The correction file will be omitted by a lot of applications/players, including VLC, mplayer and ffmpeg; thus, using ffmpeg or ffmpeg-based players to convert/play hybrid-encoded WavPack will be lossy. For WavPack in Matroska, there doesn't seem to be any player that will play both the lossy stream and the correction stream, although mkvmerge/mkvextract will import/extract both streams. foobar2000 can play hybrid lossless .wv+.wvc, but will omit a Matroska-encapsulated correction stream.)
 
Basic use: the <code>-b</code> switch &ndash; and for losslessness, use <code>-c</code> to create a correction file.
A numerical argument for quality is mandatory: if < 24 it will signify ''bits per sample'' and if > 24 it will signify ''kbit/second''. Decimal separator is . even if your locale uses the comma.
For example, <code>wavpack -b12.5 filename</code> will create filename.wv of bit rate 12.5 bits per sample. 
For an example that creates filename.wv at at most 234.56 kilobits per second and a correction file filename.wvc, the following commands will work:
* In all versions, <code>wavpack -b234.56 -c filename</code>. Or equivalently <code>wavpack -cb234.56 filename</code>
* From 5.70, also <code>wavpack -c234.56 filename</code> will do the same.  Thus, a user can avoid the "<code>b</code>" altogether, eliminating the risk of loss from forgetting the "<code>c</code>".
More options can be added, like <code>wavpack -cb234.56 -mhx filename</code> to compress in high mode with extra processing and stores the (''original'' PCM's) MD5 sum. 
When filename.wv and filename.wvc are both present, the original file will be restored completely by decoding the usual way by <code>wvunpack filename</code> (or <code>wvunpack filename.wv</code>, but not <code>wvunpack filename.wvc</code>).  Playback of the .wv+.wvc is also lossless provided the player application supports correction files (like foobar2000, but few do).
<code>filename.wv</code> can be copied to a different location without compression file and played in the same way as if it was encoded as lossy in the first place; the decoder will only look in the same path and for same file name except with .wvc extension.
 
If a high enough lossy quality is specified, it is possible that the file can losslessly contain the entire signal.  If so, WavPack will report at the end of the encoding process &ndash; but that information is not stored in the file.  It can be inferred later from the small .wvc file, and if that is lost: if <code>-m</code> was used upon encoding.
WavPack will refuse to recompress lossy-generated .wv to "lossless .wv" as that would make a false pretense of being a lossless file.  (That goes even in the "that information is not stored in the file" case just mentioned.)  If a lossless hybrid with correction file is recompressed, the default is to create a single-file lossless .wv; from 5.7.0, the old .wvc file will then be removed (as it does no longer belong to any .wv file), but earlier version would need to use the delete switch.
 
Advanced use: The encoder has several options to tune lossy quality through e.g. noise shaping.
 
=== Decoding options ===
In addition to the basic usage above (drag and drop or <code>wvunpack filename.wv</code>), the wvunpack executable offers several options.  For use with the Windows front-end or drag and drop, the Windows-only <code>--pause</code> (waits for keypress at the end, like for wavpack.exe) is essential to read the output report.  Also Windows-only options like <code>--drop</code> and <code>-l</code> work as for wavpack.exe, and so do <code>-d</code> (use with caution!) and <code>-y</code> (ditto!) as well as <code>-t</code>.
 
* Output ''filename'' can be set with <code>wvunpack infilename.wv -o outfilename </code> (the <code>-o</code> being superfluous on Windows, where &ndash; in the absence of <code>--drop</code> &ndash; the second filename will be assumed to be output name).  Then wvunpack will affix the file extension of the original file (say, outfilename.wav if the wavpacked file was somefilename.wav).  The wavpack encoder detects the file type from content, and so wvunpack will not "fix misleading extensions" automatically; the user can provide a giving full output filename with extension, but note that this will override the ''name'' only but not the ''type''.  To make sure that -o out.aif indeed produces an AIFF, separate switches have to be employed.
* To force output ''file format,'' one needs to apply options to wvunpack.  The following are for PCM output: <code>--raw-pcm</code>, <code>--wav</code>, <code>--w64</code>, <code>--caf-be</code>, <code>--caf-le</code>, and from version 5.6.0 on also <code>--aif</code> and <code>--aif-le</code>. 
** These will delete non-audio chunks and replace them with a fresh file header: there is no option to "unpack to WAVE and restore the original headers if the original file was WAVE".  <code>wvunpack --wav</code> will select RF64 if (and only if) exceeding WAVE's 4 GB limit, and wvunpack will select old AIFF over AIFF-C if the audio data permit it.
** For DSD, those format switches will also force a &ndash; necessarily lossy &ndash; conversion to PCM.  To switch losslessly ''between'' DSD formats, there are also <code>--dsf</code> and <code>--dff</code> (the latter being synonymous to <code>--dsdiff</code>) which again delete non-audio chunks.  Note that WavPack cannot force any (also necessarily lossy) conversion ''to'' DSD, having no DSD encoder.
** <code>--raw</code> outputs both PCM and DSD as headerless streams (lossless for both; <code>-r</code> is synonymous; beware that this is not precisely the same as the same letter switch upon encoding).
 
In addition to decimating DSD for conversion to PCM, there are other options where power users can utilize certain ''lossy'' operations by wvunpack, e.g. normalizing floating-point files (recommended before conversion to integer), dropping correction files from hybrid encodes &ndash; and <code>--skip</code> and/or <code>--until</code> to decode only a segment of the file.  See the documentation. 
Other options include <code>-b</code> to "blindly" decode until end disregarding errors and corruption (potentially useful to save as much as possible from a destroyed file).
 
<code>wvunpack -m</code> will decode with MD5 sum calculation.  If the .wv file had an MD5 sum stored, it will also be displayed for comparison. However, <code>-m</code> will not give an error if they don't match (and if the .wv is lossy without correction file, they won't: the MD5 stored is that of the original).
 
wvunpack is also the utility to display information from .wv files even when it does not involve decoding or file output, see the [[#Other file handling]] subsection.  Inter alia, <code> -s</code> will correctly report the input file ''type'' even if it had a misleading extension (like a .wav extension disguising an AIFF file).
 
== <span id="Other file handling"></span>Other file handling (incomplete) ==
The WavPack distribution includes wvunpack, wvtag and wvgain. 
 
=== File information with wvunpack (without decoding to file) ===
wvunpack can get information about WavPack files without outputting any uncompressed audio file:
* <code>-vv</code>: Quick verify without decoding (WavPack 5 files only; from 5.5.0 there is also a more verbose <code>-vvv</code>).  Quick verify seems to be unavailable outside the official wvunpack; other applications which verify will fall back to the next item, <code>-v</code>.
* <code>-vm</code>: Decode and verify, but not write output file.  The "m" will compute the the MD5 sum of the decoded PCM and output it along with the .wv file's stored MD5, if such was present.  Note that the user has to check manually that they match.  A user who never uses <code>-m</code> upon encoding can safely drop the <code>-m</code> from wvunpack too.  Note that absent the "v", <code>wvunpack -m</code> will write output file &ndash; and that <code>wvunpack -mvv</code> is not allowed, as MD5 calculation requires decoding.
* <code>-s</code>/<code>-ss</code>: <code>-s</code> displays summary of the file, <code>-ss</code> a long summary including tags. Also there is <code>-f</code> for parseable output, see documentation.
* <code>-x</code> FIELD: Shows tag, e.g. <code> -x comment </code> shows the <comment> field.  <code>-c</code> is synonymous to <code> -x cuesheet</code>.  Also <code> wvtag -x </code> resp. <code> wvtag -c </code> do the same thing.  <code>-xx</code> (same option for wvtag) can output to file (use <code>-n</code> to avoid decoding) &ndash; see documentation.
 
=== (To fill in:) Tagging (wvtag) and replaygain management (wvgain) ===
(... most of these options are available in HA's fave taggers/player? Except the following, maybe?)
<code>wvtag --import-id3 wavpackfile.wv</code> will read and "import" ID3 tag stored in wavpackfile.wv's non-audio chunks; this will overwrite existing APEv2. Can also be used with <code>--allow-huge-tags</code>
 
== File formats, versions, decoding and transcoding support ==
Even if WavPack has expanded its feature set over the years, it has gone to lengths to maintain compatibility.  Old WavPack 4.x decoders can restore WavPack 5 files to several file types it cannot encode, but not DSD. 
The TL;DR is that unless one has an ancient portable device or even more ancient files, one will do just fine with the most recent WavPack, and if not then WavPack 4.80 will suffice &ndash; it is still available and can convert ancient WavPack version 3 files. 
Over the years, one might have encountered WavPack files in (at least) the following variants:
 
* .wv (current!) is the file extension used for file formats 4 and 5. Can in most cases be decoded by "anything" (even if the source was e.g. AIFF, which old WavPack cannot read but still restore).  Exceptions:
** WavPack 4 cannot play or restore compressed DSD files (that is new to WavPack 5).  Although FFmpeg's wavpack implementation is version 4-based, DSD and DSD-in-WavPack can still be ''played'' with an FFmpeg-based player. (But not restored, as FFmpeg has no DSD pipeline, so this is for playback or lossy conversion.)
** FFmpeg creates non-compliant files for 17 channels and up.  WavPack 5.7.0 can decode and repair (FFmpeg itself cannot!)
** Mono signals encoded to WavPack 5 might require WavPack version 4.3 (from 2005) or later to play.  It is doubtful that there are hardware players around using older WavPack; should incompatibilities occur, the easiest is likely then to recompress using 4.80.
** To older WavPack versions than 5.7.0, encodes with the new <code>--optimize-int32</code> will be viewed as "lossy without correction file".  They are safe to play (and will apparently only introduce loss from the 24th bit, -138 dB down), but only 5.7.0 can see the lossless version and restore the file completely.
* .wvc, correction files when hybrid lossless encoding is chosen.  Honoured by official WavPack, but users might note that wvpack/wvunpack should be fed the .wv file and will err out if pointed at merely the .wvc file.
* .exe (deprecated): WavPack 4 could compress to Windows self-extracting file (like OptimFROG also offers).  This feature is discontinued in WavPack 5.  Newer versions of the decoder can still play and decode them &ndash; indeed, merely renaming them from .exe to .wv will make them play in players that use the official WavPack library (e.g. foobar2000 will, but VLC will not), and they can be tagged.
** How to recompress with tag transfer: Rename to .wv and run the recompression.
** Similar goes for the 3rd party hack ".iso.wv" which could also be mentioned, and also if a .wv file is stored (uncompressed!) in a .zip container renamed .zip.wv: like for self-extracting files, the official decoder might look further into a file to find WavPack headers, and could find them if the .wv file is put first in an uncompressed container.  Circa 2010 some developer would use the .iso format to contain single WavPack file, and then auxiliary files like rip logs and artwork; renaming it from .iso to .iso.wv would player applications actually play it. Due to efforts from a few enthusiasts when this hack was introduced, iso.wv is mentioned in several players' official and unofficial feature lists, including Wikipedia pages.  These files can be recompressed like the self-extracting files can &ndash; this will however discard ''everything else'' than the WavPack file.
* .wav (pre-2004, long deprecated).  WavPack 3 and below used the .wav extension, which explains the error message "this legacy WavPack file is deprecated, use version 4.80.0 to transcode" if a user tries to wv''un''pack a WAVE file.
 
 
= Using WavPack with 3rd party tools (FFmpeg & more) =
 
Some applications may behave slightly surprising.  FFmpeg has its own WavPack implementation and has a few known peculiarities, some which are expected to be fixed and others of unknown status.  Android users may need to use the player application's folder to get WavPack files recognized.  The tl;dr are that as long as it plays, it plays &ndash; but to safeguard against loss of information (e.g. upon conversion), use the official tools.  In particular, hybrid lossless correction files are usually not honoured by 3rd party tools. (A player that ''does'', foobar2000, uses the official WavPack libraries.)
 
== Splitting WavPack files by cuesheet ==
WavPack is a format with good support for storing an album as one .wv file with embedded (or external) cuesheets, but splitting into tracks by way of cuesheets is not straightforward without external tools.  Audio players like [[foobar2000]] which support cue sheets can also split upon conversion.  Other external applications that will do this splitting &ndash; also with more variations of the cue sheet format(s) supported &ndash; include
* [[CUETools]] can if it is CDDA (44.1 kHz 16-bit stereo), and can re-encode back to WavPack. 
* refalac can decode & split by cuesheets with the appropriate (official) WavPack library DLL file<ref>[https://github.com/nu774/qaac/wiki/refalac-usage refalac usage] includes how to split by cuesheet</ref>, outputting WAVE or ALAC-in-MP4.
Both refalac, CUETools and foobar2000 use the official WavPack tools for the decoding(/encoding).
 
== <span id="FFmpeg's WavPack implementation"></span>FFmpeg's WavPack implementation: differences and quirks ==
FFmpeg can encode/decode to/from WavPack &ndash; which may be seen as attractive from how it also can transfer metadata in one go &ndash; but with some limitations and maybe unfamiliar behaviour.  <br/> FFmpeg has had some bugs which may cause audio corruption.  Although some fixes were applied with FFmpeg release 6.1, users might beware that players and converters that employ FFmpeg as a decoding engine may or may not update that quickly.
* [Still not fixed as of ffmpeg 6.1] Encoding, multi-channel only: Above 16 channels, when the WavPack 5 format is required, FFmpeg will still attempt encoding to WavPack version 4, but will produce non-compliant files &ndash; that ffmpeg itself might not be able to read.<br/>Official WavPack 5.7.0 can repair those files, at least the "known" defects.
* [Fixed in ffmpeg 6.1] Encoding, 8-bit PCM only: FFmpeg (up to 6.0) will produce broken files with static noise.  No known attempt at recovering them.
* [Fixed in ffmpeg 6.1] Decoding, any format but rare: A bug FFmpeg's WavPack decoder, discovered in August 2022<ref>[https://hydrogenaud.io/index.php/topic,122810 HA forum thread on the ffmpeg bug in .wv decoding]</ref>, will cause dropouts in certain files. The bug is ''"rare"'' in that no such file was discovered in several years. 
 
Further limitations in FFmpeg's implementation:
* No MD5 sum and no verification &ndash; although it is possible for power users to set up a command-line to compute audio-only checksums of input, decode output to checksum and compare.  FFmpeg will also only write WavPack 4 files, hence no ''fast verification'' of the bitstream.  (FFmpeg can however decode WavPack 5 files, including converting DSD files to PCM.)
* As a general rule &ndash; not specific to .wv &ndash; FFmpeg will ''not'' honour the input bit depth: for example when outputting WAVE/AIFF, it will default to 16 bits regardless of input bit depth.  This default behaviour is not lossless when input bit depth is > 16 bits, and could even induce clipping (with no warning!) if the source is a 32-bit float.  To force lossless decoding of 24-bit/32-bit files (WavPack/FLAC/ALAC/TAK/uncompressed) to WAVE/AIFF, the user must extract the bit depth information and specify the respective 24-bit/32-bit output format using ffmpeg's command-line syntax. <br/> <br/>For an extreme example: <code>FFmpeg -i DSDfile.dsf outfile.wv</code> will not store the DSD &ndash; rather it will convert to floating-point PCM which is then compressed, typically making for several times the file size, with no warning that it is lossy.<br/>
The tl;dr for users who do not have this at their fingertips, is to use other (= official!) decoders when losslessness is desired.
* Correction files ignored, leading to lossy playback/conversion of hybrid-encoded WavPack files with when ffmpeg or ffmpeg-based players are used.
* Loss of information that is not directly audio-related: FFmpeg has no ambition of preserving file structure and (R)IFF chunks, so you will not get the non-audio chunks of the files back when using ffmpeg to encode &ndash; however it ''will'' by default transfer metadata it supports.
* FFmpeg will sometimes &ndash; depending on input format &ndash; output 32-bit WavPack files and lose the information that the source was indeed only 24. Not all players support 32-bit files, and verifying that the operation (or an attempted downconversion to 24) was lossless is not straightforward as even fewer applications are willing to compare a 32-bit and a 24-bit file for differences. <br/>Also for files with bit depth not being 8/16/24/32 is lost; WAVE/AIFF/CAF can handle "17 bit" files by storing 24 and employing a flag to disregard the 7 LSBs, and ffmpeg will lose this flag even when encoding to / decoding from codecs which support it, WavPack and FLAC.
 
FFmpeg's compression settings can be set with <code>-compression_level</code> 0 to 8, which work different than the reference implementation. Like for ALAC compression, FFmpeg has chosen a ''default'' that prioritizes speed over size <ref>[https://hydrogenaud.io/index.php?topic=118278.msg976262#msg976262  HA forum comment comparing the compression presets]</ref> &ndash; while on the other end, FFmpeg's WavPack encoder offers settings even slower than <code>-hhx6</code>. FFmpeg version 7 does some multithreading, although not in the encoding process itself; apparently it offloads the ''input file reading'', improving speed on single-file encoding.
FFmpeg multithreads decoding, and could be fast.
 
 
= Software support (& hardware) =
The following list is unlikely to be complete, and the same goes for the lists https://www.wavpack.com/#Software and https://www.wavpack.com/#Hardware : In the age of Android-powered devices with ffmpeg-based playback, it is not feasible to list all players which can in one way or another play this or that format, nor to distinguish clearly between hardware players and software players.
 
== Players ==
* [[foobar2000]] advanced freeware audio player plays/decodes WavPack out of the box on both Windows, MacOS, Android and iOS (Windows: supports encoding if wavpack.exe is installed, and redistributes the official wavpack.exe through its "Free encoder pack" addon for encoding.  With ReplayGain & cuesheets support.) Also [[Boom]] from the same author.
* [http://www.videolan.org/vlc/download-windows.html VLC] multiplatform media player
* [http://www.vuplayer.com/vuplayer.php VUPlayer] (official plugin, supports encoding)
* NullSoft [[Winamp]] (plugin with ReplayGain & Media Library support) and Winamp-compatible players
* NullSoft [[Winamp]] (plugin with ReplayGain & Media Library support) and Winamp-compatible players
* [[foobar2000]] Advanced Audio Player (official encoding/decoding addon, with ReplayGain & Cuesheets support)
* [http://www.vuplayer.com/vuplayer.php VUPlayer] (official plugin, supports encoding)
* [[Windows Media Player]] and other directshow-based players (MPC, TCMP, RadLight) (with [http://www.hydrogenaudio.org/forums/index.php?showtopic=103693 CoreWavPack] directshow filter)
* [[Windows Media Player]] and other directshow-based players (MPC, TCMP, RadLight) (with [http://www.hydrogenaudio.org/forums/index.php?showtopic=103693 CoreWavPack] directshow filter)
* [http://www.un4seen.com/xmplay.html XMplay] (official plugin)
* [http://cogosx.sourceforge.net/ Cog] Audio player for MacOS X.
* [http://cogosx.sourceforge.net/ Cog] Audio player for MacOS X.
* [https://wiki.jriver.com/index.php/WavPack JRiver Media Center]
* [[XMMS]] (with Kuniklo's plugin)
* [[XMMS]] (with Kuniklo's plugin)
* [http://fondriest.frederic.free.fr/realisations/lamip/ LAMIP] (official plugin)
* [http://fondriest.frederic.free.fr/realisations/lamip/ LAMIP] (official plugin)
* [http://mpxplay.sourceforge.net/ MPXplay] for DOS!
* [http://mpxplay.sourceforge.net/ MPXplay] for DOS!
* [http://aqualung.sourceforge.net/ Aqualung] for GNU/Linux
* [http://aqualung.sourceforge.net/ Aqualung] for GNU/Linux
* [http://www.videolan.org/vlc/download-windows.html VLC Player]
* Cowon [http://www.jetaudio.com/ JetAudio Player] and CD ripper
* Cowon [http://www.jetaudio.com/ JetAudio Player]
* [http://www.un4seen.com/ XMPlay] Plugin required (WavPack input plugin) and (bass library) to play '.wv' files
 
=== Frontends ===
* Custom Windows [http://www.wavpack.com/WavPack_frontend.zip WavPack frontend] (by Speekenbrink)
 
=== Converters ===
'''Note:''' ''Several players, like Cowon JetAudio, foobar2000 and VUplayer, can also convert from other formats to WavPack!''
 
* [http://www.dbpoweramp.com/ dBpowerAMP] Music Converter / Audio Player / CD Writer (official addon)
* [http://www.easeaudioconverter.com/wavpack.htm Ease Audio Converter] (Shareware / NOT Freeware)
* [http://media.io/ Online Audio Converter]
 
=== Editors ===
* [[Adobe Audition]] and Cool Edit (filter with 32-bit floats & extra info save support)


=== CD writers/rippers ===
== Converters, CD rippers etc. ==
For conversion (of ''audio'' only), one can use several of the ''players'' listed above, like Cowon JetAudio, foobar2000 and VUplayer &ndash; although some with limitations in the audio pipeline, like for example DSD handling. <br/>
More software that support conversion to or from WavPack include:
* Custom [http://www.wavpack.com/WavPack_frontend.zip WavPack frontend] (by Speekenbrink) for Windows.
* [http://www.dbpoweramp.com/ dBpowerAMP] Music Converter CD ripper/writer / Audio Player / (official addon)
* [[fre:ac]] multi-platform CD ripper/converter
* [[Exact Audio Copy]] CD Ripper (guide at this wiki<ref>[[EAC_and_WavPack | HA Wiki: Configuring EAC and WavPack]]</ref>)
* [http://www.nero.com/eng/ Nero]
* [http://www.nero.com/eng/ Nero]
* [[Exact Audio Copy]] CD Ripper
* [http://cdexos.sourceforge.net CDex] CD ripper
* [http://cdexos.sourceforge.net CDex] CD ripper
* Cowon [http://www.jetaudio.com/ JetAudio Player]
* [https://download.cnet.com/Ease-Audio-Converter/3000-2140_4-10390634.html Ease Audio Converter] (Discontinued; shareware / NOT Freeware)
* [http://media.io/ Media.io Online Audio Converter]
* [http://www.logipole.com/index.html Konvertor]
* [http://cuetools.net CUETools] converter and AccurateRip/CTDB checker
* [https://github.com/nu774/qaac refalac] (user must copy the wavpackdll.dll file to the appropriate directory)


=== Taggers ===
== Taggers and audio info utilities ==
* [http://www.mp3tag.de/en/index.html Mp3tag] Universal Tag Editor
* [http://www.mp3tag.de/en/index.html Mp3tag] Universal Tag Editor
* [https://picard.musicbrainz.org/ MusicBrainz Picard] Tagger with audio identification
* [http://www.jtclipper.eu/thegodfather/ The GodFather] Tagger / Music manager
* [http://www.jtclipper.eu/thegodfather/ The GodFather] Tagger / Music manager
* [[Tag.exe|Case's Tag]] command line tagger
* [[Tag.exe|Case's Tag]] command line tagger
* [https://mediaarea.net/ MediaInfo]
* [http://mr-questionman.en.uptodown.com/windows Mr. QuestionMan]


=== Other tools ===
== Audio editors and other tools ==
* [http://mr-questionman.en.uptodown.com/windows Mr. QuestionMan]
* [[Audacity]] has WavPack support (using official libraries) from version 3.2.0 (2022)<ref>[https://github.com/audacity/audacity/releases/tag/Audacity-3.2.0 Audacity 3.2.0 release notes]</ref>.
* [http://www.bunkus.org/videotools/mkvtoolnix/ mkvtoolnix] tool to multiplex WavPack streams inside the Matroska container
* [[Adobe Audition]] and Cool Edit (filter with 32-bit floats & extra info save support)
* [https://www.reaper.fm/about.php#technical Reaper] DAW software for Windows / MacOS
* [https://sourceforge.net/projects/sox/ SoX] can read and write WavPack files.  (Write: limited to <code>-hh</code> compression, not file format version 5.)
* [http://www.bunkus.org/videotools/mkvtoolnix/ mkvtoolnix] &ndash; tool to multiplex streams in Matroska container files.
''It's worth mentioning the [[Matroska]] guys decided to concentrate on WavPack as the lossless compressor of choice for their container. Quite an honor... :-)''
''It's worth mentioning the [[Matroska]] guys decided to concentrate on WavPack as the lossless compressor of choice for their container. Quite an honor... :-)''
* [https://support.pkware.com/display/PKSZLU/PKZIP+Toolkit+for+Windows PKWare]'s .zip format compresses audio by WavPack since version 6.3.2 (2007).  Beware that there is no expectation that other decompression software handles these zip files; even if PKWare co-designed the format and PKZip was the original .zip implementation, their subsequent compression methods are outside the ISO/IEC standardized zip format specification.


->[http://www.wavpack.com/#Software WavPack Software Section]
== Hardware Support ==
* iRiver iHP-120/iHP-140 with the open source [http://www.rockbox.org Rockbox firmware]
* Roku PhotoBridge HD (with [http://www.wavpack.com/downloads.html#binaries plugin])
->[http://www.wavpack.com/index.html#Hardware WavPack Hardware Section]
== Technology description ==
To ensure high-speed operation, WavPack uses a very simple predictor that is implemented entirely in integer math. In its "fast" mode the prediction is simply the arithmetic extrapolation of the previous two samples. For example, if the previous two samples were -10 and 20, then the prediction would be 50. For the default mode a simple adaptive factor is added to weigh the influence of the earlier sample on the prediction. In our example the resulting prediction could then vary between 20 for no influence to 50 for full influence. This weight factor is constantly updated based on the audio data's changing spectral characteristics, which is why it is called "adaptive".
The prediction generated is then subtracted from the actual sample to be encoded to generate the error value. In mono mode this value is sent directly to the coder. However, stereo signals tend to have some correlation between the two channels that can be further exploited. Therefore, two error values are calculated that represent the difference and average of the left and right error values. In the "fast" mode of operation these two new values are simply sent to the coder instead of the left and right values. In the default mode, the difference value is always sent to the coder along with one of the other three values (average, left, or right). An adaptive algorithm continuously determines the most efficient of the three to send based on the changing balance of the channels.
The developer has developed a unique data encoder for WavPack that he believes is better than Rice coding in two different areas. It is impossible to encode more efficiently than Rice coding because it represents the optimal bit coding (sometimes known as the Huffman code) for this type of data. WavPack's encoder is slightly less efficient than this, but only by about 0.15 bits/sample (or less than 1% for 16-bit data). The first advantage of WavPack's coder is that it does not require the data to be buffered ahead of encoding, instead it converts each sample directly to bitcodes. This is more computationally efficient and it is better in some applications where coding delay is critical. The second advantage is that it is easily adaptable to lossy encoding because all significant bits (except the implied "one" MSB) are transmitted directly. In this way it is possible to only transmit, for example, the 3 most significant bits (with sign) of each sample. In fact, it is possible to transmit only the sign and implied MSB for each sample with an average of only 3.65 bits/sample.
This coding scheme is used to implement the "lossy" mode of WavPack. In the "fast" mode the output of the non-adaptive decorrelator is simply rounded to the nearest codable value for the specified number of bits. In the default mode the adaptive decorrelator is used (which reduces the average noise about 1 dB) and also both the current and the next sample are considered in choosing the better of the two available codes (which reduces noise another 1 dB).
The developer has decided to not use any floating-point arithmetic in WavPack's data path because he believes that integer operations are less susceptible to subtle chip to chip variations that could corrupt the lossless nature of the compression, the Pentium floating point bug being a blatant example of this. It is possible that a lossless compressor that used floating-point math could generate different output when running on that faulty Pentium. Even disregarding actual bugs, floating-point math is complicated enough that there could be subtle differences between "correct" implementations that could cause trouble for this type of application. To further ensure confidence in the integrity of WavPack's compression, the encoder includes a 32-bit error detection code to the generated streams.
WavPack source code is very portable. It has been compiled on several Unices (Linux, Mac OS X, Solaris, FreeBSD, OpenBSD, NetBSD, Compaq Tru64, HP-UX...) as well as Windows, DOS and OpenVMS. It works on architectures such as x86, ARM, PowerPC, SPARC, DEC Alpha, PA-RISC, MIPS, Motorola 68k...


== External links ==
= Links =
* [http://www.wavpack.com/ Official website]
* [http://www.wavpack.com/ Official website]
* [http://www.rarewares.org/lossless.html Unofficial multiplatform versions] at RareWares
* [https://github.com/dbry/WavPack Github repository]
* [[Lossless_comparison|Lossless Codec Comparison]]
* [http://www.rarewares.org/lossless.html Unofficial compiles] at RareWares. As of 2023: 5.50 for Windows and 4.32 multiplatform
* [[EAC_and_WavPack | Configuring EAC and WavPack]]
* [https://en.wikipedia.org/wiki/WavPack WavPack at Wikipedia]
* [https://wiki.multimedia.cx/index.php/WavPack WavPack at Multimediawiki] (not updated with version 5)
* [[Lossless_comparison| HA Wiki's Lossless Codec Comparison]] originally by [[User:Rjamorim|Rjamorim]]  
* An older (2005) performance comparison of lossless audio compressors {{webarchive|https://web.archive.org/web/20151027213336/http://members.home.nl/w.speek/comparison.htm|2015-10-27}} by Speek, using WavPack version 4.0
== References ==
<references/>


{{navbox audio codecs}}
[[Category:Codecs]]
[[Category:Codecs]]
[[Category:Lossless]]
[[Category:Lossless]]

Latest revision as of 15:28, 30 May 2024

WavPack
Official WavPack logo

Hybrid Lossless Audio Compression
Developer(s) David Bryant
Release information
Initial release {{{released}}}
Stable release 5.7.0 (2024-02-29)
Preview release {{{preview_release}}}
Compatibility
Operating system Windows, MacOSX, Linux/BSD/Unix, ...
Additional information
Use Encoder/Decoder
License BSD license
Website http://www.wavpack.com/

WavPack (pronounced "wave-pack") is a lossless audio codec, also offering optionally a hybrid lossless/lossy mode. It is distributed as a free open-source encoder/decoder with a library and a large number of tools, including a Windows GUI and a range of plugins for both audio players and other software. Third party implementations are available, including ffmpeg. WavPack supports and/or can be played back on a large number of platforms/OSes including mobile (Android, iOS), portable (Rockbox) and even web apps.

WavPack is arguably the most feature-rich lossless compressor, supporting a unique range of audio signals including Direct-Stream Digital. Everyday use is supported by a wide range of players and taggers, but conversion is likely safest done with applications that invoke the official tools (rather than e.g. ffmpeg's implementation) – and special features might require the user to apply the WavPack executable directly, for example with drag+drop, see the #Using WavPack section below.

Performance-wise, WavPack defaults to a fast codec – less CPU intensive than ALAC, but typically not as fast as FLAC or TAK, especially in decoding CPU usage.[1] In the age of low-power portable Rockbox-equipped players, WavPack could be seen as a reasonable middle ground between FLAC's low CPU footprint and long battery life, and the smaller files but more CPU-intensive Monkey's Audio[2] – invoking WavPacks high mode and extra compression that would compress to smaller sizes than FLAC.

WavPack has inspired other codecs[3] and their features[4]. For more on WavPack, including on its history and technology, see the Wikipedia entry.


Features

For an end-user considering WavPack as audio format, its feature-richness might be the big selling point. WavPack supports pretty much all the more common features noted at HA Wiki's Lossless Codec Comparison as in the following first list, but several users might consider the more unique features listed under the subsequent headline.

  • Seekable and streaming playback.
  • Error handling: upon playback, it will detect and report corrupted frames, mute to protect against static/noise output, and continue playback. Since version 5, WavPack can also check for corruption without decoding, hence quicker than any decoding format. Optional MD5 audio checksum can also be added upon encoding for file fingerprinting.
  • High-resolution audio support (see next headline).
  • Multichannel support: currently capped at 256 channels, supports WAVEFORMATEXTENSIBLE channel masks.
  • Piping support for encoding, and support for RAW PCM input/output.
  • Non-audio chunks (RIFF and similar) stored; by default, WavPack will not only encode/decode the audio losslessly, but store the non-audio chunks and restore them into a file bit-identical to the original.
  • Tagging: APEv2. (ID3v1 is possible, but not advisable.)
  • Cuesheet support. In practice, some applications handle embedded cuesheets better in WavPack than in some other formats.
  • Unicode support.
  • Can be used in the Matroska container.
  • Windows GUI available.
  • Multithreading (from version 5.7.0).

WavPack also handles bit depths not divisible by 8, e.g. 20-bit audio (found on some DVDs).

Special/unique features

Most of these features are shared with only a few if any notable codecs, or extend to signal types or file types others do not support (comparisons given).

  • DSD support: can losslessly compress Philips DSDIFF and Sony DSF files (see "Using WavPack" below; no other end-user codec compresses DSD.) ID3v2.3/2.4 tags can be imported. wvunpack can select between DSDIFF and DSF out (i.e. 'convert between the two'). wvunpack can also convert DSD to PCM, but not the other way around. (Lossy, as conversion between PCM and DSD necessarily is.)
  • High-resolution support for bit depth 1-bit to 32-bit integer and sampling rates up to gigaherz range radio frequencies, in integer steps. (2 GHz works although only 1 GHz is officially supported; for more UHF, Monkey's Audio, OptimFROG and MPEG-4 ALS support the entire WAVE range up to 4 GiHz.) Can also compress non-integer sampling rates in AIFF/AIFC/CAF (signals the WAVE format cannot contain).
  • 32-bit floating-point supported – also including CoolEdit/Adobe Audition's own float format (use the -a option only if the .wav was generated by CoolEdit/Audition). (This line like OptimFROG.)
  • As much as 256 channels currently supported (from version 5.5.0 on; can be extended to the thousands – more than any codec except MPEG-4 ALS (which is capped at 66536).)
  • Hybrid lossy/lossless mode (can also be used as lossy – OptimFROG also has such a mode.)
  • For LPCM it can read and output to WAVE (including the RF64 format extension used for large files and from 5.70 also BW64), to Sony's Wave64, AIFF/AIFC (both endiannesses) and CAF (ditto) – with full restore of also non-audio parts to bit-by-bit the original file in the original format. (Monkey's/OptimFROG/TAK do the same to the input formats they support.) Also WavPack can handle too large noncompliant "WAVE" files (by default, those will be restored to bit-identical the same as the flawed input file – optionally one can force output to compliant RF64/W64 files).
  • Recompression: Can recompress .wv files in place, with tag transfer. (Like FLAC on .flac files.)
  • Drag and drop support: Dropping a file on to wavpack.exe/wvunpack.exe will encode/decode it to source directory. (Similar to FLAC.) From 5.5.0, one can also apply options to drag and drop by renaming the executable, and drop several files.

Like FLAC/TAK/OptimFROG, WavPack employs a "wasted bits" strategy to handle cases of n "actual bits of signal" zero-padded and stored as N bits; such signals can be found in certain DVDs, but also as "fake high resolution" where a 16-bit signal is merely put in a 24-bit file to look impressive. WavPack handles more "fake high resolution" cases than just zero-padding. 5.7.0 introduces an further improvement to capture similar patterns in 32-bit integer files generated by "naively converting from 32-bit float". That particular mode is disabled by default and is arguably best left to power users (invoking it with --optimize-int32) as only 5.7.0 can decode as lossless; to earlier versions and players they will be presented as lossy without correction file (and will indeed be lossy with differences around -138 dB down).

Limitations

The following bullet item list is hardly of interest except for special purposes; WavPack supports nearly every input format that any competing codec handles. One exception is the legacy AU/SND, apparently supported only by Monkey's Audio.

  • DSD: Will reject DST-compressed DSDIFF (which are already compressed heavier than WavPack does) and Wideband Single-bit Data files (apparently, the Tascam and Korg devices which can produce these, can also export to other DSD formats).
    Also, DSD files cannot be encoded as hybrid with correction files.
  • 64-bit float is not supported. (Apparently no other lossless audio compressor can support it either.)
  • wvunpack can force output to a different format than input, and for AIFF/CAF also select endianness, but it cannot force output to different versions of big-endian AIFF (it will avoid AIFC as long as the signal can be fit in the original AIFF container) nor BW64 – nor select between WAVE_FORMAT_PCM and WAVE_FORMAT_EXTENSIBLE. Few other formats do allow for such output selection; reference FLAC can from 1.4.3 offer some wider choices than wvunpack can.
  • Although all non-audio will be stored, --import-id3 can not import every type of ID3 tag to APEv2. (5.70 imports more tag types than previous versions, yet some users might want use use e.g. Mp3tag to copy over more tags from the original.) Also, unless --allow-huge-tags is specified, size is limited to 1 MB; older software might not read larger tagsets (but no known playback incompatibilities are known).
  • Some file formats have features stored in file headers (like loop points, or for AIFF possibly non-integer sampling rates) which will not be visible to the end-user when trying to play back the .wv file in a typical player. They are nevertheless available to certain audio editing software plugins, and will in any case be restored upon decoding.
  • Some features are unsupported by several applications: in particular, support for correction files is only found in a few players.
  • The most significant third-party implementation (ffmpeg as of version 7.0) has bugs waiting to be fixed.

As of 5.5.0 and above, MacOS versions must be built with e.g. HomeBrew, and Windows XP is only supported through a special executable (available in version 5.6.0 at wavpack.com, upgrade from previous unofficial build posted at HA is strongly advised). WavPack version 5 discontinues some features, but version 4.80 is still available to convert any version 3.x files that might still exist.

WavPack has traditionally had less hardware support than FLAC (Rockbox having been the most notable platform, others listed at https://www.wavpack.com/index.html#Hardware ), but with WavPack playback through Android and iOS players, the distinction between "hardware" and "software" is arguably blurred. The Android OS does not natively support other lossless audio formats than WAVE and FLAC, so there have been issues getting certain Android solutions to recognize other media files including WavPack.[5]

Information for users of other codecs (and older WavPack)

Parts of this section will be less relevant to users who primarily decode and convert through player software, rather than directly invoking the executables. WavPack is the only "major" lossless encoder with separate executables for encoding (wavpack) and decoding/info (wvunpack).

Even for features that are comparable between codecs, they may behave different – or default to different behaviour – out of the purpose they were designed to address, their development, or other design choices.

  • WavPack is designed as a file compressor for audio files – this like Monkey's, TAK and OptimFROG, but in contrast to FLAC and ALAC which are audio compressors. The difference is in the ambition to store all non-audio information (and in the correct order). Using reference FLAC one might "opt in" on non-audio parts by giving options; using WavPack one can "opt out" and discard this information.
    • Note: This difference is irrelevant for CD ripping. Contrary to a common misconception, CD audio is not stored as WAVE – nor in any sort of file. Thus, using a file compressor gives no more "true" copy of a CD. (WavPack's support for embedded cuesheets might – depending on player application – give a better user experience for those who prefer to store one file per CD, but that is not due to how CDs work.)
  • MD5 is opt-in (the -m switch) – even if verification is requested and the MD5 is calculated, it is only written to file if specifically requested. TAK and OptimFROG work similarly in that they also require the user to opt-in on MD5. FLAC, ALAC and Monkey's all work different: FLAC includes MD5 (though some encoders make exceptions under some circumstance), ALAC has nothing such – and Monkey's MD5s are not comparable with others, as it hashes the encoded bitstream.
    • Also, WavPack computes MD5 using the source's endianness (endianness is like the distinction between "4th of July" and "July 4th"), and so MD5s may differ between WAVE source and AIFF/CAF source for the same audio. (At least a recent foobar2000 will handle them without giving false warnings.)
  • Like Monkey's/TAK/OptimFROG – but unlike FLAC and ALAC-in-MP4 – tags are at the end of the file. Consequences for users are that retagging will not trigger full file rewrite, but sometimes applications may spend longer time displaying art and viewing tags.
  • Users of "older WavPack" might take note that version 5 discontinues some features, like -p, and also the -e for self-extracting files – those and other older files can still be converted, but the ancient WavPack 3 with .wav extension requires version 4.80.0 (still available).

Performance – file size, CPU load

Rewind twenty years, to 2004 hardware costs, compression ratios did matter much more – also, several formats would be too heavy to even play on portable devices, and the official WavPack site would warn against the -hh mode for that use even if it were not heavier than the fastest Monkey's Audio mode. Fast forward to now, enthusiasts will still compare performance even if ordinary users may take note that impact on cost is often negligible. Different considerations may apply when a drive is near full. The HA wiki's lossless comparison article compares speed and compression ratio on CDDA on the respective codecs' default setting, taken from van Beurden's comparison studies. The test corpus is chosen to be a "wide" selection, and most music collections are biased in one direction or another genre-wise; users who are concerned about compression might look up the individual sources in the study and/or make a test sample from their own collection. By and large, the following observations can be made:

  • WavPack defaults to a fast codec, between FLAC and Monkey's; is not so heavy on decoding CPU as to cause actual practical problems, although it officially recommends against -hh "for use on vintage portable devices" – it should be fine on anything modern. Even -hh seems to decode lighter than Monkey's fastest mode.
    • The "between FLAC and Monkey's" hold for "default encoding and all decoding". Like most modern codecs, WavPack can be set to exert more encoding effort without affecting decoding load: the -x switch. Thus, decoding for e.g. ReplayGain tagging will be slower than e.g. FLAC in all modes, but faster than Monkey's – and recompressing with a slow -x setting (which can be done in the background) will not make the files any heavier to process later. (Indeed, -x sometimes makes decoding lighter, although unlikely to be noticed except by measuring it.)
    • Playback on Android might be less battery efficient than FLAC, which can take advantage of the OS' native support. The difference is likely small for power-hungry players (like VLC).
    • On the other hand, integrity verification can be done lightening-fast, without decoding (presuming WavPack 5 file format and WavPack 5 decoder).
  • Compressing CDDA: WavPack can compress to slightly smaller files than (reference) FLAC; the difference has diminished with the most recent FLAC releases, but "in return", modern CPU speeds might have made the more expensive WavPack settings more tempting, especially when one can re-encode in the background.
  • Compressing high resolution signals and multi-channel: The "extra" resolution might be a mixed bag of upsampling artefacts, tape hiss, sometimes geniune overtones (and for bat enthusiasts, actual interesting audio). There are different kinds of samples one might call "fake high resolution", and different properties of such – upsampling or bit depth – are handled different by the codecs. WavPack is known to handle some properties exceptionally well ("wasted bits" are exploited also by FLAC and TAK, but WavPack and OptimFROG are capable of detecting more "wasteful" patterns; Monkey's and ALAC cannot exploit wasted bits at all) – and others lesser. Several codecs benefit from spending more effort on high resolution signals, and WavPack users might consider to (re-) compress high resolution and multi-channel with as slow setting as -hx4, presuming it can be done as background recompression where time is not much of an object; decoding load is largely unaffected (sometimes slightly improved) by the high -x.
    • For 32-bit float, there is not much competition, and WavPack might be the natural choice for compatibility; it does outcompress Monkey's recently-added float mode. Those files are not very common in the wild, and users with a sizeable collection of 32-bit files for audio processing will likely choose codec for compatibility with their DAW software. WavPack 5.7.0's special setting for 32-bit integer converted from 32-bit float might be an option in such situations.
  • Users who compare nearly tied compression levels between codecs, should take into account how metadata storage affect total file size. WavPack defaults to storing the source's metadata, which may include big album art; on the other hand, FLAC defaults to leaving some kilobytes padding in the file.


Using WavPack

For everyday use in what other lossless codecs can do, just play it back in a supported player – many of which support tagging, and so do several tagging software. Several of these players can also encode to WavPack, invoking the official tools.

Certain more advanced uses are not accessible through player software – not even if they invoke the official tools – and are best invoked through the WavPack executables directly. For example, you cannot expect non-audio data (for full file restore) to be preserved when encoding/decoding through players, as they usually pass on only the audio; this is not particular to WavPack, but must be expected if you want to store non-audio chunks in other formats that support it. Also, WavPack supports input formats that might exceed the player's internal decoding; e.g. trying to convert DSD with foobar2000 will yield a warning that it will not be lossless (also, converting DSD to PCM leads to files many times the size, being inherently different formats), and the same will 32-bit integer in 32-bit foobar2000 (which uses float internally).

Encoding/decoding by drag and drop (Windows)

The simplest encoding/decoding might be dragging and dropping a (supported) file to wavpack.exe (/wvunpack.exe). Then the file will be encoded/decoded with the default options. Dropping a .wv file onto wavpack.exe will recompress it, prompting before overwrite (again, using default settings – possibly a bad deal if it was encoded with high -x switches). Drag and drop also works on a shortcut to the executable. It is not possible to drop a folder, but from version 5.5.0, there is a way to drag and drop several files.

From version 5.5.0, drag and drop supports options by renaming the wavpack/wvunpack executable. The user can rename a copy of the executable according to preferred settings, which will be applied to the process upon drag and drop. The example given by the developer in in this HA forum post[6] uses encoding options that many WavPack users will recommend (better compression than default, verification and MD5 fingerprinting), and novice users can choose to copy that filename for the executable. For fine-tuning performance or for more specialized tasks, more options are described below.

Basic command line encoding/decoding (for Windows: command-line hints here)

The basic encoding usage is wavpack filename (which creates filename.wv) – this is what drag and drop accomplishes. Wildcards are supported, e.g. wavpack *.wav (but not simply wavpack *). For a single input file, one can specify output like e.g. wavpack infilename.wav -o outfilename.wv (on Windows, the -o can be omitted). Input file extension ".wav" can be dropped, and output ".wv" extension as well – but wavpack foo will only find foo.wav, not e.g. foo.w64 – and not a "foo" with no file extension. (Power users may take note that for --raw-pcm input, the encoder will not look for foo.wav but rather for foo.raw.)

The basic decoding usage – as will be accomplished by drag and drop – is wvunpack filename.wv. By default, wvunpack will restore the exact same file (metadata and file structure and all; it will know the original file name extension but not the rest of the file name – timestamp can be stored by using -t.) If only audio was encoded (conversion from a player would usually work this way), output defaults to filename.wav. Output filename can be specified, and just like for the wavpack encoder, file extensions can be dropped; e.g., wvunpack foo -o bar (or on Windows, dropping the -o) will decode foo.wv to bar.<original file's extension>. This is arguably advisable: wvunpack will not override output format by setting file extension. E.g. if the input was a CAF file, wvunpack foo -o bar.w64 is still a CAF file, and the user has only managed to mislead themselves. To force output format, see the #Decoding options paragraph.

Several input files

To give several filenames as input to wavpack/wvunpack, other than through wildcards, there are (for historical reasons) slight differences between the Windows version and the *n*xes: Windows (requires WavPack 5.5.0): use the --drop option as in the above example given by the developer. It is intended for drag and drop (hence the name of the option) and will write the output to same directory as source. However it can also be used with command-line: wavpack --drop firstfile secondfile will compress firstfile.wav to firstfile.wv and secondfile.wav to secondfile.wv. Note that without the --drop, the command wavpack firstfile secondfile will compress firstfile.wav to secondfile.wv, as -o is optional on Windows – indeed that is why the --drop had to be introduced. An arbitrary number of files can be processed, e.g. wvunpack --drop firstfile secondfile thirdfile fourthfile fifthfile will decode firstfile.wv, ..., fifthfile.wv. For *n*x, one can omit the --drop.

Applying options

For tuning performance or other settings, one might want to apply command-line options. Some external applications can apply options without the user having to type – e.g. encoding with foobar2000, there are two compression sliders, one for the fast-to-extra-high and one for the -x settings (see below) – but for command-line one will have to type them, and also in the Windows GUI. Options can be concatenated for short, like for example writing -hh -x2 -m -v -y as -hhx2mvy.

The user should beware that the wavpack encoder and the wvunpack decoder (and wvtag/wvgain) have to "re-use letters". While some do the same in the wvunpack and wavpack (like -d for delete input file, -y for "yes to all", -t to preserve timestamp, and -l for (Windows only) "run with low priority") and others cover the same purpose in both executables (like -m and -v), the user may be warned that certain letters do not. E.g. -b, -c, -n cover completely urelated functions upon decoding vs upon encoding.

5.7.0 introduces multi-threading options for both encoding and decoding, invoked with --threads=<number 1 to 12>, or simply --threads to let WavPack choose. Multithreading does not reduce overall CPU load, but unless the CPU is already working at max, it will do one or a few files in fewer seconds; thus it is invoked by default for the CoolEdit plugin. For encoding, it leads to slightly different files, with usually very small size impact.

Encoding options (lossless)

Encoding using -hxm seems a sensible trade-off between compression and CPU load. Some selected options are described as follows; for an exhaustive refence, see the manual (online, or included as wavpack_doc.html in the distribution).

  • Compression. WavPack has four compression modes that affect compression as well as encoding and decoding time: fast (-f), default, high (-h) and very high (-hh). The CPU load of -hh is measured to around twice that of -f (and could in the early 2000s be too heavy for portable players, although it does decode faster than any Monkey's). On top these modes, the optional extra processing -x1 to -x6 settings will apply extra compression effort that does not increase decoding CPU load. -x without number is synonymous to -x1, which is often recommended (in all modes, fast/normal/high/extra high). The official manual calls -x4 to -x6 "extremely slow", but the size gains might be significant for high resolution audio in particular (van Beurden's revision 5, testing -x4).
    • 5.5.0 introduces optional switches for the default compression: -g for normal mode and -x0 for "no -x". These are redundant for basic use, but can be used to switch off options already given (e.g. in renamed executables, or custom builds): -x6 -x0 will switch off the extra processing, and -h -f -g will encode as normal, whereas previous versions would abort with an error.
    • With DSD files, there are only two compression settings, normal and high; the option -f will select normal, -h/-hh will both select high, and the -x switches are silently ignored.
  • Guarding against errors upon encoding: The "-m" switch will compute an audio MD5 sum (like FLAC does by default) and store it for later verification. The "-v" switch will verify by decoding the file after it has been written to disk[7]. -vm will do both – that is, calculate the MD5s to verify, and store it. Using the corresponding switches in wvunpack will check without producing output file, however wvunpack also has a faster corruption check for WavPack 5-encoded files: -vv.
  • --import-id3 will import ID3v2.3/2.4 tags present in the source file – typically in Sony DSF files – and convert them to WavPack's preferred APE tags. (Not all tags are supported, but the full tags chunk will be kept for restoring the original file.) By default, importing is limited to 1 MB; for more, use --allow-huge-tags. Same option works in wvtag; indeed, one can encode first and then afterwards "import" the tags from the WavPack file using wvtag --import-id3 wavpackfile.wv; this provided that these data have not been deleted by the following -r option:
  • -r: remove non-audio chunks. By default, WavPack will store these in the .wv file for later bit-by-bit restoration of everything, not only the audio. Use -r to throw them away and encode audio only – like encoding through most players appear to do.
  • -t: copy input file's time stamp. (To restore the file with the original time stamp, use -t both when encoding and when decoding.)
  • --pause: (Windows only!) waits for keypress at the end. Useful for reading output before exit when calling wavpack/wvunpack in a separate window (which both drag-and-drop the Windows front-end do).
  • -y: "yes" to everything. Use with caution, will overwrite. From 5.5.0 there is also a --no-overwrite that will skip instead of asking to overwrite.
  • -d: delete source file upon successful completion. Again, use with caution.
  • -l will force WavPack to run at low priority (Windows only)
  • -c: this is for hybrid lossless, see below.

WavPack can recompress .wv files in place (using a temporary file until done). For example, wavpack -hx4mvy wavpackfile.wv will compress wavpackfile.wv in high mode using -x4 extra processing, writing everything (and an audio MD5 checksum) to a temporary file with tags transferred; close and then re-open the temp file to re-read for verification – and only once verified, replace the old wavpackfile.wv. wavpack -hx4rlmvy wavpackfile.wv will also run with low priority (assuming the Windows platform), and will discard non-audio chunks – that is, the ones used to restore the original file's metadata; the .wv file's APE tags will still be copied. Some operations do require recompression even if the user would not demand it; For example, wavpack cannot add MD5 sum to a .wv file without recompressing it. Also, if the user wants to discard the original file's headers/footers, that can be done upon decompression or recompression – but not by simply removing them from the .wv file. There is no out-of-the-box facility to recompress based on how heavy the original file was compressed, or to keep the smallest file.

(Incomplete:) hybrid lossless & lossy encoding

(Needs to be expanded. Notes: DSD can currently not be hybrid-encoded and floating-point files should not be. The correction file will be omitted by a lot of applications/players, including VLC, mplayer and ffmpeg; thus, using ffmpeg or ffmpeg-based players to convert/play hybrid-encoded WavPack will be lossy. For WavPack in Matroska, there doesn't seem to be any player that will play both the lossy stream and the correction stream, although mkvmerge/mkvextract will import/extract both streams. foobar2000 can play hybrid lossless .wv+.wvc, but will omit a Matroska-encapsulated correction stream.)

Basic use: the -b switch – and for losslessness, use -c to create a correction file. A numerical argument for quality is mandatory: if < 24 it will signify bits per sample and if > 24 it will signify kbit/second. Decimal separator is . even if your locale uses the comma. For example, wavpack -b12.5 filename will create filename.wv of bit rate 12.5 bits per sample. For an example that creates filename.wv at at most 234.56 kilobits per second and a correction file filename.wvc, the following commands will work:

  • In all versions, wavpack -b234.56 -c filename. Or equivalently wavpack -cb234.56 filename
  • From 5.70, also wavpack -c234.56 filename will do the same. Thus, a user can avoid the "b" altogether, eliminating the risk of loss from forgetting the "c".

More options can be added, like wavpack -cb234.56 -mhx filename to compress in high mode with extra processing and stores the (original PCM's) MD5 sum. When filename.wv and filename.wvc are both present, the original file will be restored completely by decoding the usual way by wvunpack filename (or wvunpack filename.wv, but not wvunpack filename.wvc). Playback of the .wv+.wvc is also lossless provided the player application supports correction files (like foobar2000, but few do). filename.wv can be copied to a different location without compression file and played in the same way as if it was encoded as lossy in the first place; the decoder will only look in the same path and for same file name except with .wvc extension.

If a high enough lossy quality is specified, it is possible that the file can losslessly contain the entire signal. If so, WavPack will report at the end of the encoding process – but that information is not stored in the file. It can be inferred later from the small .wvc file, and if that is lost: if -m was used upon encoding. WavPack will refuse to recompress lossy-generated .wv to "lossless .wv" as that would make a false pretense of being a lossless file. (That goes even in the "that information is not stored in the file" case just mentioned.) If a lossless hybrid with correction file is recompressed, the default is to create a single-file lossless .wv; from 5.7.0, the old .wvc file will then be removed (as it does no longer belong to any .wv file), but earlier version would need to use the delete switch.

Advanced use: The encoder has several options to tune lossy quality through e.g. noise shaping.

Decoding options

In addition to the basic usage above (drag and drop or wvunpack filename.wv), the wvunpack executable offers several options. For use with the Windows front-end or drag and drop, the Windows-only --pause (waits for keypress at the end, like for wavpack.exe) is essential to read the output report. Also Windows-only options like --drop and -l work as for wavpack.exe, and so do -d (use with caution!) and -y (ditto!) as well as -t.

  • Output filename can be set with wvunpack infilename.wv -o outfilename (the -o being superfluous on Windows, where – in the absence of --drop – the second filename will be assumed to be output name). Then wvunpack will affix the file extension of the original file (say, outfilename.wav if the wavpacked file was somefilename.wav). The wavpack encoder detects the file type from content, and so wvunpack will not "fix misleading extensions" automatically; the user can provide a giving full output filename with extension, but note that this will override the name only but not the type. To make sure that -o out.aif indeed produces an AIFF, separate switches have to be employed.
  • To force output file format, one needs to apply options to wvunpack. The following are for PCM output: --raw-pcm, --wav, --w64, --caf-be, --caf-le, and from version 5.6.0 on also --aif and --aif-le.
    • These will delete non-audio chunks and replace them with a fresh file header: there is no option to "unpack to WAVE and restore the original headers if the original file was WAVE". wvunpack --wav will select RF64 if (and only if) exceeding WAVE's 4 GB limit, and wvunpack will select old AIFF over AIFF-C if the audio data permit it.
    • For DSD, those format switches will also force a – necessarily lossy – conversion to PCM. To switch losslessly between DSD formats, there are also --dsf and --dff (the latter being synonymous to --dsdiff) which again delete non-audio chunks. Note that WavPack cannot force any (also necessarily lossy) conversion to DSD, having no DSD encoder.
    • --raw outputs both PCM and DSD as headerless streams (lossless for both; -r is synonymous; beware that this is not precisely the same as the same letter switch upon encoding).

In addition to decimating DSD for conversion to PCM, there are other options where power users can utilize certain lossy operations by wvunpack, e.g. normalizing floating-point files (recommended before conversion to integer), dropping correction files from hybrid encodes – and --skip and/or --until to decode only a segment of the file. See the documentation. Other options include -b to "blindly" decode until end disregarding errors and corruption (potentially useful to save as much as possible from a destroyed file).

wvunpack -m will decode with MD5 sum calculation. If the .wv file had an MD5 sum stored, it will also be displayed for comparison. However, -m will not give an error if they don't match (and if the .wv is lossy without correction file, they won't: the MD5 stored is that of the original).

wvunpack is also the utility to display information from .wv files even when it does not involve decoding or file output, see the #Other file handling subsection. Inter alia, -s will correctly report the input file type even if it had a misleading extension (like a .wav extension disguising an AIFF file).

Other file handling (incomplete)

The WavPack distribution includes wvunpack, wvtag and wvgain.

File information with wvunpack (without decoding to file)

wvunpack can get information about WavPack files without outputting any uncompressed audio file:

  • -vv: Quick verify without decoding (WavPack 5 files only; from 5.5.0 there is also a more verbose -vvv). Quick verify seems to be unavailable outside the official wvunpack; other applications which verify will fall back to the next item, -v.
  • -vm: Decode and verify, but not write output file. The "m" will compute the the MD5 sum of the decoded PCM and output it along with the .wv file's stored MD5, if such was present. Note that the user has to check manually that they match. A user who never uses -m upon encoding can safely drop the -m from wvunpack too. Note that absent the "v", wvunpack -m will write output file – and that wvunpack -mvv is not allowed, as MD5 calculation requires decoding.
  • -s/-ss: -s displays summary of the file, -ss a long summary including tags. Also there is -f for parseable output, see documentation.
  • -x FIELD: Shows tag, e.g. -x comment shows the <comment> field. -c is synonymous to -x cuesheet. Also wvtag -x resp. wvtag -c do the same thing. -xx (same option for wvtag) can output to file (use -n to avoid decoding) – see documentation.

(To fill in:) Tagging (wvtag) and replaygain management (wvgain)

(... most of these options are available in HA's fave taggers/player? Except the following, maybe?) wvtag --import-id3 wavpackfile.wv will read and "import" ID3 tag stored in wavpackfile.wv's non-audio chunks; this will overwrite existing APEv2. Can also be used with --allow-huge-tags

File formats, versions, decoding and transcoding support

Even if WavPack has expanded its feature set over the years, it has gone to lengths to maintain compatibility. Old WavPack 4.x decoders can restore WavPack 5 files to several file types it cannot encode, but not DSD. The TL;DR is that unless one has an ancient portable device or even more ancient files, one will do just fine with the most recent WavPack, and if not then WavPack 4.80 will suffice – it is still available and can convert ancient WavPack version 3 files. Over the years, one might have encountered WavPack files in (at least) the following variants:

  • .wv (current!) is the file extension used for file formats 4 and 5. Can in most cases be decoded by "anything" (even if the source was e.g. AIFF, which old WavPack cannot read but still restore). Exceptions:
    • WavPack 4 cannot play or restore compressed DSD files (that is new to WavPack 5). Although FFmpeg's wavpack implementation is version 4-based, DSD and DSD-in-WavPack can still be played with an FFmpeg-based player. (But not restored, as FFmpeg has no DSD pipeline, so this is for playback or lossy conversion.)
    • FFmpeg creates non-compliant files for 17 channels and up. WavPack 5.7.0 can decode and repair (FFmpeg itself cannot!)
    • Mono signals encoded to WavPack 5 might require WavPack version 4.3 (from 2005) or later to play. It is doubtful that there are hardware players around using older WavPack; should incompatibilities occur, the easiest is likely then to recompress using 4.80.
    • To older WavPack versions than 5.7.0, encodes with the new --optimize-int32 will be viewed as "lossy without correction file". They are safe to play (and will apparently only introduce loss from the 24th bit, -138 dB down), but only 5.7.0 can see the lossless version and restore the file completely.
  • .wvc, correction files when hybrid lossless encoding is chosen. Honoured by official WavPack, but users might note that wvpack/wvunpack should be fed the .wv file and will err out if pointed at merely the .wvc file.
  • .exe (deprecated): WavPack 4 could compress to Windows self-extracting file (like OptimFROG also offers). This feature is discontinued in WavPack 5. Newer versions of the decoder can still play and decode them – indeed, merely renaming them from .exe to .wv will make them play in players that use the official WavPack library (e.g. foobar2000 will, but VLC will not), and they can be tagged.
    • How to recompress with tag transfer: Rename to .wv and run the recompression.
    • Similar goes for the 3rd party hack ".iso.wv" which could also be mentioned, and also if a .wv file is stored (uncompressed!) in a .zip container renamed .zip.wv: like for self-extracting files, the official decoder might look further into a file to find WavPack headers, and could find them if the .wv file is put first in an uncompressed container. Circa 2010 some developer would use the .iso format to contain single WavPack file, and then auxiliary files like rip logs and artwork; renaming it from .iso to .iso.wv would player applications actually play it. Due to efforts from a few enthusiasts when this hack was introduced, iso.wv is mentioned in several players' official and unofficial feature lists, including Wikipedia pages. These files can be recompressed like the self-extracting files can – this will however discard everything else than the WavPack file.
  • .wav (pre-2004, long deprecated). WavPack 3 and below used the .wav extension, which explains the error message "this legacy WavPack file is deprecated, use version 4.80.0 to transcode" if a user tries to wvunpack a WAVE file.


Using WavPack with 3rd party tools (FFmpeg & more)

Some applications may behave slightly surprising. FFmpeg has its own WavPack implementation and has a few known peculiarities, some which are expected to be fixed and others of unknown status. Android users may need to use the player application's folder to get WavPack files recognized. The tl;dr are that as long as it plays, it plays – but to safeguard against loss of information (e.g. upon conversion), use the official tools. In particular, hybrid lossless correction files are usually not honoured by 3rd party tools. (A player that does, foobar2000, uses the official WavPack libraries.)

Splitting WavPack files by cuesheet

WavPack is a format with good support for storing an album as one .wv file with embedded (or external) cuesheets, but splitting into tracks by way of cuesheets is not straightforward without external tools. Audio players like foobar2000 which support cue sheets can also split upon conversion. Other external applications that will do this splitting – also with more variations of the cue sheet format(s) supported – include

  • CUETools can if it is CDDA (44.1 kHz 16-bit stereo), and can re-encode back to WavPack.
  • refalac can decode & split by cuesheets with the appropriate (official) WavPack library DLL file[8], outputting WAVE or ALAC-in-MP4.

Both refalac, CUETools and foobar2000 use the official WavPack tools for the decoding(/encoding).

FFmpeg's WavPack implementation: differences and quirks

FFmpeg can encode/decode to/from WavPack – which may be seen as attractive from how it also can transfer metadata in one go – but with some limitations and maybe unfamiliar behaviour.
FFmpeg has had some bugs which may cause audio corruption. Although some fixes were applied with FFmpeg release 6.1, users might beware that players and converters that employ FFmpeg as a decoding engine may or may not update that quickly.

  • [Still not fixed as of ffmpeg 6.1] Encoding, multi-channel only: Above 16 channels, when the WavPack 5 format is required, FFmpeg will still attempt encoding to WavPack version 4, but will produce non-compliant files – that ffmpeg itself might not be able to read.
    Official WavPack 5.7.0 can repair those files, at least the "known" defects.
  • [Fixed in ffmpeg 6.1] Encoding, 8-bit PCM only: FFmpeg (up to 6.0) will produce broken files with static noise. No known attempt at recovering them.
  • [Fixed in ffmpeg 6.1] Decoding, any format but rare: A bug FFmpeg's WavPack decoder, discovered in August 2022[9], will cause dropouts in certain files. The bug is "rare" in that no such file was discovered in several years.

Further limitations in FFmpeg's implementation:

  • No MD5 sum and no verification – although it is possible for power users to set up a command-line to compute audio-only checksums of input, decode output to checksum and compare. FFmpeg will also only write WavPack 4 files, hence no fast verification of the bitstream. (FFmpeg can however decode WavPack 5 files, including converting DSD files to PCM.)
  • As a general rule – not specific to .wv – FFmpeg will not honour the input bit depth: for example when outputting WAVE/AIFF, it will default to 16 bits regardless of input bit depth. This default behaviour is not lossless when input bit depth is > 16 bits, and could even induce clipping (with no warning!) if the source is a 32-bit float. To force lossless decoding of 24-bit/32-bit files (WavPack/FLAC/ALAC/TAK/uncompressed) to WAVE/AIFF, the user must extract the bit depth information and specify the respective 24-bit/32-bit output format using ffmpeg's command-line syntax.

    For an extreme example: FFmpeg -i DSDfile.dsf outfile.wv will not store the DSD – rather it will convert to floating-point PCM which is then compressed, typically making for several times the file size, with no warning that it is lossy.

The tl;dr for users who do not have this at their fingertips, is to use other (= official!) decoders when losslessness is desired.

  • Correction files ignored, leading to lossy playback/conversion of hybrid-encoded WavPack files with when ffmpeg or ffmpeg-based players are used.
  • Loss of information that is not directly audio-related: FFmpeg has no ambition of preserving file structure and (R)IFF chunks, so you will not get the non-audio chunks of the files back when using ffmpeg to encode – however it will by default transfer metadata it supports.
  • FFmpeg will sometimes – depending on input format – output 32-bit WavPack files and lose the information that the source was indeed only 24. Not all players support 32-bit files, and verifying that the operation (or an attempted downconversion to 24) was lossless is not straightforward as even fewer applications are willing to compare a 32-bit and a 24-bit file for differences.
    Also for files with bit depth not being 8/16/24/32 is lost; WAVE/AIFF/CAF can handle "17 bit" files by storing 24 and employing a flag to disregard the 7 LSBs, and ffmpeg will lose this flag even when encoding to / decoding from codecs which support it, WavPack and FLAC.

FFmpeg's compression settings can be set with -compression_level 0 to 8, which work different than the reference implementation. Like for ALAC compression, FFmpeg has chosen a default that prioritizes speed over size [10] – while on the other end, FFmpeg's WavPack encoder offers settings even slower than -hhx6. FFmpeg version 7 does some multithreading, although not in the encoding process itself; apparently it offloads the input file reading, improving speed on single-file encoding. FFmpeg multithreads decoding, and could be fast.


Software support (& hardware)

The following list is unlikely to be complete, and the same goes for the lists https://www.wavpack.com/#Software and https://www.wavpack.com/#Hardware : In the age of Android-powered devices with ffmpeg-based playback, it is not feasible to list all players which can in one way or another play this or that format, nor to distinguish clearly between hardware players and software players.

Players

  • foobar2000 advanced freeware audio player plays/decodes WavPack out of the box on both Windows, MacOS, Android and iOS (Windows: supports encoding if wavpack.exe is installed, and redistributes the official wavpack.exe through its "Free encoder pack" addon for encoding. With ReplayGain & cuesheets support.) Also Boom from the same author.
  • VLC multiplatform media player
  • VUPlayer (official plugin, supports encoding)
  • NullSoft Winamp (plugin with ReplayGain & Media Library support) and Winamp-compatible players
  • Windows Media Player and other directshow-based players (MPC, TCMP, RadLight) (with CoreWavPack directshow filter)
  • Cog Audio player for MacOS X.
  • JRiver Media Center
  • XMMS (with Kuniklo's plugin)
  • LAMIP (official plugin)
  • MPXplay for DOS!
  • Aqualung for GNU/Linux
  • Cowon JetAudio Player and CD ripper
  • XMPlay Plugin required (WavPack input plugin) and (bass library) to play '.wv' files

Converters, CD rippers etc.

For conversion (of audio only), one can use several of the players listed above, like Cowon JetAudio, foobar2000 and VUplayer – although some with limitations in the audio pipeline, like for example DSD handling.
More software that support conversion to or from WavPack include:

Taggers and audio info utilities

Audio editors and other tools

  • Audacity has WavPack support (using official libraries) from version 3.2.0 (2022)[12].
  • Adobe Audition and Cool Edit (filter with 32-bit floats & extra info save support)
  • Reaper DAW software for Windows / MacOS
  • SoX can read and write WavPack files. (Write: limited to -hh compression, not file format version 5.)
  • mkvtoolnix – tool to multiplex streams in Matroska container files.

It's worth mentioning the Matroska guys decided to concentrate on WavPack as the lossless compressor of choice for their container. Quite an honor... :-)

  • PKWare's .zip format compresses audio by WavPack since version 6.3.2 (2007). Beware that there is no expectation that other decompression software handles these zip files; even if PKWare co-designed the format and PKZip was the original .zip implementation, their subsequent compression methods are outside the ISO/IEC standardized zip format specification.


Links

References

  1. Martijn van Beurden: Lossless audio codec comparison archive, all comparisons in this wiki article consistent with CDDA results up to revision 6, 2023, using WavPack 5.6.0.
  2. CodecPerformanceComparison at the Rockbox wiki
  3. Monkey's Audio historical FAQ (archived on October 17, 2000)
  4. OptimFROG's "DualStream" hybrid encoding – apparently WavPack coined this phrase
  5. HA thread with link to Android bug report by the Monkey's Audio author
  6. HA forum post on how to rename executable for drag and drop
  7. HA forum comment: verification checks the written file after closing and reopening
  8. refalac usage includes how to split by cuesheet
  9. HA forum thread on the ffmpeg bug in .wv decoding
  10. HA forum comment comparing the compression presets
  11. HA Wiki: Configuring EAC and WavPack
  12. Audacity 3.2.0 release notes