Tested: WavPack 5.7.0, including multithreading

Topic: Tested: WavPack 5.7.0, including multithreading (Read 8488 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Tested: WavPack 5.7.0, including multithreading

2024-03-25 19:21:04

Here will follow some tests with the new WavPack 5.7.0. Sure we have test-run multithreading from the 5.6.x versions posted here, but ... now is a release. I have already posted some results that include 5.7.0; in particular, with the change of compiler it doesn't seem there is much to gain by shopping around for builds (unlike for FLAC where some builds could cost you time). And I have already done something on "fake high resolution", but ...

... but, why not run a CDDA test too? That's old and boring, but ... take the multithreading into some "how many kilobytes do you save by running one second more" considerations like I did at https://hydrogenaud.io/index.php/topic,120454.msg1004848.html#msg1004848 (essentially telling the compression geeks that this is much ado about tiny - but fun! - improvements). New WavPack with new functionality, and new CPU here ... why not?

There would soon be answers to that "why not" - I could have expected it, trying to get reliable numbers out of this passively cooled CPU. Some scripting in cooldown minutes and some overnight runs later, I got fairly consistent results in the end.

I ran only a part of "my signature" here. Per "broad supergenre subdivision" (classical music, heavier material, and "others") I use, I generated 10min26.8 sec of each of seven albums. Think of it as a full compilation CD of each "supergenre". Not much, but enough to learn something - and although unweighted over genre could be unfair here unless one likes metal, the exact matching of PCM length made it easier to eyeball some speed discrepancies.

First: Not much size impact of --threads (it creates slightly different files than non-threaded, so I tested that).
84 multithread-or-single-thread data pairs: 3 supergenres times four modes -f/-g/-h/-hh times all seven -x settings
One of the 84 differed by as much as 0.24 percent (that's 0.12 percentage points), and the next was 2/3rds of that; for both, threading made bigger files. Broadly speaking, -x and -x2 were "least --threads-friendly"
On the other side, -x0 and -x3 produced smaller files with --threads, and so did most -fx<something>. In particular, for the default setting, none of the individual signals were harmed (that's good for optics, but won't affect your hard drive budget).

Here is a table which I'll explain afterwards - and then give a bigger one.

setting	time	of which vrfy	size	\|Δ size\|/Δt	over what
-fx0 -mv --threads	32	50%	55.23%	32516	over WAVE
-fx1 -mv --threads	38	41%	54.46%	2754	over fx0
-fx4 -mv --threads	93	16%	54.26%	84	over fx1
-fx6 -mv --threads	127	11%	54.25%	10	over fx4

-gx0 -mv --threads	39	46%	53.85%	4837	over -f (ie fx0)
-gx1 -mv --threads	52	34%	53.56%	483	over default
-gx4 -mv --threads	227	8%	53.25%	41	over -x
-gx6 -mv --threads	577	3%	53.16%	6	over -x4

-hx0 -mv --threads	50	41%	53.25%	1182	over default
-hx1 -mv --threads	72	29%	53.03%	226	h
-hx4 -mv --threads	338	6%	52.77%	23	hx
-hx6 -mv --threads	630	3%	52.72%	4	hx4

-hhx0 -mv --threads	63	39%	52.99%	464	over -h (ie hx0)
-hhx1 -mv --threads	98	25%	52.80%	129	hh
-hhx4 -mv --threads	487	5%	52.63%	10	hx
-hhx6 -mv --threads	1103	10%	52.60%	1	hx4

* Setting: I use -mv here. It verifies after encoding. Sure verification takes extra time, which I have also quantified.
* Time: In seconds for 211 minutes of CDDA audio. Wall time; CPU time is much more since it runs multithreaded. (4 cores, 8 threads.) Yes the x4 and up are expensive (but that's a one-time cost).
* of which vrfy: I also did the same thing without verification. Dropping that will save you 50 percent of the -f time cited, 3 percent of the -hx6 time, etc. I seriously don't understand the last "10%".
* size: in percent of uncompressed WAVE.
* The two last columns explain how many kilobytes it takes for one second heavier encoding.
. For the -x1 / -x4 / -x6 rows, it is relative to same mode, -x0 / -x1 / x4 i.e. the row immediately above in the table: The impact of -x
. For those that don't have any x, it is the impact of mode (-h over default, say), except for -f where it is the baseline: how much do you save by running WavPack -f over the .wav files.

This is CDDA. The -x make a quite different impact on high resolution.
You see that it is easy to improve over -f (not surprising!) and the first -x makes for much more than the rest. Even if you think -x4 is worth it, -x6 is expensive.

More information overload?

Cost/benefit heavily depends on what music you feed it, so here I broke it down to the three supergenres.
And ran all 28 settings. That means that -x4 is no longer compared to -x, but to -x1!
New thing to notice: not only compressed size varies over musical style - for x4 and up time also does.
For this test I used precisely the same audio length per genre - seven files of 10:26.8. I also ran a few heavy extra tests in different order to see if there were anything strange.

setting	time classical	time heavier	time other	of which is vrfy	Size classical	sz heavier	sz other	\|Δ size\|/Δt	sec to save 1kB	‘wrt. [as explained]
-fx0 -mv --threads	11	11	11	50%	43.8%	70.0%	51.9%	-f saves	32.5 megabytes/sec	over WAVE
-fx1 -mv --threads	13	13	13	41%	42.4%	69.8%	51.1%	4793	663	2759
-fx2 -mv --threads	14	15	15	36%	42.3%	69.8%	51.0%	527	142	439
-fx3 -mv --threads	17	17	17	31%	42.3%	69.7%	50.9%	174	140	291
-fx4 -mv --threads	32	31	31	16%	42.20%	69.68%	50.90%	28.8	28.0	27.8
-fx5 -mv --threads	38	36	37	13%	42.19%	69.68%	50.89%	21.2	8.7	10.8
-fx6 -mv --threads	43	41	42	11%	42.18%	69.67%	50.88%	1.9	3.2	9.0

-gx0 -mv --threads	13	13	13	46%	42.3%	68.9%	50.4%	-gx0 saves	4837 kB/sec	over -fx0
-gx1 -mv --threads	17	18	17	34%	41.9%	68.7%	50.1%	739	272	435
-gx2 -mv --threads	21	21	21	28%	41.8%	68.7%	50.1%	87	57	74
-gx3 -mv --threads	26	27	27	22%	41.8%	68.6%	49.9%	86	78	227
-gx4 -mv --threads	77	73	77	8%	41.59%	68.52%	49.66%	25.0	18.0	43.1
-gx5 -mv --threads	107	98	107	6%	41.52%	68.51%	49.61%	15.9	4.5	11.5
-gx6 -mv --threads	201	179	197	3%	41.48%	68.46%	49.55%	3.2	4.9	5.6

-hx0 -mv --threads	17	17	17	41%	41.8%	68.3%	49.6%	-hx0 saves	1182 kB/sec	over -gx0
-hx1 -mv --threads	24	24	24	29%	41.6%	68.1%	49.4%	288	141	251
-hx2 -mv --threads	30	31	31	23%	41.5%	68.1%	49.4%	82	49	38
-hx3 -mv --threads	40	40	40	18%	41.4%	68.1%	49.3%	63	29	59
-hx4 -mv --threads	114	110	114	6%	41.30%	67.95%	49.07%	11.9	13.5	23.1
-hx5 -mv --threads	157	147	158	4%	41.28%	67.93%	49.02%	3.4	2.9	9.2
-hx6 -mv --threads	213	199	218	3%	41.24%	67.93%	49.00%	5.4	1.1	2.2

-hhx0 -mv --threads	21	21	21	39%	41.6%	68.0%	49.4%	-hhx0 saves	464 kB/sec	over -hx0
-hhx1 -mv --threads	32	33	33	25%	41.4%	67.9%	49.1%	174	53	159
-hhx2 -mv --threads	42	43	42	20%	41.3%	67.9%	49.1%	36	22	39
-hhx3 -mv --threads	57	57	57	15%	41.3%	67.8%	49.1%	18	16	19
-hhx4 -mv --threads	160	162	165	5%	41.22%	67.77%	48.90%	5.6	4.5	10.6
-hhx5 -mv --threads	253	262	273	3%	41.21%	67.76%	48.85%	0.9	0.8	3.4
-hhx6 -mv --threads	317	341	444	10%	41.19%	67.75%	48.85%	3.0	0.3	0.3

No, the x4 and up aren't big savings just because they take space in the table - they got one more decimal in the rightmost columns.

You see hx5 and hhx5 are bad deal for classical music - if you are willing to wait for that, you might as well run the "x6" instead.
But for the "other" genre - with some near-mono signals and who knows - the picture is different. Also those benefit more from -hx4 over -hx3, and so forth.
For the harder to compress metal / industrial synth / hard rock, the -x[N] generally pay off less. Those are the biggest files to begin with, but that doesn't mean there are many bytes lost that can be picked up by more juice rather the contrary.

Then, some boring details at the end. What I actually did, from inside of the loop and out:
* run WavPack a few times with pauses in between each run
That is, "one supergenre's compilation 'CD'", pause, "same 'CD' over again", pause,
* Next genre. Do the same over again.
* Increment x.
* Do another pause because now we are passing from -x6 to no x at all, and then increment mode

Then read off timings and pick median. Uh, after discarding a few runs that looked suspicious. Some were (Windows Update I guess ...) but the genre time differences would replicate.

Everything was run on that disaggregated level - the top table has summed up times and sizes.

Re: Tested: WavPack 5.7.0, including multithreading

Reply #1 – 2024-04-02 22:20:44

Dear @Porcus, I've been going around this study for a few days and it seems there are not enough conclusions that can be immediately applied. In a similar study on FLAC, you concluded (please correct me if I misquote here) that -7 is more optimal than the default -5, and there is no point in -8, because it takes more time and the payoff is minuscule. Is it possible to give an equally clear recommendation regarding WavPack? Is -x3m --threads good enough in your opinion?

Re: Tested: WavPack 5.7.0, including multithreading

Reply #2 – 2024-04-03 17:09:02

I took the liberty of doing my own brief research based on a few songs of different genres (Depeche Mode, Loreena McKennitt, Shpongle) on Core2Duo with SSE3 support, as I wanted to find optimal settings to benefit from multi-threading. Sometimes a particular encoder or encoding mode may lag or get ahead, but in general it looks like this.

Version: WavPak 5.70

Size in bytes (lower is better).
Encoding time in seconds (lower is better).
Decoding speed in × real-time (higher is better).
Results are sorted by size from smallest to largest.

Code: [Select]

  Size         Encoding   Decoding   Filename               Comment
 ------------ ---------- ---------- ---------------------- ----------------------------------------------------------------------
  30 307 738       48.0      128.5   song.hx4m.wv           -x ≥ 4 noticeably slows down the encoding
  30 310 068       27.6      126.3   song.hx4m.threads.wv
  30 359 800        7.7      128.1   song.hx3m.threads.wv   seems to be optimal among other WavPack settings here
  30 360 272       12.9      128.3   song.hx3m.wv
  30 573 352       30.8      178.1   song.x4m.wv
  30 576 186       17.6      178.1   song.x4m.threads.wv
  30 681 680        5.5      178.7   song.x3m.threads.wv
  30 682 344        9.2      178.9   song.x3m.wv
  31 009 648       17.3      235.8   song.fx6m.wv
  31 010 040       10.2      226.4   song.fx6m.threads.wv

MOD edit: Topic is about testing WavPack 5.7.0. Non-WavPack results removed. If you want to compare, start your own topic.

Re: Tested: WavPack 5.7.0, including multithreading

Reply #3 – 2024-04-03 22:52:06

I am not completely convinced that a CPU with two cores and no more threads is what will make multithreading look most awesome

Re: Tested: WavPack 5.7.0, including multithreading

Reply #4 – 2024-04-04 00:02:59

@Porcus , thanks for your (as always) thorough and detailed analysis! Everything mostly aligns with my expectations, but the most important takeaways are that the --threads option doesn’t do anything bad (e.g., noticeably worse compression, corrupt output, crash) and generally gives a nice speed-up (which seems to be the case).

@Kraeved , your results also make sense as you’re getting close to double speed encoding with threading on a 2-core machine (I also test on my trusty CoreDuo). You don’t get quite 2x speed-up because some of the work must be done single-threaded (especially the MD5).

But I notice that your decode times did not improve. I hope you used the --threads with decode as well, although perhaps you used something like Foobar2000 to measure this? With 4 cores or more, WavPack can now decode faster than anything out there.

It’s still an open question what circumstances can justify this new feature. Obviously real time recording or playback makes no sense, unless you’re doing hundreds of channels (which, of course, was the original purpose) or using the higher -x modes (which I have done with EAC, although that also provides its own multithreading over multiple tracks).

Another application is to improve the response time when using DAW programs. I have updated my Cool Edit plugin and it’s quite a bit snappier. I also experimented with Audacity and it made an improvement there, but they have shown no hurry to get it in. I suspect some developers are nervous about possible instability with a library doing multithreading behind their back, although I try to make it clear that the threads only operate during calls into the library, and only if a sufficiently large buffer is passed in.

Re: Tested: WavPack 5.7.0, including multithreading

Reply #5 – 2024-04-04 16:51:54

Quote from: bryant on 2024-04-04 00:02:59

Obviously real time recording or playback makes no sense, unless you’re doing hundreds of channels (which, of course, was the original purpose) or using the higher -x modes

Also decoding high-order multichannel DSD from WavPack directly to PCM.

Re: Tested: WavPack 5.7.0, including multithreading

Reply #6 – 2024-04-05 18:16:49

@bryant
https://hydrogenaud.io/index.php/topic,121447.msg1008315.html#msg1008315
Opening 30ch_8bit_tenthofasecond.wv in Audition 1.5 resulted in a crash.
No crash if I use the older filter dated at Jan 19 2017.

Re: Tested: WavPack 5.7.0, including multithreading

Reply #7 – 2024-04-06 04:37:51

Quote from: Bogozo on 2024-04-04 16:51:54

Quote from: bryant on 2024-04-04 00:02:59
Obviously real time recording or playback makes no sense, unless you’re doing hundreds of channels (which, of course, was the original purpose) or using the higher -x modes
Also decoding high-order multichannel DSD from WavPack directly to PCM.

Yes, I forgot about DSD! Even just compressing large multichannel SACD whole-album rips can be slow in the "high" mode.

Quote from: bennetng on 2024-04-05 18:16:49

@bryant
https://hydrogenaud.io/index.php/topic,121447.msg1008315.html#msg1008315
Opening 30ch_8bit_tenthofasecond.wv in Audition 1.5 resulted in a crash.
No crash if I use the older filter dated at Jan 19 2017.

Oops. Verified on Cool Edit. Should be a simple fix. Thanks!

Re: Tested: WavPack 5.7.0, including multithreading

Reply #8 – 2024-04-06 15:34:55

So here are my 6ch DSD benchmarks, speed in seconds.
i3-12100, Win10 x64, tested on RAM disk
Pink Floyd - Shine On You Crazy Diamond (1.61GB, 13m36s, dsf)

Code: [Select]

encode    threads    single
-hmv        74.46    194.03
-mv         21.76     43.04
-h          34.81     92.63
-m           9.05     17.51

verify    threads    single       size
high        36.32     98.21    -53.93%
norm        10.76     23.75    -41.46%

Re: Tested: WavPack 5.7.0, including multithreading

Reply #9 – 2024-04-07 22:25:22

A few more timings here - official WavPack up against ffmpeg.
Hence this post has timings without --threads, -m nor -v. The corpus - all CDDA - was slightly different from above, for stupid reasons. Details at the end.

There are a couple of differences that could slightly impact size.

Zero impact for the tag that ffmpeg writes, as I removed that; all sizes are tagless.
Peanuts impact from the mono optimization that was introduced some seventeen years ago, and which by default is off in ffmpeg and wavpack.exe 4.*. At the most extreme setting, it matters a part per million. At the fastest, six times as much.
Then it is the WavPack 4 file format vs the WavPack 5 file format. WavPack 5 has a block checksum, and also wavpack.exe version 5 uses smaller blocks. That incurs a size penalty which, when comparing with 4.80 at -hhx6, makes for around 0.11 percent larger files on CDDA. So when savings are compared to "format 5 overhead" below, it is relative to that 1.1 megabyte difference. Strictly speaking, "format 5 overhead with wavpack 5.7.0 block size minus format 4 overhead with wavpack 4.80 block size", and I don't know ffmpeg block sizes.

The difference between 4.80 and 5.7.0 file sizes (at -hhx6) could be a kind of "yardstick" to what is a tiny compression improvement? It seems it makes up four or five extra CDs in on a TB drive I think, and that isn't much - maybe it is fruitful to have this as a backdrop as to how little you save by waiting for ages? Opinions may vary of course. @bryant sacrificed that much for a format improvement that benefits you when you want to verify file integrity.

ENcoding: official WavPack settings included are those that roughly match ffmpeg's, for comparison, plus -hh.
TL;DR: by and large, official WavPack wins. (With some files being exceptions. If you think the new format overhead is too much, use 4.80.)
In particular: even if ffmpeg has prioritized speed over compression, in their default setting (the lightest!), it is not nearly as fast as official -f in this test.
Corpus is 2.1 GB uncompressed, 1.07 to 1.126 compressed.
370x realtime: -f
275x: ffmpeg at default, that is -compression_level 0. 55 megabytes bigger than -f. The size difference is not due to mono optimization (on by default in wavpack 5); switching it on in ffmpeg saves only 13 kilobytes.
185x: -x.
177x: -hh. Does not match any ffmpeg, but since most of the following are -hhx[N], I included it.
160x: ffmpeg -compression_level 1. Rough -x equivalent; beats -x by 2 MB, that is twice the format 5 overhead. Therefore, I checked against 4.80 at -x; ffmpeg wins narrowly, less than 1 kilobyte per file.
80x: -hx2.
68x: ffmpeg -compression_level 2. Rough -hx2 equivalent and 201 kB smaller.
Note this. Here and up, ffmpeg will make 160 to 201 smaller files, which is only a fraction of the 1.1 MB format 5 overhead, and be slower than the corresponding official setting.
28x: -hhx3. Remember that it is from -x4 things get really expensive, this is "only" six times as much as -hh.
24x: ffmpeg -compression_level 3. Rough -hx3 equivalent, 193 kB smaller.
9x: -hhx4. Saved 2 MB over -hhx3. That isn't much for taking three times as long.
6.6x: ffmpeg -compression_level 4, saves 170 kB over -hhx4.
5x: -hhx6. Save 0.8 MB over -hhx4, that is 0.07 percent. Move the decimal point one step for the saving over ffmpeg's compression level 4.
Now if you think this is much waiting for nearly nothing:
4.4x: ffmpeg -compression_level 5: bigger files than -hhx6 and slower. Saving 175 kB on -hhx5 is then moot ...
3.3x: ffmpeg -compression_level 6, saves 160 kB over -hhx6, still only a fraction of the format 5 overhead. In fact, 4.80 at -hhx4 outcompresses it.
1.6x: ffmpeg -compression_level 7. Takes twice the time of level 6, saves another 755 kilobyte on a 2GB corpus. But is 218 kB bigger than 4.80 at -hhx6, though not losing in all three genre divisions.
0.44x: ffmpeg -compression_level 8. Yes, less than half realtime. For 138 kilobytes savings over 7 - and only narrowly beating 4.80 -hhx6 due to a couple of files (not beating it on classical and heavier music).

To summarize the competition between ffmpeg and the roughly-equivalent official settings,

ffmpeg is always slower than 5.7.0. Even ffmpeg's default, that compresses quite a bit weaker than -f.
only -compression_level 1 outcompresses 5.7.0 -x by more than the format overhead, and then 4.80 -x practically ties it.
compression levels 2 through 6 pretty consistently saves 160 to 201 kB (on 2 GB uncompressed) compared to the corresponding WavPack 5.7.0 files. If you think that is worth it ... use WavPack 4.80 to get format 4 and smaller files.
-compression_level 5 loses at both size and time to -hhx6. When comparing format 4 to format 4: -compression_level 6 loses at both size and (badly!) at time to 4.80 at -hhx4.
-compression_level 7: Again, if you think that gaining the format overhead is worth it, consider 4.80 at -hhx6. Though some signals did better with ffmpeg.
-compression_level 8: if you think -hhx6 is fast, then this is eleven times the wait. Porcus tests stupid settings so you won't have to.

.

DEcoding times:
These timings are done with official WavPack 5.They don't measure ffmpeg's decoding speed at all - they measure how light or heavy ffmpeg files are to decode.
18.5 seconds for ffmpeg 0-generated files
19-ish for -fx0 to -fx6; everything within half a second
24 seconds for the -g's and ffmpeg 1, everything within .3 seconds
31.6 to 32.4 for the -h and ffmpeg 2; ffmpeg and -hx6 fastest
So, confirms that not only file sizes but also CPU load are like f, g, h for ffmpeg levels 0, 1, 2.
Then the -hh and ffmpeg levels 3 and up:
38.2 to 42 for the -hh, with -hhx6 decoding fastest and then pretty much as follows: ffmpeg 8 about like -hhx5, ffmpeg 7 like -hhx4, etc. to ffmpeg 3 like -hhx0 (the 42 seconds).
The slowest figure is about like Monkey's "Fast", in line with results at http://audiograaf.nl/losslesstest/revision%206/Average%20of%20CDDA%20sources.pdf .

Also tested: "--threads" has no noticeable impact on decoding speed.

More details:
I first set out with ten minutes from half of the corpus of my signature - that would give about the same compressed sizes - but for the table in the first post of this thread, it would be much tidier to have the times about the same. So two more metal clips were added after sizes were compiled ... and when I realized that inconsistency, I didn't bother to re-do that. With Gojira and Laibach out of the size measurements, the -hhx6 ratios are down to 50.948% for 5.7.0 and to 50.894% for 4.80. Need that third decimal to distinguish out ffmpeg -compression_level 8 at 50.893 ...
But times are with the two, because I had to re-run for timing anyway. That is one reason why I converted to speed x realtime. Also because when something approaches worse-than-realtime I think it should be visible. Those encoding times are nuts.
Decoding ran a lot of times (with some cooldown in between) with the hyperfine benchmarking tool to get reliable numbers, here the margins were narrow.
Encoding: all were median of at least 3 runs (also here cooldown in between) except possibly the worst ffmpegs; rougher measured than decoding, since this test was not doing delta t/delta size (which would require more accuracy I think). So in order not to pretend they are much more exact than they are, I rounded off the fastest figures to nearest 5, then to nearest integer, then to decimals as stated - that is by gut feeling. Anyway the pattern is quite clear.

Re: Tested: WavPack 5.7.0, including multithreading

Reply #10 – 2024-04-08 21:53:47

Well that ~~escal~~ obsoleted quickly!

ffmpeg 7, released this week-end, encodes faster than the build I used for the timing (6.1).
Not unlikely because it now does some kind of multithreading. Not the encoding itself it seems, but between encoding and decoding - maybe that means it has a thread reading the WAVE before feeding it to its wavpack encoder.
I have no idea whether that is doing much work other than keeping the queue, so to say.
And so I don't know whether it is less or more apples-to-apples with ffmpeg 7 than with 6.1.1.

Also I found out that wavpack *.wav is a bit faster than a FOR loop. ffmpeg doesn't do wildcards. From a user perspective, that is "their loss" if user has to wait longer - but if you are interested in CPU efficiency, then what? If you run the CPU at full throttle, those small I/O-related pauses might just get something else done?

I am not going to try to run four or eight concurrent ffmpegs to time it. Getting those times reliable ... meh.

So here is a table for the comparable presets up to 4, using old and new ffmpeg, old and new WavPack - and with 5.7.0 both wildcarded and FOR looped. All with -y overwrites for each file, all on the same SSD as the .wav encoded. This time in seconds, because you are waiting in seconds not in percents I guess? Similar corpus.
Each row is about the same compression level, see previous post (0: ffmpeg compresses worse)

.	*5.7.0 .wav**	5.7.0 FOR	*4.80 .wav**	FFmpeg 6.1.1	FFmpeg 7.0	remark
0	24	+1	+6	+15	-0.3	-f and compression_level 0
1	49	+5	+7	+17	-1.0	-x and compression_level 1
2	117	+9	+7	+37	+5	-hx2 and compression_level 2
3	360	+8	-1.4	+68	+21	-hhx3 and compression_level 3
4	1235	+9	+12	+402	+354	-hhx4 and compression_level 4

Less is better and plusses are worse.
5.7.0 *.wav column shows time in seconds. Other columns seconds difference relative to that. Why FOR looping makes very little difference for -f and more difference with higher modes ... who knows.
Anyway, the FF is now as fast as gets on compression_level 1, and faster than FOR-looped wavpack at 2. Results at level 4 are so clear that I'll happily leave it there rather than running the even slower ones.

BTW, both ffmpegs are MSYS2 project builds. Don't know if anything relevant has changed.

Code: [Select]

ffmpeg version 6.1.1-essentials_build-www.gyan.dev Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 12.2.0 (Rev10, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --pkg-config=pkgconf --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-sdl2 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-dxva2 --enable-d3d11va --enable-libvpl --enable-libgme --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libtheora --enable-libvo-amrwbenc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-librubberband
  libavutil      58. 29.100 / 58. 29.100
  libavcodec     60. 31.102 / 60. 31.102
  libavformat    60. 16.100 / 60. 16.100
  libavdevice    60.  3.100 / 60.  3.100
  libavfilter     9. 12.100 /  9. 12.100
  libswscale      7.  5.100 /  7.  5.100
  libswresample   4. 12.100 /  4. 12.100
  libpostproc    57.  3.100 / 57.  3.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

--pkg-config=pkgconf has disappeared and gcc is newer. Then the following are added that make for some hardware acceleration, but not here?! Or?
--enable-d3d12va
--enable-vaapi

Code: [Select]

ffmpeg version 7.0-essentials_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 13.2.0 (Rev5, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-sdl2 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libgme --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libtheora --enable-libvo-amrwbenc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-librubberband
  libavutil      59.  8.100 / 59.  8.100
  libavcodec     61.  3.100 / 61.  3.100
  libavformat    61.  1.100 / 61.  1.100
  libavdevice    61.  1.100 / 61.  1.100
  libavfilter    10.  1.100 / 10.  1.100
  libswscale      8.  1.100 /  8.  1.100
  libswresample   5.  1.100 /  5.  1.100
  libpostproc    58.  1.100 / 58.  1.100
Universal media converter
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

Re: Tested: WavPack 5.7.0, including multithreading

Reply #11 – 2024-04-08 22:06:04

wavpack encoder unlike decoder is not (frame) multithreaded at all, and mostly because of it being low hanging and irrelevant request for niche codec and format/container.

Re: Tested: WavPack 5.7.0, including multithreading

Reply #12 – 2024-04-08 23:48:20

Is ffmpeg's wavpack decoder doing multithreading?

Re: Tested: WavPack 5.7.0, including multithreading

Reply #13 – 2024-04-09 00:43:37

Yes, it does. And it did so long before official WavPack decoder got multithreading.

Re: Tested: WavPack 5.7.0, including multithreading

Reply #14 – 2024-04-14 01:03:06

Quote

Quote from: bennetng on 2024-04-05 18:16:49
@bryant
https://hydrogenaud.io/index.php/topic,121447.msg1008315.html#msg1008315
Opening 30ch_8bit_tenthofasecond.wv in Audition 1.5 resulted in a crash.
No crash if I use the older filter dated at Jan 19 2017.
Oops. Verified on Cool Edit. Should be a simple fix. Thanks!

Wow, that was a tough one to find, especially because I had three distinct build environments to deal with (VS 2008, VS 2019, and cmake/mingw). Another complicating issue is that the bug actually exists in the older plugin too, but you needed to cancel out of the load operation to trigger it whereas starting at libwavpack 5.3.0 it would happen every time you load a file over 24 channels.

Re: Tested: WavPack 5.7.0, including multithreading

Reply #15 – 2024-04-14 05:29:47

Thanks for the fix

Notice