SmartVersion | Tools + Scripts

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).

 

I think, recompressing is faster?

 

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.

 

Oki-dok, I can give it a try and post the result.

 

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.

 

Already under control.

 

@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

 

So, 3.7 can recompress from 192 to 119, but still cannot decode, even 119 SVF.

 

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.

 

You need to login to view this posts content.

 

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

 

You need to login to view this posts content.

 

Oh! At least 3.7 worked for once!