Skip to main content


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.
Recent Posts
WavPack / Re: WavPack decoding complexity vs FLAC
Last post by Porcus -
Dig down here: .

There is hardly anything that decodes as fast as FLAC - no lossless audio compressor, at least - and that is part of what FLAC was designed for. Of course, twenty more years of computing power has made both megabytes and CPU cycles much cheaper.

Things to take note of:

* FLAC's "-8" is by no means the slowest setting. It is called "--best" because well, "best among what is useful". Indeed reference FLAC gives you access to "statistical filters" that can improve if you are willing to to pay. Chiptune? Try e.g.
flac --lax -8per15 -A "flatopp;gauss(7e-2);tukey(7e-1);subdivide_tukey(7)" -l 32
and watch the paint dry. It will be slow, and on chiptune a hunch would be that it is the "r" number that improves this much. If you think this is not slow enough, I can offer more "-A" functions to keep your CPU hot.

* The above command will not be FLAC "subset". If you are unlucky, an in-car unit and other hardware players could very well choke on the files you generate. They will be heavier to decode (the "prediction" for each sample will require a history of 32 rather than just 12). Without -l32 it would be much lighter. Without -l32 and with "r8" in place of "r15" it would be within subset. And would still be slow encoding; the "-pe" combines two brute-force elements and is typically not worth it. But with "-r6" and no "-l" switch, decoding will still be about like -7, and that is closer to -0 than to any other lossless codec.

* WavPack's -x settings "do not increase decoding complexity" (well actually, for nitty-gritty reasons they can even improve decoding speeds). They also employ a filterbank for improved compression. -x1 to -x3 are pre-defined filters that are coded in based on knowledge of how music signals typically behave (for CDDA!). -x4 to -x6 will "learn the filtering" from scratch without prior notion of what the music is like, and that is why -x4 can behave so different from -x3, especially on high resolution. Here you got some high resolution numbers:,120454.msg1004848.html#msg1004848 . You see that -x is fairly cheap, and -x4 is much better value for money than -x3; then -x5 and -x6 are expensive.

Both reference encoders can re-encode in-place, so if you first are just ripping CDs you can use a fast setting and then you can run re-encodes overnight / over week-end if that is what you want.
WavPack / Re: WavPack decoding complexity vs FLAC
Last post by cid42 -
If you feel adventurous --hh corresponds to CONFIG_VERY_HIGH_FLAG, and --h to CONFIG_HIGH_FLAG. grepping those shows you where they're used which you can then investigate to see exactly what is enabled/disabled(the tool grep is a good first step to picking apart unfamiliar code):
Code: [Select]
./src/common_utils.c:        if (wpc->config.flags & (CONFIG_HIGH_FLAG | CONFIG_VERY_HIGH_FLAG)) {
./src/common_utils.c:            if ((wpc->config.flags & CONFIG_VERY_HIGH_FLAG) ||
./src/pack.c:    if (wpc->config.flags & CONFIG_VERY_HIGH_FLAG) {
./src/extra2.c:    if (wpc->config.flags & (CONFIG_HIGH_FLAG | CONFIG_VERY_HIGH_FLAG))
./src/pack_utils.c:    if (config->flags & CONFIG_VERY_HIGH_FLAG)
./src/extra1.c:    if (wpc->config.flags & (CONFIG_HIGH_FLAG | CONFIG_VERY_HIGH_FLAG))
./include/wavpack.h:#define CONFIG_VERY_HIGH_FLAG   0x1000  // very high
./cli/wvtest.c:        res = run_test_extra_modes (wpconfig_flags | CONFIG_VERY_HIGH_FLAG, test_flags, bits, num_chans, num_seconds);
./cli/wvtest.c:    else if (wpconfig_flags & CONFIG_VERY_HIGH_FLAG)
./cli/wavpack.c:                        config.flags &= ~(CONFIG_HIGH_FLAG | CONFIG_VERY_HIGH_FLAG);
./cli/wavpack.c:                        config.flags &= ~(CONFIG_FAST_FLAG | CONFIG_HIGH_FLAG | CONFIG_VERY_HIGH_FLAG);
./cli/wavpack.c:                            config.flags |= CONFIG_VERY_HIGH_FLAG;
./cli/wavpack.c:    else if (config->flags & CONFIG_VERY_HIGH_FLAG)
./audition/cool_wv4.c:        config.flags |= (CONFIG_VERY_HIGH_FLAG | CONFIG_HIGH_FLAG);
Code: [Select]
grep -r CONFIG_HIGH ./
./src/common_utils.c:        if (wpc->config.flags & (CONFIG_HIGH_FLAG | CONFIG_VERY_HIGH_FLAG)) {
./src/pack.c:    else if (wpc->config.flags & CONFIG_HIGH_FLAG) {
./src/extra2.c:    if (wpc->config.flags & (CONFIG_HIGH_FLAG | CONFIG_VERY_HIGH_FLAG))
./src/pack_dsd.c:    if (wpc->config.flags & CONFIG_HIGH_FLAG) {
./src/pack_utils.c:// o CONFIG_HIGH_FLAG           "high" compression mode
./src/pack_utils.c:        config->flags &= (CONFIG_HIGH_FLAG | CONFIG_MD5_CHECKSUM | CONFIG_PAIR_UNDEF_CHANS);
./src/pack_utils.c:        wpc->config.flags |= CONFIG_HIGH_FLAG;
./src/pack_utils.c:        if (wpc->config.flags & CONFIG_HIGH_FLAG)
./src/pack_utils.c:        int divisor = (wpc->config.flags & CONFIG_HIGH_FLAG) ? 2 : 4;
./src/unpack3_open.c:        wpc->config.flags |= CONFIG_HIGH_FLAG;
./src/extra1.c:    if (wpc->config.flags & (CONFIG_HIGH_FLAG | CONFIG_VERY_HIGH_FLAG))
./include/wavpack.h:#define CONFIG_HIGH_FLAG        0x800   // high quality mode
./cli/wvtest.c:        res = run_test_extra_modes (wpconfig_flags | CONFIG_HIGH_FLAG, test_flags, bits, num_chans, num_seconds);
./cli/wvtest.c:    else if (wpconfig_flags & CONFIG_HIGH_FLAG)
./cli/wavpack.c:                        config.flags &= ~(CONFIG_HIGH_FLAG | CONFIG_VERY_HIGH_FLAG);
./cli/wavpack.c:                        config.flags &= ~(CONFIG_FAST_FLAG | CONFIG_HIGH_FLAG | CONFIG_VERY_HIGH_FLAG);
./cli/wavpack.c:                        if (config.flags & CONFIG_HIGH_FLAG)
./cli/wavpack.c:                            config.flags |= CONFIG_HIGH_FLAG;
./cli/wavpack.c:    else if (config->flags & CONFIG_HIGH_FLAG)
./audition/cool_wv4.c:        config.flags |= (CONFIG_VERY_HIGH_FLAG | CONFIG_HIGH_FLAG);
./audition/cool_wv4.c:        config.flags |= CONFIG_HIGH_FLAG;

flac -8 is far from the slowest encode setting you can use for flac. -8p seems to be the slowest in common use with non-negligible efficiency gains, but there are many settings an expert can tinker with and you can basically make the encoder as slow as you like.

Here's some encode/decode stats but it looks like they only go up to x4hh, just plonk x6hh somewhere to the right of that for an estimate:,122508.0.html
WavPack / WavPack decoding complexity vs FLAC
Last post by kylxbn -
Hello, everyone.

I'm a WavPack user and I love its hybrid feature. Thanks for creating a very useful software. I just have a curious question.

I tried comparing the compression efficiency of WavPack versus FLAC, and while my tests were of course not scientific, I was able to get slightly more compression on WavPack (-x6 -hh) compared to FLAC (-8), although the advantage is almost insignificant on normal CD-quality sources. A significant WavPack advantage was found on a 96kHz 24-bit mono source (some emulated chiptune music) but those are of course uncommon audio files.

What made me curious was that WavPack in its absolute highest compression settings (-x6 -hh) took extreme efforts to encode while FLAC (-8) seemed to compress the files in just seconds (I have an Intel i9-9980HK). Personally, I don't mind the encoding time since I find WavPack's hybrid lossy encoding very useful for syncing songs to my phone, but I was curious on how difficult WavPack (-hh) files are to decode compared to FLAC (which I believe the compression rate does not affect decoding speed). Can someone please tell me, or how do I check for myself? (I use Linux if that matters.)

(This one is unrelated and I don't mind if you ignore this part--I have a general idea of how WavPack compresses samples, but how does the -h and -hh flags change the compression method? I know I can just read the source code but I tried and I don't know which file or line to check... Can anyone please simply explain it or point me to a file and line number?)

Thank you very much in advance!
FLAC / Re: Multithreading
Last post by cid42 -
Actually fixed gasc as of commit 5fb1861601759de021a8b25f9038f5034da890be. gasc/fixed/peakset passed flac-test-files and MD5 works for all bit depth input now. Latest commit adds a --no-md5 option which disables md5 for fixed/gasc/peakset.
Audio Hardware / Re: SOtM dx-USB HD driver help needed
Last post by frenzic -
I'm having trouble remembering how to install the driver.

Can someone help, please?

Here's your drivers and firmware if that somehow was a problem.

Looked at the latest windows driver and the files are dated 2014 so they'd be win8 ish. Probably work fine on ten.

Unpack the zip file and run setup.exe.
If unpacking was the problem you can dl 7-zip which is free and trustworthy.

On linux and Mac it should just work.
FLAC / Re: Multithreading
Last post by Porcus -
Interesting indeed. Though I realize that I have too often overlooked the log scale, damn sometimes I am just stupid and even sticking to it ... but anyway:

* Bumping prediction order from 8 to 12 makes for quite a bit, and that is not a surprise. Not unlikely that could have been exploited further, which within subset is only possible for high resolution
* Optimizing blocksize - which obviously also makes for a better fitting predictor - can easily make for slightly more than half of that improvement

Which effect is largest?

So for testing purposes, I am curious what happens in the following comparison.
* Take the leftmost red (peakset output-comp 8, is that?) and limit it to be comparable to -6 (prediction order, apodization, max Rice parameter) It would still improve over -6; how much? Is it cheaper/better than going -l12?
* To get "everything else equal", one would have to consider the fact -r6 means half the partition size for half the block size. At least to compare predictor fit one might consider to lock it down to ... well -r9 would of course make everything equal? Not time taken, I mean - it is so -r6 will run 7 calculations rounds?

Wondering if the association between blocksize and the actual partitioning of that block shows anything surprising?
Some phenomena possibly at play:
1: bad-fitting predictor leads to larger residuals and to more block splitting and finer (in terms of absolute sample count) partitioning
2: "short noisy parts" surely lead to bad-fitting predictor, but there the more noise-alike the less point in improving it and so you might as well just use the "neighbouring frame's vector" and merge the blocks.
General A/V / Re: Blu-Ray and DVD Authoring on Ubuntu Linux using only FOSS
Last post by cid42 -
Doom-9 seems to be documenting parameters for x264.exe, presumably a Windows encoder, or some other that uses these shortcuts such as --bluray-compat.
The x264 binary is kind of like the reference x264 encoder, like ffmpeg it's a frontend for libx264 but unlike ffmpeg that's all it does (so actually using it with audio probably requires muxing with ffmpeg separately). The x264 binary is available in the Ubuntu repo's.