All but a few of our very youngest readers are surely familiar with music formats that rely on optical disks. When we say [RobSmithDev] made a MOD tracker that uses an optical disk, then, you might be forgiven for thinking he stuck a bunch of MOD files onto a CD– MOD files being a format of electronic music that was conceived of on the Commodore Amiga that is still used to this day. A dedicated MOD-CD player might be a fun project, but it’s not what [Rob] did; his project is far more impressive and impractical, as he’s come up with a way to encode the MOD files on paper for optical playback. This way the Amiga’s legacy can be preserved longer than the paltry thousand years promised by the optical M-disk format.
Zooming way, way in on the disk reveals that he’s actually printing the patterns of the MOD file row by row, just like you’d see playing it in a ‘tracker’ program. A MOD file, you see, does not encode music like a WAV or MP3. Rather, like with MIDI, it lists the notes the software reading the file — traditionally called a tracker — is to recreate. Unlike a MIDI file, though, you don’t have to store the same notes more than once: repeating sections are stored in patterns. So most of the disk is just a long list of hexadecimal numbers: several columns worth, one for each ‘voice’ or instrument playing in the song. Another difference with MIDI is that MOD files are self-contained in that they are supposed to contain the samples, which isn’t in evidence until you flip over the disk.
There’s no B-side to [Rob]’s album. Instead a QR-code like series of barcodes is used to encode the samples used in each track on the disk, as well as other information needed to recreate the MOD file, including metadata like title and artist, and the sequencing of the patterns on the front. Of course this means he needs two cameras on his physical mod player, one on each side, and steppers to slide them across the disk like a linear tracking turntable. The front is read via OCR of his modified Amiga “Topaz” font, while the rear holds the first 1084 bytes of the MOD file in a QR-inspired format [Rob] produced specifically for this project.
Unlike the last time we saw someone store music in QR codes, the more modest size requirements of modfiles — something that led to their use in keygens — means this player can store the music’s 8-bit sound samples without the OPUS compression [Rob] is using affecting fidelity. He’s working on another video to give the details of the player– as he works out the bugs, right now it can’t jump betwixt patterns on the disk as fast as some modfiles need–but we’re willing to hazard a guess he’s got a Raspberry Pi in there, and that it’s probably not running the Amiga-inspired AROS operating system.
I think a good way to think of mod tracker format is a combination of wave data and playback data (not midi but similar concept) is contained in one file.
The Super Nintendo SPC700, the OPL4 chip and the Roland CM-32L do support what used to be widely known as “wavetable” technology.
Same goes for GUS and the EMU 8000 synthesizer (SB32, AWE etc).
They can arrange, mix and alter short PCM samples.
It’s basically derived from a ROMpler, but with RAM. So a RAMpler, maybe?
PS: There’s also Adlib Tracker II that does a similar thing with FM instead of PCM (OPL3 chip).
When MOD equals WAV (VOC)+MIDI, then A2M equals FM+MIDI.
The there’s S3M format used by Amiga Trackers, which allows PCM samples and OPL3 commands in a tracker file.
PS: MOD Archive has a large collection of free MOD files.
In the 90s, MODs were also found on CD-ROMs.
Shareware CDs and MOD compilation CDs, for example.
Many smaller sized MODs uses looping point in a sample of one wave phase for the instrument. MIDI soundsets often do this too. I see SNES, PS1 and N64 music all as based on MOD paradigms, this meant coaxing SFX out of standard instrument sounds. Yoshis “scratch” fx sound comes to mind. Super Metroid showed us that we can even manage our memory budget for dialogue samples.
Normal printed paper is not going to outlast an M-disk. You need high quality archival paper and ink.
What if you punch holes in the paper instead?
Like a pianola roll?
Use two sheets of tinfoil, cut the pattern out with a laser or a plasma arc on a pen plotter, put a black sheet between them, then laminate it.
I wonder how small you could make it. It could be read with a laser, maybe a widened beam to reflect the image and shrink it or enlarge a section at a time or even a galvo to scan the entire disc rather than spinning it or having a moving camera.
Perhaps something similar to using photographic film to make microdots could be employed.
Perhaps, use a laser to make microscopic holes in an aluminized layer. Hmm, sounds familiar….
Microscopic pits in a thin metallic disc to optically store data? That’ll never catch on
The limitation is that regular copy paper is acidic with leftover chemicals from the pulp washing process, so it turns brown and brittle from oxidation over time. The process is called “slow fire”.
https://en.wikipedia.org/wiki/Slow_fire
Just looking at the photo, I have some severe reservations about the data format. Perhaps it’s equivalent to how data was stored in MOD files themselves, but the change in storage medium might necessitate a commensurate change in formatting.
There doesn’t appear to be any address labeling, or if there is it’s done using marker instructions that have to be interpreted, rather than predictable fixed-size intervals. That seems to imply that seeking within the data stream involves either:
Fragile relative motions (“begin the pattern located N instructions before/after this one”)
Absolute addressing relative to some start point (“begin the pattern at instruction X in the file”, or “…starting from marker Y”).
Which is fine when your data is stored in a random-access file, where you can jump directly to any point as long as you can compute its byte offset (or have an index of marker locations). It’s less fine when you’re dealing with a data stream that can only be read sequentially. Especially if losing your place requires costly position-finding, or if missing a particular instruction requires a full revolution to get back to it again.
There’s a reason both tape and optical disc favor very linear data streams. And why magnetic disks use large blocks and even larger caches, so that many reads — and ideally all repeated reads — just become memory accesses.
Grr. The comment parser strikes again. Pretend my third “paragraph” actually reads:
• Fragile relative motions (“begin the pattern located N instructions before/after this one”)
• Absolute addressing relative to some start point (“begin the pattern at instruction X in the file”, or “…starting from marker Y”).
Those are pertinent problems with using this format memory-less, but this is designed as a storage format.
Most MOD files are a few kB to a Mb so almost anything today has ample capacity to keep the whole file in memory for random access. My i7 laptop processor has 12 MB L3 cache, enough to keep a chonky MOD in SRAM without adverse effects to the OS or other tasks!
Hardware is awesome these days 🙂
Supposing you could read the code as fast as you can spin it, the disc would need to have a maximum seek time around 10 ms, which means the disc would have to be spinning at 6000 RPM to reach the next random position that is specified in the pattern list.
That said, it’s not possible to do it memory-less because you have to read the samples to memory in advance. Otherwise you’d be reading the pattern from one side of the disc and waiting for the disc to spin to the correct sample to start playing it from the other, but then it would be too late.
Back in the 90s, some soundcards would assist at playing MODs!
That helped a lot with 386 and 486 PCs.
The GUS, the AudioTrix Pro (OPL4 with sample RAM) and the EWS 64 had been supported by Mod4Win, for example.
It’s optional IDO filter could use an x87 FPU, even.
There also were players using the EMU 8000 synthesizer (Sound Blaster AWE).:
Impulse Tracker (DOS, has MMX optimized drivers), AWE32 modplayer v1.40, AMP for Windows v1.0b2 (WIN), AWEMod v0.20, Cubic Player etc.
More info: http://www.dcee.net/Files/Music/Player/
A downside of PC soundcards used to be that left and right channel were locked at same fidelity.
Both were running at 44,1 KHz and 16-Bit, for example.
They didn’t have several channels that could be aligned to left/center/right and also have individual sampling rates and Bit depth.
Why was that a downside? The other systems had variable bitrate and sampling frequency because they had more limited resources.
If you have multichannel audio, wouldn’t you want all of the channels be 44.1 kHz 16 bit instead of having to compromise with limited bandwidth?
How MOD files work, it’s not realistic to play it directly off the disc. It’s too slow. The MOD format contains a pattern list that specifies the order that you play the actual patterns, with repetition, so it can jump backwards and forwards in as little as 10-20 milliseconds depending on the minimum time frame. You have to scan the entire thing, OCR the code, and reconstruct the file in memory.
would have been any cool if it used actual spiral recording
This is madness, I love it!
Pulling off real time playback using a mechanism this slow could be a fun tribute to the demo scene ;)
I don’t think I ever even heard of the Amiga until long after it was obsolete. It could have even been here on HaD. And yet, I remember a friend showing me his mod collection on a DOS machine back in the 90s.
Hi, this site has on-line players: https://modarchive.org/
Though MOD4WIN has IDO and a fine 3D surround sound effect, I think.
It can be run on Windows 3.1x in DOSBox or on any later Windows (via VM, OTIVDM).
Sounds still better than OpenMPT or Winamp, IMHO.
On DOS, software such MOD Master XT, Impulse Tracker or MOD Play Pro 2.19b seems to be common. OS/2 has PowerMOD.
An Amiga emulation with NoiseTracker or ProTracker is also an experience. 😎
I forgot to mention: MODs were equally beloved on both Amiga and PC, to what I remember.
The famous “Guitar Slinger” file might some of you remember, too.
Nowadays, the IBM PC/XT community does care about MOD music, too.
Mod Master XT runs on an unmodified 4,77 MHz IBM PC, for example.
It supports EMS memory, Covox Speech Thing (resistor DAC on LPTx) but also Sound Blaster, PC speaker and so on. It’s fun!
Good old MODPlay Pro 2.19b can run on slow/fast ATs, too.
The sampling rate has to be adjusted accordingly, simply.
Other platforms have interesting MOD software, too, of course! Really recommend to try! 😃
Eventually the tracker software evolved with more capabilities and higher fidelity on the PC platform than what the Amigas could play hardware wise, so the MOD was left behind as a legacy format over the more advanced ones with the same idea.
Like any useful format, modfiles broke containment from their original system pretty quickly, but they started on the Amiga and boingballbros are never, ever going to let anyone forget it.
To reduce seek times, give it multiple read heads like the floppy drives on the Apple Lisa.
Maybe optimize placement of the blocks on the disk like they used to interleave sectors on a hard drive.
i’d rather have sheet music but it’s sobering to consider that what i think of as sheet music really only goes back about 300 years before it starts getting really weird (to me)
If you’re going to do something like this, then it need to be carried all the way to the end, not part-way like this. My suggestion to top this? First, encode the MOD file as an array of QR codes. Maximum size (Type 40) QR will give your about 2KB of data with maximum error-correction enabled. That’s basically the same size as a sector of data in a computer filesystem, so might as well treat it as such. One person has already gone this route:
https://hackaday.com/2024/09/12/back-up-your-data-on-paper-with-lots-of-qr-codes/
But wait, there’s more! :) Why stop at using paper? One could take these QR codes and using a highly precise laser, use that precision to shrink them waaaaay down, then engrave them into a durable form of ceramic. Why ceramic? Because the oldest known civilization that built cities, the Sumerians, had written language that only survived because it was written on clay tablets….ceramics. Now you not only have a fun way of archiving, you also have a very practical, long-lived form of data archival. And….someone already thought of this too:
https://www.techspot.com/news/111378-etching-world-smallest-qr-code-ceramic-pushes-data.html
optical music box
Saw this live at Kickstart a couple of weeks ago; it was truly a joy to behold. It’s great to see the tradition of slightly unhinged invention is alive and well. There is a school of thought of course that something like this will be far easier for academics to read in a couple of hundred years than electronic media as they will be nothing at that point to access a USB stick, optical disk or SATA drive. And maybe that’s already happening with the ‘death of physical media’…
This project is brilliant. I could watch it all day.
Seek times for backtracking probably can be improved by adding better index marks that can be sensed by a simple and fast optical sensor, not by the main camera, and giving some serious power to the main motor.
It could rip the disk apart but that would be a different problem to solve.