| arm7.bin
Common file in DS games. Runs then ARM7 binary which is more or less the same (you can swap them around between games of a similar vintage) and has no interesting code in for most purposes.
| arm9.bin
The main workhorse of the DS commercial games (homebrew might vary). This is what the bulk the game's code will be in.
| banner.bin
| header.bin
| y7.bin
| y9.bin
Files to sort the banner and layout of various files.
+---data
| +---Art
| | \---IPL
| | iplDCUS_banner.nbfc
| | iplDCUS_banner.nbfp
| |
Those are likely graphics formats, though rarer ones than the usual set, and the banner part likely gives that away too.
| +---bink
| | Intro.bik
Rad/Bink is a well known video codec (
http://www.radgametools.com/binkgames.htm . In this case I imagine it is the intro video to the game. I would however also say check said intro and developer splash screens -- many times an external audio library will be credited.
http://www.radgametools.com/bnkdown.htm might even be able to get it playing back but I don't know if those include DS aspects these days (for a while it was mostly PC only, later some consoles).
| +---dwc
| | utility.bin
Files called utility.bin, especially in directories called dwc, tend to be download play components.
Is technically another DS ROM so whatever you used to pull the main ROM apart you get to use again. It might even contain its own SDAT file (sometimes things get quite simplified*), or indeed if the download play aspect has things you want (sometimes they do have unique data not available in normal play) then you get to look at this as well.
*said simplicity can also be other examples of file formats used in the main game, or simpler versions thereof which can be easier to get your teeth stuck into.
| \---gob
| mainDCUS.gfc
| mainDCUS.gob
|
\---overlay
overlay_0000.bin
overlay_0001.bin
overlay_0002.bin
overlay_0003.bin
overlay_0004.bin
overlay_0005.bin
overlay_0006.bin
overlay_0007.bin
overlay_0008.bin
overlay_0009.bin
overlay_0010.bin
overlay_0011.bin
overlay_0012.bin
These are so called overlay files. They are inserted into a premade gap in DS memory (something like ndsts will tell you where
https://no-intro.org/tools.htm ) and replaced when no longer needed. A crude way of expanding your memory (if you have seen DLL files on your PC then that is the equivalent there) and are ostensibly for code but I have seen games use them for all sorts of data over the years (not to mention binaries themselves tend to have data in them). I would however be quite surprised to see audio dumped into these with only the 13 files -- normally when data starts being stuffed into overlays the counts shoot up from usually rather less than 50 into the hundreds or even broaching 1000.
That then leaves
+---data
| \---gob
| mainDCUS.gfc
| mainDCUS.gob
Never heard of the format before but if as above it is a known archive format made by/used predominantly by the devs from that company then it is in line with other things (for the bored my usual list of such things tends to be the first Tony Hawk game; Touch Detective, which is one of the rare ones to include music in the archive; and there was a Star Wars game I looked at once for someone).
I have often found you get two files in such scenarios. One large one, one small one (probably should have asked for sizes with the description there but oh well). The large one tends to house all the files while the small one (usually named very similarly, maybe without numbers on the end) houses the data about it - hopefully names, extensions and such but theoretically can be a list of file sizes/locations as names are irrelevant to the console itself if programmed even vaguely sensibly/with an eye towards that.
In which case you then get to start pulling apart that.
Again you might not need to know much about it if you are only ripping things
https://web.archive.org/web/2020102...ogle.com/site/kiwids/sdat.html?attredirects=0
That is an older but still valuable description of the SDAT format.
Short version open the larger of the two files (assuming one is in the megs while the other is not that) in a hex editor and search for SDAT in ascii/text search. SDAT files, which tend not to be compressed additionally (music is already inherently compressed and large file decompression is tricky as well), will start with that and include how long they are immediately after that. You can then take the start of SDAT, the length you read shortly after, either delete everything before and after (technically might not even have to do after) or copy-paste the SDAT into a new file and then go to town with vgmtrans, vgmtoolbox or whatever else it is the kids are using to rip things these days.
If it is not SDAT do check the link above about the various audio formats -- most of those have magic stamps/tells and few devs were inclined to reinvent the wheel for their DS games so you can do that but for those formats instead.
https://wiki.multimedia.cx/index.php?title=Category:Game_Formats http://wiki.xentax.com/index.php/Game_File_Format_Central
Might also be of interest.
For DS files then there are others of interest, and this might not include those graphics formats above but as a start most go with
http://www.romhacking.net/documents/469
If you do have to further continue pulling it apart then we get to discuss the usual pointers and theories of archive construction.
Names, file lengths (not necessary but sometimes included, especially if the archive is padded -- for various hardware related reasons it can be easier to have data land on certain locations within a file rather than a few bytes before or after so files will sacrifice said few bytes to have the next one start on a pleasing location), file locations (can be normal pointers, relative, offset or possibly sector but I doubt it, file lengths have also been seen as an alternative but is dubious as adding lots of things up for say the 30th file in an archive rather than simply reading off where you want to go via pointers), encoded data (32 bits of pointer is about 4 gigabytes or larger than any DS game, 31 bits is 2. whatever gigabytes which is still going to be way larger than anything needed and thus that top bit or possibly more can be used to indicate compression, subdirectories if you want to see the NARC/CARC format for an example or whatever else might be relevant), shifted pointers/locations (touch detective mentioned above was that actually, and finding the SDAT in the raw with it filling in the size part allowed me to figure that out. NSMBD, the 3d model format for the DS, also does this at times for reasons I have never been able to quite fathom).
More data is more better if the devs have given it but you might be left with just a list of file numbers and locations. In that case I usually go to the magic stamp thing mentioned above -- if the file starts with a nice bit of text or whatever that indicates its type then guess what becomes my new extension when I rip all the files?)