if lzma speed is 20 mb/s and 4x4:lzma speed is 1 gb/s, then you have at least 25 cpu cores :) start with measuring full decompression time from start to finish rather than looking into hdd read speeds

you have a good pc, only if u have what u says
but u should first read some Forums post and others to understand
How actually stuffs works?

@Bulat can you do something for this pls
http://fileforums.com/showthread.php...681#post452681
http://fileforums.com/showthread.php...684#post452684
http://fileforums.com/showthread.php...762#post452762

bulat
if you don't believe me try it for you self you the expert,
but i am not stupid...
i am not trying to argue just sharing what i encounter.
but try it you self...
the system i used is
I7 6700K
DDR4 2X8GB 3200MHZ TIMING 15-15-30
SSD SAMSUNG 950 PRO
THE HDD IS WD BLACK
AND THE EXTRNAL STORAGE IS Seagate STEA2000400.

your English is worse then mine

may be you get me wrong, i never said u r stupid nor i think like that, what i have said is that u need some reading first, nothing else

it is because
and LZMA is LZ77 algorithm. Moreover 4x4 can use more then one lzma instance to unpack files by making them work on seperate chunks since its very difficult for Lzma to do that alone and the most Important one, "IGOR don't want to implement it " or in his word he don't have time

Using Lzma the highest speed u can get is around 25-30 mb/s
but u r saying u r getting 175 mb/s with 4x4
this mean u r using 6 out of 8 threads of ur pc
but still saying 50% cpu usage , strange really strange

my frist post on the forum i said pardon me english :o
if someone have skylake or kabylake it is good to test with fast ram and try to montor cpu usage
first run test on normal hdd
the second run try on ssd
you will see different cpu usage
i will try soon agian just to be sure
i will try high clock like 4.5g and then
i will try to test by lower down the clock on the cpu to 3 ghz and see the difference
and if i have more time i will test by disable 2 core to will bee like i3 then i will test with 4 core but without hyper threading like i5
and report back...
but i can't promess so take it with grain of salt.

well, i said how to check the real speed. if you think that i'm wrong, i can't help youi

razor is correct - -sSIZE works only at compression stage. it allocs memory required to compress files up to this size. it's ignored at decompression stage. if atcompression you tries to process file larger than specified, it should just copy remaining data without further compression and correctly decompress it, but may i'm not sure whether it really works - try yourself with standalone srep.exe and report if it goes wrong

overall, if it goes wrong with srep+7z+shar, why you don't try srep alone?? do you expect that someone will solve yuor problems if you can't do simple things yourself?

the setting i used for zstd ver 1.1.2 IS

[External compressor:zstd]
header = 0
packcmd = zstd -22 --ultra <stdin> <stdout>

and for 4x4:lzma i used
arc a -ed -ep1 -lc2000 -r -ma -md -mx -s; -w.\temp -m4x4:lzma:a1:mfbt4:d185m:fb273:mc10000:lc8

only arc.exe witout srep or anything else.

if anyone have similar system I7 6700K with fast ddr4 and ssd nvme welcome to try and share the results..:confused:
i simple man trying to making sense of what i encounter

there article on pcper about how flash 3d nand accelerate data like burst write...
i don't know maybe this is the reason ?
if someone care to test and explain.
it does not matter to me like i said before i try to post what i experienced if someone find it useful great if not no need for hostile comments...

sir, i tried it many maany timeees, every times the same result
i compress those files with shar|srep|7z
since i am archiving with shar i know the correct input size so i give it to srep via -s while compressing
while decompressing i tried to decompress all the things in pipe but it doesn't work srep gives wrong data,
i tried doing every thing separately, first decompress with 7z, It says Every thing is correct, then srep it doesn't say anything, looking at logs and size fo resultant(decompressed) file from srep i concluded that srep is the culprit and it is not restoring the files correctly

if u say so i will run those tests again, i don't have those archives anymore but at morning, its 12AM here

that's great. so you can't describe what exactly happened nor have files. sorry, i can't help in that case

bulat
how the FreeArc Next development going ?
when are you planing to release it..

it's almost done. now i fix bugs and write docs

great
are you plan to make it shareware like winrar or like 7z GNU source

i plan to release existing freearc as shareware so that those whio want to help fa'next development can do it by buying existing freearc

so you planing to support freearc more add more feature like built in zstd-srep or just convert freearc 0.67 alpha to 1.0 stable