Difference between revisions of "BCSAR"
(Specified which vgmtoolbox tool to use to extract BCWAVs) |
(→STRG) |
||
Line 86: | Line 86: | ||
STRG contains the names of the audio files in the BCSAR. | STRG contains the names of the audio files in the BCSAR. | ||
− | Header | + | ==== Header ==== |
{| class="wikitable" border="1" | {| class="wikitable" border="1" | ||
Line 101: | Line 101: | ||
| 0x4 | | 0x4 | ||
| Length of STRG partition (also in CSAR header) | | Length of STRG partition (also in CSAR header) | ||
+ | |- | ||
+ | | 0x8 | ||
+ | | 0x4 | ||
+ | | Version? (always 0x2400) | ||
+ | |- | ||
+ | | 0xC | ||
+ | | 0x4 | ||
+ | | Offset to root node (always 0x10) | ||
+ | |- | ||
+ | | 0x10 | ||
+ | | 0x4 | ||
+ | | Root node type (always 0x2401) | ||
+ | |- | ||
+ | | 0x14 | ||
+ | | 0x4 | ||
+ | | This + 8 points to some kind of descriptor table | ||
|- | |- | ||
| 0x18 | | 0x18 | ||
Line 108: | Line 124: | ||
|} | |} | ||
− | + | ==== Node struct ==== | |
{| class="wikitable" border="1" | {| class="wikitable" border="1" | ||
Line 118: | Line 134: | ||
| 0x0 | | 0x0 | ||
| 0x4 | | 0x4 | ||
− | | Type of the | + | | Type of the node? |
|- | |- | ||
| 0x4 | | 0x4 | ||
| 0x4 | | 0x4 | ||
− | | Offset | + | | Offset to node data? |
|- | |- | ||
| 0x8 | | 0x8 | ||
| 0x4 | | 0x4 | ||
− | | | + | | Length of some data based on node type |
|- | |- | ||
|} | |} | ||
+ | |||
+ | ==== Nodes ==== | ||
+ | |||
+ | ===== Root node (0x2401) ===== | ||
+ | * Offset + 8 points to some unknown data. | ||
+ | * Length specifies how many nodes after this node belong to this node. | ||
+ | |||
+ | ===== File node(?) (0x1F01) ===== | ||
+ | * Offset + 0x18 points to the file's name | ||
+ | * Length specifies the file name buffer size, including the NUL terminator. | ||
+ | |||
+ | |||
Then every filename is rawly setted. You can set up a dictionary that contains, using a simple counter, the size of every filename in order. Then, using the same type of counter, get the values of the size of the filename in a correct order. | Then every filename is rawly setted. You can set up a dictionary that contains, using a simple counter, the size of every filename in order. Then, using the same type of counter, get the values of the size of the filename in a correct order. | ||
+ | |||
=== INFO === | === INFO === | ||
Revision as of 02:25, 31 October 2018
Overview
The BCSAR (CTR Sound ARchive) format is the 3DS's equivalent of the Wii's BRSAR format. They're not the same structures, though, but they do have the same purpose.
BCSAR are located in the RomFS, this is usually stored under "romfs:/sound/<name>.bcsar". This contains various audio formats, such as CSTM, CWSD, and CWAV.
BCSAR Header
OFFSET | SIZE | DESCRIPTION |
---|---|---|
0x0 | 0x4 | MAGIC "CSAR" |
0x4 | 0x2 | Byte order mark (0xFEFF = Big Endian, 0xFFFE = Little Endian) |
0x6 | 0x2 | Length of BCSAR header |
0x8 | 0x4 | Version |
0xC | 0x4 | Length of the entire BCSAR (starting from 0x0) |
0x10 | 0x4 | Amount of main partitions in the BCSAR [STRG + INFO + FILE = 0x03 (= 3)] |
0x14 | 0x4 | Partition header length [same for each partition? (ie STRG,INFO,and FILE header lengths)] |
0x18 | 0x4 | Location of STRG partition |
0x1C | 0x4 | Length of STRG partition |
0x20 | 0x4 | Unknown (always 0x01200000?) |
0x24 | 0x4 | Location of INFO partition |
0x28 | 0x4 | Length of INFO partition |
0x30 | 0x4 | Location of main FILE partition |
0x34 | 0x4 | Length of main FILE partition |
0x38 | 0x4 | Reserved for 4th main partition location? |
0x3C | 0x4 | Reserved for 4th main partition length? |
Partitions
STRG
STRG contains the names of the audio files in the BCSAR.
Header
OFFSET | SIZE | DESCRIPTION |
---|---|---|
0x0 | 0x4 | MAGIC "STRG" |
0x4 | 0x4 | Length of STRG partition (also in CSAR header) |
0x8 | 0x4 | Version? (always 0x2400) |
0xC | 0x4 | Offset to root node (always 0x10) |
0x10 | 0x4 | Root node type (always 0x2401) |
0x14 | 0x4 | This + 8 points to some kind of descriptor table |
0x18 | 0x4 | Count of audio names (since each file should have a name you could also say this is essentially a file count) |
Node struct
OFFSET | SIZE | DESCRIPTION |
---|---|---|
0x0 | 0x4 | Type of the node? |
0x4 | 0x4 | Offset to node data? |
0x8 | 0x4 | Length of some data based on node type |
Nodes
Root node (0x2401)
- Offset + 8 points to some unknown data.
- Length specifies how many nodes after this node belong to this node.
File node(?) (0x1F01)
- Offset + 0x18 points to the file's name
- Length specifies the file name buffer size, including the NUL terminator.
Then every filename is rawly setted. You can set up a dictionary that contains, using a simple counter, the size of every filename in order. Then, using the same type of counter, get the values of the size of the filename in a correct order.
INFO
INFO presumably contains information on the audio files? Possibly used to connect names from STRG to data from FILE?
For now I only know some information in the header for this partition, but I'm working on figuring the rest out.
OFFSET | SIZE | DESCRIPTION |
---|---|---|
0x0 | 0x4 | MAGIC "INFO" |
0x4 | 0x4 | Length of INFO partition (also in CSAR header) |
FILE
FILE contains all of the audio data in the BCSAR.
OFFSET | SIZE | DESCRIPTION |
---|---|---|
0x0 | 0x4 | MAGIC "FILE" |
0x4 | 0x4 | Length of FILE partition (also in CSAR header) |
There isn't a whole lot else I can document about the FILE partition, since the data in it will most definitely vary depending on the game. (since audio is more than likely to change in each game)
There is no table in FILE so a different partition (presumably INFO) must be used to connect the data in FILE with the names from STRG.
After some more research, there are multiple FILE partitions, but only 1 of them is the 'main' FILE partition (it's the one you get from the BCSAR header). The 'main' FILE partition contains all of the other sub FILE partitions.
Tools
- vgmtoolbox's Advanced Cutter/Offset Finder tool can extract BCWAVs without filenames