It's pretty hilarious complaining about the module. Team order has always been available in the replay file for any would be cheater to exploit. This module just exposes that "cheating" in the open.
So in effect being against wkWormOrder is doing more to defend cheating than fight against it.

Perhaps I should make an open source python module to allow for effortless automatic printouts of team order

@cgar, How much did it take to convert that replay into video?

For the total time It's kind of hard to say since it was all done manually and separately instead of with armaRec. But it was pretty slow.

I've took some time to do some more testing to get an idea about the speed. This is still just manual encoding and is only for the png frames to mp4 part. And the chosen replay is the same as previous (28m 14s).

Test	Time	Speed
CPU, 720p, 60fps, placebo preset, 1 thread	19m 28s	1.45x
GPU, 720p, 60fps	9m 3s	3.12x
CPU, 720p, 60fps, veryfast preset, 16 threads	4m 11s	6.19x
GPU, 480p, 60fps	4m 51s	5.82x
CPU, 480p, 60fps, veryfast preset, 16 threads	1m 40s	17x

CPU is the AMD 5950x and GPU is the AMD 6700XT. I expect the speeds to be faster in the future but atm I cant push them due to my dodgy PSU.

The sound part for ArmaRec can take quite some time. Last time I tested it the sound processing part took about 10 minutes for an 8 minute replay. And that was after turning on more compiler optimizations lol.
Which is the other reason I prefer my hacky bash script manual'ish approach over armaRec. It means I have to play the file twice, once for video exporting. and once at realtime for sound recording. But its still faster and better quality than ArmaRec currently is. For large replays at least.
So as well as batch abilities and the other improvements that Charles mentioned, the sound part would also need it's speed improved and the slight quality issue fixed. Though the sound issue might only be for non 50fps exports.

double check what's the real framerate - is it 60 now? or 50? when i tried recording in 50fps, i felt like the recording process seemed a bit sped up

The game logic is still tied to 50fps but the graphics can be more using tweening so you can specify almost whatever framerate you want.
And IIRC when exporting at 50fps you don't get any tweened frames. So it should look identical to pre 3.8.
Oh and the recording might seem sped up since when exporting frames with 3.8+, it will try to export frames as fast as possible. So depending on computer speed and disk write speed and how many fps you want the gameplay may look very fast.

Since the fps is now so flexible and its only an extra 10fps I would say that 60fps would be ideal. Since that's much more standard for monitors.
As for resolution, imo 720p is the sweet spot. 1080p may be too zoomed out for some, and 480p may be the opposite.

Using that size multiplied by the 227,560 games is surprisingly only 15.8TiB. Only slightly bigger than my home server. Perhaps within the realms of self hostable.
Though with something like YouTube the quality and bandwidth hit could be much better.

For encoding I actually just manually used ffmpeg to record the sound and encode the frames from the /getvideo WA command. ArmaRec still has slight audio issues.
This is the file's mediainfo: https://gist.github.com/cgarz/2a40a791515d1724bc8aab771bd25695

For mass conversion it might be wise to look into adding command line options to ArmaRec for batch operation. Perhaps even one per core to decrease encoding time if WA is receptive to running more than one video exporting instance.

[...]I'm the creator of that one, I think I can fix those broken files right away.
[...]Noticed these files dont have tags and when opening em in audacity causes it to make a message to install the FFMpeg plugin.

The issue with those files is that they are actually MP3 files despite having the wave extension. They just need converted to 16bit MS PCM wave like the rest of the files.
I'm sorting through the pack just now and will probably just convert any invalid formats to wav where possible. However if you have the source in lossless format then using that would be the most proper fix.

That's because of the design of the frontend menus, called "DXMFC". What happens is [...]
All of these issues have been completely fixed for the next update (3.8.0.0).

Thank you very much StepS. A very thorough explanation. I had heard rumblings about the upcoming v3.8 release and got exited. If it will also allow me to use D3D9 with wine then I'm extra excited! 

Anyone know how to get this working in wine? The FrontendUseDesktopWindow tweak doesn't seem to fix the black screen issue in D3D9 modes.
Clicking a button in the blackness causes the UI to briefly flash on screen. But it quickly turns black again. Its like a black window is being drawn over it for some reason.
When using stretch you can see this black window obscuring just the top left of the screen.

Works great in windows though. Amazing module.