XTool (2020)

XTool (2020) 0.6.7

Нет прав для скачивания

Edison007

Ветеран
Модератор
Разор сам в обновлении писал, что лзма для тех, кто хочет использовать хтул без фриарка.
Да я понимаю, зачем оно, но сомневаюсь, что кто-то будет использовать хтул, как standalone прогу. А городить огород, ради того, что был огород - ИМХО решение не лучшее.

Почему будет хуже, а не точно так же
Уже сжатое - не сжимается (за редким исключением). Или что Вы имеете в виду?
 

Shegorat

Lord of Madness
Администратор
Человек захотел и смог реализовать задуманное, кроме этого оставил за пользователем выбор, использовать эту функцию или нет, а не навязал её по умолчанию.;)
Если в версии 0.6.1 она была интегрирована и активировалась через ключ (--compress), то в версии 0.6.2, Рэйзор ушёл от этого, оставив выбор за пользователем.
Первая аналогия, которая приходит на ум - это Lzma из Precomp, который тоже может работать без FA.:)
Это да, но и в том же прекомпе никто не использует сжатие, Просто потому что можно накрутить различные фильтры типа msc и прочего и получить более лучшее сжатие
 

Den.Scaletta

Новичок
Уже сжатое - не сжимается (за редким исключением). Или что Вы имеете в виду?
Edison007, всё так и есть.

Xtool+Lzma2
Xtool+Lzma2+Lolz
результат на выходе был одинаков в моём случае.
Если быть точным то: from 1.03 GB to 105 MB.
Но когда dixen18 спросил:
dixen18: написал(а):
То есть по логике XTool:lzma2+lolz должно жаться лучше чем XTool+lolz?
Вы ответили:
Edison007: написал(а):
Нет. Будет хуже
Вот я и решил, а вдруг что-то упустил, поэтому и спросил:
Den.Scaletta: написал(а):
Почему будет хуже, а не точно так же?:)
Хотя, сколько сколько людей, столько и результатов, наверное.;)

P.S. У вас нашлось время, чтобы протестировать тот архив, который оставил для вас в теме Lolz?
Если да, то я его удалю с google drive.
 

Shegorat

Lord of Madness
Администратор
@Den.Scaletta, просто что lzma что lolz имеют в своей основе высоко-энтропийные алгоритмы. И за очень редким исключением их вывод не жмется от слова совсем, часто получается даже размер больше
 

Den.Scaletta

Новичок
Это да, но и в том же прекомпе никто не использует сжатие, Просто потому что можно накрутить различные фильтры типа msc и прочего и получить более лучшее сжатие
Shegorat, согласен.

Но если так, тогда в каком направлении должен был бы развиваться xtool, по вашему мнению и как вы смотрите на систему inject libraries в версии 0.6.2?
 

Shegorat

Lord of Madness
Администратор
@Den.Scaletta, а я не смотрел последние версии xtool. Поэтому про инджект ничего не скажу
Но вообще Разору надо реализовать скользящий буфер. В текущей реализации сжатые потоки на границе блока просто не находит при малом размере блока. А при большом - высокое потребление памяти.
Ну и реализовать нормальный stdin/stdout чтобы обойтись без временных файлов
 

Edison007

Ветеран
Модератор
P.S. У вас нашлось время, чтобы протестировать тот архив, который оставил для вас в теме Lolz?
Только скачал, еще не было времени на тесты

Ну и реализовать нормальный stdin/stdout чтобы обойтись без временных файлов
Временный файл там только для дубликатов (как я понимаю), которые не влезли в выделенный буфер.
А еще stdin-out нужно нормально реализовать в самом FA :)

Но вообще Разору надо реализовать скользящий буфер.
Вот это было бы отличное развитие. Сам я не тестил нормально хтул, не смотрел сорцы, но боюсь, что многопоточность при кодировании завязана, как раз на блоках. Но это только предположение)


результат на выходе был одинаков в моём случае.
Это только из-за того, что lolz несжимаемые данные сохраняет "как есть".
 
Последнее редактирование:

Den.Scaletta

Новичок
@Den.Scaletta, просто что lzma что lolz имеют в своей основе высоко-энтропийные алгоритмы. И за очень редким исключением их вывод не жмется от слова совсем, часто получается даже размер больше
Shegorat, спасибо.🙏
Теперь буду знать.
Shegorat: написал(а):
В текущей реализации сжатые потоки на границе блока просто не находит при малом размере блока. А при большом - высокое потребление памяти.
Размер блока - это ведь ключ (-с), верно!?
Если так, тогда какой оптимальный размер для Xtool 0.5.3 на ваш взгляд? :scratchhead:
И что такое скользящий буфер?:scratchhead:
 
Последнее редактирование:

Den.Scaletta

Новичок
Edison007: написал(а):
Только скачал, еще не было времени на тесты.
Edison007, отлично.🤝
Как будет позволять время проверьте.:)
Собирался архив на FA 0.67 + Xtool 0.5.3 + Lolz test22c4b, все нужные файлы идут в комплекте.
 
Последнее редактирование:

Den.Scaletta

Новичок
Но вообще Разору надо реализовать скользящий буфер. В текущей реализации сжатые потоки на границе блока просто не находит при малом размере блока. А при большом - высокое потребление памяти.
Ну и реализовать нормальный stdin/stdout чтобы обойтись без временных файлов
Edison007: написал(а):
Вот это было бы отличное развитие. Сам я не тестил нормально хтул, не смотрел сорцы, но боюсь, что многопоточность при кодировании завязана, как раз на блоках. Но это только предположение)
Shegorat & Edison007, хотелось бы узнать.:scratchhead:
Рэйзор знает об этих идеях?:)
 
Последнее редактирование:

Razor12911

Новичок
Но вообще Разору надо реализовать скользящий буфер. В текущей реализации сжатые потоки на границе блока просто не находит при малом размере блока. А при большом - высокое потребление памяти.
Ну и реализовать нормальный stdin/stdout чтобы обойтись без временных файлов
Xtool uses a similar technique though, it's the same to a sliding window (hybrid of sliding window and a chunk). When a user sets 16mb chunk size for example, the scanning range is 16mb but if a stream is found at the boundary, it overextends by an additional 16mb so effectively 32mb sized streams can be detected. It's done this way so that when more than 1 thread is used for scanning, at least each thread has the set chunk size to access and the ability to overextend to the data that the next thread has access to. The high memory usage comes from the number of threads the user has selected because if you have 8 threads for example, 144mb is read into memory. (16 mb x 8 threads + 16 mb) making sure every thread has at least 32mb range to find stream that is at least 16mb that can overextend to 32mb. (Theoretically, no streams are missed if the right chunk size is set, 64mb should be enough. I am not sure why people set 512mb and expect better results then complain about very high memory usage...)
PS: There is an option -lm (low memory mode which makes xtool use 1 thread to scan bringing down memory usage) In this mode 1 thread performs scanning however the streams themselves are processed by all threads.

If however you were referring to how reflate works by reading data and processsing it sequentially then this would mean multi threading is not possible, not to mention it's not just one codec that is scanning/processing data (there are databases, ini files, zlib, oodle etc) this would not work as intended without sacrificing either speed or losing stdio due to data needing to be re-read more than once.

У TTA, WavPack, SLA исходники также доступны, у OFR и TAK есть библиотеки для декодирования (можно было сделать, как в MSC, кодирование через exe-файл). К тому же в версии TAK 2.3.3 появилась х64 либа для декода. С остальными кодерами сложнее (они просто в кучу попали, т.к сейчас занимаюсь сжатием аудио и тест с flac до кучи сделал). Вообще для FLAC можно добиться сжатия и лучше, если брутить не пресеты, а опции по отдельности, но там брут будет слишком долгим, к такому даже я еще не готов :)
Well it's not like I haven't tried TTA and Wavpack but either implementing these causes problems as I need to translate parts of the source to Delphi from Cpp and in addition, not sure if it was tta or wavpack but one of these libraries does not seem to be thread safe meaning when used in parallel the entire process fails. Flac was available because not only was it easy to implement but it was also thread safe. TAK/OFR were not chosen because the encoder is not open source which means temps need to be created (which I dislike).

_______________________

Regarding the addition of fast-lzma2, it's something that I use personally mostly for quick tests because Freearc is very problematic on my PC especially when accepting a folder with a lot of files in it and would crash without warning hence why I made xtool accept directory as an input and once precompression is done, it would just compress the data so I can see that the changes to the source were done correctly because I grew tired of making tar archives to use as input for xtool for tests. fast-lzma2 was chosen because it may produce 1% less ratio but at least it's about 2x faster than standard lzma so I don't pretty much know where some people got the idea of combining this with lolz. I guess goes to show that when users are given options, they want to use all of them without having some prior knowledge as to why it was added and when it can be used. I cannot use lolz for quick tests because I want to see results right now and not till kingdom come.
 
Последнее редактирование:

Den.Scaletta

Новичок
Xtool uses a similar technique though, it's the same to a sliding window (hybrid of sliding window and a chunk). When a user sets 16mb chunk size for example, the scanning range is 16mb but if a stream is found at the boundary, it overextends by an additional 16mb so effectively 32mb sized streams can be detected. It's done this way so that when more than 1 thread is used for scanning, at least each thread has the set chunk size to access and the ability to overextend to the data that the next thread has access to. The high memory usage comes from the number of threads the user has selected because if you have 8 threads for example, 144mb is read into memory. (16 mb x 8 threads + 16 mb) making sure every thread has at least 32mb range to find stream that is at least 16mb that can overextend to 32mb. (Theoretically, no streams are missed if the right chunk size is set, 64mb should be enough. I am not sure why people set 512mb and expect better results then complain about very high memory usage...)
PS: There is an option -lm (low memory mode which makes xtool use 1 thread to scan bringing down memory usage) In this mode 1 thread performs scanning however the streams themselves are processed by all threads.

If however you were referring to how reflate works by reading data and processsing it sequentially then this would mean multi threading is not possible, not to mention it's not just one codec that is scanning/processing data (there are databases, ini files, zlib, oodle etc) this would not work as intended without sacrificing either speed or losing stdio due to data needing to be re-read more than once.


Well it's not like I haven't tried TTA and Wavpack but either implementing these causes problems as I need to translate parts of the source to Delphi from Cpp and in addition, not sure if it was tta or wavpack but one of these libraries does not seem to be thread safe meaning when used in parallel the entire process fails. Flac was available because not only was it easy to implement but it was also thread safe. TAK/OFR were not chosen because the encoder is not open source which means temps need to be created (which I dislike).

_______________________

Regarding the addition of fast-lzma2, it's something that I use personally mostly for quick tests because Freearc is very problematic on my PC especially when accepting a folder with a lot of files in it and would crash without warning hence why I made xtool accept directory as an input and once precompression is done, it would just compress the data so I can see that the changes to the source were done correctly because I grew tired of making tar archives to use as input for xtool for tests. fast-lzma2 was chosen because it may produce 1% less ratio but at least it's about 2x faster than standard lzma so I don't pretty much know where some people got the idea of combining this with lolz. I guess goes to show that when users are given options, they want to use all of them without having some prior knowledge as to why it was added and when it can be used. I cannot use lolz for quick tests because I want to see results right now and not till kingdom come.
Razor12911, hello Razor and welcome back.🤝
Thank you so much for your detailed explanation.🙏

I have some practice with xtool and I have one question for you about the key --mem.
What if the --mem key, gets one more value like a --mem=auto.
Default value is --mem=75p, correctly?!
For example:
If I run xtool on the system with( from 2048 to 4096) ram, then xtool automatically select the value --mem=25p.
This is really important for the fix error unarc.dll -12.
I did some tests and every time I ran to unpack xtool+lolz with 2048 or 4096 ram at 75p value, I got the error unarc.dll -12.
If I changed this value to 25p, everything worked fine.
It's not lolz that creates this error, only the value of --mem=75p.
What do you think about it?:scratchhead:
Thanks in advance!:)
 
Последнее редактирование:

Razor12911

Новичок
Does this problem persist in v0.6.1+? Because I thought I fixed any error related issues but if it's still there then could you provide a sample?

Deduplication memory usage is dynamic as it constantly checks and ensures that the moment 75% of the system resources is used up (overall, not by xtool). Like for example if on that system with 4GB ram, the user was running google chrome which used a lot of memory and 70% memory was available before xtool was started, from that 75p default, it means xtool actually has 5% that it can use before switching over to virtual memory. Not that xtool should use 75% of 4GB (3GB) - this is not how it works.

This constant memory checks can be bundled with the fact that if srep+lolz is used as well (since data passes through them before xtool), their total memory affects how much memory xtool itself can use.

In any case, a simple fix to this for systems with low memory would be --mem=75p-2gb which means on those systems, like 2-4GB ram systems, xtool in most cases would immediately use virtual memory. (Math equations are allowed when setting parameters)

Edit: Most issues were present in versions prior to 0.6 (0.5.3) because the technique that was used was flawed because xtool tries to reuse memory as much as possible and when it's no longer being needed, rather than allocate more memory, reuses old inactive memory. This reuse of memory means xtool alternates between physical and virtual memory for both storing duplicates and reading from them so please do run the same test using 0.6.1+

Thanks
 
Последнее редактирование:

Den.Scaletta

Новичок
Does this problem persist in v0.6.1+? Because I thought I fixed any error related issues but if it's still there then could you provide a sample?

Deduplication memory usage is dynamic as it constantly checks and ensures that the moment 75% of the system resources is used up (overall, not by xtool). Like for example if on that system with 4GB ram, the user was running google chrome which used a lot of memory and 70% memory was available before xtool was started, from that 75p default, it means xtool actually has 5% that it can use before switching over to virtual memory. Not that xtool should use 75% of 4GB (3GB) - this is not how it works.

This constant memory checks can be bundled with the fact that if srep+lolz is used as well (since data passes through them before xtool), their total memory affects how much memory xtool itself can use.

In any case, a simple fix to this for systems with low memory would be --mem=75p-2gb which means on those systems, like 2-4GB ram systems, xtool in most cases would immediately use virtual memory. (Math equations are allowed when setting parameters)

Edit: Most issues were present in versions prior to 0.6 (0.5.3) because the technique that was used was flawed because xtool tries to reuse memory as much as possible and when it's no longer being needed, rather than allocate more memory, reuses old inactive memory. This reuse of memory means xtool alternates between physical and virtual memory for both storing duplicates and reading from them so please do run the same test using 0.6.1+

Thanks
Razor12911, hello.🤝
Thank you so much for explaining in detail.🙏

You were right about behavior of xtool v0.6.2
[External compressor:xtool]
header = 0
unpackcmd = xtool.exe decode -t100p-1 --mem=75p --dedup - - <stdin> <stdout>
If I have os with RAM from 2048 to 4096 MB. and pagefile.sys 16384 and I run xtool v0.5.3, then:
I get the error Unarc.dll -12

If I change --mem=75p to --mem=75p-1000mb, then all working fine without error.

[External compressor:xtool]
header = 0
unpackcmd = xtool.exe decode -t100p-1 --mem=75p --dedup - - <stdin> <stdout>
If I have os with RAM 4096 MB. and pagefile.sys 16384 and I run xtool v0.6.2, then:
All working fine without error.
But, if I have os with RAM 2048 MB. and pagefile.sys 16384 and I run xtool v0.6.2, then:
I get the error Unarc.dll -11
If I change --mem=75p to --mem=75p-1000mb, then all working fine without error.
Xtool v0.5.3+Lolz - 2.18 GB. after unpacking 7.47 GB.

Xtool v0.6.2+Lolz - 2.19 GB. after unpacking 7.47 GB.

P.S. Sorry for the late reply, I've been a little busy.:)
 

Mickey1s

Ветеран
Модератор
Mickey1s обновил(а) ресурс XTool (2020) новой записью:

0.65

Update available

Changes

- updated oodle scanner
- remove xdelta support from oodle and lzo codecs (crc mismatch often generates large diff files)

Notes
I've been getting reports of xtool taking a long time to process oodle streams (or getting stuck) so I reworked the scanner. I reverse engineered the code of oo2rec (I lost the source code) and rewrote parts of the code so xtool should produce better results while being faster.

There is a parameter rework as well...
Узнать больше об этом обновлении...
 

Mickey1s

Ветеран
Модератор
Сверху