Research: 3DS BSCAR Format

[Pingus!]

The BSCAR format has been partially documented, and extraction of BCWAV's has been easily achievable. Despite these successes however, name preservation is destroyed in the process. In attempt to recover this, I've been looking into analyzing the missing bits of the archive to figure out the missing portions. The base research I took from here, but there are some inaccuracies in the written information. I've discovered little things along the way about this format:

- It's separated into partitions (Generally MAIN HEADER, STRG, INFO, + MAIN FILE (Which has "sub-file" partitions, which probably contain all the files of each type of format. Such as one for bcwavs, and one for another format etc.)

Main Header:

Spoiler

0x0 - long "CSAR" (Magic Word)
0x4 - short Endian Identifier 0xFFFE = Little Endian 0xFEFF = Big Endian
0x6 - short CSAR Header Size
0x8 - long Version ID
0xC - long Archive Size
0x10 - long Partition Count
0x14 - long partition header length
0x18 - long STRG Partition Offset
0x1C - long STRG Partition Length
0x20 - long unknown constant (?)
0x24 - long INFO Partition Offset
0x28 - long INFO Partition Length
0x2C - long unknown constant (?)
0x30 - long Main FILE Partition Offset
0x34 - long Main FILE Partition Length
0x38 - longlong Reserved Space(?)

STRG:

Spoiler

0x40 - long "STRG" Partition String identifier
0x44 - long STRG Partition Size
0x48 - long unknown
0x4C - long unknown
0x50 - long unknown
0x54 - long unknown
0x58- long # Of Files Referenced (Applies to inside + outside of archive)

Table #1:
- Each entry is 0xC in length

Structured as follows:
- long: entry start identifier
- long: file name relative offset (add 0x58 to that value to get the absolute pointer! Uncertain if this is the actual constant value across all archives, but it seems to be for whatever reason)
- long: file name length

Table #2:
Raw file names (Length corresponds to values in table 1)

Table #3: Unidentified. No clue what it does yet. It looks like it's used to link something to another something.

INFO:

Spoiler

- long "INFO" identifier
- long INFO size
- long Constant
- long INFO Header Size
-long constant
-11 unknown longs
- long Constant(?)
- 2 unknown longs
-First table Start(?)


There may be more to this header, but I'm uncertain where the first table data starts.

There looks to be Three tables. I don't know where the first one ends and the second one starts, but it seems to be this:
- The first one may be pointers to the STRG entries. Some values land me on the entry start value, so I think that's what it is.
UPDATE: There seems to be a noticeable pattern within the first table I think. Looks like a constant 0x00002200 followed by a value and 0x000022000 repeated again. I don't know how many times this appears, but it could be for all the files referenced(?) or maybe just the files referenced externally?

- The second one points to the data that immediately follows the raw file names. No clue what that does yet.
- The third one (the most interesting to me) is a list of all externally referenced files. I don't know what the data values between the names mean yet, but will get there after I handle the first two tables.

- Have not started researching the Main FILE partition as of yet.

Future developments and discoveries into this format I will post about below. If anyone has any interesting information to contribute, all help is welcomed. I've attached a few sample ones that I've looked at. If anyone could find a big endian BCSAR, that would be even more useful!


  BCSAR's.zip (Size: 670.43 KB / Downloads: 202)

---

Clarified INFO partition format in regards to header length:

MWORD long
Size long
constant long
header size long
constant long