Level5 Sample Thread

[AnonBaiter]

I'm quite surprised no one has wrote a quickBMS script for this game yet, as it was the first game Level5 developed, back at a time when they decided to start off their career.

Anyways, here are the samples(filecutter'd for one big file as always) in case someone want to work with these archive files:
https://mega.nz/#!NNdF2ZTb!zlI4meUrvAdnU7-x-gWw1Vt1Ej2CsJsafoDXdys4oXA

Thanks.

[aluigi]

http://aluigi.org/bms/dark_cloud.bms

[AnonBaiter]

Huh. I tested that script on said file and it gave me this error:


Any idea what's causing it?

[aluigi]

I forgot to specify the file number "1" in the log. Fixed

[AnonBaiter]

I forgot to specify the file number "1" in the log. Fixed

It actually worked this time. Thanks!

[AnonBaiter]

Looks like I found another game that uses these similar archive files. And yes, it's a Level5 game.

https://mega.nz/#!1F9xABoL!SfiIY4FULiKODTr6KcdBgiRuCM3hNV_lrMR4ScKTgTc
https://mega.nz/#!1dEySJ4S!2gfw-jCu7DOyIeeWwSXLoRu2l9YDyRTmmGoVL-zo4cc

EDIT: I was actually surprised that DATA.DAT/HD2/HD3 files worked with the script. However, with the SOUND.DAT/HD3 files...


Is there any way to make a new version of the script to fix the problem?

EDIT2: I found yet another game - the last PS2 game Level5 worked on - that uses a similar structure as Dark Cloud 2. Here are the samples:
https://mega.nz/#!gYFkWThL!fHeU821O25RweOe0uRMifYRpFYuC9lBMNDfyV-P3kYY

That's enough from me. I initially wanted to post samples of one Level5 game but as I was being interested in the company that made such games I couldn't help it. You might as well name your script as "level5" if you plan on working with these files.

[aluigi]

Script updated to version 0.1.2 but no names for HD6 (unknown mechanism to build them)

[AnonBaiter]

no names for HD6 (unknown mechanism to build them)

It's probably because the filenames for HD6 are scattered around somewhere in the DAT file - that includes the files I extracted from said DAT/HD6 archive.
As well there are some instances where an extracted file ends with what is the middle of another file. At least in regards with your script, that is.

[aluigi]

Right, HD3 didn't consider the padding at 0x800. Fixed in 0.1.3.

Regarding HD6 the filenames are built from the chunks of strings at offset 0x34 of the HD6 file but the method to build them is unknown.
There are no names in the DAT archive because it's just a raw container, probably you refer to some types of files like the mot ones but that's part of their format and not of the archive.

[AnonBaiter]

I see what you mean by that.

Also, DATA0_1.DAT/HD6 contains WAV files. Is there any way to decode those since they're not the normal kind of WAV?
https://mega.nz/#!8AcQXDhC!PvvRSyjjyCqWnetL4ddiu09WT9BKzUJNXlrRleLBvCM

But anyways, back to their games - I have another sample to show you:
https://mega.nz/#!oJ0QkYKQ!KNH5QEEQe6bo033_V0S6HHMI7rBxkkZQq6y3ioV8O_8

It's from a PS3 game they worked on. Judging by the start of their header(the .sdat files either start with NPD, or in the case of .adat files, PSAR), they seem to be compressed by the zlib algorithm. The files themselves end with the SDATA 3.3.0.W string, which indicates it might be a version of some compression method tool(as with the .adat files, I don't know).

[aluigi]

The index files appear to be encrypted.

[AnonBaiter]

Seems like somebody wrote a script for Ni No Kuni PS3 version(it's on second post):
http://forum.xentax.com/viewtopic.php?f=18&t=11104

The author of the script has yet to identify himself/herself. Meanwhile, see if you can find something to decrypt it.

[aluigi]

PSAR was used by the game Brink.
I have a script here http://aluigi.org/bms/brink.bms
which is a bms conversion of these tools:
http://svn.gib.me/public/brink/
https://github.com/komiga/brinktools

[AnonBaiter]

I tested the brink.bms script with these .adat archives, but they were extracted without the filenames. Also, some of the extracted files appear to be corrupt if you check them.
The first file that was extracted from both archives actually has all the filenames stored though, complete with folders and all. They might be useful so I'll just leave it here.

Also, there are a lot of .zarc files throughout these two archives. I'll post a sample as soon as I'm done with searching.

[AnonBaiter]

1-week bump.

[aluigi]

I tested the cutted-files you provided and the script seems to work, but obviously it's limited to 2Mb of data.
Can you upload one of these whole archives that gives you corrupted files?
For the filenames I'm not sure if the PSAR format puts the filenames in the first file or it's just this case, if it was common for the PSAR format then it would have been already implemented in the script.

[AnonBaiter]

I tested the cutted-files you provided and the script seems to work, but obviously it's limited to 2Mb of data.
Can you upload one of these whole archives that gives you corrupted files?
For the filenames I'm not sure if the PSAR format puts the filenames in the first file or it's just this case, if it was common for the PSAR format then it would have been already implemented in the script.

I'll see what I can do.

EDIT: Here it is:
https://mega.nz/#F!MIcEULQT!ayBq5NaqmtSWj5tRKUt9Fw

[aluigi]

Script 0.3

[AnonBaiter]

Well, I just updated your brink.bms script and the extracted files don't look so corrupted anymore. On top of that, it actually decompressed/dumped .zarc files.

Thanks man, you script really is something!

[AnonBaiter]

Due to an abundance of samples I've posted from Level5 games, this thread is now renamed Level5 Sample Thread.

Anyways, regarding Rogue Galaxy:
I discovered that inside the .HD6 files, the file containers are already set up for all the filenames in the corresponding .DAT archive. Considering that the filename directories themselves start at the 0x35 offset, it's no surprise that they're this messy due to an unorthodox method used to build the filenames. Therefore the filenames for each of their corresponding archives end at the 0x70DA offset in the DATA0_0.HD6 file, and at the 0x10F8 offset in the DATA0_1.HD6 file.

The filenames themselves are also scattered around the DATA0_0.DAT file as you can see by your hex editor. But alas...

The "\" symbols before the filenames represent the folders in which the files are stored in a specific folder. As for the "_"/"-" symbols before the filenames, they can represent the files themselves - it's also true for those without the "_"/"-" symbols, although they are actually keywords related to something else, preferrably a folder. The "." symbols before them actually represent the file containers, therefore they're file containers.

Well, I hope I made sense by clearing this up so... tell me what you think about this.

EDIT: Wait a minute, looks like the .HD6 file is obfuscated after all.