Compressing DSD files with Wavpack 5
Last updated 1 Dec. 2022
If you are reading this you already know that DSD files (DSF and/or DFF) have rather big sizes and large collections of these require plenty disk space. Although the cost of HDDs is relatively low, it can be a problem for some people like those who want to migrate to expensive in terms of GB/$ SSD disks, those who use laptops and don’t want to carry additional external drives or those who can’t afford additional or higher capacity HDDs.
Lossless compression of PCM files with FLAC, ALAC or WavPack has been abailable for quite long but until now, the only possible way to reduce the DSD files’ footprint was using Philips’ DST software to compress DFF files. The problem with this method is that; the software is “Pro” use focused and unavailable to most users, needs very powerful processors both for compressing and for playing back and also the resulting DFF files have very poor tagging capabilities compared to DSF or other formats like FLAC, MP3, etc.
The latest Wavpack version 5.x changes this situation making it now possible to losslessly compress (ie. the compression is reversible without any loss) DSF and DFF files for free by up to 60% depending on source file and compression rate used. The resulting .wv file will play as 24/352 PCM in any Wavpack compliant media players and as “native” DSD in Foobar with SACD plugin 1.04 or later or MPD (Music Player Daemon.
Should you not want to output DSD from DSF and DFF, these can be easily compressed within Foobar using the latest encoder pack just like you would compress WAV to FLAC, ie right click on file/s and select convert then configure to taste. If you want your Wavpacked files to play back as DSD Foobar’s decoder order needs to be altered so Super Audio CD Decoder is at the top of the list:
Version 5.6.0
Changes:
- added: AIFF file import/export support
- added: WATCOM compiler and OS/2 support
- added: cmake support for mingw, builds Cooledit + Winamp plugins
- added: –force-even-byte-depth option for rounding up bit depths
- fixed: detect and report PCM files having non-zero padding bits
- fixed: possible crash when displaying long channel assignments
- fixed: big-endian-sourced “raw” files gave big-endian “wav”s
- fixed: numerous minor issues
Version 5.5.0
Changes:
- fixed: CVE-2021-44269 (encoding crafted DSD file triggers OOB read crash)
- fixed: very long filenames cause stack-overflow crash in all CLI programs
- fixed: the length stored in WAV headers not always corrected when using -i
- fixed: attempting to encode raw DSD audio from stdin sometimes causes crash
- fixed: DSD to PCM decimation: small clicks between tracks and tiny DC offset
- fixed: length update in library-generated WAV headers on big-endian machines
- fixed: sanitize custom extensions read from WavPack files to be alphanumeric
- added: accepting brace-delimited options in the wavpack executable filename
- added: “–drop” option to Windows executables for multi-file “drag-and-drop”
- added” “–raw-pcm” option to wvunpack executable (does DSD –> 24-bit PCM)
- added: “–no-overwrite” option to wavpack executable (to resume sessions)
- improved: build system clean-up including switch to non-recursive “make”
Version 5.4.0
Changes:
- fixed: potential security issue CVE-2020-35738
- fixed: disable A32 asm code when building for Apple silicon
- fixed: issues with Adobe-style floating-point WAV files
- added: –normalize-floats option to wvunpack for correctly exporting un-normalized floating-point files
- updated: Visual Studio 2019 for Windows builds dropped: WinXP support in official binaries
Version 5.3.0
Changes:
- fixed: OSS-Fuzz issues 19925, 19928, 20060, 20448
- fixed: trailing garbage characters on imported ID3v2 TXXX tags
- fixed: various minor undefined behavior and memory access issues
- fixed: sanitize tag extraction names for length and path inclusion
- improved: reformat wvunpack “help” and split into long + short versions
- added: regression testing to Travis CI for OSS-Fuzz crashers
Version 5.2.0
Changes:
- fixed: potential security issues including the following CVEs:
CVE-2018-19840 CVE-2018-19841 CVE-2018-10536
CVE-2018-10537 CVE-2018-10538 CVE-2018-10539
CVE-2018-10540 CVE-2018-7254 CVE-2018-7253
CVE-2018-6767 - added: support for CMake, Travis CI, and Google’s OSS-fuzz
- fixed: use correction file for encode verify (pipe input, Windows)
- fixed: correct WAV header with actual length (pipe input, -i option)
- fixed: thumb interworking and not needing v6 architecture (ARM asm)
- added: handle more ID3v2.3 tag items and from all file types
- fixed: coredump on Sparc64 (changed MD5 implementation)
- fixed: handle invalid ID3v2.3 tags from sacd-ripper
- fixed: several corner-case memory leaks
Version 5.1.0
Changes from 5.0.0:
- added: all new command-line tagging utility (wvtag)
- added: option to import ID3v2.3 tags from Sony DSF files
- fixed: fuzz test failures from AFL reported on SourceForge
- improved: DSD decimation filter (less HF rolloff & CPU use)
- fixed: non-byte audio depths (12-bit, 20-bit) not showing
- fixed: rare case of noise-shaping triggering a lossy mute
- fixed: recognize UTF-8 BOM when reading text files
- fixed: a few portability issues
How to:
First download the compressor zip from the Wavpack web:
http://www.wavpack.com/downloads.html
Select the packet that matches your Windows version (32 or 64bit – only one is needed):
| WavPack Win32 | Windows command-line programs and user manual | Download | 548kB | 5.6.0 |
| WavPack Win64 (for 64-bit Windows) | Windows command-line programs and user manual | Download | 613kB | 5.6.0 |
Next download the free BatchEncoder tool from its developper site (https://github.com/wieslawsoltes/BatchEncoder):Extract the contents of downloaded zip to a folder.
You can either chose a conventional install or a portable installation to a folder you can move or delete when finsihed. If you plan on converting your DSD files all at once the portable installation is probably the best choice but if you think you will be using it again on more ocassions I would recommend the standard instalaltion.
Here are the links:
| Windows 32-bit | Installer | 5.1 | BatchEncoder-5.1-Win32.exe |
| Windows 64-bit | Installer | 5.1 | BatchEncoder-5.1-x64.exe |
| Windows 32-bit | Portable | 5.1 | BatchEncoder-5.1-Win32.zip |
| Windows 64-bit | Portable | 5.1 | BatchEncoder-5.1-x64.zip |
| All | Config | 5.1 | BatchEncoder-5.1-Config.zip |
On the main window configure the “format” as “WV (WavPack)”and “preset” as either “Lossless (Normal compression)” if you prefer higher processing speed but larger resulting files or “Lossless (Best compression)” (see below) if you don’t mind longer processing times to obtain the smallest possible files:Start BatchEncoder from the Windows menu (standard install) or double clicking on “BatchEncoder.exe” (portable installation).The following step is copying “wavpack.exe” from the folder the first download was extracted to to either the standard installation or portable folder of BatchEncoder.
The program is now ready and you can add files through the menu (click on “Edit” and then select “Add files” or “Add directory”) or by drag&drop from Windows explorer the click “Convert”. If no output path is selected files will be output to the source folder which is very convenient if you are processing several folders at the same time.
Once finished you can check each folder and verify that all the original DSD files have a .wv with the same name and tags have been correctly imported (use SACD plugin 1.0.5) then proceed to delete the DSD files and obtain the benefit of compression: plenty aditional free space in your drive.
When you are confident with the process, you can easily automate the process of DSD file deletion by adding an additional parameter in the encoder configuration. Press the F7 key or on the menu click “Options” and then select “Configure presets”. On the window that opens click on “Lossless (Normal compression)” and/or “Lossless (Best compression)” and in the “Commmand-line” box below add a space plus a “-d” after the -h then click “OK”, when done your options should be like the ered rectangle in this picture (Fast compression doesn’t apply to DSD so you can skip it):
The result:
Before
After
If you are not using Foobar, there is a command line utility (wvtag.exe) inside the wavpack zip file that can be used to import ID3V2 tags from DSF files to the compressed wv files. For instructions on how to use it read the included wavpack_doc.html.
DIY-Audio-Heaven 
When the file is played in jriver it is displayed as 24/352 PCM, not DSD.
Why foobar can play it as DSD and others (jriver) as PCM.
Players need to have wv DSD decoding implemented. I don’t use JRiver so I don’t know if they have done this yet or not. The developper of the SACD plugin is without a doubt the most active of them all when it comes to adding new features that is the reason it is possiblke to decode wv to DSD in Foobar.
I guess you’ll need to ask JRiver developpers to add this function.
I posted a question on Jriver forum : https://yabb.jriver.com/interact/index.php?topic=110703.0
David Bryant said that Foobar2000 can only handle PCM internally so it has to work this way, and it plays all DSD formats this way (in PCM). But maybe it was an older version.
Concerning Jriver, they will implement native DSD inside wavpack in next version (23).
Indeed Foobar can only handle PCM that is the reason why the SACD plugin plus a special outmode need to be used to overcome that limitation. Once installed and properly setup Foobar can do DSD fine.
DSD compressed with Wavpack are processed as PCM by standard Foobar but it is decoded to DSD once the correct SACD plugin is installed.
can I convert back the wv file to dsf?
Indeed you can and as this is a lossless process you’ll get exactly the same original DSF you had at the beginning. Bit by bit perfect.
But I couldnt find such option in batch encoder.
“The resulting .wv file will play as 24/352 PCM in any Wavpack compliant media players”
I don’t know about all players, but WavPack native decoder gives out samplerate equal to DSD samplerate divided by 8, when converting DSD to PCM. So 352 is only true for DSD64. And foobar2000 acts the same way (without foo_input_sacd).
What a great article!
May I suggest adding the following command line arguments:
1. for every dsf to wv conversion: wavpack -h -m -v –import-id3 onebitaudio.dsf
2. for single file SACD rips (.dff -> .wv): wavpack -h -m -v -w “Cuesheet=cuesheet.cue” master.dff
There is something I’m not sure of. Lets say I convert a DSD file to WavPack so I end up with a WV file, that’s fine. But then lets say 10 or 20 years go by and I find that file, how would I know that the file originally was a DSD file? Also, how would I know which was, DSD64, 128, 256, etc? If I open the file with MediaInfo it says nothing about the original format. That’s one concern I have about converting my files from DSD to WV because it is impossible for me to keep record of which files was what originally.
Forgot to add, even using wvunpack with -ss I don’t get the correct original format. I just tested this with a DSD128 file converted to WV and I got this:
source format: Microsoft RIFF with ‘wav’ extension
file wrapper: 44 byte RIFF header
Please, correct me if I’m getting something wrong, I’m not familiar with DSD files.
use “wvunpack *.* –dsf” if you want to extract to .dsf files or “wvunpack *.* –dff” if you want .dff files. It is explained at Wavpack’s web site: http://www.wavpack.com/wavpack_doc.html#wvunpack
You could include the format either at the end of the file’s name (eg. xxxxxxxx (DSD64)) or in the containing folder’s name. That is what I do. Another option would be to include in the folder where the files are an empty text file with the format as the title (eg. all wvpack here are DSD64.txt)
Hello . i was wondering why would i add a space plus a “-d” after the -h in the collamd-line options
and what does theese commands do
Hi Ahmed, it deletes de source files after compression. Since the process is lossless and can thus be reverted without any degradation of the content, once finished the source files are not necessary any more and, in case one wants them back for whatever the reason, they can be recreated by decompressing the .wv files.
thanks alot for this information
i have another question : what does (-h) in the command line options ?
will (-h) case any quality loss ?
-h is for “highest” compression which means smaller output files. No matter what compression is used, there will be no quality loss.
Thanks Again : )