MxCh: Difference between revisions

From LEGO Island Wiki
Jump to navigation Jump to search
(Created page with "MxCh is the 32-bit identifier for a Lego Island data chunk. They are seen extensively in SI Files to allow interleaving of several different data types. MxCh chunks c...")
 
No edit summary
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[MxCh]] is the 32-bit identifier for a Lego Island data chunk. They are seen extensively in [[SI Files]] to allow interleaving of several different data types.
[[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.
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 ==
== Specification ==
=== WAV Data ===


{{Incomplete}}
{{Incomplete}}


The MxCh header is 20 bytes long and specifies the length of the chunk with other data.
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"
{| class="wikitable"
Line 15: Line 19:
| "MxCh" || 0 || 4-byte chunk identifier
| "MxCh" || 0 || 4-byte chunk identifier
|-
|-
| Chunk Size || 4 || 4-byte integer
| 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
|-
|-
| ''Unknown'' || 8 || Unknown data
| 2 || Chunk is an ending chunk. Chunk size must also be "14" (length of just the header - implies an empty chunk)
|-
|-
| Data || 20 || Arbitrary data no more than "Chunk Size" in bytes
| 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 20000h (131072 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 20000h. Doing so causes Lego Island to crash as it tries to read beyond the 20000h buffer it's allocated for streaming. Therefore if a chunk is going to extend beyond a 20000h 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 20000h 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 20000h boundaries. LEGO Island allows a chunk to be split more than once (possibly infinitely), meaning as long as the chunk is split every 20000h 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.

Revision as of 13:37, 7 August 2019

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

NOTE: This information is incomplete and requires more research and information.

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.

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:

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 20000h (131072 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 20000h. Doing so causes Lego Island to crash as it tries to read beyond the 20000h buffer it's allocated for streaming. Therefore if a chunk is going to extend beyond a 20000h 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 20000h 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 20000h boundaries. LEGO Island allows a chunk to be split more than once (possibly infinitely), meaning as long as the chunk is split every 20000h 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.