Yes, i too use x86 by default on Windows. No issues. This thing here with linux is new.......... More testing I tried to create a patch using Windows 10 iso´s: Linux smv x86 3.7 skipping < -compressratio> Linux smv x86 3.6 skipping < -compressratio> Final size ~1 million bytes smaller than < -compressratio 119> I don't have a Linux x64 atm so cant say much, however, encoding and decoding seems a lot faster in a Linux environment compared to Windows. Samplesize is small so this is just how I feel it.
This all sums up that the 32bit linux version of smv 3.7 is problematic under most situations. The faster encoding and decoding on linux can be attributed to the better filesystem that it uses (ext4).
Possible, give it a try Never tried recompressing from < -compressratio 192> to < -compressratio 119> and if that would make a difference to the issue with smv 3.7 x86 Linux version... Do you want me to try or do you have a Linux x86 runnin`?
I do not have linux now. Sometimes i have linux inside VM, just to try something sometimes. I think, try to use the same nbhashbits parameter and see. Windows and Linux.
It will be interesting to see 3.7 under Linux. If 3.7 cannot decode under Linux, is it even possible to recompress under Linux? (192 -> 119) If it is possible, then try 3.6 and 3.7, for recompressed (119) SVF.
@3zero3 That actually works <smv m "old_svf_file" "new_svf_file" -recompress -nbhashbits 24 -compressratio 119 -sha1 -sha256> (add ./ in front of smv in Linux) Took ~10 s (smv.exe x64) on i7-4720 @ 2.60GHz with 8 GB ram using the same Windows 10 svf patch as previously Linux smv 3.6 x86 all good, smv 3.7 x86 no dice Edit: Original file - recompressed on Windows 7 x64 with smv.exe x86 3.7 241170944 bytes | [el-gr]_el_windows_10_consumer_editions_version_1909_x86_dvd_30e49323.svf Time recompress | new size in bytes | switches 23,0 s | 364374112 bytes | -recompress 14,5 s | 364423240 bytes | -recompress -nbhashbits 24 -sha1 -sha256 13,5 s | 365920864 bytes | -recompress -nbhashbits 24 -compressratio 119 -sha1 -sha256 05,0 s | 376105172 bytes | -recompress -nbhashbits 24 -compressratio 160 ~10 s faster with -nbhashbits 24 ~18 s faster with -nbhashbits 24 and -compressratio 160 All files are tested
smv 3.7 x86 Linux is nogo! It will work on smaller patches, like XP etc but with Windows 7 and 10 It seems to be related to size somewhere.......
@3zero3 I did a re-test, didn't try recompress with x86 3.7 in Linux That works, but I still cant decode this recompressed svf file with 3.7, 3.6 is the rescue.
Done some thinkering: A script to rename svf file to, say "svf file 192", then recompress using original svf name and then decode with 3.6 would be a solution.......
Maybe I am wrong, but we cannot find out which compression was used. We can only recompress, even 192 to 192 or 160 to 160.
Yeah, that's dangerous s**t My old i5 allowed me to enter Win+R: taskkill /im svfx.exe /t /f and survived. Switch to .dll would be nice, but w/o API description (and lack of experience), I think I can't overpower it. Also regularly updated ISOs discourages any desire to do anything else Thanks for report