The past few days saw me have a minor revelation regarding some of the floppy disks in my possession.
For a while now, I had bought some floppy disks for the Emu SP-12 drum machine, in addition to my Emulator 1 collection. The relatively easy part was dumping most of them to my computer via Kryoflux (some wouldn't read, so I ordered another 5.25" floppy drive in case it was that the jackets were too thin for the drive I used, and a small few others had some bad sectors due likely to their age)
Problem with the new images: there are currently no tools that support them. Even EMXP, as useful as it was for decoding my Emulator 1 floppies, does not officially support the SP-12 yet beyond MIDI dumps and the files that are supposed to be stored on the disks. Therefore, long story short, I had no choice but to try to decode myself.
For a while now, I had bought some floppy disks for the Emu SP-12 drum machine, in addition to my Emulator 1 collection. The relatively easy part was dumping most of them to my computer via Kryoflux (some wouldn't read, so I ordered another 5.25" floppy drive in case it was that the jackets were too thin for the drive I used, and a small few others had some bad sectors due likely to their age)
Problem with the new images: there are currently no tools that support them. Even EMXP, as useful as it was for decoding my Emulator 1 floppies, does not officially support the SP-12 yet beyond MIDI dumps and the files that are supposed to be stored on the disks. Therefore, long story short, I had no choice but to try to decode myself.
Since the floppy drive meant for the SP-12 is a Commodore 1541, I naturally read up on the Commodore 64 disk format. It turns out that despite it holding different data, the original SP-12 floppy disks conform to the Commodore 64 format in that the first sector of track 18, shown in the hex editor above at address 0x16500, does have some metadata about the disk layout, complete with a filename for the disk ("SP12", at address 0x16590). Alas, that seems to be where the similarities end.
Out of frustration a few days ago, I tried loading the images as raw data in Audacity. Surprisingly, it turned out there was a tiny bit of conventional audio with the right import settings, but with lots of noise added. This motivated me to read up on the SP12 ROM decoder tool by R-Massive, which, thankfully, included some of their own technical findings on the page. Having learned that the 12-bit data for the ROM's is actually a combination of three 8-bit ROMs at a time (1 for the least significant bits, and 2 for the rest), I decided to see if the same logic applied to the SP-12 disk images, so I wrote up a Python script that separated one out of every three bytes from the rest. Then I retried Audacity, specifying 8-bit unsigned, little endian when importing as raw data, and long behold, it looked significantly more like the audio that should've been there:
Out of frustration a few days ago, I tried loading the images as raw data in Audacity. Surprisingly, it turned out there was a tiny bit of conventional audio with the right import settings, but with lots of noise added. This motivated me to read up on the SP12 ROM decoder tool by R-Massive, which, thankfully, included some of their own technical findings on the page. Having learned that the 12-bit data for the ROM's is actually a combination of three 8-bit ROMs at a time (1 for the least significant bits, and 2 for the rest), I decided to see if the same logic applied to the SP-12 disk images, so I wrote up a Python script that separated one out of every three bytes from the rest. Then I retried Audacity, specifying 8-bit unsigned, little endian when importing as raw data, and long behold, it looked significantly more like the audio that should've been there:
Since some bits were discarded for this test, I realized I had to re-encode them in later, but thanks to R-Massive's tool, that was the easy part. The harder part, as shown above, was that the audio was split up into seemingly random chunks of 256 bytes (the number of bytes in the sectors) per track. This took a lot of effort to attempt to rearrange them into the correct format with Python, but I did eventually refine the script so that that issue was fixed.
And with that, I successfully made an extraction of the sounds stored on some of the floppies! The script as it is now separates the disk into six files that should be fully compatible with R-Massive's ROM decoding tool, though I had to add a few bytes at the end to keep the tool from throwing a filesize error. Note that this is only good for extracting the raw samples: I have no knowledge of the metadata or how to use it to slice up the audio accordingly, though hopefully Esynthesist, the creator of EMXP, will be able to address that much later.
Regardless, I hesitate to share the script immediately in case either entity is interested in the decoding work I put in, so I'll be reaching out to them with my finds. If neither of them express interest before SP-12 disk support is implemented in EMXP, then I'll share the script then.
Thanks everyone for reading!
And with that, I successfully made an extraction of the sounds stored on some of the floppies! The script as it is now separates the disk into six files that should be fully compatible with R-Massive's ROM decoding tool, though I had to add a few bytes at the end to keep the tool from throwing a filesize error. Note that this is only good for extracting the raw samples: I have no knowledge of the metadata or how to use it to slice up the audio accordingly, though hopefully Esynthesist, the creator of EMXP, will be able to address that much later.
Regardless, I hesitate to share the script immediately in case either entity is interested in the decoding work I put in, so I'll be reaching out to them with my finds. If neither of them express interest before SP-12 disk support is implemented in EMXP, then I'll share the script then.
Thanks everyone for reading!
RSS Feed