Chrono Cross .BIK files -- any experience with these?

[FaustWolf]

Okay, time for an update brought to you by Cygnus.

First, .TIM 288 and its clones appear in .BIK #1 within the following offsets:

0002F0FD ~ 0003331D
000C6D69 ~ 000CAF80
002B6341 ~ 002BA560


.TIM 288 appears in the .iso a total of 9 times:

00B57000 ~ 00B5B220
013488E8 ~ 0134CB08
026B728C ~ 026BB4AC
027260EC ~ 0272A30C
0902C2DC ~ 090304FC
0A374CE0 ~ 0A378F00
0AB228E8 ~ 0AB26B08
0ABBA554 ~ 0ABBE774
0ADA9B2C ~ 0ADADD4C

Whew! And that's just one of these suckers. Typing all that out brings back fond memories of the Ultimate Sephiroth Code. We're getting Sephiroth into Chrono Cross once we've figured out how to rip everything a few years from now...right?

Oh, but I haven't uploaded all the .TIMs yet, have I? That will happen tomorrow morning.

I'm starting to think the best way of mapping out .TIM file locations in the iso will be to get a huge Microsoft Excel file going. People can post their findings on the board and I can add them to an Excel file that could be hosted at the Compendium, perhaps?

Next up, besides the .TIMs upload, is to find out where the .BIK files are in the .iso. I can already see a .BIK header -- it literally reads "BIK" toward the beginning.

[FaustWolf]

Hey, Zeality - I've been reading a bit of Terminus Traduction's User Guide, and Nemesis writes on page 2 (pg 4 on the Adobe navigator) that their team has been able to access a table contents at the beginning of the Chrono Cross ISO!? Am I reading that right? If so, that might cut out a lot of the "mapping" work and we could get right down to extracting archives and finding ways to open them. But my understanding of the user guide is hazy at the moment; I will take a more thorough look at it later.

Do you know if Terminus Traductions was working with the American version? I wonder if the files on other versions of Chrono Cross could be easier to get at...

EDIT: Daaamn, I've come up with an even easier way to map where the .TIM files are! Involves only the .iso, TIMViewer, and the Hexit Hex calculator! It'll be much more accurate than what I've been doing, too; less worries about quality control now. Should have thought of it earlier, silly me. Mwahahahaha~! I'm going to do an illustrated tutorial and post it in a separate Kajar Labs thread (if that's okay), and hopefully we can get it stickied. I'll get that done during the week, and then we can start on some serious datamapping.

I promised I'd upload the .TIMs, and here they are without duplicates if anyone wants to experiment with anything involving .TIMs and doesn't have them already:
http://rapidshare.com/files/62505597/TIMs.rar.html

Also, I haven't gotten around to determining exactly where the .BIKs are in the .iso. I'll get that done later today.

We are on the verge of some serious stuff here, folks! I haven't felt this alive in ages!

[FaustWolf]

Ooh, just thought of something ominous. How different are the Chrono Cross versions released in various countries? Like, will the European versions have data stored at totally different locations than the American version? I own the Ohio version of Cross myself.

[dankun]

There is no European version of Chrono Cross that was ever released. And there'll probably never be.
Same thing with Chrono Trigger. There are only the NA versions and the Japanese ones.
And probably our versions are a little better than theirs, if I may say so.

[FaustWolf]

Thanks for that, dankun. That gives me some ease of mind, actually -- though I'm sorry for European folks. Silly Squeenix.

[ZeaLitY]

I'll see if Chrono'99 can e-mail Terminus again. They gave us the ripped script in '05 before releasing their tools.

[FaustWolf]

CONFIRMED -- the .BIKs are indeed in the ROM in their extracted state, i.e., FileStripper didn't take data and slap a .BIK format onto it all by itself, which was a concern I had. EDIT: Or at least FileStripper didn't change the data any. Is it possible FileStripper could have added a .BIK attachment to ripped data without changing its hex code in any way?

The first .BIK appears between offsets 0AAF37EB ~ 12B040B5 in the iso file. I'll get a "macro" map of the iso going as well as the other .BIK offsets when I get a chance.

Also, the .BIK topic has attracted some interest at the xentax forums. I'm currently having a forum discourse with Savage, who I believe speaks English as a second language. He might be telling me that the files aren't .BIKs after all, but in light of the above I tend to disagree. Though I'm not exactly sure what he's saying -- could someone take a peek at the topic and give me a second opinion on what he's saying? IF you can view the forums without having to register, of course. If not, I'll do the best I can over there.

http://forum.xentax.com/viewtopic.php?t=2815

[ZeaLitY]

Your reply should suffice to get clarification. Chrono'99 will e-mail Terminus tomorrow once I fix something in the Cross script.

[Luminaire85]

I'd say Savage is arguing that since he can compress the file you sent him considerably using RAR, he suspects the original data is not compressed and therefore not of the Bink format. He thinks that Filestripper saw the hex code for BIK and, since Filestripper is looking for Bink data, immediately started writing a .bik file. Since (1) it makes no sense for images/model data/etc. to be compressed with Bink and (2) you've found uncompressed TIM data and possibly uncompressed TMD data within the iso/bik, I'd say he brings up a good point.

Bah, now that I think about it it makes perfect sense.

[FaustWolf]

That clarifies things for me, Luminaire. If FileStripper did chuck data into .BIK files by itself, it didn't change any of the file data as far as I can see in hexadecimal though. To complicate things further, I'd like to point out as well that the .BIK files don't seem to have a consistent header -- the ascii reads "BIK" and a bunch of random gobbledegook after that.

Though on the other hand, there's lots of instances where "BIK" appeared in ascii within the iso and FileStripper *didn't* shove the following data into a fresh .BIK file.

I'll show you the beginning and ending .BIK hex and see if you can make more sense of what's going on than I can:

BIK1:

BIK2:

BIK3:


FileStripper is literally trained to look out for .BIK files -- well, Bink & Smacker files, which I assume includes .BIKs. This could be taken either way though -- maybe FileStripper got "trigger happy" when it saw the BIK code and said, "This is a .BIK!" when it really wasn't. Ah, so confusing.

Should we forget about the whole .BIK matter and focus on finding .TMD and other data such as pre-rendered backgrounds in the iso, you think? It seems things are progressing beyond the need to open the .BIKs anyway since the data inside is uncompressed -- I hope it stays that way. We'll have to see if we can extract another .TMD or other file from somewhere else in the iso to be sure.

Thanks again for your wisdom, Luminaire!

Oh, Zeality -- maybe Terminus Traductions would know the offsets of the game text and "accent" files within the iso? If so, that would be good to know in case the Compendium really needs to map out the entire iso to get at the good stuff. Did they use the American version of Chrono Cross for translation? Not that I know whether it would make any difference.

And another question for ya -- I imagine people have done PSF and perhaps FMV movie rips (.str?) from Chrono Cross. Do you know of anyone who might know where that data is located? If not, I'd still be ecstatic if I could get my hands on whatever file type the movies and music were in their "natural" state, since we could easily locate its position from the hex signature. If we could get that stuff mapped out it would eliminate quite a large chunk of the iso that we have to worry about.

[jono]

Yeah it's a bit unfortunate but it's more likley that they are a wrapper file that square has used to bunch files (doesn't look compressed though) together. A 'false positive' is the probable explanantion, just bad luck the the data in the headers looks the same.

EDIT: Still it's likely that these files contain most of the resources we are looking for. I'll start having a look at them at some stage this week (about to start exams at uni), it's tough when we don't know what were looking for but I guess it'll have to start some where. Who knows, we could get exceptionally lucky and stumble across other file types.

[FaustWolf]

Once I get the positions of the "supposed" .BIKs (no longer my "blessings," grr!) maybe we'll be able to sit down, take a general look at the iso structure with the .BIKs in place, and see whether or not it makes any sense for Square to have used .BIKs as a noncompressing container for the files.

[ZeaLitY]

PSMplay and PSXMC both can scan a raw ISO for streaming sounds and movies. PSMPlay is better (because PSXMC doesn't let you rip the native files; it only lets you convert), but PSMPlay is also hard as hell to figure out (at least it has been for me).

IIRC PSMPlay can scan for textures, too, but I'm pretty sure it's just TIMs all over again.

[FaustWolf]

Thanks for the tip, Zeality. I'll look up PSMPlay then and see how I fare.

The xentax folks have pretty much confirmed what Luminaire has suggested, i.e., that the .BIK files are false positives. Drat! The .BIKs I have are now only useful as snippets of the iso that can be more easily handled by hex editors than the entire iso. Useful in and of itself, but not the breakthrough I was hoping for after all.

Be sure to have Chrono '99 ask about the Table Of Contents Terminus Traductions found/created. That will be a major help, methinks.

[attachment deleted by admin]

[xkoks]

Hello. Do you still have old version of RAD video tools? Could you upload it for me? I'm searching the web for old versions and I can't find anything.