.pck is a fairly generic extension (presumably the shortened form of pack) that has been used on half a hundred different formats (sometimes even multiple within the same game) on the DS alone.
To that end I would treat it as a new format.
BatchLZ77, DSDecmp, and Nintendo DS Compressors (and crystaltile2 and most of the other DS based stuff) will tend to only look at the first bytes (or last bytes in the case of BLZ). If the file is an archive of other files then most times compression will only be applied to individual files (saves having to decompress the whole thing to get one file -- if you have ever had a .7z with multiple files and you only wanted one and still had to wait an age for it to get it then same idea). apicula on the other hand will tend to scan for files within other files (if nothing else .nsbmd models often have textures within them).
Anyway if you have a bunch of smaller archives with the same name/extension/general location it can make sense to look at them first, though keep in mind they might not use some of the advanced functionality seen in larger things (might not have compression indicators, might not have directories/subdirectories, might not do various other things along such lines such formats often see).
What I normally do is see if I can find a format I know or obvious breaks between files.
Usually then at the start of the file, or maybe the end, or maybe a separate file within the ROM (this is presumably what the tbl, likely shortened form of table as in file name table, in the thing you saw handles) will be a list of at least locations/sizes (sometimes both) and often names as well. That and anything like the subdirectory, compression indicators and whatever else.
Flick between the two (or three or four) and eventually it makes sense.
Don't necessarily go right for the first entry -- you never know what is a section size indicator or file count or so somewhere in the middle is not bad.
You say it has models but in another area I am seeing various .nsbmd.lzc files (lz is a type of compression, not sure why c in this scenario other than maybe just lz compressed, and nsbmd is a model format that Nintendo provides and many devs use) in DGamer/GameData/ so I am curious there. Could always have eliminated it as well -- either let apicula loose on the file itself or rebuild the ROM without it.
Enough beating around the bush though so hex editor time.
Not much joy as far as it being a simple name and size type deal.
Scanning further in I see some BTX0 and BMD0 markers so presumably some 3d models in there.
Anyway DGamerArchive.fun on the root of the data directory might be one of those index files containing everything.
In it there is a nice chunk of text that is unmistakeably file names from a DS games. Between each file is a number, larger names seem to have larger numbers and match sizes so length of name is what is here.
Small selection, note not all files have .lzc extensions in this so some are not highlighted.
Though later in the file are what might be its corresponding files so I will skip that for now.
Back on _out.pck then.
First BMD0 is at f0f29 hex, though as such things are usually compressed then looking back a bit lands me on 0f0f20 where I see 10 hex (common start for compression followed by a file size, which is also the same as the file size in the BMD0 section, B017 when unflipped).
Above that I also see BTX0 and TEX0 so presumably other files before it, and that is quite far down into the file to be going to get to a first file, even when it is 58 megs large.
Anyway 039F E323 is the file length. Nothing even close to that at the start of the file. Looks like this will be a fun one.
Data changes in character around 0A4B with it having the entries count up one by one since really early in the file before then.
0AD6 is mentioned in the header and might be the end of a section.
Though a slight tweak to window size and
Far nicer
That first 00 is likely then a false positive and it follows the same format as all that follows after that.
The numbers at the start appear to be counting upwards so likely some file number/ordinal (can be used instead of names in some of these archives as it is quicker to say get file 52 than find somerandomfile.file and grab that)
The next sections appear to be getting larger. Careful with patterns at this point -- if a bunch of files have the same size (which is common in DS stuff -- 16x16 pixels is 16x16 counts of whatever data it uses regardless of whether it is random rainbow colours or all black).
The usual guesses at this point are size values and location values.
Could be that the file sizes or some other data is stored
039F E323 is again the file length so presumably the pointers used have to be able to handle a file of said length (too few bits and you can't reach the end of the file, which is not necessarily fatal but I have yet to see sector addressing on the DS and don't expect it here.
That would match the first set of numbers there, though it breaks down quickly and goes lower a few entries in.
Don't see anything that might be the BMD0 found earlier, nor a convincing location for start of the first file.
Comparing again to one of the other .pck files. In this case _out_SP.pck (presumably spanish if the rest of the names in the directory are common abbreviations for such things-
_out_DC.pck
_out_FR.pck
_out_GR.pck
_out_IT.pck
_out_JP.pck
_out.pck
_out_SP.pck
_out_US.pck )
Said other .pck also soon has a """"UUUU early into the file and the normal _out.pck has this as well a few times. Might be a part of a common file type within the archives, probably should check a tile viewer (looking at all the repeated data I doubt it is compressed either) but I don't have one with me right now.
