First impressions:
— DST is a significantly most efficient tool for compressing DSD than Wavpack
— WavPack should be much more hardware friendly (decoding speed): current portable players or even standalone one which supports DSD and even ISO files can not decode DST, which makes DSD format a really huge one for µSD cards)
— WavPack is maybe easier to handle (tagging DST/DFF files seems to be possible with ID3v2 but is widely accepted?)
— It's a lot of trouble for a format (DSD) which doesn't bring significant advantage (to say the least) over PCM. But for those who like, it might become popular over DSF, DFF, or ISO (or even DOP-FLAC which I heard from but never see it)
Thanks for your exhaustive testing and sharing your impressions, guru, it's greatly appreciated!
The goal was to come up with an alternative to DST compression, because there are a couple of problems with DST, as far as I see it. The most obvious problem is that it is not readily available, probably because Philips intended it to be just for SACDs – that people might want to have DSD files in their music library and play on portables does not interest them. There's a reference encoder/decoder with source, but it's extremely slow (1/5X realtime on my PC) and the encoder doesn't compress nearly as well as the format is capable of. You can buy the Philips ProTECH encoder for many thousands of dollars, but that's obviously not a solution for most people.
The other problem is that the DST format, while offering very good compression (perhaps approaching entropy), is very CPU intensive, which again is not a problem for Philips because they probably sell/license hardware decoders for SACD. People have optimized the reference decoder in attempts to make it useful in real applications, but it's still not fast enough for many portable players. The best performance I have seen is the decoder in FFmpeg (see below).
My thought was that a freely-available DSD compressor with reduced CPU requirements (compared to DST) would be useful, even if it provided more modest compression. Also, as you point out, there are two major DSD transport formats, and one offers compression but no tagging (Philips) and the other offers tagging but no compression (Sony), so that's the justification for adding DSD compression to WavPack.
Using the Philips ProTECH Audio Converter, I created 10 difference DSD encodings of a single PCM sample using 10 difference SDM settings, and then compressed all 10 using WavPack's two modes and the reference and pro versions of the DST compressors. I measured the decode speed (to 8x decimated PCM) using x86 versions of FFmpeg and WavPack, both running under Wine and using a single thread:
total bytes compr% compr range decode
-------------------------------------------
Original DFF data: 1,591,929,920 0.00
WavPack default: 843,395,464 47.02 41.97–52.38 34x
WavPack high: 708,570,418 55.49 50.22-60.04 10x
DST reference: 694,851,546 56.35 50.01-61.69 5.5x
DST ProTECH: 606,176,506 61.92 54.84-68.20 5.6x
On these files the difference between WavPack "high" and DST pro encoder on the same sample varied from 3.48% and 8.85%, so that pretty much matches your results.
And, based on this quick test, WavPack “high” is almost twice as easy to decode as DST, and the default mode is six times easier, which would certainly make them both more likely candidates for portable decoding than DST.