High quality resource - Revision history

91.100.202.126: Added better description of how to find the hidden entries. Added missing part of the algorithm for the last hidden entries.

2020-03-08T23:02:05Z

Added better description of how to find the hidden entries. Added missing part of the algorithm for the last hidden entries.

← Older revision		Revision as of 23:02, 8 March 2020
Line 60:		Line 60:
	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]].		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]].

	=== ~~Hidden~~ entries ===		=== 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 entry offset and length with the next ~~entry offset. If the offset + length + 10 is not equal to the next~~ entry offset~~, then it is sign that a hidden entry exists between the two 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.		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.		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.

	{{providers\|[[provider::El Muerte]], [[provider::Zink]]}}		{{providers\|[[provider::El Muerte]], [[provider::Zink]]}}

Zink at 04:52, 1 July 2013

2013-07-01T04:52:12Z

← Older revision		Revision as of 04:52, 1 July 2013
Line 64:		Line 64:
	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 entry offset and length with the next entry offset. If the offset + length + 10 is not equal to the next entry offset, then it is sign that a hidden entry exists between the two 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 entry offset and length with the next entry offset. If the offset + length + 10 is not equal to the next entry offset, then it is sign that a hidden entry exists between the two entries.

	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 ~~grups~~: one normal plus several hidden ones after it.		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.		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.

79.169.34.78: fix typo

2013-06-29T22:38:36Z

fix typo

← Older revision		Revision as of 22:38, 29 June 2013
Line 64:		Line 64:
	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 entry offset and length with the next entry offset. If the offset + length + 10 is not equal to the next entry offset, then it is sign that a hidden entry exists between the two 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 entry offset and length with the next entry offset. If the offset + length + 10 is not equal to the next entry offset, then it is sign that a hidden entry exists between the two entries.

	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 ~~gorups~~: one normal plus several hidden ones after it.		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 grups: 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.		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.

Zink at 06:17, 24 April 2013

2013-04-24T06:17:03Z

← Older revision		Revision as of 06:17, 24 April 2013
Line 1:		Line 1:
			__NOTOC__
	{{Infobox format		{{Infobox format
	\| extension = HQR		\| extension = HQR
Line 5:		Line 6:
	\| lba2 = true		\| lba2 = true
	}}		}}
			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''.
	High Quality Resources, also called ''package files'', ''resource files'' or ''archives'' are containers for other smaller files. Their purpose is identical to ''zip'', ''rar'' or ''tar.gz'' archives: to keep large amounts of files in a more efficient way (easier to copy and using less space by using compression).

	All resource package formats (''HQR'', ''VOX'', ''ILE'' and ''OBL'') share the same format, they differ only in purpose.

	* '''HQR''' - stands for High Quality Resource - these files are of general usage. They contain various types of files, like images, text strings, 3D objects.		* '''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 ~~you~~ ~~hear~~ 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 identical extension.		* '''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.		* '''ILE''' - contain 3D islands for LBA 2.
	* '''OBL''' - contain 3D objects for appropriate islands (LBA 2 only).		* '''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 [http://en.wikipedia.org/wiki/LZSS LZSS].
⚫	=== Types of entries ===

			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:		There are four kinds of entries, that are stored inside resource files:

Line 21:		Line 24:
	* '''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.		* '''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.		* '''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 ==		== Specification ==

Zink at 10:32, 10 February 2013

2013-02-10T10:32:29Z

← Older revision		Revision as of 10:32, 10 February 2013
Line 17:		Line 17:
	There are four kinds of entries, that are stored inside resource files:		There are four kinds of entries, that are stored inside resource files:

	* '''Normal entries''' - contain "physical" data that can be extracted to a file.		* '''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 ~~isn't~~ ~~able~~ to play big files at once).		* '''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.		* '''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.		* '''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.
Line 24:		Line 24:
	== Specification ==		== Specification ==
	See also: [[HQR compression]]		See also: [[HQR compression]]
	{{Cleanup\|It should be reformatted to use wikitext instead of <pre> tags.}}
	<pre>
	--------------------------------------------------------------------
	LBA High Quality Resource (HQR) file format
	Author: Kazimierz Król (zink)
	Based on HQR format description written by el-muerte.
	Revision: 1.0
	--------------------------------------------------------------------

	This format applies to HQR, VOX, ILE and OBL files from LBA 1 and 2.		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") ~~don't~~ 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.		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:		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.		* '''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.

	~~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.

	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.		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:		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.		* 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 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.		* 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~~ the ~~LBA_Compression_EN~~.~~txt file~~		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]].

	Hidden entries		=== Hidden entries ===
	----------------

	There is also a kind of entries called "hidden entries". These entries are special, because they ~~don't~~ have addresses pointing to them in the address block. They can be found by comparing one entry ~~ofset~~ and length with the next entry offset. If the offset + length + 10 is not equal to the next entry offset, then it is sign that a hidden entry exists between the two 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 entry offset and length with the next entry offset. If the offset + length + 10 is not equal to the next entry offset, then it is sign that a hidden entry exists between the two entries.

	Hidden entries appear in VOX resources only. They are used to split one large voice sample into smaller pieces, probably because the engine ~~can't~~ play large samples. Thus no hidden entry can occur as the first entry in a resource, but only as gorups: one normal plus several hidden after it.		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 gorups: 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 ~~gorup~~ (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.		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.
	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 doesn't have to do the offset/length computations. What if a normal ehtry 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.
	</pre>

	{{providers\|[[provider::El Muerte]], [[provider::Zink]]}}		{{providers\|[[provider::El Muerte]], [[provider::Zink]]}}

Zink at 10:08, 10 February 2013

2013-02-10T10:08:22Z

← Older revision		Revision as of 10:08, 10 February 2013
Line 23:		Line 23:

	== Specification ==		== Specification ==
			See also: [[HQR compression]]
	{{incomplete}}
			{{Cleanup\|It should be reformatted to use wikitext instead of <pre> tags.}}
			<pre>
			--------------------------------------------------------------------
			LBA High Quality Resource (HQR) file format
			Author: Kazimierz Król (zink)
			Based on HQR format description written by el-muerte.
			Revision: 1.0
			--------------------------------------------------------------------

			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") don't 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 the LBA_Compression_EN.txt file


			Hidden entries
			----------------

			There is also a kind of entries called "hidden entries". These entries are special, because they don't have addresses pointing to them in the address block. They can be found by comparing one entry ofset and length with the next entry offset. If the offset + length + 10 is not equal to the next entry offset, then it is sign that a hidden entry exists between the two entries.

			Hidden entries appear in VOX resources only. They are used to split one large voice sample into smaller pieces, probably because the engine can't play large samples. Thus no hidden entry can occur as the first entry in a resource, but only as gorups: one normal plus several hidden 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 gorup (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 doesn't have to do the offset/length computations. What if a normal ehtry 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.
			</pre>

			{{providers\|[[provider::El Muerte]], [[provider::Zink]]}}

Zink at 09:36, 10 February 2013

2013-02-10T09:36:31Z

← Older revision		Revision as of 09:36, 10 February 2013
Line 2:		Line 2:
	\| extension = HQR		\| extension = HQR
	\| noref = 1		\| noref = 1
			\| lba1 = true
	\| occurence = LBA1 & LBA2
			\| lba2 = true
	}}		}}
	High Quality Resources, also called ''package files'', ''resource files'' or ''archives'' are containers for other smaller files. Their purpose is identical to ''zip'', ''rar'' or ''tar.gz'' archives: to keep large amounts of files in a more efficient way (easier to copy and using less space by using compression).		High Quality Resources, also called ''package files'', ''resource files'' or ''archives'' are containers for other smaller files. Their purpose is identical to ''zip'', ''rar'' or ''tar.gz'' archives: to keep large amounts of files in a more efficient way (easier to copy and using less space by using compression).

Zink at 19:57, 9 February 2013

2013-02-09T19:57:01Z

← Older revision		Revision as of 19:57, 9 February 2013
Line 23:		Line 23:
	== Specification ==		== Specification ==
	{{incomplete}}		{{incomplete}}

	{{discussion}}

	[[Category:File formats]]

Zink at 16:53, 21 January 2013

2013-01-21T16:53:27Z

← Older revision		Revision as of 16:53, 21 January 2013
Line 2:		Line 2:
	\| extension = HQR		\| extension = HQR
	\| noref = 1		\| noref = 1
			\| occurence = LBA1 & LBA2
	}}		}}
	High Quality Resources, also called ''package files'', ''resource files'' or ''archives'' are containers for other smaller files. Their purpose is identical to ''zip'', ''rar'' or ''tar.gz'' archives: to keep large amounts of files in a more efficient way (easier to copy and using less space by using compression).		High Quality Resources, also called ''package files'', ''resource files'' or ''archives'' are containers for other smaller files. Their purpose is identical to ''zip'', ''rar'' or ''tar.gz'' archives: to keep large amounts of files in a more efficient way (easier to copy and using less space by using compression).

Zink at 10:06, 20 January 2013

2013-01-20T10:06:19Z

← Older revision		Revision as of 10:06, 20 January 2013
Line 1:		Line 1:
	{{Infobox format		{{Infobox format
	\| extension = HQR		\| extension = HQR
			\| noref = 1
	}}		}}
	High Quality Resources, also called ''package files'', ''resource files'' or ''archives'' are containers for other smaller files. Their purpose is identical to ''zip'', ''rar'' or ''tar.gz'' archives: to keep large amounts of files in a more efficient way (easier to copy and using less space by using compression).		High Quality Resources, also called ''package files'', ''resource files'' or ''archives'' are containers for other smaller files. Their purpose is identical to ''zip'', ''rar'' or ''tar.gz'' archives: to keep large amounts of files in a more efficient way (easier to copy and using less space by using compression).