LEGO Island Wiki - User contributions [en]

MxHd

2024-09-18T16:03:03Z

DmitriLeon2000:

The [[MxHd]] section is part of the [[Interleaf File]] standard. It's the global header that defines metadata about the Interleaf file itself.

== Specification ==
{{Incomplete}}

{| class="wikitable"
|-
! Name !! Bytes !! Offset !! Description
|-
| "MxHd" || 4 || 0 || A data identifier
|-
| Chunk size || 4 || 4 || An integer specifying the size of this chunk minus the first 8 bytes (usually '''12''' or '''0xC''' for MxHd section)
|-
| Minor version || 2 || 8 || An integer specifying minor version (always '''2''' in retail releases)
|-
| Major version || 2 || 10 || An integer specifying major version (always '''2''' in retail releases)
|-
| Buffer size || 4 || 12 || An integer specifying the size of every data buffer
|-
| Buffer count || 4 || 16 || An integer specifying the number of data buffers
|}

MxCh

2024-04-20T13:49:15Z

DmitriLeon2000:

[[MxCh]] is the identifier for a [[Lego Island]] data chunk. They are seen extensively in [[SI Files]] to allow interleaving of several different data types.

MxCh chunks contain partial data of various different data types intended to be joined together continuously to form a complete file (an MxDa section). The chunks can also contain solely header data. A chunk will almost never contain a complete file on its own.

== Specification ==

=== WAV Data ===

{{Incomplete}}

This data is only known to be accurate for chunks that store WAV data.

The MxCh header is 22 bytes long and specifies the length of the chunk with other data. MxCh chunks must start on an even offset or they will not be skipped by LEGO Island.

{| class="wikitable"
|-
! Bytes !! Offset !! Description
|-
| "MxCh" || 0 || 4-byte chunk identifier
|-
| Chunk Size || 4 || 4-byte integer specifying the size of this chunk minus the first 8 bytes
|-
| Flags || 8 || 2-bytes that appear to have set flags about the chunk
|-
| ID || 10 || 4-byte integer that identifies which MxOb this belongs to.
|-
| Milliseconds || 14 || 4-byte integer that appears to be the chunk's offset in milliseconds increasing continuously (1000, 2000, 3000, etc.)
|-
| Chunk Data Size || 18 || 4-byte integer for the size of the data following the header.
|-
| Data || 22 || Arbitrary data no more than "Chunk Size - 14" in bytes (14 for the 22-byte header minus the first 8 bytes)
|}

=== Flags ===
The full purpose of the 2-byte "Flags" value above is not entirely known, however the following appear to be accurate:
{| class="wikitable"
|-
! Flag !! Description
|-
| 2 || Chunk is an ending chunk. Chunk size must also be "14" (length of just the header - implies an empty chunk)
|-
| 16 || Chunk is split (see below).
|}

=== Split Chunk ===
In addition to the data being split into chunks, the chunks themselves are sometimes split into two. If a chunk is split, both chunks will have the '''Flags''' section set to 16, and they'll also both have the same '''Milliseconds''' value. The "Chunk Size" will be accurate to each chunk's size (data length + 14), but the "Chunk Data Size" of the first chunk appears to be the total size of both chunks' data. The second chunk's "Chunk Data Size" is accurate to its own chunk data size.

The necessity of the split chunks appears to be due to the way Lego Island streams SI files; it appears to only be able to stream a certain amount of bytes (the buffer size) dictated by the SI file's [[MxHd]] (in the case of [[JUKEBOX.SI]], 20000h/131072 bytes; in the case of SNDANIM.SI, 58000h/360558 bytes; otherwise, 10000h/65536 bytes) at a time and the SI file must conform to this limitation. A chunk can have no data that extends over a multiple of the set buffer size. Doing so causes Lego Island to crash as it tries to read beyond the buffer it's allocated for streaming. Therefore, if a chunk is going to extend beyond a buffer size multiple, it must be split at that point and then another chunk must be written directly afterwards with the remainder of the data. This is a big obstacle to inserting audio that is larger than the existing audio, since literally all subsequent chunks of all subsequent songs must be shifted to fit around the buffer size multipliers or Lego Island will crash. This essentially necessitates a reconstruction of most, if not all, of the file.

There seems to be no hard limit for the size of a chunk, other than having to accommodate these boundaries set by the [[MxHd]]. LEGO Island allows a chunk to be split more than once (possibly infinitely), meaning as long as the chunk is split every set buffer size it may be possible for each song to be read as one large chunk rather than one chunk per second. However, LEGO Island appears to expect each chunk to be one second long and seems to time certain events based on the length of a chunk rather than a length of time.

Interleaf File

2024-04-20T06:48:38Z

DmitriLeon2000:

An '''Interleaf File''' (extension '''.SI''') is a general-purpose asset archive format designed for streaming from CD-ROM. It was developed by [[Mindscape]] for use throughout [[LEGO Island]].

== Overview ==
The Interleaf file format was originally thought to be exclusive to ''[[LEGO Island]]'', but has since also been discovered in earlier [[Mindscape]] games called ''{{Wikipedia|Warhammer: Shadow of the Horned Rat}}'' and ''{{Wikipedia|Chessmaster 5000}}''. Regardless, it remains an extremely obscure format and therefore is not well documented. All information known about this format has been through reverse engineering or interviews with game developers.

Interleaf files are derived from the {{Wikipedia|Resource Interchange File Format}} standard (best known as the basis of {{Wikipedia|Audio Video Interleave}} and {{Wikipedia|WAV}} files). They are comprised of various LEGO Island-specific structures (such as [[MxDa]] and [[MxCh]]), however these structures usually contain standard format file data (such as PCM WAV audio and Windows BMP images).

The primary purpose of Interleaf files is to split various file formats into smaller chunks that are interleaved together so they can all be read as one continuous stream. For example, a chunk of voice data may be followed by a chunk of matching animation data or a bitmapped graphic. This is done to reduce the amount of seeking around the disc for assets since CD-ROM speeds of the era were generally very slow and end-user hard drive space was usually too limited to store much game data.

Interleaf files were produced internally with a tool called [[Weaver]], however this tool has never been publicly released or leaked.

== Version ==
Interleaf files went through a number of revisions, as indicated by this error message that's thrown if an SI version doesn't match:

<center>[[File:WrongSIVersion.png]]</center>

The SI version is set in an SI file's [[MxHd]] section. The version used in both retail versions is 2.2.

== Modification ==
As aforementioned, no official documentation of Interleaf files has ever been released. There are a handful of tools for working with them (e.g. [[LEGO Island Rebuilder]]), but none with a complete implementation. Therefore, manual hex editing is often used to replace or extract assets.

When working with Interleaf files, this interleaving needs to be taken account as it will dictate how the data is both extracted and inserted. One file stream may be separated into several chunks with chunks of other files interleaved between them.

Since audio is stored in PCM, Interleaf files can be crudely listened to using Audacity's "Import Raw Data" feature. SI audio is always uncompressed mono PCM and is either 11025 Hz and 16-bit or 22050 Hz and 8-bit. Unfortunately, due to the aforementioned chunked/interleaved nature of SI files, the audio retrieved through this method will be noticeably glitchy and will require further processing (removal of chunk headers and any non-audio chunks) to extract clean PCM data.

== See also ==
* [[JUKEBOX.SI]]
* [[NOCD.SI]]

MxHd

2024-04-20T06:39:20Z

DmitriLeon2000:

The [[MxHd]] section is part of the [[Interleaf File]] standard. It's the global header that defines metadata about the Interleaf file itself.

== Specification ==
{{Incomplete}}

{| class="wikitable"
|-
! Bytes !! Offset !! Description
|-
| "MxHd" || 0 || 4-byte data identifier
|-
| Chunk size || 4 || 4-byte integer specifying the size of this chunk minus the first 8 bytes (usually '''12''' or '''0xC''' for MxHd section)
|-
| Minor version || 8 || 2-byte integer specifying minor version (always '''2''' in retail releases)
|-
| Major version || 10 || 2-byte integer specifying major version (always '''2''' in retail releases)
|-
| Buffer size || 12 || 4-byte integer specifying the size of every data buffer
|-
| Buffer count || 16 || 4-byte integer specifying the number of data buffers
|}

MxHd

2024-04-20T06:39:06Z

DmitriLeon2000:

The [[MxHd]] section is part of the [[Interleaf File]] standard. It's the global header that defines metadata about the Interleaf file itself.

== Specification ==
{{Incomplete}}

{| class="wikitable"
|-
! Bytes !! Offset !! Description
|-
| "MxHd" || 0 || 4-byte data identifier
|-
| Chunk size || 4 || 4-byte integer specifying the size of this chunk minus the first 8 bytes (usually '''12''' or '''0xC''' for MxHd section)
|-
| Minor version || 10 || 2-byte integer specifying minor version (always '''2''' in retail releases)
|-
| Major version || 8 || 2-byte integer specifying major version (always '''2''' in retail releases)
|-
| Buffer size || 12 || 4-byte integer specifying the size of every data buffer
|-
| Buffer count || 16 || 4-byte integer specifying the number of data buffers
|}

MxHd

2024-04-17T13:41:09Z

DmitriLeon2000:

The [[MxHd]] section is part of the [[Interleaf File]] standard. It's the global header that defines metadata about the Interleaf file itself.

== Specification ==
{{Incomplete}}

{| class="wikitable"
|-
! Bytes !! Offset !! Description
|-
| "MxHd" || 0 || 4-byte data identifier
|-
| Chunk size || 4 || 4-byte integer specifying the size of this chunk minus the first 8 bytes (usually '''12''' or '''0xC''' for MxHd section)
|-
| Major version || 8 || 2-byte integer specifying major version (always '''2''' in retail releases)
|-
| Minor version || 10 || 2-byte integer specifying minor version (always '''2''' in retail releases)
|-
| Buffer size || 12 || 4-byte integer specifying the size of every data buffer
|-
| Buffer count || 16 || 4-byte integer specifying the number of data buffers
|}

JUKEBOX.SI

2024-04-17T11:43:33Z

DmitriLeon2000:

{{Confused|JUKEBOXW.SI}}

[[JUKEBOX.SI]] is an [[Interleaf File]] containing 60 audio tracks of music and radio dialogue. With a few exceptions{{Citation needed}}, all of [[LEGO Island]]'s music is stored in JUKEBOX.SI.

== Details ==

As an Interleaf file, JUKEBOX.SI is a container for a large number of asset files. Most of these files are background and radio music (including the radio voices) in Microsoft {{Wikipedia|WAV}} audio, however there are also 4 [[FLIC]] video files for each of the building rooms (dune buggy, jetski, helicopter, and race car). These FLC files are the small instructional videos played in the screen and are interleaved together as "movies" that are equal length (thus looping together).

All audio in JUKEBOX.SI (like most of LEGO Island's audio assets) is mono uncompressed PCM. While the majority of tracks are sampled at 11025 Hz/16-bit, a handful are sampled at 22050 Hz/8-bit. These can be distinguished by each track's WAV header (the "fmt " section if you're familiar with WAV headers) left intact in the first [[MxCh|chunk]] of their respective streams.

When replacing, the WAV "fmt " header can be directly transplanted over the existing data in said first chunk. All WAV formats are compatible. The PCM data can be transplanted too, but it must be interleaved into chunks.

== Technical Information ==

Music appears to begin with a <code>MxDa</code> and is split into chunks of <code>MxCh</code>. The <code>MxDa</code> header contains information about the PCM audio in the <code>MxCh</code> chunks. The first <code>MxCh</code> appears to be information about the remainder of the chunks in the <code>MxDa</code> structure.

All bytes are little endian as is normal for RIFF-based files.

=== Extracting Audio ===

* Audio streams can be located in JUKEBOX.SI by searching for " WAV" (note the prepending space).
** A few bytes before the " WAV" will be the original filename of the WAV file prior to being imported into the SI file if you wish to retrieve that too.
* A few bytes later will be "LIST" which appears to specify an array (or "list") of chunks that make up one audio track. The next 4 bytes will by a 32-bit integer for the total size of this "LIST", in other words the total amount of upcoming bytes of the SI file that belong to this particular audio track.
* The first [[MxCh]] after the "LIST" will contain WAV-compatible header data, most of which can be transplanted directly into a WAV file (see below for details).
* Every MxCh after this one will contain PCM audio data (formatted according to the header data in the first MxCh). Each MxCh has a 22 byte header that will need to be stripped out when extracting. After the 4 byte "MxCh" identifier, the header contains a 4 byte integer of the total amount of bytes that the chunk takes up (minus 8 bytes for the "MxCh" identifier and chunk size integer). All data after this 22 byte header is PCM audio that will be exactly "chunk size - 14" bytes in size (14 is the size of the 22 byte header minus the first 8 bytes).
* Each MxCh's data can be dumped until you reach the end of the "LIST" size extracted above. At that point the end of the track has been reached and the process must be repeated to extract the next track.

=== Header ===

{{Incomplete}}

As mentioned above, the first MxCh in a "LIST" contains solely header data. Most of this data is completely compatible with the specification for WAV.

{| class="wikitable"
|-
! Bytes !! Offset !! Description
|-
| <code>MxDa</code> || 0 || Identifier
|-
| <code>MxCh</code> || 4 || Chunk Header
|-
| Chunk Size || 8 || 4-byte Integer
|-
| Sub-Chunk Size || 22 || 4-byte Integer - The remaining size of this chunk after this value
|-
| Audio Format || 26 || 2-byte Integer - 1 = PCM, others indicate some form of compression
|-
| Number of Channels || 28 || 2-byte Integer - 1 = Mono, 2 = Stereo
|-
| Sample Rate || 30 || 4-byte Integer
|-
| Byte Rate || 34 || 4-byte Integer - is equal to <code>Sample Rate * Number of Channels * BitsPerSample/8</code>
|-
| Bytes per Sample || 36 || 2-byte Integer - is equal to <code>Number of Channels * BitsPerSample/8</code>
|-
| Bits per Sample per Channel || 38 || 2-byte Integer - 8 = 8-bit, 16 = 16-bit, etc.
|}

==== Transplanting the Header ====

Use this [http://archive.is/XXc3O WAV File Format Header Specification] and you'll be able to determine the 16 bytes from "Audio Format" to "Bits per Sample per Channel" are identical. This makes up most of the WAV header data (apart from file and chunk size which cannot be determined from here) and can be directly transplanted to make extraction easier and ensure the sample rate and sample size are correct in the extraction.

Note that the MxCh header contains a few more bytes after "Bits per Sample per Channel" and therefore its "Sub-Chunk Size" is larger than the average WAV file's. These extra bytes should be ignored and not transplanted, though if they are the "Sub-Chunk Size" should be translated too (or at least increased to accommodate for them).

MxHd

2024-04-17T11:36:48Z

DmitriLeon2000:

The [[MxHd]] section is part of the [[Interleaf file]] standard. It's the global header that defines metadata about the Interleaf file itself.

== Specification ==
{{Incomplete}}

{| class="wikitable"
|-
! Bytes !! Offset !! Description
|-
| "MxHd" || 0 || 4-byte data identifier
|-
| Chunk size || 4 || 4-byte integer specifying the size of this chunk minus the first 8 bytes (usually '''12''' or '''0xC''' for MxHd section)
|-
| Major version || 8 || 2-byte integer specifying major version (always '''2''' in retail releases)
|-
| Minor version || 10 || 2-byte integer specifying minor version (always '''2''' in retail releases)
|-
| Buffer size || 12 || 4-byte integer specifying the size of every data buffer
|-
| Buffer count || 16 || 4-byte integer specifying the number of data buffers
|}

MxHd

2024-04-17T11:33:08Z

DmitriLeon2000: Defined buffer size and buffer count variables.

The [[MxHd]] section is part of the [[Interleaf file]] standard. It's the global header that defines metadata about the Interleaf file itself.

== Specification ==
{{Incomplete}}

{| class="wikitable"
|-
! Bytes !! Offset !! Description
|-
| "MxHd" || 0 || 4-byte data identifier
|-
| Chunk size || 4 || 4-byte integer specifying the size of this chunk minus the first 8 bytes (usually '''12''' or '''0xC''' for MxHd section)
|-
| Major version || 2 || 2-byte integer specifying major version (always '''2''' in retail releases)
|-
| Minor version || 2 || 2-byte integer specifying minor version (always '''2''' in retail releases)
|-
| Buffer size || 4 || 4-byte integer specifying the size of every data buffer
|-
| Buffer count || 4 || 4-byte integer specifying the number of data buffers
|}