The VG Resource
Research: 3DS BSCAR Format - Printable Version

+- The VG Resource (https://www.vg-resource.com)
+-- Forum: The Resources (https://www.vg-resource.com/forum-109.html)
+--- Forum: General Ripping (https://www.vg-resource.com/forum-145.html)
+--- Thread: Research: 3DS BSCAR Format (/thread-31401.html)

Research: 3DS BSCAR Format - Pingus! - 07-24-2017

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
STRG:

[+]Spoiler
INFO:
[+]Spoiler
- 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!


.zip   BCSAR's.zip (Size: 670.43 KB / Downloads: 249)
Clarified INFO partition format in regards to header length:

MWORD long
Size long
constant long
header size long
constant long

RE: Research: 3DS BSCAR Format - Pingus! - 07-25-2017

Recently uncovered the location of the BCWAV's offsets and sizes within the archive. This is more information that would be useful for later on. The huge missing link is the ability to link the actual names to the data (which is the main issue everyone is facing). But, uncovering this info cancels out one possible place for this information to be hiding. The CWAR holds all the data relative to the Main File Partition (Kind of like it's dictionary). Here's it's structure:
Code:
CSAR "CWAR" Archive

offset      length              info
0x0           0x4           "CWAR" MWORD
0x4           0x2           Endianess Identifier (0xFFFE = Little, 0xFEFF = Big)
0x6           0x4           Header Size
0xA           0x2           Version ID
0xC           0x4            Archive Size
0x10         0x4            Partition Count (INFO + FILE)
0x14         0x4            Weird Constant
0x18         0x4            Info Partition Pointer**
0x1C         0x4            Info Partition Size
0x24         0x4            Main File Partition Pointer**
0x28         0x4            Main File Partition Size
0x2C         0xC            Reserved space for other partitions(?)

** These values pertain to the CWAR when it's separate outside of the main CSAR archive, to get these real values, add the current value to the CWAR's actual offset
in the CSAR archive!!!
----------------------------------------------------------------------
Info Paritition:
**Offsets pertain to that of the partition
offset     length          info
0x0          0x4         "INFO" MWORD
0x4          0x4          INFO Partition Size
0x8          0xC          File Count (of CWAR)

Splits off into a table, per each entry:
long - entry start
long - relative offset of the file in the CWAR
long - size of the file in the CWAR

--end table
Concatenated Files Follow


The way to find the actual offsets of the BCWAV's is easy. All of the relative offsets given are padded by a certain number (we'll call it x).
We first need to jump to the main file partition location, read the h8 bytes. After that, theres a DString of h18 following that which leads us to the first bcwav. We can save that position and then subtract that from the given offset to find the relative difference. So:

1. Find relative difference:
First actual offset - (given offset + Actual Offset of the beginning of the CWAR) = x!

2. Calculate the actual file offsets:
add the relative offset (given in the table ) + x = y
Seek from the beginning of the CWAR y Bytes. To get to the new position.

I'm uncertain if the structure of the CWAR is old news or not, but if it isn't, tahdah! Now that the analysis of that is done, I plan on looking into the "CWSD" portion of the archive, in order to clarify that the linkage isn't hidden in there. Until then!
~Pingu!