1000 metric is the standard for Linux and 1024 the standard for Windows so it's a bit hard to decide for one. As the majority uses Windows, I maybe switch to the 1024 metric.It seems the file size in progress bar and status is based on 1000 metric, not 1024. Would it be better to use the same metric as the system file explorer?
--------------------- MERGED ---------------------------
For compressing level, would higher level of compressing require more memory or cpu time when the nsz been installed or later maybe mounted?
Even on highest compression level you still get 642 MB/s decompression speed per core which is around half the speed compared to worst compression level. Which such a decompression speed you will probably bottleneck on many other places first but let's assume you game manages to actually bottleneck the SD card's compressed read speed now as better the compression ratio the later you get that sort of bottleneck. As better the compression ratio as less compressed data needs to be read for the same amount of decompressed data. As higher the compression ratio the more you artificially increase your SD card's read speed. Because of this scarifying compression ratio for decompression cost makes absolutely no sense and was one of the main reasons why zStandard was chosen.
I don't think the RAM usage depends on the compression level and should generally be very low. To mount a game, you need to compress it using block compression anyways as otherwise you won't have random read access. The default chunk size is 1 MB so you will never need more then few hundred KB RAM anyways which is extremely important as sysmodules are extremely RAM limited.
Take a look at https://gist.github.com/nicoboss/62ae92c5dd0d44088323dc8b37859abf to see all zStandard compression and decompression performance for all compression levels using a single core.
With clean unmodified or properly modified games you should never get any verification errors if you are using the latest stable NSZ 2.1.1 release. Most likely you are using games from a dirty source, use an instable version with a major bug inside compression or decompression or something with your setup is wrong. Verification makes sure games you compress still matches the hashes inside the Cnmt file after decompression which are the same hashes Horizon uses to verify the integrity of your games. If somebody modified the game without adjusting these hashes or something during compression or decompression went wrong you get a hash error. If this error occurs for clean games on latest stable and latest commit with latest prod.keys please open an issue with informations how to reproduce under https://github.com/nicoboss/nsz/issues/newIt seems verification report hash mismatch happens very often. What's the cause of this?
Does the problem come from verification or compressing?
Last edited by nicoboss,