Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Small DSD/DFF compression test: WavPack vs xz (Read 61466 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Small DSD/DFF compression test: WavPack vs xz

I once downloaded a couple of DSD files from http://www.2l.no/hires/ - and I noticed that one was delivered as .zip, at a pretty decent compression ratio.
In fact, WavPack didn't seem to improve *that* much over zip.

So - out of curiosity, I'd add - I decided to put WavPack up against a quite heavy general-purpose compressor: 7-zip's xz.
Non-rigorous testing on stereo music suggests that xz - even at "Ultra" compression level - is absolutely no match for e.g. default WavPack, but that turned out not to be the case here.

Test corpus: two pieces of music, each downloaded as stereo DSD64 and surround DSD64.
One chosen for being small and delivered as .zip, the other for being Bach (maybe I'll even listen to it), both for being available in both formats.

Compression levels:  Both compression levels chosen for WavPack. Encoded using 5.1.0-x64 CLI (with -m) and manually adding up the times taken.
For xz using 7-zip 17.01 beta x64, compression is much slower, so I chose "fast" to get something that isn't totally off WavPack high - and, "ultra" just to squeeze as much as practically feasible.
Times taken on my slow fanless media-playing Windows 7 desktop:
.wv: 38s.  .wv -h: 167s   .xz fast: 275-ish .xz ultra: go have a shower and come back later.

Not-very-scientific-summary:
  • WavPack doesn't shine that much on this material
  • -h improves - and even more for multichannel
  • Two previous bullet items suggest that compression could be improved if one wants to ...
  • ... which arguably might not be worth the effort unless the DSD bullshit gets widespread and e.g. takes over the market for surround-recorded music. Until then, a lossless format that works and does a decent job could very well be more than enough.

Table over file sizes: From Windows' "Properties" of the files read off in MiB, smallest-file recording stereo & multichannel, then the other:
Code: [Select]
File: 2L-125_stereo-2822k-1b_04.dsf
.dsf 66.4 .xz fast 36.3 ultra 32.9 .wv 33.2 .wv -h 29.3
File: 2L-125_mch-2822k-1b_04.dsf
.dsf 198 .xz fast 105 ultra 94.0 .wv 97.1 .wv -h 85.8

File: 2L-139_stereo_DSF_2822k_1b_01.dsf
.dsf 278 .xz fast 161 ultra 144 .wv 152; .wv -h 120
File: 2L-139_mch_DSF_2822k_1b_01.dsf
.dsf 837 .xz fast 474 ultra 421 .wv 441; .wv -h 360
For the two files delivered as .zip (unknown compressor, unknown parameters), xz fast improves ~7 percent.

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #1
Very quickly…
I have myself a large amount of SACD and DSD files and I use a lot WavPack for DSD encoding. At the beginning I made some stats for my own usage, comparing the two WavPack's presets and sometimes DST encoder. I noticed that WavPack efficiency (compared to the DST compressor) varies significantly from disc to disc (from ~10% to ~20% lower when I compared WavPack -high to DST). I also noticed that WavPack -h is much more enjoyable for compression (~20% between two WavPack presets). As you said, two files are probably not enough to make rigorous conclusions.

I never heard about xz compressor—though I'm a long time user of 7-zip  :-[  Thanks for the discovery :)
So I made a small test myself. I haven't reported the encoding time/speed.
For this comparison I took two SACD I recently bought:
I • “1865 — Songs of Hope & Home from the American Civil War”, from Anonymous 4. Harmonia Mundi USA (2015). DSD Recording
II • “Horizon 9” — Contemporary Music, from Royal Concertgebouw Orchestra. RCO label (2019). PCM recording

The whole disc is compressed as one single DSD file :

Code: [Select]
    DFF (no comp)      DST          WP-high      WP-normal    xz-normal    xz-fast     7z-normal

I   2.763.899 kb       1.109.843    1.257.455    1.513.258    1.698.133    1.832.290   1.698.132            
II  3.530.181 kb       1.209.585    1.535.952    1.811.728    2.041.049    2.228.881   not done

Few words:
• xz seems to be multi-threaded; wavpack isn't. Even then xz with normal setting is rather slow on my Core i7.
• WavPack's efficiency compared to DST encoder is different with these two SACD. The cause might be DSD vs PCM recording but I don't think so (I had many “pure DSD” recorded SACD that don't compress very well with WavPack compared to DST).
• xz -fast files are ~20% bigger than WavPack -normal, which are ~20% bigger than WavPack -high. From these two SACD/DSD discs, WavPack appears to be rather well-tuned.
• I also recall to readers that are not familiar with DSD techniques that DST is not very convenient (no embedded tagging system, rather slow decoding time).

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #2
Don't forget that .xz is not really designed for random access, so you'll be looking at unpacking your entire files to memory or to disk on every playback.

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #3
So, more-or-less retraction time for the pig's nose:

I have myself a large amount of SACD and DSD files and I use a lot WavPack for DSD encoding.
[...]
As you said, two files are probably not enough to make rigorous conclusions.
So I got curious enough to do more testing, and even though I drew "out-of-sample" files last time, it seems not to generalize.
Further testing: The efficiency of .xz and .7z - compared to dedicated audio encoders - varies quite a lot on stereo material too. I had checked with material where WavPack easily could shave off another thirty percent compared to .xz ultra (not percentage points ... the .wv was 0.69 times the .xz). And 7z as well.

With that baseline, then xz suddenly overtaking WavPack normal, was quite a "wow" - and also WavPack "high" shaving off so much as it did compared to the normal.

But, turns out: I compared WavPack to a race where the general purpose compressors happened to fare badly. Hence the "doesn't shine that much" - compared to material where xz was "easily outshone" - might be misleading.

(Actually, testing more I found an audio file which is way "worse": a quiet electronic track where WavPack (and FLAC) filesize are down to 0.3 of the .wav, while .xz ("Ultra") only get down to .67. And .7z ("Ultra") is .49 ... after having taken twice the time. So any testing of this kind needs more files from various genres.)

Don't forget that .xz is not really designed for random access, so you'll be looking at unpacking your entire files to memory or to disk on every playback.
Just like your foo_unpack_7z, right? Except I don't think anyone will bother thinking that about .xz as long as they cannot be played ...

Anyway, .xz doesn't seem to perform consistently enough to be a benchmark unless I pick a much bigggger corpus and leave it overnight(s).

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #4
Thanks for posting these test results! They pretty much match my expectations. And hey guru...nice to see you're still around!

One of the first things I noticed when I started working on DSD compression (which, at the time, had nothing to do with WavPack) is that Bzip2 actually did a pretty good job; in fact it was a while before I had anything that beat it! And this makes sense because of the noise-shaping in DSD, you almost never get long sequences of 1's or 0's; instead the bit is always changing, so some bytes values (like 0xAA) are much more common than other values (like 0xFF). Just taking advantage of the relative frequency of byte values give decent compression of DSD.

The “normal” DSD compression mode of WavPack is byte-oriented also, but unlike complex compressors like bzip2, it does not use large dictionaries to achieve good compression because that would require large blocks (and I wanted to be able to do short, independently decodable blocks for seeking). I also wanted it to be simple and fast, so the fact that it beats general-purpose compressors at all but their highest settings is actually not bad.

What's kind of cool is the default DSD mode actually makes not a terrible general-purpose compressor! You can try it by specifying “--raw-pcm=2822400,1,1” on the command-line.

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #5
I'm compressing my dsd all with the -h option and I get an average of over 50% of file reduction, without the -h option are a little bigger, what is the difference between quality and quality between the two modes?

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #6
There's no differenec in quality, of course, because this is lossless. The "high" mode is what I usually use because (as you say) the files are smaller. The regular mode is useful if you're going to be decoding and reencoding a lot because it's much faster, and if you were playing on a portable device it might be easier on your battery. But if the "high" mode is working well, use it.

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #7
Yes, it works very well the high mode, in fact I always use that, I just wanted to know if there were differences but since I'm not there I will continue to use that .....

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #8
The regular mode is useful if you're going to be decoding and reencoding a lot because it's much faster, and if you were playing on a portable device it might be easier on your battery. But if the "high" mode is working well, use it.

I just made some decoding speed tests. I get speed values from foobar2000 for mobile and with foobar2000 for PC. I made several encodings (DFF, DST, WavPack default and WavPack high, and also FLAC 88.2/24) of the same long (~20 minutes) track (high dynamic orchestral music). I also tested WavPack PC decoding speed with both foo_input_sacd and native component. And for both PC and mobile phone everything was tested with 1 thread, 2 threads, 4 and 8 threads.

Here is the result:

Code: [Select]
                      phone 1 thread   phone 2 threads   phone 4 threads  phone 8 threads  PC 1 thread   PC 2 threads   PC 4 threads   PC 8 threads

DFF                          n o t    s u p p o r t e d   in   f b 2 k   m o b i l e          46.525x        80.012x      102.551        94.820x
DST                          n o t    s u p p o r t e d   in   f b 2 k   m o b i l e          16.016x        15.692x       15.652x      not tested

WavPack -high    (fb2k)   10.119x          17.507x            30.386x          43.323x        12.747x        25.399x       39.362x       47.798x
WavPack -high (foo_sacd)  10.119x          17.507x            30.386x          43.323x        11.119x        22.161x       27.051x       33.466x

WavPack -default (fb2k)   32.851x          56.459x           113.330x         164.031x        38.639x        76.927x      152.142x      214.110x
WavPack -default (f_sacd) 32.851x          56.459x           113.330x         164.031x        22.784x        41.658x       59.141x       73.298x

FLAC 24/88 -8            311.702x         614.419x          1088.604x        1633.005x       400.155x       790.473x     1561.307x     2055.200x

Phone: Samsung Galaxy S8+ Exynos 9 Octa 8895
PC CPU: Core i7-3610QM 4 Core/8 Threads
tested with foobar2000 for PC (1.41) [foo_input_sacd 1.1.0] and with foobar2000 mobile
file loaded to memory — 4 passes — no conversion to integer — no DSP
Flac: converted from DSD with foobar2000, multistage 32, +6dB, 88200 Hz

SIZE & BITRATE:
Code: [Select]
file: 19'43'', orchestral music
DFF:          814.833 Kb    5645 kbps
WV default:   411.145 Kb    2850 kbps
WV high:      354.954 Kb    2459 kbps
FLAC 24/88.2: 362.388 Kb    2510 kbps
DST:          277.846 Kb    1925 kbps

• As you can see, DST seems at first look less CPU consuming on one thread than WavPack -high. But it appears that DST decoding is multithreaded. With eight threads, WavPack -high is three time faster on PC than DST. On one thread, DST decoding speed should be ~4x or ~5x.
• WavPack decoding speed on PC is slower with foo_input_sacd. For heavy batch reencodings from WavPack-DSD source, it seems to be better to disable the component [v 1.1.0] and let the native component do the job.
• WavPack decoding speed on my mobile phone is rather similar to the Core i7 performances. That's a huge surprise.
• WavPack -default setting is three times faster on decoding than WavPack -high. But the latter compresses much better.
• FLAC high resolution is of course much more CPU friendly :)
• DFF (tested with foo_input_sacd enabled) is not really faster than WavPack -normal (native component)… that's surprising. There's no real interest for keeping raw DFF/DSF: WavPack -default files are twice smaller and just a bit more CPU consuming (at least on PC/foobar2000).

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #9
There's no real interest for keeping raw DFF/DSF: WavPack -default files are twice smaller and just a bit more CPU consuming (at least on PC/foobar2000).
Apart from possible compatibility issues? Somewhere in this universe there must be some software that supports DFF/DSF and fails to support (new) WavPack? How is the state of matter on Appleware?
But if your player can do WavPack, then it is king of this very lonely hill too.

I use WavPack for a couple of things that FLAC cannot handle (DFFs and floating-point) - and then I use it for CD rips with pre-emphasis just in case I accidentally delete the tag. That is actually the greatest set ... 14 GB.

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #10
Apart from possible compatibility issues? Somewhere in this universe there must be some software that supports DFF/DSF and fails to support (new) WavPack? How is the state of matter on Appleware?
But if your player can do WavPack, then it is king of this very lonely hill too.
Indeed :)
foobar2000 mobile is available on iOS, and should plays WavPack 5 (PCM and DSD). On MacOS there's Jriver Media Center. Current version (24.xx) also supports WavPack 5.
DFF is still probably useful on specific hardware, like digital audio players and DVD/BR audiophile players. I know that some modern DAP like Fiio are running Android and can handle APK. Therefore, the need for DFF is shrinking :)

 

Re: Small DSD/DFF compression test: WavPack vs xz

Reply #11
The regular mode is useful if you're going to be decoding and reencoding a lot because it's much faster

After the pure decoding speed obtained with foobar2000 dedicated tools, I made a real reencoding test to get the true impact of complexity on reencoding speed. For that purpose I used a 11xSACD boxset (Bruckner complete symphonies, 35 tracks, 9:54:19.160).

Sources formats were: uncompressed DFF/DSF — DST encoding — WavPack default — WavPack high (and for curiosity, I also add FLAC 88,2 KHz and FLAC 352 KHz).

Decoders were:
WavPack: foobar2000 native decoder and foo_input_sacd
DFF: foo_input_sacd and foo_input_DSDIFF
DST: foo_input_sacd only (kode54's foo_input_DSDIFF also supports DST format but it's highly unoptimized: I reached ~1.0x…1.1x speed and therefore aborted the process)

Output format:
Everything was converted to AAC at ~160 Kbps using qaac (iTunes AAC encoder) -v82 [qaac 2.67, CoreAudioToolbox 7.10.9.0, AAC-LC Encoder, TVBR q82, Quality 96] which resulted to 156 Kbps, 48000 Hz AAC files. It's 36 time smaller than the original and it still sounds gorgeous!

Code: [Select]
total time: 9:54:19.160 (12 580 551 648 samples)

DST to AAC:                             Total encoding time: 46:06.031, 12.88x realtime    4'39"/Hour of music
DSF (foo_input_sacd) to AAC:            Total encoding time: 12:56.516, 45.92x realtime    1'18"/H
DFF (foo_input_dsdiff) to AAC:          Total encoding time: 10:38.125, 55.88x realtime    1'04"/H
WV -default (foo_input_sacd) to AAC:    Total encoding time: 15:23.859, 38.59x realtime    1'33"/H
WV -default (foobar2000 native) to AAC: Total encoding time: 16:53.360, 35.18x realtime    1'42"/H
WV -high (foo_input_sacd) to AAC:       Total encoding time: 25:36.625, 23.20x realtime    2'35"/H
WV -high (foobar2000 native) to AAC:    Total encoding time: 26:48.954, 22.16x realtime    2'42"/H
FLAC 24/88 -8 to AAC:                   Total encoding time:  7:05.657, 83.77x realtime    0'43"/H
FLAC 24/352 -8 to AAC:                  Total encoding time: 15:44.172, 37.76x realtime    1'35"/H


DSF:           23.4 GB (25 161 255 266 bytes)      5645 Kbps    100%
DST:            8.36 GB (8 984 891 932 bytes)      2016 Kbps    35.7%
WV -high:      10.2 GB (11 011 315 269 bytes)      2470 Kbps    43.8%
WV -default:   12.2 GB (13 179 996 136 bytes)      2957 Kbps    52.4%
FLAC 24/88.2:  10.3 GB (11 063 193 787 bytes)      2482 Kbps    43.9%
FLAC 24/352:   58.9 GB (63 246 205 254 bytes)     14189 Kbps   251.4%


• On my computer, the difference between WavPack -default and WavPack -high is one minute of encoding time per hour of music. It's not dramatic but could be really boring for big playlist conversion.
• During this test, foo_input_sacd was slightly faster than foobar's native component. Eight threads were used. I don't understand why the result doesn't match the foo_benchmark results I get earlier.
• Kode54's component really makes a difference compared to foo_input_sacd: more than 20% on DFF uncompressed file. Reencoding time was 15 seconds less per hour of DSD64 music.
• PCM sourced encoding with FLAC at 88,2 KHz is ~twice faster than WavPack -default for reencoding purpose.
• PCM sourced encoding with FLAC at 352 KHz needs the same amount of CPU ressouces than WavPack -default for reencoding tasks. Why 352 KHz? Because WavPack 5 decodes internally DSD64 to PCM at 354 KHz if I'm not wrong. I wonder if WavPack's decoding and reencoding performances couldn't significantly increase if internal decoder could work at lower samplerate.
• DST really hurts reencoding speed: it's twice slower than WavPack -high and up to three time slower than WavPack -default.
• Uncompressed DFF is still faster on this test than WavPack (it wasn't necessary the case with foo_benchmark): up to 30 seconds per hour of reencoded music.