9
edits
MxCh: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| 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 | 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 | 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. | ||