interesting sample. you interpretation is not entirely correct or imcomplete. anyway...
if you know the file that contains the buffer lenghts or vertex or index counts or whatever describes this data container you should load that first and then the data file. how you do it depends if the description file has the same name or got a filename in it that relates to the data file here.
have an xsample code.
http://www.mediafire.com/file/39v5gg5t9 ... ed_wip.rar it's slightly messy and maybe to advanced to read for you rn. but you should get something out of it and get there. no file examples, cause they are not relevant. the adr file just links the model and skeleton. but you get the idea of file relations. you base the script on and load the file higher in the hierarchy aka the description first then load the data container into this 2nd bytearray and bitstream, to parse it. be smart and label your bitstreams. makes it all easy. you can access the description and data at the same time and composite/compile whatever you need in the process.
now, for this example: those are multiple 'submeshes'. the first vertex count is 52 you should get that from the description file. you potentially have a vertex stride to figure out, but it could be an all in one default format. either way.
52 * 48 bytes - position+w, normal+pad, tangent+bitangentsign
52 * 32 bytes - 4 * blendweights + 4 * blendindices (uint32)
52 * 8 bytes - tu + tv
then the indices of 48 triangles or 144 (x3) index length you should get from the description too. whether the description contains buffer size or relative offsets the next part/submesh starts at 0x1270.
for the sake of readability: when you have power of two components or arrays that align, you can write hex notation. absolute offsets or relatively (0x10) aligned jumps should be written as hex too.
![:]](./images/smilies/%5Bcolon%5D%5D.gif "Satisfied"){kind=small}