Difference between revisions of "Broken Sword Templars CLU"

From XentaxWiki
Jump to: navigation, search
(The majority http://www.greencoffeeextractnow.com/best-diet-supplement best best diet supplement coming out every day. http://www.greencoffeeextractnow.com/weight-loss-product top weight loss product)
(Revert spambot attacks)
Line 1: Line 1:
The majority http://www.greencoffeeextractnow.com/best-diet-supplement best best diet supplement coming out every day. http://www.greencoffeeextractnow.com/weight-loss-product top weight loss product You http://www.greencoffeeextractnow.com/coffee-beans-direct coffee beans direct on greencoffeeextractnow.com Antioxidants http://www.greencoffeeextractnow.com/best-green-coffee-supplement-for-weight-loss best green coffee supplement for weight loss greencoffeeextractnow.com body to burn calories as celebrities become http://www.greencoffeeextractnow.com/green-coffee-oz green coffee oz which have been known http://www.greencoffeeextractnow.com/green-mountain-coffee-company top green mountain coffee company Soda is packed with unhealthy http://www.greencoffeeextractnow.com/green-coffee-bean-extract-supplement top green coffee bean extract supplement you can embark on your http://www.greencoffeeextractnow.com/pure-green-coffee-bean-extract-review pure green coffee bean extract review on greencoffeeextractnow.com we are to reduce weigh http://www.greencoffeeextractnow.com/green-coffee-beans-to-lose-weight best green coffee beans to lose weight show which relates to obesity and .
+
== RIF + CLU ==
 +
 
 +
* ''' Format Type ''':    Archive <br>
 +
* ''' [http://en.wikipedia.org/wiki/Endianness Endian Order] ''': Little Endian <br>
 +
 
 +
 
 +
=== Format Specifications ===
 +
 
 +
To extract data from cluster files, the type of the cluster file has to be determined first. There are two known types: general data clusters and sound clusters. To process data clusters, a RIF file is needed.
 +
 
 +
 
 +
==== RIF ====
 +
 
 +
The RIF file contains global information for all data cluster files.<br><br>
 +
 
 +
<tt><b>
 +
<font color="blue">// RIF header</font><br>
 +
uint32 {4} - Number of clusters<br>
 +
: <font color="blue">// for each cluster</font><br>
 +
: uint32 {4} - Cluster ID<br>
 +
: <font color="blue">// for each cluster</font><br>
 +
: uint8 {1}&nbsp; - Cluster name length<br>
 +
: char {31}&nbsp; - Cluster name<br>
 +
: uint32 {4} - Number of sections<br>
 +
:: <font color="blue">// for each section</font><br>
 +
:: uint32 {4} - Section ID<br>
 +
:: <font color="blue">// for each section</font><br>
 +
:: uint32 {4} - Number of files<br>
 +
::: <font color="blue">// for each file</font><br>
 +
::: uint32 {4} - File ID<br>
 +
::: <font color="blue">// for each file</font><br>
 +
::: uint32 {4} - File offset<br>
 +
::: uint32 {4} - File length<br>
 +
</b></tt>
 +
 
 +
 
 +
==== Data CLU ====
 +
 
 +
Data clusters contain no header of their own. Instead, the information read from the RIF (where the cluster in question can be identified by its file name prefix) is needed to process these files. The gained offset and length values can then be used to seek through the cluster file.
 +
 
 +
 
 +
==== Sound CLU ====
 +
 
 +
To process sound clusters, the RIF file is not needed. Instead, these files have their own header:<br><br>
 +
 
 +
<tt><b>
 +
<font color="blue">// CLU header</font><br>
 +
uint32 {4} - Data offset<br>
 +
uint32 {4} - Index offset<br>
 +
</b></tt><br>
 +
 
 +
This header is followed by some unknown data. At the index offset, the actual entry information array can be found. The number of entries can indirectly be computed via <tt>(Data offset - Index offset) <b>div</b> 8</tt>.<br><br>
 +
 
 +
<tt><b>
 +
: <font color="blue">// for each entry</font><br>
 +
: uint32 {4} - Data offset<br>
 +
: uint32 {4} - Data size<br>
 +
</b></tt><br>
 +
 
 +
The resulting sounds are expressed as PCM wave files with a standard RIFF header. However, the content of their data chunk has been [[RLE]]-compressed. Also, the size value of the RIFF chunk usually seems to be wrong and has to be fixed.<br><br>
 +
 
 +
===== Sound data RLE variation =====
 +
 
 +
The compressed sound data does not follow a standard RLE scheme, but uses a certain variation. The decompression is easy nonetheless. In the following pseudo code, it is assumed that decompression takes place from <tt>InBuf</tt> to <tt>OutBuf</tt>.<br><br>
 +
 
 +
<tt>
 +
<b>while</b> still data to decompress <b>do</b>
 +
: get (big endian!) int16 RunLen from InBuf
 +
: <b>if</b> RunLen < 0 <b>then</b>
 +
:: copy the next int16 value from InBuf to OutBuf -RunLen times
 +
: <b>else</b>
 +
:: copy RunLen int16 values from InBuf to OutBuf
 +
</tt><br>
 +
 
 +
=== MultiEx BMS ===
 +
 
 +
Not written yet<br><br>
 +
 
 +
=== Supported Programs ===
 +
 
 +
Unknown<br>

Revision as of 08:32, 14 December 2014

RIF + CLU


Format Specifications

To extract data from cluster files, the type of the cluster file has to be determined first. There are two known types: general data clusters and sound clusters. To process data clusters, a RIF file is needed.


RIF

The RIF file contains global information for all data cluster files.

// RIF header
uint32 {4} - Number of clusters

// for each cluster
uint32 {4} - Cluster ID
// for each cluster
uint8 {1}  - Cluster name length
char {31}  - Cluster name
uint32 {4} - Number of sections
// for each section
uint32 {4} - Section ID
// for each section
uint32 {4} - Number of files
// for each file
uint32 {4} - File ID
// for each file
uint32 {4} - File offset
uint32 {4} - File length


Data CLU

Data clusters contain no header of their own. Instead, the information read from the RIF (where the cluster in question can be identified by its file name prefix) is needed to process these files. The gained offset and length values can then be used to seek through the cluster file.


Sound CLU

To process sound clusters, the RIF file is not needed. Instead, these files have their own header:

// CLU header
uint32 {4} - Data offset
uint32 {4} - Index offset

This header is followed by some unknown data. At the index offset, the actual entry information array can be found. The number of entries can indirectly be computed via (Data offset - Index offset) div 8.

// for each entry
uint32 {4} - Data offset
uint32 {4} - Data size


The resulting sounds are expressed as PCM wave files with a standard RIFF header. However, the content of their data chunk has been RLE-compressed. Also, the size value of the RIFF chunk usually seems to be wrong and has to be fixed.

Sound data RLE variation

The compressed sound data does not follow a standard RLE scheme, but uses a certain variation. The decompression is easy nonetheless. In the following pseudo code, it is assumed that decompression takes place from InBuf to OutBuf.

while still data to decompress do

get (big endian!) int16 RunLen from InBuf
if RunLen < 0 then
copy the next int16 value from InBuf to OutBuf -RunLen times
else
copy RunLen int16 values from InBuf to OutBuf


MultiEx BMS

Not written yet

Supported Programs

Unknown