Diversi-Tune Apple IIGS demo video

Download the video

Contents of the video

The video shows the following:

An emulated Apple IIGS (described below) booting
The startup screen of ProDOS 8, the operating system used by Diversi-Tune
The Diversi-Tune loading screen
Diversi-Tune's Auto-Play mode, in which it sequentially plays the songs on the disk immediately after booting
The intro composition: This is a brief piano piece. While playing this piece, Diversi-Tune shows the Key Velocity display. This display shows the program name, the song title, a piano keyboard, the ever-present status bar, and an animation of vertical lines with varying heights, indicating which keys are being pressed and the velocities of those keypresses. The poster frame for this video shows a moment roughly 2 seconds into this playback.
The song "You're a Grand Old Flag": This arrangement features piano, drums, and an organ for the melody line. While playing this piece, Diversi-Tune shows the Words (Large) display, which goes through the song lyrics, showing a bouncing-ball animation over the currently sung word. This is similar to modern karaoke displays.
An extended piece called "IMPROV1.BILL": This is an up-tempo piece with multiple piano tracks, an organ track, and drum tracks on the left and right channels. The name suggests that it was performed by Bill Basham himself. Diversi-Tune again shows the Key Velocity display for this piece.

Diversi-Tune would have continued to play the rest of the songs on the disk, but I stopped the emulator just after the end of IMPROV1.BILL.

How I made this video

I (Matt Campbell) made this video using MAME, configured to emulate a ROM version 01 Apple IIGS at the original speed, running Diversi-Tune from an emulated 3.5-inch disk. I'm aware that the emulated sounds of the 3.5-inch disk drive aren't entirely authentic, particularly when seeking across multiple tracks, but they still represent the original experience more accurately than, say, running from an emulated hard disk at modern read speeds. More importantly, though, MAME's emulation of the Ensoniq ES5503 chip in the Apple IIGS is the best I've yet heard, including stereo output and accurate reproduction of high-pitched notes.

Technical details about video encoding

Because it's relatively rare to independently encode and self-host a video as I write this in late 2024, I'll provide details about how I did it for this video. As usual for video encoding, I depended heavily on FFmpeg.

First, I used MAME's own video output feature to create the uncompressed video, with this command-line option:

-aviwrite divtune.avi

Note that videos produced from an emulated Apple IIGS using this option look very long, because the Apple IIGS didn't use square pixels. MAME does have a -snapsize option for correcting this, and I used that for a previous version of this video. But for the current version, I decided to do a truly lossless capture from MAME and scale the video later using FFmpeg.

Uncompressed AVI files like the one produced by the -aviwrite option are very large. This one was roughly 12 GB. To avoid keeping this huge file longer than needed, and to reduce the I/O or memory demands of future encoding operations, I next produced a losslessly compressed version with this FFmpeg command:

ffmpeg -i divtune.avi -c:v ffv1 -level 3 -c:a flac divtune_lossless.mkv

According to the FFmpeg wiki page on encoding to FFV1, FFv1 version 3 is strictly better than version 1. That's why I used the -level 3 option.

Next, I produced a scaled version of the video that looks right on modern displays, to serve as the input for later steps (including the upload to YouTube), with this FFmpeg command:

ffmpeg -i divtune_lossless.mkv -vf scale=704:528 -c:v ffv1 -level 3 -c:a flac divtune_scaled.mkv

I derived the new size, 704x528, as follows: The original size was 704x228, but the aspect ratio of the Apple IIGS's display was actually 4:3. So, to avoid averaging or dropping any pixels in the longer dimension (the horizontal one), I divided 704 by 4 and multiplied by 3, yielding 528.

Once I had the scaled video, I decided to encode it in two formats for distribution on this site, along with the upload to YouTube:

WebM, using the excellent Opus codec for audio and VP9 for video: This format uses exclusively patent-free codecs, making it suitable for playback on computers running exclusively free and open-source software with no risk of violating patents. I encoded this version with this sequence of two FFmpeg commands:

ffmpeg -i divtune_scaled.mkv -c:v libvpx-vp9 -b:v 0 -crf 15 -deadline best -pix_fmt yuv420p -pass 1 -an -f null /dev/null && \ ffmpeg -i divtune_scaled.mkv -c:v libvpx-vp9 -b:v 0 -crf 15 -deadline best -pix_fmt yuv420p -pass 2 -c:a libopus -b:a 160k divtune.webm

The FFmpeg wiki page on encoding to VP9 recommends two-pass encoding for optimal quality and file size. A CRF of 15 is the minimum recommended by that page; a lower CRF means higher quality.

For added compatibility, this command converts the video to the yuv420p pixel format, from its original RGB format. This tweak proved necessary for correct playback in the Media Player app on Windows 11.

I decided on the bit rate for the Opus audio stream as follows: The FFmpeg wiki page on high-quality audio encoding says that with Opus, a bit rate of 160 Kbps or more is required for real transparency. Meanwhile, the Xiph wiki page on recommended Opus settings says that for stereo music, 128 Kbps is pretty much transparent. (Note: Xiph.org is the primary developer of Opus.) This matches what I previously read elsewhere about Opus enabling higher quality at a lower bit rate than MP3, Vorbis, or AAC. So I decided that, taking all of this into account, 160 Kbps, being just a bit over the top, was what I wanted.
MP4, using AAC for audio and H.264 for video: This format is compatible with all mainstream platforms. I encoded this version with this FFmpeg command:

ffmpeg -i divtune_scaled.mkv -c:v libx264 -crf 17 -preset veryslow -tune animation -pix_fmt yuv420p -c:a aac -b:a 256k -movflags +faststart divtune.mp4

As with the VP9 encoding command, a lower CRF means higher quality, as explained on the FFmpeg wiki page about encoding to H.264. According to that page, two-pass encoding is only necessary for targeting a specific file size, so I didn't use it. That page lists the -tune animation flag, which seems appropriate for computer-generated graphics. Also as explained on that page, -movflags +faststart optimizes the file for streaming. I again converted the video to the yuv420p pixel format; this was necessary for compatibility with both the Windows 11 Media Player app and Firefox. Finally, I decided to err on the high side for the AAC bit rate, since I knew from previous experience that FFmpeg's built-in AAC encoder isn't optimal (FFmpeg's wiki page on high-quality audio encoding confirms this); I decided to go with a somewhat larger file rather than set up the alternative AAC encoder.

Because this video contains exclusively low-resolution computer graphics with limited motion, both video files are exceptionally small, even with exaggerated audio bit rates and video quality settings; the WebM version is about 16 MB, and the MP4 version is about 18 MB.

Finally, to produce the poster image for the video, I used this FFmpeg command, with a timestamp obtained through trial and error:

ffmpeg -i divtune_scaled.mkv -ss 00:00:20.9 -vframes 1 divtune_poster.png