5 June 2026

What I should have done

From a suggestion by John-K themself, I have finally figured out how to use the dreamsmith and dreamprojector tools. For background on this attempt, I had:

• (1) fragmented BSLSBS with dreamsmith.
• (2) I swapped out the audio file for the first frame ("labeled PAGE_03.wav" due to Segment 2.1 and 2.2 audios preceding it) with a sine wave created in Audacity.
• (3) used dreamsmith to patch it all back together.
• (4) used dreamprojector to visualize the audiovisual components of the franken-cartridge (found in /audio/4june2026 of the repo).

It appears that my modded sine wave in frame 2 produces a light seizure in dreamprojector as well. I did not touch the led data, so something is spilling over and affecting the lighting -- I must investigate further. It further appears from Regions 13-24 and Segments 2.1 and 2.2 that not including a light table may enable no light use? I thought I had tried this and it crashed? Perhaps not, since this would mean changing all the pointers -- and the thought alone is revolting... so much editing (but not anymore 👉)

Here is the dreamsmith info log on this modded sine-wave cartridge:

This process also came with some surprises:

Using dreamsmith

I used dreamsmith to fragment BSLSBS.bin and found the data stratified into effects, pages, and leds. The best part about using dreamsmith is that it uses the a1800-codec to convert the binary sound back into a .wav and I can immediately play it on my computer. When reading John-K's documentation, I was getting a bit worried about effects as opposed to audio. It seemed that there were two types of sounds: sound effects (which I thought were the non-narrative sounds that also play) and the "audio" (or the narrative reading of the book). If this were to be true, perhaps stitching a franken-cartridge would be more of a fine task than first assumed. How am I to figure out how to stitch small chunks of audio and effects together, slicing them perfectly for frame-perfect audio playback? LUCKILY, this is not the case. Effects seem quite irrelevant for playing a cartridge at this stage -- I will explain below. I am really glad I accepted the help (that was previously extended for a good while before now anyway...) that John-K's dreamsmith affords me. I should of done this much earlier as opposed to the rough attempts to do it from scratch (albeit a good learning experience; but was it worth the tears?).

What is Segment 2.1 and Segment 2.2?

It can be noted that the binary for Segments 2.1 and 2.2 follow the same pattern as all the Regions:
[00 00 00 00] [80 3E] ... where the '00' bytes are the length of the data payload of the audio.

This would suggest that it's audio of some kind too, right? My initial thoughts were: I don't hear anything beyond 12 frames, so perhaps they are not. Maybe they must be there for integrity checks. Since it was conserved I did not want to touch it. That would mean its important! Well, well, well...

dreamsmith fragmentation of a cartridge converts these Segments to audio. And they play audio that is never used! It may be just a waste of space, as it may have been for debugging purposes...

Segment 2.1 is a unique narrator (honestly sounds like an AI voice -- re: YouTube AI slop for kids). Over 4.6 seconds, it simply says the following: "Hello! I can't wait to listen to some stories with you."

Segment 2.2 is the same narrator as in Segment 2.1. Over 5.5 seconds, it simply says the following: "Thanks for listening to the stories with me today. I hope we see each other again soon."

I really hope I can cut down these Segments to just a header and the smallest bit of silent audio data.

What is Segment 4 (Regions 13-24)?

Like Segments 2.1 and 2.2, this is also a narrator (a different one from Segment 2) that simply comprises of a short 'beep' (Region 13), the spoken letter 'V' (Region 14), and the spoken numbers 0 through 9 (Regions 15-24). These are the "effects" mentioned in John-K's documentation. These too, it seems, are debug audio that are irrelevant to the playing of our cartridge data. I have not recalled any time where these were played. Could we cut out Regions 13-24 entirely? What would the Segment 1 pointers be? Would it just be the same address for each Region? In the least, I assume that a minimal packet of a1800-codec audio could be given, which would require the header for each Region still.

Using dreamprojector as a visualizer

I also used dreamprojector which showed a lack of lights for a few frames when visualizing BSLSBS. I freaked out thinking either the tool was broken or I royally corrupted my franken-cartridge I tried to modify. I wonder if the previous led data is pulled from whatever it was last time, and it carries over. So the displayed changes in dreamprojector is actually the anticipated update of the led, and (0,0,0) is just no change. I may be wrong about this and I actually messed up the BSLSBS binary.

Upon a further investigation (using dreamprojector on the unedited version of BSLSBS in /Binary/MyBins/DoubleQuint/BigSharkLittleSharkBabyShark/+BSLSBS-GS/BSLSBSBaseF.bin) it seems that the first frame erroneously does not display leds, nor does the third frame. These should have lights attached to them. I will have to see why this is the case. The Saggy Baggy Elephant had lights display for almost each frame too, save frame seven and ten. Looking at preliminary_data.md again to match the colour changes, I see that there are supposed to be different colours for each frame of BSLSBS. I am unsure what to conclude from this.

An argument against Segment 1's first 4 bytes being the number of effects and sounds

Each cartridge has the exact same structure, all contained within the 12 frames + 12 useless frames. When using dreamsmith to fragment Saggy Baggy Elephant, I see that it expected 0 "effects", but generated 24 "audio"s. Upon checking the contents of the last few audio files I can say that they are identical to the "effects" files found in BSLSBS. This would be more evidence that the first 4 bytes of Segment 1 are useless as shown by a knockout test (replacing them with '00' bytes, and test-playing the modded cartridge. It still works with these missing magic numbers).

An updated estimate of maximum audio we can shove in here

Assumptions:

• Delete Segments 2.1, 2.2, and 4
• Delete all light tables
• Retain all Segment 1 pointers

1048576 bytes = full capacity Whole Segment 1 = 108 bytes Header for any frame = 6 bytes 1 byte = 2 milliseconds of decoded audio

$1048576-108=1048468$

$1048468*2=2096936$

Theoretically, there are 2096936 milliseconds available.

• = 2096.936 seconds
• $s/60$ = 34.9489333333 minutes

This is about three times my initial estimate!

A more conservative estimate (assuming we need headers + 1 chunk of audio data for all existing Segments and Regions) would be the following:

The minimal chunk of audio I would have to insert would be 10 bytes according to John-K's format.md.

$1048576-108=1048468$

$1048468-(2+12+12)*(6+10)=1048052$

• 1048.052 seconds
• $s/60$ = 17.4675333333 minutes

This still surpasses initial estimates!

Next steps

• I will investigate why the custom audio injection seems to mess with the accompanying lights.
• I will determine what silence would look like in a1800-encoded audio
• I will try to inject the least-possible audio in these garbage sections (Segments 2.1, 2.2, & 4)

⟵ Older	Table of Contents	Newer ⟶