Perception is everything to many. Ones that look at percent compressed vs flac vs ones that look
for the 'fastest' decoding even though both are meanigless in modern scenarios.
Still, It will stick that both have same compression but flac is 'fast' and wavpack is 'slow' due to
looking at some 'studies' and graphs.
If -h became the new default, Wavpack compression on paper would look much better than flac. The speed
would still be very fast both ways. This could help popularity. It would stick in peoples mind that wavpack
compress better than flac and most other codecs - except TAK & APE. Tak is closed source. APE -c2000 is fast but slow to decode.
APE -c1000 compression is similar to wavpack -h but still slower in decoding . WV has better license then APE.
I think win win for -h as default. -hh can be new -h, normal could be 'fast' and fast could become 'very fast'
Hi shadowking, and thanks for the suggestion! I actually have thought about this and I do use the high mode the most, although sometimes I use -x6 as the default when I’m not in a hurry.
I think though that there are other reasons for people not using WavPack unrelated to this, like limited hardware support and confusion about all its additional features. If people are looking for a codec just to rip their CDs to I suggest FLAC.
If someone needs something unique that WavPack has, like 32-bit audio (integer or float), or DSD, or hybrid/lossy, or dozens of channels, etc, then obviously I recommend it.
And at this point I think it would only add confusion to either rename the modes I have, or force high mode on by default and create a new option for “normal” (which is probably the way I’d go).
BTW, do you really still use 4.80? :)
Last night I had another thought, This time much simpler. The idea is to hide the complicated options
and emphasise 'presets' for the most common lossless / hybrid options. I took ideas from zip, lzop, flac, mac cli tools
-0 = -f
-1 = -x
-2 = -hx (recommended)
-hybrid0 = -b256hx3c
-hybrid1 = -b320hx3c
-hybrid2 = -b384hx4c
Yes still on 4.8. I really should try latest or just delete my dumb signature :)
Yes, that's actually kind of a good idea that I had not thought of. In fact, FFmpeg works that way (although I don't agree with what they've chosen, for example you can only get the high -x modes with -hh).
Of course, it doesn't address the original issue unless we force one of them as default, but it's something to think about.
As for the 4.8 issue, you know you're missing out on the new quick verify feature by using that, right? :)
Nice ideas by shadowking, course as long as the "complicated options" remain available (I guess that's what he means by hiding them).
Stil on 4.80.0?! How can you live without wvtag ;) ? Come on, man :)) !
Has this gone anywhere since please? Thanks.
What one could do, is to elevate the "-x" to be the preset. -x0 to -x6.
Then take the fast/normal/high/very high mode to be a modifier. Akin to how TAK has -p as the preset and then with modifiers, except that I would propose -x0 as default if -h is default. "-x" could still mean "-x1".
If one is to go for -h as new default mode, one could have a letter for current "normal". "g" works. Between f(ast) and h(igh), there is g(ood). (Heck, if others can call some preset "best", you can call that mode "good".) Or you can consider f and ff for the faster than high. Of f and ff, so that -x0ff means current --fast. And you can keep "--fast: synonymous to -x0ff".
-x1hh ... or, to highlight the warning against it for portables, require it to be given separately.
All this won't change much but the mindset; and it should, if you embrace -h (and still warn against -hh), for then the x is what the user would have to select unless diving into the detail.
"purely numerical" presets like FLAC have an issue with WavPack: as long as one has already decided that -hx shall be accepted as -h -x, then it would confuse a user if -3 -x is not the same as -x3.
Now whether going for -h is a good or a bad idea is another issue; it is a double-edged sword in that it puts the default to even slower decoding - but on the other hand, those obsessed with that might look elsewhere.
But I would think twice before letting new -hx be default, as it takes twice the time to encode as current default does. That is quite some change. -h is already smaller than any FLAC. And with ktf's freshly posted flac beta, it is about the speed of -7.
Oh, and I think the manual does something very wrong when speaking of (very) high "quality" for -h and -hh. Very high compression effort?
... but if one wants to pick presets from a selection of reasonable settings, then ... I put my computer to a couple of overnight tasks with around 3 GB CDDA and 3 GB 96/24 (well a few 88.2/24), same corpus as here (https://hydrogenaud.io/index.php?topic=120158.msg1003738#msg1003738). Warning: Rock to metal, not much classical. But if one is to pick presets, I think the considerations below are a significant point (and then others can fill in with more testing).
The below table is interesting. The -x3 setting is frankly quite useless in this test. -x1 is so excellent on this hirez corpus that it is tempting to make it mandatory, despite whatever I said in the previous post about a new default taking so much more time.
Explanation: CDDA to the left, hi-rez to the right. Size and seconds are self-explanatory; times are taken from Igor Pavlov's timer64.exe ("process time", I think it ignores time to access files on the SDD.)
The -Δt/Δsize means the cost in seconds per megabyte saved compared to the setting immediately above it
. Reasonably, this should be progressive within the mode (which means everything else equal): you would have to pay more seconds for another megabyte reduction if the file is already smaller.
-x3 violates that (except in fast mode): if you are willing to pay for going -x2 to -x3, you get better per second going -x4. Indeed, for the higher-rez material, -x3 is both bigger and slower than -x2, indicated by "BIGSLOW". (That means that a number immediately below "BIGSLOW" is low because it is in comparison to something bad.)
The other "bigger" indicated, are when mode is switched and file size goes up. Then the negatives are when higher mode yields both faster encoding and smaller file.
I also question the usefulness of -x5. It is already so slow that you would leave it in the background for long rather than watching it. If you are first going -x5, why not leave it overnight or for the week-end for -x6?
To get a reference to FLAC: ktf's newly posted beta, which improves quite a bit, beats WavPack on hirez unless you go up to -h -x4. (This edited after a big mistake.)
But for CDDA: -7 compresses to both time&size between normal and -x1, and -8 to both time&size between -x1 and -x2. -x2 is likely smaller than any FLAC ever - for this CDDA corpus.
|setting||bytes CDDA||sec||-Δt/Δsize||-Δt/Δsize||sec||bytes hirez|
| -f -x1||2202072762||100||4||1||83||2323061806|
| -f -x2||2198609618||131||9||16||106||2321563994|
| -f -x3||2197522750||204||67||56||166||2320481204|
| -f -x4||2196193122||461||193||65||356||2317536024|
| -f -x5||2195912276||571||393||106||420||2316936660|
| -f -x6||2195820750||657||938||7132||491||2316926664|
| -h -x1||2138172066||176||13||2||131||2217805534|
| -h -x2||2136565630||279||64||116||208||2217136902|
| -h -x3||2136430268||535||1889||BIGSLOW||400||2219912878|
| -h -x4||2131282798||1964||278||15||1672||2137653818|
| -h -x5||2130429436||2676||835||398||2249||2136206612|
| -h -x6||2130069132||3647||2695||626||3285||2134552628|
| -hh -x1||2128773398||234||23||2||172||2203717666|
| -hh -x2||2127751110||392||155||125||291||2202768210|
| -hh -x3||2127514768||806||1752||BIGSLOW||585||2203496882|
| -hh -x4||2124631636||2833||703||23||2477||2121330764|
| -hh -x5||2123744660||4566||1954||1358||3876||2120301594|
| -hh -x6||2123586950||6255||10708||2921||5483||2119751366|
-x3 is both bigger and slower than -x2, indicated by "BIGSLOW". (That means that a number immediately below "BIGSLOW" is low because it is in comparison to something bad.)
Oh, but for hirez the numbers indicate something to scratch one's head over. Disregarding -f:
-x2 to -x4 (normal mode): Shaving 1 MB costs 25 seconds. That is cheaper than going -x1 to -x2 (35 sec per MB s(h)aved).
-x2 to -x4 (high mode): Shaving 1 MB costs 18 seconds. That is much
cheaper than -x1 to -x2 (116 sec per MB).
-x2 to -x4 (hh mode): Shaving 1 MB costs 27 seconds. That is much
cheaper than -x1 to -x2 (127 sec per MB).
So a reasonable interpretation (well the official documentation pretty much says the same) is that going for high x is a speculative investment of time; one that could yield good return if and when lower x (including no x) might not be well optimized for the particular signal in question.
Now this single test (no classical music, yeah ...) indicates that x2 might not be well-optimized for high-frequency content; x3 might not be well optimized at all?
Then also to think over: getting a MB for half a minute is pretty good bang for buck if you are in the market for high compression - but that number is because WavPack performs quite bad
on these files without -x4: ktf's new FLAC beta at -8 saves two percent (45 megabytes) over -hhx and at faster encoding time.
This would provoke the question: should presets be "same for all signals" or should the encoder read sample rate and shift settings accordingly? But no, not in this case: a default setting cannot run fifteen times as long on a GB of 96/24, compared to a GB of CDDA.
: Is there maybe something you should look at about selecting block size from sample rate? Also I noticed from timer64 output that WavPack spends only a fraction of the memory that flac.exe does, but that might be due to flac.exe trying to buffer before writing to limit the number of i/o operations and the file fragmenting that would follow?)
-h is already smaller than any FLAC.
That was CDDA.