WavPack - Revision history

Porcuswiki: A few "and up" on versions (5.7.0 in particular) - with 5.9.0 out there is more reason to avoid the risk of giving the impression that a particular feature is only in particular version

2026-01-23T22:35:40Z

A few "and up" on versions (5.7.0 in particular) - with 5.9.0 out there is more reason to avoid the risk of giving the impression that a particular feature is only in particular version

Porcuswiki: 5.8 update and some corrections.

2025-10-21T16:33:26Z

5.8 update and some corrections.

Show changes

Porcuswiki: New Mediawiki wasn't as forgiving about tags unclosed, fixed. Added some wording about playing.

2024-05-30T15:28:01Z

New Mediawiki wasn't as forgiving about tags unclosed, fixed. Added some wording about playing.

Porcuswiki: On ffmpeg 7, and on .zip.wv and ...

2024-04-12T20:44:37Z

On ffmpeg 7, and on .zip.wv and ...

Porcuswiki: ID3v2.4, Reaper, removed double info, typos, blah blah

2024-04-02T17:10:00Z

ID3v2.4, Reaper, removed double info, typos, blah blah

Show changes

Porcuswiki: A forgotten mention of --optimize-int32

2024-03-30T11:19:30Z

A forgotten mention of --optimize-int32

← Older revision		Revision as of 11:19, 30 March 2024
Line 194:		Line 194:
	** FFmpeg creates non-compliant files for 17 channels and up. WavPack 5.7.0 can decode and repair (FFmpeg itself cannot!)		** 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. If there are hardware players around using older WavPack and failing to play these files, the easiest might be to recompress using 4.80.		** Mono signals encoded to WavPack 5 might require WavPack version 4.3 (from 2005) or later. If there are hardware players around using older WavPack and failing to play these files, the easiest might be 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.		* .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.		* .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.

Porcuswiki: missing word

2024-03-30T10:36:32Z

missing word

← Older revision		Revision as of 10:36, 30 March 2024
Line 85:		Line 85:
	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:		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" – it should be fine on anything modern. Even <code>-hh</code> seems to decode lighter than Monkey's fastest mode.		* 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" – it should be fine on anything modern. Even <code>-hh</code> seems to decode lighter than Monkey's fastest mode.
	** The "between FLAC 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 – 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.)		** 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 – 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).		** 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).		** On the other hand, ''integrity verification'' can be done lightening-fast, without decoding (presuming WavPack 5 file format and WavPack 5 decoder).

Porcuswiki: Sections 1.3 and 2.5, and some other fixes

2024-03-30T10:21:43Z

Sections 1.3 and 2.5, and some other fixes

Show changes

Porcuswiki: code tag

2024-03-28T12:26:12Z

code tag

Show changes

Porcuswiki: 5.7.0 update

2024-03-03T13:05:10Z

5.7.0 update

Show changes

← Older revision		Revision as of 22:35, 23 January 2026
Line 5:		Line 5:
	\| caption = Hybrid Lossless Audio Compression		\| caption = Hybrid Lossless Audio Compression
	\| maintainer = David Bryant		\| maintainer = David Bryant
	\| stable_release = 5.8.0~~/.1~~ (~~2025~~-01-~~27/28~~)		\| stable_release = 5.9.0 (2026-01-16)
	\| operating_system = Windows, ~~MacOSX~~, Linux/BSD/Unix, ...		\| operating_system = Windows, macOS, Linux/BSD/Unix, ...
	\| use = Encoder/Decoder		\| use = Encoder/Decoder
	\| license = BSD license		\| license = BSD license
	\| website = http://www.wavpack.com/		\| website = http://www.wavpack.com/
			http://github.com/dbry/WavPack
	}}		}}

	'''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.		'''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.

	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 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.
Line 57:		Line 58:
	* 64-bit float is not supported. (Apparently no other lossless audio compressor can support it either.)		* 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.		* 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'' and restored, <code>--import-id3</code> can not ''import'' every type of ID3 tag to APEv2. (5.7.0 ~~and 5.8.0 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).		* Although all non-audio will be ''stored'' and restored, <code>--import-id3</code> can not ''import'' every type of ID3 tag to APEv2. (From 5.7.0, importing 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 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.		* Some features are unsupported by several applications: in particular, support for correction files is only found in a few players.
Line 72:		Line 73:

	* 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.		* 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.
	** ''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.)		** ''This difference is irrelevant for CD ripping.'' Contrary to a common misconception, CD audio is ''not'' stored as WAVE – actually not in a ''file'' at all. 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 <code>-m</code> 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.		* MD5 is opt-in (the <code>-m</code> 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.)		** 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.)
Line 89:		Line 90:
	* 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 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 <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>.		* 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 <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.		** 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 special setting for 32-bit integer converted from 32-bit float (5.7.0 and up) 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.		* 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.

← Older revision		Revision as of 15:28, 30 May 2024
Line 60:		Line 60:
	* 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 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.		* 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 6.1) has bugs waiting to be fixed.		* 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.		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.
Line 94:		Line 94:

	= Using WavPack =		= Using WavPack =
	~~WavPack files~~ can ~~be played~~ back in supported ~~players (see below)~~, and several of these can also encode to WavPack, invoking the official tools. ~~However, there~~ are ~~situations where~~ the ~~appropriate WavPack features~~ are ~~accessible only~~ 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. Also, ~~the~~ input ~~format~~ might exceed the player's internal decoding; e.g. trying to convert ~~32-bit integer or~~ 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).		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) ==		== Encoding/decoding by drag and drop (Windows) ==
Line 144:		Line 146:
	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:		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>		* 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>".		* 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.		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).		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).

← Older revision		Revision as of 20:44, 12 April 2024
Line 197:		Line 197:
	* .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.		* .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.		** How to recompress with tag transfer: Rename to .wv and run the recompression.
	* ~~The~~ 3rd party hack ".iso.wv" ~~can~~ also be mentioned ~~here~~: ~~Circa 2010~~, ~~some developer took advantage of how~~ the official decoder might look further into a file to find WavPack headers ~~(like it~~ would ~~have to on the self-extracting files) and used~~ the .iso format to contain ~~a folder with whatever files including one~~ single WavPack file ~~as playable~~. 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 are .iso files, but the .wv extension makes the official decoder search in the container and and play the WavPack file it finds – and so will e.g. foobar2000 which uses official WavPack to play them. Technical reservations apply, and are beyond the scope of these article.		** 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.
	** 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 wv''un''pack a WAVE 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.

Line 219:		Line 218:

	Further limitations in FFmpeg's implementation:		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 DSD.)		* 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. <br/> <br/>For an extreme example: <code>FFmpeg -i DSDfile.dsf outfile.wv</code> 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.<br/>		* 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. <br/> <br/>For an extreme example: <code>FFmpeg -i DSDfile.dsf outfile.wv</code> 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.<br/>
	The tl;dr for users who do not have this at their fingertips, is to use other (= official!) decoders when losslessness is desired.		The tl;dr for users who do not have this at their fingertips, is to use other (= official!) decoders when losslessness is desired.
Line 226:		Line 225:
	* 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. <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 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. <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> – while on the other end, FFmpeg's WavPack encoder offers settings even slower than <code>-hhx6</code>.		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> – 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.