Very interesting to see how wavpack extends its features.
A thing to note about DST compression is that when you're using anything like foo_input_sacd that does DST decompression using the reference decoder, you're using 4-8 threads at near full utilization for real time playback. Whereas the WavPack decoding is likely going to use 10-50% of a single core.
I also note one issue with CoolEdit playback: DSD *.wv files are really, really noisy when played. It's surely a consequence of the onboard chip (basic Realtek) which doesn't handle 352/32: once dithered to 44,1/16 it sounds fine.
EDIT: at the moment I can't use foobar2000's converter to get DSD/wv files. When I use it, I get very large *.wv file, and they're apparently PCM. I tried to play with foo_input_SACD options (DSD output mode, Edited Master Playback…) without success.
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)
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 34xWavPack high: 708,570,418 55.49 50.22-60.04 10xDST reference: 694,851,546 56.35 50.01-61.69 5.5xDST ProTECH: 606,176,506 61.92 54.84-68.20 5.6x
Just wanted to say congrats Bryant for coming up with a freely available solution for DSD compression and tagging!I've been talking about this since 2013 and glad to see someone has taken up the "cause" :-).I think the folks who sell these DSD downloads should seriously support this if they're serious about DSD.
I'm not familiar with DST tools. I know they're slow but I always thought the main cause was a true lack of optimization. Apparently not… DST compression seems to be really and very strong.
Thanks for warning us about the future change. Do you plan to work further on the DSD compression engine?
if (!(flags & OPEN_DSD_NATIVE)) flags |= OPEN_DSD_AS_PCM;