FF7Tools lzss unclear syntax. (Posting in the right place this time.)

  • Thread starter Thread starter NERV Agent
  • Start date Start date
Status
Not open for further replies.
N

NERV Agent

Guest
I inadvertently posted this in the wrong forum. It would be a good idea if that thread was merged with this one.

As mentioned in that thread, the command line syntax for this program is unclear. I've tried using asterisks and plus signs, and get no desirable results.

I even tried doing "lzss [folder name]" and got this:

python lzss modifiedopeningcontents OPENING.BIN
Error opening file 'modifiedopeningcontents': Permission denied

Before someone tells me to "RTFM", I already did and it's still unclear. I scoured Google, and the only results I get are the message board posts I made on the subject! I even e-mailed cebix and and never heard back.

How do you use this program? It can't be an unsolved mystery.
 
Last edited:
OK i don't know much about the PSX version of the game (not as much as the PC version atleast) but i am assuming the OPENING.BIN is probably like "window.bin" on the PC version (window.bin is a file made up of multiple gziped files but looking at the unbinlz name i would guess that OPENING.BIN is made using LZSS instead of GZIP)
And "lzss" program doesn't support folders or multiple files so your way of trying to force it using + signs is wrong (some windows programs might be fine with that but this program isn't).
If you know C# you could try editing the source to FF7dec to do LZSS instead of GZIP (you can get it at Lasyan's site at http://lasyan3.free.fr/index.php?page=ff7-autres it comes with the source code.
Or you could just try compressing each file with LZSS and then reinserting them using a hex editor manually, or if it really is like "window.bin" you could just compress each file then use a filejoiner to put all the files into 1 then get the headers from the original file if needed.
I will go find my CD's tomorrow, i have the original PSX PAL CD's somewhere (i live in the UK so i only have access to the PAL version but the OPENING.BIN should be similar or the same)
 
Interesting.

So if I get this correctly, if I use lzss on each file, but then merge each file together via a hex editor or some utility it could work?

I am familiar with file splitters, but file mergers?
 
I dug my discs out today and started messing with "opening.bin", looking at it in unbinlz it says only files 0-7,17,18,21 are lzs compressed, all the rest are uncompressed files so compressing them all with lzss is probably a bad idea anyway (use unbinlz with the command "--list" to see what i mean).
Looking at the opening.bin it does appear to be files just piled on top of each other with a header, the question is if the header tells the game where to look for the files like a lba, if it does it won't be simple to change files unless you can get files to be the EXACT same size as the originals so that might be something to think about, i have tested a few edits i have made but so far i am not having much luck editing any of the files, every time i try and insert the edited opening.bin back into the game it crashes at the credits screen but i haven't given up yet.

EDIT:- Finally had some success
its just a quick edit to see if it worked (i only edited the background and producer name quickly with a editor just to see if it works so i apologize for the ugly editing)
 
Last edited:
Interesting!

So if I understood this correctly, you:

1.) Extracted the contents of "OPENING.BIN".
2.) Used lzss only on 0-7, 17, 18, and 21 since they are all lzs compressed (according to unbinlz).
3.) Copied and pasted all the files one after the other in a hex editor.
4.) ? ? ?
5.) Profit!

Is that how you did it? I want to verify this method this weekend.

Also, are there "file mergers" (as I mentioned earlier) to make this more convenient?

Thanks.
 
OK what i found is the start of the .bin is the ToC (Table of Contents) which tells the game where files in the .bin are, there are basically 2 methods to deal with this.

Method 1 (easy way) - Use a hex editor to manually overwrite the old files with the new ones but the new ones MUST BE SMALLER OR THE SAME SIZE then the old ones (if they are smaller i recommend padding the file to the same size as the original), they can NOT BE BIGGER THEN THE ORIGINAL files, this is the easiest way since you can leave the ToC as is and also makes it easier to reinsert into the game since the opening.bin will be the same size.

Method 2 (hard way) - Completely remake the .bin using what was said above (a file joiner or just pasting each file 1 after another into a hex editor) will get the file structure correct but you will need to manually remake the ToC of the .bin, this is where you might find it hard (i will post info on the ToC below). Although this method is harder it will allow you to have files bigger then the original.

And here is information on the opening.bin (taken from the PAL version of the game but from what i understand it is the same on the NTSC-U version, I'm unsure about the NTSC-J version)
OPENING.BIN is a archive of LZS and uncompressed files, when extracted from unbinlz files 0-7, 17, 18, and 21 are lzs compressed and the rest are uncompressed files
If you open OPENING.BIN in a hex editor the first 92 bytes or 0x5c of the file are the ToC of the BIN, to read the table of contents you read it 4 bytes at a time and in Reverse.
So for example if you look at the start of OPENING.BIN the first 4 bytes say 5C 00 00 00 what this means is the first file in the BIN is actually at 0000005C
To save time i already wrote down where each file started so this should make things faster (it lists which file is which in the ToC and where the file is in the OPENING.BIN)
Code: [Select]
Code: 
OPENING_005C0000000000005COPENING_01301D000000001D30OPENING_02683F000000003F68OPENING_032C6500000000652COPENING_04E0870000000087E0OPENING_05E8A600000000A6E8OPENING_06B8C800000000C8B8OPENING_07C4E400000000E4C4OPENING_0890FF00000000FF90OPENING_097400010000010074OPENING_105801010000010158OPENING_113C0201000001023COPENING_122003010000010320OPENING_130404010000010404OPENING_14E8040100000104E8OPENING_15B0050100000105B0OPENING_169406010000010694OPENING_17541B010000011B54OPENING_189CC501000001C59COPENING_1918FC01000001FC18OPENING_2038FC01000001FC38OPENING_2158FC01000001FC58OPENING_22E8460200000246E8
Anyway all this information should be more then enough to fully edit the OPENING.BIN, i hope this helps and please let me know how you get on (also the file joiner i used when testing was called "FFSJ" but it requires you to rename the files first, but i am sure there are lots of binary file joiners out there where you wouldn't need to rename files first)
 
Last edited:
So I've run into a problem.

The file I edited is "OPENING_17.data".

Uncompressed, both the original and modified files have matching size (61 KB).

I tried the method above. The original OPENING.BIN is 145 KB. The new one I made with FFSJ is 146 KB. Now the game won't load.

I don't know where that extra KB is coming from. What could be going wrong?

UPDATE:

Actually, both OPENING.BIN files are ~146 KB.

The original is 149,372 bytes.

The new one I generated is 149,165 bytes.

This makes no sense, because both the original and modified OPENING_17.data are 61,984 bytes.

How is it smaller all of a sudden?
 
Last edited:
Okay, now things are making even less sense.

So according to unbinlz:

>python unbinlz -l OPENING.BIN
0: 7373 bytes compressed
1: 8756 bytes compressed
2: 9662 bytes compressed
3: 8877 bytes compressed
4: 7939 bytes compressed
5: 8651 bytes compressed
6: 7176 bytes compressed
7: 6856 bytes compressed
8: 228 bytes
9: 228 bytes
10: 228 bytes
11: 228 bytes
12: 228 bytes
13: 228 bytes
14: 200 bytes
15: 228 bytes
16: 5312 bytes
17: 43585 bytes compressed
18: 13943 bytes compressed
19: 32 bytes
20: 32 bytes
21: 19083 bytes compressed
22: 148 bytes

But after using lzss to compress the appropriate files, the output is LARGER.

OPENING_00.data is now 7,375 bytes.

OPENING_01.data is now 8,761 bytes

OPENING_02.data is now 9,666 bytes.

What makes this even more confusing is that the new OPENING.BIN is smaller, even though the compressed files are BIGGER.
 
Oh man, now it gets even weirder.

Based on the TOC info that has been posted in this thread, I tried to calculate the size of the compressed OPENING_17.data and get inconsistent results.

OPENING_17.data starts @ 0x11B54 = 72532

OPENING_18.data starts @ 0x1C59C = 116124

116124 - 72532 = 43592 bytes

But unbinlz says the file is 43585 bytes.

My head hurts.
 
Last edited:
I padded my newly compressed OPENING_17.data to 43585 bytes with a hex editor.

With a hex editor, I manually replaced the 43585 byte block at 0x11B54 in OPENING.BIN with all the data from my modified OPENING_17.data.

The game loads, but my edits are nowhere to be seen.

Kranmer, how exactly did you pull this off? I've spent my entire Saturday afternoon trying to figure this thing out with no results.
 
I'm not sure why the filesizes differ from unbinlz's reported sizes, it could be that unbinlz lists the filesize where mine just lists where the next file begins ? (by this i mean maybe the files are needlessly padded and unbinlz lists the true filesize, or maybe its just wrong ?) but in my tests the values i listed above seemed to work so i wouldn't worry too much about the filesizes reported by unbinlz.
The game loads, but my edits are nowhere to be seen.

Kranmer, how exactly did you pull this off? I've spent my entire Saturday afternoon trying to figure this thing out with no results.
Click to expand...
Now this is odd, your game isn't showing any changes at all ? if you did it badly it would crash at the credits screen but if its showing no changes i can only think that its the program your using to replace the file or maybe the opening.bin you made is unchanged, what are you using to replace the opening.bin ? I used a tool called CDMage to replace my opening.bin with my changed one (i tried a few programs but that worked best for me)
also did you try extracting from your new opening.bin to see if it extracts your new TIM file instead of the original ? (this is incase you repacked the original TIM back in by accident)
 
I also use CDMage, with the "M2/2352 track" setting. I replaced OPENING.BIN in the MOVIE directory.

What is odd is that it doesn't show any changes at all.

I tried extracting the files from my new OPENING.BIN, and used Tim2View on OPENING_17.data, and it loads nothing.

The modified OPENING_17.data file from before compressing and recombining has my changed title screen when I view it in Tim2View. But after compressing, rejoining, and decompressing, OPENING_17.data doesn't show anything in Tim2View.
 
Oh i forgot to mention that unbinlz doesn't seem to like repacked LZS files so after it extracts the files again you need to unLZS the outputed parts you changed (so basically just decompress opening_17.data) and it should show back up in Tim2View, if you still having trouble send me the modified TIM via PM and i will see if i can insert it.
 
So I used unbinlz on my new OPENING.BIN. Then I renamed the (supposedly) compressed OPENING_17.data to unbinlzmeOPENING_17.data and used unbinlz on that.

Unfortunately, this is the result:

python unbinlz unbinlzmeOPENING_17.data
Traceback (most recent call last):
  File "unbinlz", line 68, in <module>
    archive = ff7.binlz.Archive(inputFile)
  File "C:\[my personal directory names]\ff7tools-1.3\f
f7tools-1.3\ff7\binlz.py", line 47, in __init__
    assert firstOffset % 4 == 0
AssertionError

I also noticed that OPENING_7472_0.data has suddenly gone missing after decompressing OPENING.BIN.

I would send you the modified file to reinsert it, but what I really want to do is learn how this is done. Can you PM me your e-mail address? I can send you the .png and .TIM files.

Thanks.
 
So I used unbinlz on my new OPENING.BIN. Then I renamed the (supposedly) compressed OPENING_17.data to unbinlzmeOPENING_17.data and used unbinlz on that.

Unfortunately, this is the result:

python unbinlz unbinlzmeOPENING_17.data
Traceback (most recent call last):
  File "unbinlz", line 68, in <module>
    archive = ff7.binlz.Archive(inputFile)
  File "C:\[my personal directory names]\ff7tools-1.3\f
f7tools-1.3\ff7\binlz.py", line 47, in __init__
    assert firstOffset % 4 == 0
AssertionError

I also noticed that OPENING_7472_0.data has suddenly gone missing after decompressing OPENING.BIN.

I would send you the modified file to reinsert it, but what I really want to do is learn how this is done. Can you PM me your e-mail address? I can send you the .png and .TIM files.

Thanks.
Click to expand...
Sorry i think i wasn't clear in my last post (my fault, i am bad at explaining things) after extracting the OPENING_17.data decompress it with unlzss and not unbinlz, unbinlz doesn't seem to like modified LZS archives so it only extracts them and doesn't decompress them.
And i fully understand what you mean about doing it yourself, if you send me the file i will try it and see if i can insert the same image, and if i am successful i will record the process and you can see how it was done. Also PMing you my e-mail now.
And OPENING_7472_0.data doesn't appear when i extract from opening.bin (the original), but does sometimes appear when i make a error so i think its a error file and not part of opening.bin.
 
Yeah, this is weird.

So I tried decompressing it with unlzss like you said. It decompressed it, but when I view it in tim2view, my changes are nowhere to be seen.

I'll send you the .TIM and .PNG now.

Thanks.
 
OK PMed you a video of me editing the file just so you can see how i did it exactly (and hopefully you will see what i did and if you did anything different). The PNG file was fine but the TIM file you sent i couldn't open at all, not sure what happened there.
 
Congratulations on getting it working, It often is something small you miss that messes up everything else but its good that you have it all working now.
I hope you don't mind me asking but what are you planning on editing it too ? (I'm just curious but if you don't want too or can't then just ignore the question)
 
Right now it is just for my own re-education, as I was learning how to perform PSX graphics hacking years ago, but stopped due to IRL.

I really don't know what this could snowball into.
 
Status
Not open for further replies.
Back
Top