Afaik no, because DELZORec requires non solid + 2 input files whereas FA can only deliver 1 input file.

no, it's not possible because xtool can't be made to give two inputs nor accept two outputs

Update available

Changes

- generate database feature fixed
- fixed external executable support issues
- fixed lz4f level setting bug

Update available

Changes

- updated oodle scanner
- updated external executable support
- updated configuration based plugin support to add depth information
- updated verbose mode

Notes

Given that very small number of people are able to make their own plugins and codecs to use in xtool, I've added an example that imports codecs from QuickBMS after you have generated your database and have no codec to use with it.

For compression:
For encryption:
You'll need to check http://aluigi.altervista.org/papers/quickbms.txt for the list of supported compressors built in so that you don't pick something like lz2k and expect it to work (quickbms itself has to be able to both compress and decompress). You can add more codecs like I have done here "cpk,snappy,rfpk", if you wanted to add lzss for example, it then becomes "cpk,snappy,rfpk,lzss" then from there you can use Bms2Xtl for scripts that have this comtype and possibly expect xtool to use quickbms with no real issues (hopefully).

Also note that if for whatever reason there is crc mismatch, xtool will still help you by applying xdelta automatically. :)

Also also note that this generate temps files meaning the process is slower because it has to both read and write to disk therefore, only use this approach if there is nothing else that you can to do to improve the situation.

OMG ok with this I think you opened can for a whole lot of more codecs/games to be able to process.

Update available

Changes

- fixed issue with storing correct recompression information when stream patching is performed

Notes

This issue was brought up by Masquerade and L0v3craft when they were trying to precompress WRC 10 and upon decoding xtool would produce an error so thanks to them, it has been resolved however I'd like to add more useful information regarding this game and why even with xtool helping you with deltas will not allow you to process all streams based on how xtool was designed.

We all know that xtool patches streams if they cannot be restored correctly however it sets its own boundaries, by default the patch file cannot be 5% larger than the original size else the patch fails as highlighted here with some streams being missed. https://fileforums.com/showpost.php?...&postcount=248

This 5% can be changed by user via the command --diff=5p, with 5p being 5%, so to capture all these other streams, you'll have to increase this percentage.

CHUNK_57.PKG
using -mwrc10
using -mwrc10 --diff=20p
Verbose information displays
Patching this 514 byte stream produced a 26 byte patch file, which is 5.1% and that is larger than the 5% limit so increasing this means you are allowing xtool to accept this stream.

--diff=20p

LEGO® Star Wars™: The Skywalker Saga uses Kraken

OMG it's a great tool! Thanks for it!
https://radaryonline.pl/gdzie-jest-burza/

Update available

Changes

- added IO functions (erase, replace)
- fixed external executable support bugs

Notes

Xtool has introduced IO functions, which should help you perform file and folder operations such as erase and replace (for now, more will be added). I actually wanted to add these functions a long time ago as they could be useful for repacking however I delayed them time after time because precompression needed more attention but as there have been no bug reports for the past 3 weeks I decided to start working on them.

To summarise, Erase is a feature that fills a given input with zeroes in case you wanted to repack certain data separately and Replace is a feature that replaces existing data within certain files with another.
Xtool will search for locations of the extracted streams and store these positions for when you use decode function to revert the changes (yes, the process is reversible)

Erase
Use cases for erase is the removal of language/videos files from archives in games after using another extraction tool, so rather than manually searching for positions and storing them, erase will make this process automated.

An example is after extracting video files from an archive and then wanting to remove credits video, the syntax would be

decode will fill the zeroes with the original data

Replace
The use cases for replace is possibly game file modification.

An example is having several modified files and the original files and you wanted to bulk replace these files, you'd have to prepare two folders with the same file structure and the syntax would be

decode will fill the modified data sectors with the original to restore the file its original form.

PS

If you are using these features for a repack in which people would select languages or video credits for example, if the users did not select any of these to be installed then there would be missing files. Xtool's decode command would still work and will try to restore the original data using whatever data that was selected and available without problems.

Update available

Changes

- added IO functions (find, extract, patch)
- generate database feature and IO functions now can search for streams larger than chunk size

Notes

More IO functions introduced. Find simply helps you track positions of extracted files from a given input, while extract uses a generated decode file data input to extract streams in case if you wanted another person to extract their very own streams using your own findings and patch, well patch compares two inputs and generates a diff file which can allow you to patch an input to make it similar to the new data.

Find

Find can be used to search for streams to then produce decode data which you can upload here on the forum in cases where you wanted to inform people what files should be extracted if they wanted for example to separate audio files per language from a game.

An example where I wanted to make a guide of how to separate english, german, italian, russian and spanish languages from the game would be something like:

These files are then uploaded for people if they wanted to extract the same data by themselves by using xtool via the "extract" function or for later use by yourself.

Extract

Extract works mostly hand in hand with with the find function as its job is to use the decode_data to extract the data that was used for its generation.

A use case for it would be similar to the find example but from another user's perspective, so if someone uploaded decode data to use to extract my very own streams from their investigations, rather than them giving me position ranges for languages or the tools to use, we can just use their uploaded decode data to do it ourselves

Then from here, we use these extracted files, to even use the erase function introduced in the version prior to blank out the sectors to prepare our own repack

which we can then restore after installation using

Patch

Patch's use case can be the generation of update patches in cases where you already made a repack but for whatever reason refuse to re-repack the game so instead choose to generate a patch file which can be used to update the old repack with newer files

Then after the installation of the original repack, you can add an additional archive that has sims4_wedding_stories.patch which will be used to update the game

I noticed after compiling xtool.exe that xdelta is set to compress these patch files which means that they cannot be precompressed nor compressed with something better, however this compression in the next version will be removed. :)

Update available

Changes

- added IO functions (archive, execute)
- fixed issue in patch io function
- removed compression on patch diff files

Notes

More IO functions added. Archive behaves like -m0 but allows you to the archive to stdout and read from stdin when decoding (if you ever need that). Then there is execute which allows you execute several instances of another executable in parallel mode while all their inputs are fed from one source and all their output is fed to one destination.

Archive

There is nothing to add here as I have personal uses for this but the example would be

Execute

Too lazy to write description but, here's an example

The left side of the syntax is to command xtool and after specifying input and output files, the right side begins and here you can write the command line that should be used to perform execution.

[filein], [fileout], [stdin], [stdout] can be used and denote what IO the program being executed uses.
[] is used to avoid conflicting with Freearc's <>

Freearc example would look like this

and the method would be -mxbcm:c64mb:t75p

Update available

Changes

- added png stream preprocessor
- removed grittibanzli codec (since nobody uses it)

Notes

Xtool is able to process deflate/zlib streams and png images do contain these streams however, they are split up into several blocks which at times does prevent the program from being able to process them. The png stream preprocessor's job is to concatenate (rejoin all these blocks into a single stream) which can then be processed by xtool, so if you know your input contains these images then it's best to include -mpng into the method chain and use -d1 to first preprocess the streams then process them using zlib, reflate or preflate (preflate is the preferred method to use).

Results

without png preprocessor:
with png preprocessor:

@Razor12911, can i use the parameters in that order in freearc commandline?

yes but you'll have to change arc.ini from { -moption} to { -option}

Thanks.
Yes, I use { -option} in Arc.ini of the DSG.
I tested precompressing pngs with just "xtool:mpreflate" or with "xtool:mpreflate:mpng:d1" and got similar (near)I figured I was using the command order wrong.

sorry, for asking this question here, i don't know where to ask.

someone please tell me and give me,
best .Wav (.pck) compressor
with arc.ini info and required files.
Thanks 😊

hint:
i try Pck files, on GFC.
Game File Scanner showing WAV streams. so i guess i can use Wav compressor.

msc :confused:

And I don't know what this has to do with xtool.

yes, my bad, this is not related to xtool
i try msc, but wont work. can you help me. :)

yasitha: Try it use testing tta methods from FreeArc and totally ignored file extension from during compression.

This compression oks, use final packing the following switches:

tta+srep+lzma or lolz

Afaik freearc's tta works on per file basis,while msc works on stream(/file)?!

Posting it here aswell

thanks bro can you please share tta+ config required files as (.zip)
so i can try and use

thank you!! :)

thank you :)

:confused::confused::confused: what is this ? :eek:

:mad: https://fileforums.com/showpost.php?...&postcount=493

During repacking of Final Fantasy XIII(PC version), I found that using cause crc error during unpacking of the game. Cause is almost certainly due to combining zlib with reflate as alone either one work. Maybe they are not together compatible with depth option, only d0?

EDIT: Its probably something else, I still got error today after using only reflate. Its strange I don't tend to get these kind of errors for no reason:

Attachment 32015
Attachment 32016


-----------------------------------------------------------------------------------
EDIT2:
Found the problem! It's with reflate. If I use zlib instead:

Code:

---

xtool:d1:c32m:mzlib+srep64:m3f:mem8g:a0+4x4:lzma:64mb:normal:32:lc8

---

, it works. I don't know why, in other cases I never saw issue with reflate.

ADDENUM: It's due to depth. Anything higher than -d0 cause failure during decompression. Zlib and preflate do not have this problem. Data tested is 'sys' directory(2.8gb) in Final Fantasy XIII(PC, fitgirl version).

I could be wrong, but using this method line, I think something like this should be used in arc.ini:

Nope, still throws the error. Also it compress fine and show correct chain on archive info:
, which is same regardless if I use {options} or { -option}

EDIT: Found the problem, see 2 posts above.

Also, aside from what I stated above, there was another interesting thing I found. When inflating(with reflate option), if I use c32m-c128m range, xtool process about 25150 streams. Then when I use -c256m, it only process ~22000 streams. And yet, if I use -c512m option, it again process ~25150 streams. All other options same. Go figure.

And even more interesting, reflate is actually faster than zlib at same options(with depth 1 and chunk size of 32m at least)???:

Attachment 32013
Attachment 32014

And preflate is worse than zlib hmmm..:

Attachment 32017

Update available

Changes

- added wav stream detector
- added flac codec
- added jpg stream detector
- added packjpg, brunsli, jojpeg codec
- added feature that allows input to be a directory
- added feature to extract detected streams
- updated database feature
- updated deduplication feature
- IO function decode updated

Notes

I have added wav audio compression as an alternative of msc for people who has issues with it or don't want to use Freearc's tta codec as it processes wav files individually. One thing to note, it's not as good as tta, tak or even frog as it is based on flac codec (It was the only open source codec I could work with...).

Also added jpg image compression codecs, you can pick between packjpg, brunsli or jojpeg. packjpg seems to have a memory leak, brunsli is fast but cannot deal with large jpg images and jojpeg can be used if you're after ratio as it is paq based (seems to be buggy so stick to packjpg or brunsli for now)

A new parameter is added --extract=[path], this will extract all detected streams to a directory... if you're interested in the streams themselves.

database and deduplication features have been updated and can now be used at all times without worrying about crc collisions.

Special thanks to KaktoR for running several tests and Shelwien for providing compiled libraries for brunsli and jojpeg.

@elit
These issues will be investigated in time.

Find little uncritical bug


Anyway, thank Razor for update and new functions)

One question. Why TTA but not TAK?

TAK isn't Open Source.

Interesting, I should note that compression difference between different wav codecs is minimal. Also for me in the past, I found wavpack the best, It handle more formats(WAV/BWF/RF64, Sony Wave64, Apple CAF, Philips DSDIFF, and Sony DSF (all with no size limitations)), more modes(8, 16, 24, and 32-bit integer PCM; 32-bit float PCM; DSD audio; mono, stereo, and multichannel; sampling rates from 6 to 192 kHz (and non-standard rates)), RIFF chunks, is open source, does support STDIO which for me work unlike flac, which for some reason during decompression kept running past original size inflating to infinity(when used in FA with stdio mode).

However, flac is great too because is non-symetric so decompression is fast(although wavpack also seem to support asym. cmp.).

I wonder how this work, if xtool is able to use it on chunks when wav files are inside big game packs, that would be indeed very useful. In fact, I don't know what would be the point beyond that as we could then just use standalone codecs?

Could someone please remind me what's the difference between the 0.3.21 and 0.6.0 versions?

your chunk size is too small for that input
0.3.21 is an old version that supported old plugins and it is kept there until all plugins are updated to support 0.4+ versions, use 0.6.0 if you are not using old plugins.

https://wiki.hydrogenaud.io/index.ph...ess_comparison

I picked codecs based on the information provided here, it's not that I haven't tried wavpack. I did but it requires additional code as it generates lossy wav and a patch file in case you wanted to restore the original pcm data whereas flac does not. In addition, it doesn't seem to be thread safe which means it cannot work in xtool environment (maybe I'm mistaking it with tta).

That's pretty much how it is intended to work, wav files are scanned within files and then fed to codecs.

That is optional feature with extra switches, by default it work same as flac - no lossy wav. As for thread safety, I believe its single threaded app so could be used chunk per thread but I don't know for sure.
I am also perfectly ok with flac as well so don't worry about it, I just though this one may have been better due to more formats supported.
https://www.wavpack.com

Update available

Changes

- added fast lzma2 compression for portable mode
- fixed issues with wav stream detection
- fixed minor issue with stream deduplication feature

Notes

I have added fast lzma2 compression for users who would want to use xtool without FA but still want to perform compression immediately after precompressing.

Example

Thank You So Much For Your Hard Work, Razor12911!