FileForums

FileForums (https://fileforums.com/index.php)
-   Conversion Tutorials (https://fileforums.com/forumdisplay.php?f=55)
-   -   XTool 2020 (Main Project) (https://fileforums.com/showthread.php?t=102832)

Masquerade 18-03-2022 03:02

Quote:

Originally Posted by dixen (Post 496242)
Is it possible to implement this with DELZOREC? I mean Far Cry 5
For example

[fc5dec]
Encode=dlzo.exe u <filein>.fat <filein>.dat <fileout>.pack
Decode=dlzo.exe r <filein>.pack <fileout>.dat <fileout>.fat

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

Razor12911 20-03-2022 17:41

Quote:

Originally Posted by dixen (Post 496242)
Is it possible to implement this with DELZOREC? I mean Far Cry 5
For example

[fc5dec]
Encode=dlzo.exe u <filein>.fat <filein>.dat <fileout>.pack
Decode=dlzo.exe r <filein>.pack <fileout>.dat <fileout>.fat

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

Razor12911 22-03-2022 14:49

Update available

Changes

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

Razor12911 28-03-2022 10:57

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:
Code:

[cpk,snappy,rfpk]
Encode=quickbms.exe -s "comtype <codec> ; clog <fileout> 0 <insize> <outsize>" "" <filein>
Decode=quickbms.exe -s "comtype <codec>_COMPRESS ; clog <fileout> 0 <insize> <outsize>" "" <filein>

For encryption:
Code:

[blowfish,xxtea]
Encode=quickbms.exe -s "open FDDE <fileres> 1 ; getdstring X_KEY <ressize> 1; encryption <codec> X_KEY "" 0 <ressize>; log <fileout> 0 <insize>" "" <filein>
Decode=quickbms.exe -s "open FDDE <fileres> 1 ; getdstring X_KEY <ressize> 1; encryption <codec> X_KEY "" 1 <ressize>; log <fileout> 0 <insize>" "" <filein>

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.

elit 29-03-2022 09:42

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

Razor12911 03-04-2022 23:57

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
Code:

Compressed 1 file, 99,435,664 => 189,185,421 bytes. Ratio 190.26%
Compression time: cpu 0.14 sec/real 3.71 sec = 4%. Speed 26.82 mB/s

using -mwrc10 --diff=20p
Code:

Compressed 1 file, 99,435,664 => 263,029,277 bytes. Ratio 264.52%
Compression time: cpu 0.09 sec/real 3.61 sec = 3%. Speed 27.53 mB/s

Verbose information displays
Code:

[0] Processing lz4f stream at 0000000000005476 (514 >> 893 >> 514) using l9:b4:d0 has failed
[0] - Patching stream at 0000000000005476 (514 >> 514) [26] has failed

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

Code:

[0] Processing lz4f stream at 0000000000005476 (514 >> 893 >> 514) using l9:b4:d0 has failed
[0] - Patched stream at 0000000000005476 (514 >> 514) [26] successfully


Masquerade 05-04-2022 11:43

LEGO® Star Wars™: The Skywalker Saga uses Kraken

Code:

XTool is created by Razor12911

Streams: 284071/284071
Time: 00:13:43 (00:48:35)
Memory: 512 MB (512 MB)

100.0%
Errorlevel=0

Compressed 1 file, 4,061,948,534 => 9,598,998,234 bytes. Ratio 236.32%
Compression time: cpu 4.22 sec/real 1032.25 sec = 0%. Speed 3.94 mB/s
All OK


GamerfromPoland 05-04-2022 12:21

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

Razor12911 27-04-2022 18:59

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
Code:

xtool erase extracted_streams original_data [decode_data]
xtool decode decode_data extracted_streams original_data

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

Code:

xtool erase credits.bk2 Gobi\Content\Paks\pakchunk33-WinGDK.pak credits.xtl
xtool decode credits.xtl credits.bk2 Gobi\Content\Paks\pakchunk33-WinGDK.pak

decode will fill the zeroes with the original data

Replace
Code:

xtool replace old_streams new_streams original_data [decode_data]
xtool decode decode_data extracted_streams original_data

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

Code:

xtool replace "textures\original\*" "textures\modified\*" "game\*" mod_tex.xtl
xtool decode mod_tex.xtl "textures\original\*" "game\*"

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.

Razor12911 13-05-2022 02:29

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

Code:

xtool find [parameters] extracted_streams original_data [decode_data]
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:

Code:

xtool find "extracted\en\*" "game\*" en.xtl
xtool find "extracted\de\*" "game\*" de.xtl
xtool find "extracted\it\*" "game\*" it.xtl
xtool find "extracted\es\*" "game\*" es.xtl
xtool find "extracted\ru\*" "game\*" ru.xtl

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

Code:

xtool extract decode_data original_data extracted_streams
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

Code:

xtool extract en.xtl "game\*" "extracted\en\*"
xtool extract de.xtl "game\*" "extracted\de\*"
xtool extract it.xtl "game\*" "extracted\it\*"
xtool extract es.xtl "game\*" "extracted\es\*"
xtool extract ru.xtl "game\*" "extracted\ru\*"

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

Code:

xtool erase "extracted\*" "game\*" languages.xtl
which we can then restore after installation using

Code:

xtool decode languages.xtl "extracted\*" "game\*"
Patch

Code:

xtool patch [parameters] old_data new_data patch_data
xtool decode patch_data old_data

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

Code:

xtool patch "Sims4\*" "Sims4_updated\*" sims4_wedding_stories.patch
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

Code:

xtool decode sims4_wedding_stories.patch "Sims4\*"
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. :)

Razor12911 18-05-2022 04:19

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

Code:

xtool archive files1 files2... archive
There is nothing to add here as I have personal uses for this but the example would be

Code:

xtool archive game\* mygame.xtl
xtool decode mygame.xtl extracted\*

Execute

Code:

xtool execute [parameters] input output [exec_syntax]
Too lazy to write description but, here's an example

Code:

xtool.exe execute -c64mb -t8 UI.sb UI.bin bcm.exe -b64 [filein] [fileout]
xtool.exe decode -t100p UI.bin UI_dec.sb bcm.exe -d [filein] [fileout]

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

Code:

[External compressor:xbcm]
header    = 0
packcmd  = xtool.exe execute { -option} - - <stdin> <stdout> bcm.exe -b64 [filein] [fileout]
unpackcmd = xtool.exe decode -t100p - - <stdin> <stdout> bcm.exe -d [filein] [fileout]

and the method would be -mxbcm:c64mb:t75p

Razor12911 22-05-2022 13:56

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:
Code:

Compressed 1 file, 7,232,549 => 8,291,632 bytes. Ratio 114.64% -mreflate
Compressed 1 file, 7,232,549 => 7,232,655 bytes. Ratio 100.00% -mpreflate

with png preprocessor:
Code:

Compressed 1 file, 7,232,549 => 26,075,119 bytes. Ratio 360.52% -mpng+reflate -d1
Compressed 1 file, 7,232,549 => 25,289,529 bytes. Ratio 349.66% -mpng+preflate -d1


Cesar82 22-05-2022 18:44

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

xtool:mpreflate:mpng:d1

Razor12911 22-05-2022 20:09

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

Cesar82 22-05-2022 21:16

Quote:

Originally Posted by Razor12911 (Post 496943)
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.

yasitha 23-05-2022 09:30

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.

KaktoR 23-05-2022 09:55

msc :confused:

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

yasitha 23-05-2022 10:01

Quote:

Originally Posted by KaktoR (Post 496949)
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. :)

kj911 24-05-2022 04:45

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

shazzla 24-05-2022 04:51

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

KaktoR 24-05-2022 08:06

Posting it here aswell

Code:

xtool:png+xtool:preflate+srep+lzma2
Compressed 8,178 files, 2,202,105,870 => 1,112,132,188 bytes. Ratio 50.50%
Compression time: cpu 17.70 sec/real 1593.72 sec = 1%. Speed 1.38 mB/s
All OK

precomp_mtx+srep+lzma2
Compressed 8,178 files, 2,202,105,870 => 1,120,270,164 bytes. Ratio 50.87%
Compression time: cpu 16.72 sec/real 2599.17 sec = 1%. Speed 0.85 mB/s
All OK


yasitha 25-05-2022 11:40

Quote:

Originally Posted by kj911 (Post 496958)
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

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

thank you!! :)

yasitha 25-05-2022 11:44

Quote:

Originally Posted by shazzla (Post 496959)
Afaik freearc's tta works on per file basis,while msc works on stream(/file)?!

thank you :)

yasitha 25-05-2022 11:45

Quote:

Originally Posted by KaktoR (Post 496962)
Posting it here aswell

Code:

xtool:png+xtool:preflate+srep+lzma2
Compressed 8,178 files, 2,202,105,870 => 1,112,132,188 bytes. Ratio 50.50%
Compression time: cpu 17.70 sec/real 1593.72 sec = 1%. Speed 1.38 mB/s
All OK

precomp_mtx+srep+lzma2
Compressed 8,178 files, 2,202,105,870 => 1,120,270,164 bytes. Ratio 50.87%
Compression time: cpu 16.72 sec/real 2599.17 sec = 1%. Speed 0.85 mB/s
All OK



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

Masquerade 25-05-2022 11:50

Quote:

Originally Posted by yasitha (Post 496984)
:confused::confused::confused: what is this ? :eek:

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

elit 03-07-2022 14:55

2 Attachment(s)
During repacking of Final Fantasy XIII(PC version), I found that using
Code:

xtool:d1:c64m:mzlib:mreflate
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?

Code:

[External compressor:xtool]
header = 0
packcmd = _EC\xtool\xtool precomp -t50p {options} - - <stdin> <stdout>
unpackcmd = _EC\xtool\xtool decode -t50p          - - <stdin> <stdout>

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

Cesar82 03-07-2022 15:14

Quote:

Originally Posted by elit (Post 497431)
During repacking of Final Fantasy XIII(PC version), I found that using
Code:

xtool:d1:c64m:mzlib:mreflate
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?

Code:

[External compressor:xtool]
header = 0
packcmd = _EC\xtool\xtool precomp -t50p {options} - - <stdin> <stdout>
unpackcmd = _EC\xtool\xtool decode -t50p          - - <stdin> <stdout>


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

Code:

[External compressor:xtool]
header = 0
packcmd = _EC\xtool\xtool precomp -t50p { -option} --dbase - - <stdin> <stdout>
unpackcmd = _EC\xtool\xtool decode -t50p - - <stdin> <stdout>


elit 03-07-2022 15:44

Quote:

Originally Posted by Cesar82 (Post 497432)
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:
Code:

xtool:d1:c64mb:mzlib:mreflate+srep64:m3f:mem8g:a0+4x4:lzma:64mb:normal:32:lc8
, which is same regardless if I use {options} or { -option}

EDIT: Found the problem, see 2 posts above.

elit 03-07-2022 15:58

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.

elit 03-07-2022 16:40

2 Attachment(s)
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

elit 04-07-2022 05:20

1 Attachment(s)
And preflate is worse than zlib hmmm..:

Attachment 32017

Razor12911 07-07-2022 01:53

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.

dixen 07-07-2022 02:52

Find little uncritical bug

Quote:

Compressing 77,790,338 bytes with xtool.exe precomp -mFLAC -c32mb -t100p $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
XTool is created by Razor12911

Streams: 1/1
Time: 00:00:02 (00:00:02)
Memory: 276 MB (276 MB)

100%
Errorlevel=0
Compressed 1 file, 77,790,338 => 53,378,764 bytes. Ratio 68.62%
Compression time: cpu 0.08 sec/real 2.78 sec = 3%. Speed 28.01 mB/s
All OK

Quote:

Compressing 77,790,338 bytes with xtool.exe precomp -mFLAC --verbose -c32mb -t100p $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
XTool is created by Razor12911

[0] Performing scan from block 0000000000000000 to 0000000001FFFFFF (33554432)
EAccessViolation: Access violation at address 0000000000409A77 in module 'xtool.exe'. Read of address 00007FF4FE6BFBA4

Errorlevel=1

ERROR: general (de)compression error in xtool
Anyway, thank Razor for update and new functions)

One question. Why TTA but not TAK?

Quote:

Original.wav 74.1 mb
ENCTTA.tta 50.3 mb
ENCTAK.tak 48.7 mb

Masquerade 07-07-2022 03:40

Quote:

Originally Posted by dixen (Post 497488)
One question. Why TTA but not TAK?

TAK isn't Open Source.

elit 07-07-2022 03:55

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?

Prince4 07-07-2022 04:01

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

Razor12911 07-07-2022 05:27

Quote:

Originally Posted by dixen (Post 497488)
Find little uncritical bug

your chunk size is too small for that input
Quote:

Originally Posted by Prince4 (Post 497491)
Could someone please remind me what's the difference between the 0.3.21 and 0.6.0 versions?

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.

Quote:

Originally Posted by elit (Post 497490)
Interesting, I should note that compression difference between different wav codecs is minimal.

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

Quote:

Originally Posted by elit (Post 497490)
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?

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

elit 07-07-2022 09:43

Quote:

Originally Posted by Razor12911 (Post 497494)
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 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

Razor12911 12-07-2022 11:43

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
Code:

xtool.exe precomp -mzlib -c32mb -t100p --dbase --dedup --compress=l10,t100p - -

CR2032 13-07-2022 06:30

Quote:

Originally Posted by Razor12911 (Post 497597)
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
Code:

xtool.exe precomp -mzlib -c32mb -t100p --dbase --dedup --compress=l10,t100p - -

Thank You So Much For Your Hard Work, Razor12911!


All times are GMT -7. The time now is 21:12.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Copyright 2000-2020, FileForums @ https://fileforums.com