-
Notifications
You must be signed in to change notification settings - Fork 2
11 May 2026
I have filled Region 2's audio data with blanks (FFs). I ensured to cut the length the first 4 bytes's length away from the 7th byte (start of the audio data).
-
Attempt 1: It played a low "beep" and had a light seizure, then reset.
I have miscalculated the number of bytes away from the 7th byte, leaving a bit of the terminal data of the audio unblanked. I have cut more off to equal the amount represented as an integer by the first 4 bytes. I double checked the data size I selected to blank matched the number of bytes represented by the first 4 bytes in ImHex. -
Attempt 2: It played a lower "beep" and had a worse light seizure. It failed to turn off the projector light triggering a delayed carousel turn. I could see the carousel turn while the projector light was still on. It then reset after a couple of back-to-back turns.
Perhaps
FFis not 'blank' when it comes to audio data? Let us try00...
I filled Region 2's audio data with 00.
DELAYED: It looks like my crappy wiring is preventing the flash from happening tonight. I will wiggle some wires and re-establish connection before trying to flash this again. It's not the modded content, as it fails at different spots of the flashing progress each attempt I've undergone. It's likely my circuitry.
Perhaps I have marked all the audio-light boundaries wrong when mapping the ImHex project file... I'll have to double check. This means that the systematic slices I took of the gold standards may also be wrong...
After review: yes, it looks like the audio and light data slices in GoldStandardAnalysis folder are all off by 6 bytes (the length + hz). I have trimmed all the light data slices (NOT the audio yet) for all cartridges I currently have processed that far (x2). It already looks more predictable. I will try to coordinate colour and timing with the data I've collected. From preliminary_data.md, it seems that my first theory (colour patterns are separated by 00) is incorrect, as the colours for each repeated segment within the 'colour' does not necessarily match what is displayed. I need to look at John-K's light decoder to understand how lights work instead of guessing like this.
Perhaps I will sever what I think is the audio and decode it with the a1800-codec, then listen to what plays. If there is extra audio, I know I cut it too long (encroaching into the lights data). If there is an abrupt end to the audio, I know I cut it too short.
After review: It appears that the audio plays well despite faulty stratification of data, which makes this method of little value except for gross errors.
| ⟵ Older | Table of Contents | Newer ⟶ |
|---|