AnonBaiter's Script Compendium

[AnonBaiter]

Kowloon's Gate - *.TBL/*.PAK

Most - if not all - *.PAK files are stored using CD disk sectors*, and unless you somehow extracted them without these sectors, you're lucky to have one that wasn't stored with these sectors.
The script "decompresses" these sectors onto the MEMORY_FILE on the fly, so not to worry.

* The entire CD sector is 0x18 + 0x918 in size(including garbage data depending on the type of the file the CD sector is detecting on).

[AnonBaiter]

Kidou Senshi Gundam - Inchinen Sensou (PS2)

This only supports ALL.HD/ALL.BD for now. Well, actual support since 5 duplicated files of this .BD file exist as DAT##(from 00 to 05).DAT files.

UPDATE(10/04/2018): This script can now support UNITARY.DAT, which luckily uses two different file formats on every single file as stored in that one. Anyway, assuming you extracted all these UNITARY.DAT files into an entire folder of its own... If you know how to cmd, you can batch-rename all the *.fla into *.psg directly into the cmd so long as said cmd is executed within that extracted folder. That's about it.

[AnonBaiter]

007 Quantum of Solace(PS3, Xbox 360) - .ff

I wrote this script a few months back, but then some decompression problem unrelated to the script itself showed up. The script couldn't decompress some .ff files properly back then(even with unzip_dynamic).

Now, said decompression problem has been fixed in 0.8.1, which means the script can now decompress .ff files without much trouble.

[AnonBaiter]

KAZe/digifloyd - SLPS_###.##(related to [V3/KU/AGT]FILE.BIN/RUDATA.BIN)

As it is right now, this is just a dumper for any of these archives. Also you need to execute the script through the executable, not through the .BIN archive. Check the commented parts of the script if you're unsure over whether or not you're going to apply this script on which game.

[AnonBaiter]

Boku no Natsuyasumi (PS1) - SCPS_100.88/BOKU.BIN

For now this script is only limited to the BOKU.BIN archive itself.

[AnonBaiter]

Driving Emotion Type-S (PS2) - LINKFILE.INF/BIN

Well, about the whole "missing file" thing... it's because the archive files that were used in the game would list files whose size field could go about this value right here: 0x10000000. Basically, for these absent files the size field could range from 0x14000002 to 0x1bf80005(it could vary depending on the region this game was released on).
Because of this, I had to add something in which the script informs you about this absent file as well as the supposed offset of that one file.

You don't have to worry about that though. The script extracts what's already available of LINKFILE.INF/BIN anyway.

UPDATE(24/10/2018): the whole script has been re-written for the sake of a cleaner code

[zhichuner]

there is an sxd1outputed at9 file from soul sacrifice cannot be decoded to wav,at9decoder.exe printed wrong atrac9 bitrate

[AnonBaiter]

Okay, the script for that format has been revised now. You can now use the new udpated version of it.

[AnonBaiter]

SquareSoft/Square Enix - .dat(/.sz) movie format

Much like my lifeline_is.bms script, this is just a proof-of-concept for "demuxing" movie data and actually extracting them as-is. Well, apart from trying to convert any kind of "audio" into GENH that is. This was originally posted on the hcs64.com message boards as its own thread, so if you want the script... well, there it is.

To be honest, I did try my best to document all there is to the script for those planning to use it in this kind of movie format but I'll try to be as brief as I possibly can here. For those who have the Japanese version of Driving Emotion Type-S, you can see through the game files that the game uses two types of what I call "movie format": one is a paired .sz/.dat file that can store whatever chunk there is regarding both audio and video(or whatever that is), the rest(as in, the .dat files that doesn't have an accompanying .sz file at all) are just video data as far as I know. However, even a single .dat file can have its own type too as seen on Front Mission 5 in which both the video and the audio data(which in this case is a vgmstream-supported .vsf format) are stored as chunks on a single file.

That's it for now.

[zhichuner]

Thanks for hard work! !

[Graveyard]

could you create a script to extract this files?

In fact, I want to translate the first Xbox 360 Bioshock.

https://www.mediafire.com/file/tsyjr2by ... zedesp.rar

[AnonBaiter]

TVDJ (PS2) - *.FLK

I decided to do this out of curiosity.

UPDATE(03/01/2018): The whole script has been "fleshed out", as far as minor changes go. Basically there's that one 16-bit value that represents the actual file type, therefore the whole "extension guessing" thing was based mostly on this "value".

[AnonBaiter]

Okay zhichuner, you might want to use vgmstream instead. However, use only the latest version as ATRAC9 is basically supported in there now.

I marked my sxd_at9.bms script as obsolete since there's no point in using it.

[AnonBaiter]

Ubisoft Montreal - *.fat/*.000 archives

Apparently, the files themselves as stored in a .000 archive pair(as referenced in an accompanying .fat file) used an interesting method. Basically, you have about four "values" stored in varying bits. The first and the second one has both decompressed and the compressed size of a "chunked" part of a file that we need to decompress a part of the file(all in 32-bits). Then you have the third value that is written as 0xDEADBABE/0xBEBAADDE, and finally the fourth value that sticks out as two numbers, one of which is stored as 3 exclusively for the first chunk of an entire file, as for the rest it's just 1.

This script tries to decompress them all even if the files themselves are relatively uncompressed. Most of the "decompression" depends on if the first value of a chunk is 0x2000(as in, the decompressed size of a chunk in itself), otherwise the script is just done with the file and proceeds to another one.

[TON]

Hi AnonBaiter!

Maybe you can help us.
viewtopic.php?f=9&t=7217

Thanks in advance.

[AnonBaiter]

i have a few issues with your "proposal":
what "us" are you talking about? because from what i read in that thread you just linked from here, it seems that only you are actually interested at translating the game at all for whatever reason.

i also doubt you have some kind of experience in messing with this stuff, as most of the "help" threads i've ever seen in here are actually nothing but "handle this file for me plz" request threads(yeah i know, kind of an ironic statement as i started out requesting .bms scripts out of files i had no idea what to do with since i had no experience with getting the "most" out of data and stuff).

as for the files themselves, they're just raw data. something tells me the executable has at least every info related to these .BIN files in any way, but right now all these "headerless" archive files tell me absolutely nothing about how to actually handle them in any possible way beyond that.

so, as i'm not very interested in the game right now, i have to tone down your offer.

[TON]

i have a few issues with your "proposal":
what "us" are you talking about? because from what i read in that thread you just linked from here, it seems that only you are actually interested at translating the game at all for whatever reason.

i also doubt you have some kind of experience in messing with this stuff, as most of the "help" threads i've ever seen in here are actually nothing but "handle this file for me plz" request threads(yeah i know, kind of an ironic statement as i started out requesting .bms scripts out of files i had no idea what to do with since i had no experience with getting the "most" out of data and stuff).

as for the files themselves, they're just raw data. something tells me the executable has at least every info related to these .BIN files in any way, but right now all these "headerless" archive files tell me absolutely nothing about how to actually handle them in any possible way beyond that.

so, as i'm not very interested in the game right now, i have to tone down your offer.

No offense dude, I just tried to help the translator (who gave up the project because lacking of help) to find someone who could help in hacking because the text translation is done.
And jeah you are right, I know nothing about PS1 game file structure and hacking but think it over who's asking help? Those people who need help and dont know anything about hacking PS1 isos.

[AnonBaiter]

well, to be completely honest i'm not really experienced in "translating" games in general, so you might be asking the wrong person here (for now).

sorry about that.

[AnonBaiter]

SquareSoft's unusual CD format - Xenogears, Dewprism/Threads of Fate, Chrono Cross

So, I spent two days trying to figure out this strange CD format that two development teams at SquareSoft came up with during the PS1 era(see the script header for more details). Basically what goes right after the ISO9660 "TOC" part(yes, this is that one TOC you actually see on some ISO programs if you open any of these games with these programs) is the game's own "TOC". The structure between these aforementioned games were so different I had to come up with different methods of handling the whole disc out of one of those games until I could find one method that actually worked.

Just to give you an example, there's a method of guessing which "TOC type" does this disc of the game belong to(or rather the game itself). Right now there's only two "TOC types", the former which is for Xenogears, and the latter which is for Dewprism/Threads of Fate and Chrono Cross. The script actually ends there if it detects neither type.

Anyway, after the script has done "detecting" one of those "TOC types", it goes through what I refer to as the "extraction phase". Said "phase" consists of doing sanity checks to make sure only the "STR-ish" files get extracted as "raw files" while the rest of the files gets to be extracted through way of decompressing every CD sector within it.

After all this, the files are actually on the process of being extracted. How long does it take though, that depends solely on if the disk is close to weighing at least 700MB+, and how "strong" your PC is when it comes to the entire extraction process. That's about it I guess.

As of now, I only tested this script on Redump's PS1 releases, offered through the .cue/.bin format. This script will throw off an error when you execute this one on any other format than that. Hit me up if that does happen on your end.

[zhichuner]

AnonBaiter，vgm supprted sxd atrac9 now，thanks