MxCh - Revision history

MattKC: Reverted edit by PawPatroler (2025) (talk) to last revision by ZeroCool32

2026-03-06T05:49:13Z

Reverted edit by PawPatroler (2025) (talk) to last revision by ZeroCool32

← Older revision		Revision as of 05:49, 6 March 2026
(No difference)

PawPatroler (2025): PawPatroler (2025) changed the content model of the page MxCh from "wikitext" to "JavaScript"

2026-03-05T19:14:46Z

PawPatroler (2025) changed the content model of the page MxCh from "wikitext" to "JavaScript"

← Older revision		Revision as of 19:14, 5 March 2026
(No difference)

ZeroCool32: Add sizes in kbytes.

2025-04-19T10:28:34Z

Add sizes in kbytes.

← Older revision		Revision as of 10:28, 19 April 2025
Line 46:		Line 46:
	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.		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.		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/128 kbytes; in the case of SNDANIM.SI, 58000h/360558 bytes/352 kbytes; otherwise, 10000h/65536 bytes/64 kbytes) 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.		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.

DmitriLeon2000 at 13:49, 20 April 2024

2024-04-20T13:49:15Z

← Older revision		Revision as of 13:49, 20 April 2024
Line 46:		Line 46:
	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.		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.		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 ~~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.		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.

MattKC at 13:37, 7 August 2019

2019-08-07T13:37:28Z

← Older revision		Revision as of 13:37, 7 August 2019
Line 4:		Line 4:

	== Specification ==		== Specification ==

			=== WAV Data ===

	{{Incomplete}}		{{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.		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.
Line 40:		Line 44:

	=== Split Chunk ===		=== 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, 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.		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.		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.

MattKC at 13:33, 7 August 2019

2019-08-07T13:33:15Z

← Older revision		Revision as of 13:33, 7 August 2019
Line 28:		Line 28:
	\|}		\|}

	=== Flags? ===		=== Flags ===
	The full purpose of the 2-byte "Flags" value above is not entirely known, however the following appear to be accurate:		The full purpose of the 2-byte "Flags" value above is not entirely known, however the following appear to be accurate:
	{\| class="wikitable"		{\| class="wikitable"
Line 34:		Line 34:
	! Flag !! Description		! Flag !! Description
	\|-		\|-
	\| 2 \|\| Chunk is an ending chunk. Chunk size must also be "14".		\| 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).		\| 16 \|\| Chunk is split (see below).
Line 40:		Line 40:

	=== Split Chunk ===		=== 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, 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.		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, 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.		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.

MattKC at 13:32, 7 August 2019

2019-08-07T13:32:26Z

← Older revision		Revision as of 13:32, 7 August 2019
Line 17:		Line 17:
	\| Chunk Size \|\| 4 \|\| 4-byte integer specifying the size of this chunk minus the first 8 bytes		\| 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		\| 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.		\| 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.)		\| 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.		\| Chunk Data Size \|\| 18 \|\| 4-byte integer for the size of the data following the header.

MattKC at 10:52, 2 May 2019

2019-05-02T10:52:05Z

← Older revision		Revision as of 10:52, 2 May 2019
Line 28:		Line 28:
	\|}		\|}

	=== Flags ===		=== 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".
			\|-
			\| 16 \|\| Chunk is split (see below).
			\|}

	=== Split Chunk ===		=== Split Chunk ===

MattKC at 09:43, 2 May 2019

2019-05-02T09:43:27Z

← Older revision		Revision as of 09:43, 2 May 2019
Line 7:		Line 7:
	{{Incomplete}}		{{Incomplete}}

	The MxCh header is 22 bytes long and specifies the length of the chunk with other 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 17:		Line 17:
	\| Chunk Size \|\| 4 \|\| 4-byte integer specifying the size of this chunk minus the first 8 bytes		\| Chunk Size \|\| 4 \|\| 4-byte integer specifying the size of this chunk minus the first 8 bytes
	\|-		\|-
	\| ''Flags?'' \|\| 8 \|\| 2-bytes ~~whose purpose are not completely clear, but~~ appear to ~~be some kind of~~ flags ~~(16 appears to mean it's a "split"~~ chunk ~~and 2 appears to mean it's an ending chunk. Ending chunks have no data).~~		\| ''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.		\| ID \|\| 10 \|\| 4-byte integer that identifies which MxOb this belongs to.
Line 27:		Line 27:
	\| Data \|\| 22 \|\| Arbitrary data no more than "Chunk Size - 14" in bytes (14 for the 22-byte header minus the first 8 bytes)		\| Data \|\| 22 \|\| Arbitrary data no more than "Chunk Size - 14" in bytes (14 for the 22-byte header minus the first 8 bytes)
	\|}		\|}

			=== Flags ===


	=== Split Chunk ===		=== Split Chunk ===

MattKC at 16:46, 27 April 2019

2019-04-27T16:46:22Z

← Older revision		Revision as of 16:46, 27 April 2019
Line 31:		Line 31:
	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, 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.		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, 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~~. Therefore~~ the SI file ~~itself~~ 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 20000h, it must be split at that point and then another chunk must be written with the remainder of the data. This ~~can be quite an~~ 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, essentially ~~necessitating~~ a reconstruction of most, if not all, of the file.		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.