Friday, May 2, 2008

BJS Intro

I'm still mulling over how to best report on the BJS format, as it's very complicated and while I think my understanding of the format is correct thus far, there are still some unknown values. Also, because of the way the file is structured, I'm having a hard time wrapping my head around how one might write an app that will output a proper BJS.

This is a basic explanation, code examples will follow soon, hopefully after I have successfully hand-built a file that works:
The beginning of the file is quite simple; there's a magic number, a file name (e.g. dance2), the folder name (jam_0002), the tempo, time signature, and the number of VAG files that follow. Then the first VAG appears, and things get a little more complicated.
After the first VAG, and in between every VAG thereafter is a chunk of data that varies in both size and content each time. This is the biggest missing piece of the puzzle. Luckily there are some hints at the end of the file (see below) that might explain what everything is. It'll hopefully click once I go over it three or four times.

After all the VAG files and their bizarre end-data, begins the naming of all the above files and their instrument sets. Finally, there's a large collection of 12 byte chunks that follow, for the most part, the same pattern: A 4 byte ASCII ID, a 4 byte offset (little endian), and a 4 byte length (also little endian). For example, you might see 42 50 4D 30 (BPM0) 1C 00 00 00 04 00 00 00 which says "The BPM (tempo) is at x1C and is 4 bytes long." Going to this offset at will then yield a value (e.g. 140 in JAM_0002). The exception to this is when the ASCII ID is followed by FF FF FF FF, in which case the next number is the length of the following related data. For example, the very first ID is "BIFF". After this is the 4 byte set of FFs and then a value. This value is equal to the size of the rest of the footer, minus the last 4 bytes. The very last 4 bytes of the file is the offset of the BIFF ID.

Still follow me?

The ASCII names range from obvious (e.g. BPM, NAME) to somewhat understandable (e.g. VAGS is the size of the following VAG information, NVAG is the number of VAGs listed, VAGF is a VAG file) to mysterious (e.g. UINT). Luckily most of the unknown ones are unused, and are probably reserved for something else.

It seems like a simple enough database, but working in reverse with no information at hand is proving to be a lot more difficult than I thought. If this structure looks at all familiar to anyone, please let me know, as it will save a lot of frustrations all around. Note: despite the odd "BIFF" string, the file seems unrelated to the Microsoft Excel or BioWare BIFF formats.

No comments: