High quality resource

High quality resource
Extension	HQR
Occurence	LBA1 & LBA2
Programs supporting this format
LBA Image Creator LBADeComp LBArchitect LBA Package Editor LBA Text File Editor WinHQR

The games Little Big Adventure 1 and 2 (and games in general) use special files to keep all kinds of data, that builds the game world. In LBA 1 and 2 these files are in common format, that is called High Quality Resource, in short: HQR - that's the extension of these files. In the game installation directory files with other extensions can be also found: VOX, ILE and OBL (the last two exist in LBA 2 only) - these have identical formats as the HQR ones, but are named differently for convenience. HQR, VOX, ILE and OBL files are commonly called Resource files or Package files.

• HQR - stands for High Quality Resource - these files are of general usage. They contain various types of files, like images, text strings, 3D objects.
• VOX - contain voices that can be heard in the game. In LBA 1 these archives contain VOC files, in LBA 2 - WAV files. Note that VOX extension also means "Dialogic ADPCM" according to some programs, but the files used in LBA 1 are not Dialogic ADPCM format, despite the fact that they have identical extension.
• ILE - contain 3D islands for LBA 2.
• OBL - contain 3D objects for appropriate islands (LBA 2 only).

Resource files are similar to compressed archives, like ZIP, RAR, or 7z, but they do not make use of any of the common format. Instead, they utilise custom format developed by LBA creators, and compression method, which is a variant of LZSS.

There are other files in the game directories, like EXE, DLL, but they are not in scope of this wiki (but may be, if there is something one can modify inside them).

Types of entries

There are four kinds of entries, that are stored inside resource files:

• Normal entries - contain physical data that can be extracted to a file.
• Hidden entries - also contain data, but are not specified in the header. They are placed in the gaps between normal entries. Entries of this kind are present only in VOX files. They are used to split long speech data into smaller pieces (probably because the engine is unable to play big files at once).
• Repeated entries - do not contain data, but just references (addresses) to normal entries. This method is a kind of compression - two or more files that contain identical data can be stored as one copy of the data that is just referenced many times. This allows saving disk space without changing the resource file structure.
• Blank entries - do not contain data, but empty addresses (of zero value). They are probably entries that have been deleted at the alpha/beta stage of the game and they were left in the header to keep the resource file structure unchanged.

Entry indices

Each entry in a resource file is referenced by its index, not by its name. Actually, names of the entries are not stored at all. That is why it is important to keep entry indices intact while editing a resource file. Adding or removing one entry from a middle of a resource file would cause entries that are located further in the file to change their indices, which would break all the game references to those entries. The game would then encounter different entries than expected, and would most likely crash.

Real entry indices start with zero for each resource file, and continue through all the entries excluding the hidden entries (see specification below). Hidden entries can be added or removed without changing the main index, because they are not added to the resource's index table. Some resource editing programs do not follow this and assign indices to hidden entries, but this is not recommended. In this wiki hidden entries are not described (only marked where they exist in original files), because they only exist as parts of the normal entries.

File types

Each entry in a resource file is a file itself. It can be unpacked (extracted) and exist independently on the disk. The main problem with extracting is that the files do not have names or extensions assigned inside resource files, and their purposes and formats are not known. The entry types presented in this wiki have been guessed or reverse-engineered by LBA enthusiasts, and thus are known. Most of the extensions have been made up, because most of the files are in formats that are not commonly used (thus do not have common extensions). For example: image files in LBA resources are neither BMP nor JPG, PNG, nor any other format that is supported by common image editors. That is why they have been named lim, lsp, brk, and so on (depending on format and purpose), and are supported only by editors that were especially made for them.

Specification

See also: HQR compression

This format applies to HQR, VOX, ILE and OBL files from LBA 1 and 2.

Resource files are containers for other files, like .zip archives (they can be compressed too). But unlike the .zip files, the files inside them (called entries) do not have names (the names are not kept inside the resource files). The game recognizes which entry is which by their position inside the resource file, so all programs that allow replacing the entries have to keep the rest of the entries in the same order as in the original file.

At the beginning of the file there is an offset block. This block consists the offsets (addresses) to the entries that are placed further in the file. Addresses are 4-bytes long numbers (DWORDs) in Intel notation. There are 3 types of the addresses:

• Normal addresses - are not distinguished by anything special.
• Blank addresses - are addresses equal to 0x00000000. Such address means that there is no data associated with it (i.e. it is an empty slot for a file). Such addresses cannot be removed from the resource file, because the structure would then change. Blank addresses are still entries.
• Repeated addresses - are addresses equal to one of the previous normal addresses. In case that two or more identical entries (with identical data) need to exist in the same resource file, data of only first of them will be actually kept, and the rest will be just references (addresses) to the same block of data. The game sees repeated addresses as regular normal addresses, and access the data in normal way.

At the end of the offset block there is one additional address which is equal to the file size in bytes.

Each of the addresses (except for blank addresses) points to a block of data (actually start of its header). The header is always 10 bytes long and its format is following:

• first four bytes is the original size of the data block (uncompressed) as DWORD.
• next four bytes is the compressed (actual) size of the data block as DWORD.
• next two bytes is the compression type as WORD. 0 is for no compression, 0x0001 for compression type 1 and 0x0002 for compression type 2.

After the header there is the data block, which length is equal to the compressed size value in the header.

If the compression type value is 0x01 or 0x02, then the data after the header is compressed. For more information about the compression, see HQR compression.

VOX files and hidden entries

There is also a kind of entries called hidden entries. These entries are special, because they do not have an addresses pointing to them in the address block. They can be found by comparing one non-blank entry offset and length with the next non-blank entry offset. If the (nextOffset = offset + compressedLength + 10) is not equal to the next non-blank entry offset, or if there are no non-blank entries left ahead, and the nextOffset is still less than the end of the data, then a hidden entry exists at the nextOffset. Beware, that there can also be a hidden entry even after the very last entry in the address block. After any hidden entry there might immediately follow more, if the first data byte of the current hidden entry equals to 0x01 (see also below).

Hidden entries appear in VOX resources only. They are used to split one large voice sample into smaller pieces, probably because the engine cannot play large samples. Thus no hidden entry can occur as the first entry in a resource, but only as groups: one normal plus several hidden ones after it.

The normal entry and the hidden ones within the same group have the first byte of the data (in the uncompressed stage) modified. All entries in the group (including the normal one) have the first byte changed to 0x01, and the last hidden entry of the group has the first byte changed to 0x00. These changes probably indicate to the game that after the normal entry there are also some hidden ones, and the 0x00 byte indicates the last one, so the game does not have to do the offset/length computations. What if a normal entry will have its regular first byte of 0x01? That's not possible. Hidden entries are used in VOX files ONLY, and there are only two kids of files stored inside them: .voc files for LBA 1, which have the text Creative at the beginning, and .wav files for LBA 2, which have the text RIFF at the beginning, so no entry with byte 0x01 at the data beginning is normally possible. Because of this, when you read audio data files from VOX entries, you have to restore the first byte character to be 'C' for LBA 1 or 'R' for LBA 2, as it will be 0x01 or 0x00 and the extracted audio file will not play.

---

Information provided by: El Muerte, Zink