Alternatively tell users that really care to use the Linux binary on windows through WSL2, that may bypass the issue.
If we are at the "tell user" stage of solutions, it is much easier to tell them use the --silent switch (-s). They will get a "progress update" when each file is done. Heck, that could be in the help file. Or --fast could be changed to be synonymous to -0s
From reply 51, FLAC does control how often updates are printed - different ways by different parameters. It just does it in a way that is bad when compression is fast, then it adds an overhead of thirty percent.
Since that is something FLAC has made an active choice to do, it might as well do it a bit less counter-productive?
The same thing seems to happen with -e - and certainly, with -pe. Enjoy this sadistic one for twentyfour-fold time consumption:
C:\tmp>c:\bin\timer64 c:\bin\flac-1.4.1-win\Win64\flac.exe testflacfile.flac -0pefs -b 17
Commit = 14364 KB = 15 MB
Work Set = 14924 KB = 15 MB
Kernel Time = 1.218 = 22%
User Time = 4.187 = 77%
Process Time = 5.406 = 99%
Global Time = 5.419 = 100%
C:\tmp>c:\bin\timer64 c:\bin\flac-1.4.1-win\Win64\flac.exe testflacfile.flac -0pef -b 17
Copyright (C) 2000-2009 Josh Coalson, 2011-2022 Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
testflacfile.flac: wrote 113408171 bytes, ratio=1,000
Commit = 14360 KB = 15 MB
Work Set = 14928 KB = 15 MB
Kernel Time = 30.859 = 23%
User Time = 7.468 = 5%
Process Time = 38.328 = 29%
Global Time = 129.796 = 100%
To compare, -8pe took only 77 seconds.
(Huh, what does -0e do? Exhaust the Rice4 vs Rice5 options?)