How do I extract the program from the Radiohead "Nude" tribute by James Houston?

Question

One of my favorite videos ever is a tribute to Radiohead "Nude" by James Houston. I have never seen the program in the video available to download, so I've just made an attempt to extract it myself. Here are the steps I tried:

• Grabbed the audio using youtube-dl by specifying the "best audio" mode, not downloading the video.
• Trimmed the audio file to the ZX-Spectrum blocks using Audacity.
• Mixed the stereo channel into a mono (Audacity).
• Resampled the audio file to 44100 using sox (I probably did something wrong but I couldn't save the resampled audio with Audacity).
• Normalized the audio to 0dB (Audacity; there's a click in the audio so the normalization effect gained not really much -- is it a blocker?).
• Converted the result audio to a TZX file using tzxwave from the tzxtools toolkit.

The program in the extracted TZX file does not produce the exact tune that can be heard in the video, so I definitely did some mistakes in the middle (no "R Tape loading error" though). Here is what I was able to extract (gzipped and in base64):

begin-base64 644 nude.tzx.gz
H4sIAAAAAAAAA+1azYtcWRU/7737bteHTxrKCd0idE8SmyGTQYxMphjQRmoR
pBAbfBBLRAhTQcxCn4IObspGqKXQq15nWbuB2rgQ0exqdoL1B9TChZvggJtI
ero9n/fdV9U9xCgaZbII3ff97vk+5557T3/3O+WD6uHrn08+t/2XrAcA7z34
6Q8e7NO/m9CBm/A9XD+AC+jsw8dfufPO3Xc+C3DxS3j3r9evf/Du3/9AS31c
gmMovi0ksh/9bPxw/+c//uF7D397E9eP/4jrv7t58bcvA7x+cX73tRt3j792
/vTe0+8/3zm/de948pv9nRuT84s39s/P33gt+fji6S9uTPzv8f+dP1+/d/zV
959/eOMG/vD8ww/+dL5z/o1j2OpDC6ANsI2MS0gAWh1IH0GGix1wv4YcoNMp
YAbpCtoe3Bl0fJKegZuhTjtQQTolZKfjXYUrPdeFPEFMAY8grcBNhUI7ncne
L8girshew89hAq0CENYuwC14V3EAQ5ZnxcI8Y2S75z6CPCv4Vw99SA/BlcLl
wE2QlHcD/DlJB8C/pjCAdMLCK4V2OmSCE97lM+SiAKKMgCwtY0CClmkCctrS
xDRZ5Pp1wF9bHiVEkZAOydbq4nZeyfjXNkloK6liMrZSIuZ1J0K2C4eAetGK
GjZrAjK3jxL6NQzRF9i+Ksh4gw0U5sptN+i56S75RZGeBFM6CWk9DbxyuMPG
H2qQpH1wh7vkkTLYwZPpnkGWQLst1ivSjyDLzGVQ8FePpNAqSI0CrwuuT95E
Uuh9khAt043cSr+yW0sGjymc3DBDXkREnDtGdRKSZJy7kYdRQvgR48uEhEQ6
I6STwC0gyQcdXRxyMA96iKfYGyHeu2GhtqItFHXIiEgNjLUEqji9a7qbW8V6
JIx+yklOFoA+dXdpb8UEFdBTLSoBsOUFcA3ylI0/YGVHnrewnVVx2dJKx6Is
ss4plroFG+pL/HNW2xazst2CMWBSk48Q73M0iCZ7m0MX0/mQ2Y15Sz/nT6lm
65hLxIDz95CZYnEokuhr7oYJ1RCRcJS7sp2W7K9O0ChJr0GWqgwcGzkRHGot
QgMasituCrFN1hvGls80pMFjHpHjWoFL1t4SmHeHlrmHrKwZNuxVjx9SiQjb
668LkdbDNUhSwCRGfMa1lMpX2oMuJAmIUrzLtyACdykpmKxvIMWbDIsxuJd2
RRiitiBSSuQapIuaqVsUTSIvx6VAFp/SfyH6z3g7sjijY1SKHnGR9TOKDT2z
YsAZBcYmRhnVmAIekzDyNX2MAvTgiHa5x8hdv6ZHXEt5nTHgjphj/VXwRr/G
9OAkUOuhUiThCeILWadoB6n8HksB9Qmegp8xwKnk01nBlvFaxkEtIxjKa4L1
mFTBi15TxlPKUKkh+nxaNbZgumV1csnJFQCUWUV6n/mOjNoTPehhBOmTGImk
2rDiBAzgUYEwVKdGrvw6hvsKhU0Cfa8FHLytFO5XdP7yr71AxJqEYpPCBibi
Mt1L56EuFYisK6TxlaAlCisTdeVplwTwXD1lGyP8NOCFb+rmOUwNP2cjzLlt
QJvPueIFIiuqfgQI1WwVlz4Stcm3zq+mqBw2/3Vpl58o7dJYL19Y2rBljlsS
2rLkgwZ7p7lriL28Wuwli72MxF7+T4m9qMsXRj4lOFDpI0YzYVRQz++pttTt
ogAmdgXAdJgxZlVjsLvQ4F+E3lILIO1dmJXqUinUCtXUs624DGKpDGcxKc4m
kvBwR74O48em3ZHZarYWkCSngldCZ9cy10sJlV0k2EpbX9ouFZXqrSc7L/g4
mDIdLXF6ymPrpRxnzG7cxEzJLwoYs0dChZwz/mRD8inbcLYRRSJSwC9qvlRp
Z6+SzPebMj9p4tHU9zlTQsyHCv+E8VJ753HY+/SUa8VpjDdkVSNJvMrSIRTz
Uw7mylrEwG7BeESe8jqL7eaRwCvLiFdWVDx9bluavAm547shtvq35f6eaPv0
JmROzlDt4dc63pBlG4WIz8eVUmAF2dencbuliYayqdgCnnE56q6Jx9QWFiFG
8P9DCyp94RjVRwlr/Ph+La5U8DOWnNs/SgrCN+qV0tECSz1tTSQU2yoqBVaK
qRos7JFkFt306S0o15v+zG+Iyiwem1KBxTxicZVS88uU8tboNpVCOf8pddZU
UO9cqUUmh4jRzIiRVvhP8+XV0uLl8+XfFFr/gUxhOfnB8/KUca9AylyuTg3b
b7pmf8M1J5epEFrTkygIPfNiCto2VNp76Bm32V1Uze4icD9RLhty8sN4aJym
lwXb/pp3kitUy/8l1cam2kyPe22oBFOx8LMN4U8vE34WIc1r2ksvCmpu+fig
eOZF+bV25aLelerNS2Qe1jVhzKJqwva0T8b+fKz9udUTv7ZFGkUyyzpSnxr4
KxmnuSvCS2UA7e1RfdrbRfH26koy9rVZuj5a7/HNi705trq0jGzYfREiu4FI
BBBqexvVbBPjNzGiXW2Kpd4vNuywYb1gjUX9JEUUzsRle/IkFaKxCfDNr7t8
GuqbBgu5574Oee71lKSfeyyzt2OCnv3lYcdisse5VsgUg960x5p9smIvwz7E
sD6+MR1efFkKX4T0LZo7sOI97YcLcG8VuK5q9t+nwrs0y/uicfz56Li54viL
33sbcT6w0dvIRm+Sj60e3Z276jVs4O1GX+iz5JVxUlwSJyO7kTXop3SRJ+E7
StPiUyYmipcXp06bLxRZpA7b0ILzErF5YmVDkB4NQTZ2RVMSpa9zvSFPuIZB
qYzpR6oFUYdateyQLWhGaSfjRmAXdeiGZoCHWaTp0CSZMMcz7yZFLcmKFm1O
lFD59V23KvT+O2OakghchzX1toDjHzpbzVIs+bgO4/5nEyPnZqduhBqkhGmn
iQxVPTzyHJkpdIp3ipdQtCd1rUeIPNVQ9NEV0uJHqcmLkC7m+sY7Ml5o2yoK
uUMegVX6SKIjuTBqkWogoYVWHYWNbSKy4GQZgMJeiDsH+RTqt5cqKozh1XRg
cyV5UiDB0kgwJxwbZIfeRNKxpsz7dNzmCcyTyoQEKOXRIycYR0XdB1bW9mBo
hXn02E7Vyk7VmSlb780NUxBeiqoatkUwm03rYf2JjMgsISmsJNaxpPj1TlUa
ldDdQUVHtr6wVZyD9mCOIrlp1422XZVxDCRutuPKjhuF1G5LYETRktXeVL22
gh9tJYvxUWgldVCVhqwdmumQt7Q47CeuzPitnsyiowHJ64VN+kpzQRnN/cuo
Mb5l4cQj77VLdAgMKizEOqGRdLg5miTRrHyr/ksGVLxxx2Qbhrb5jt436zkL
YdrQbxa0WNS+uVieZEuUmX0nruzzRNvb/N03xvdhDtWgo0N8oyMx0FdlqQ4P
aKxM2tE5m+vUpm/zmrGshxVGEiZvrjPyjuUsdbNF3TPY3zxo66tm2RZf2PnO
LpM2WAGp4ksvE/+IlDYJpJFsMX1rpqWUNTkvDsKfN7CQRW2WcRHqMLaClEfy
qSoUP+vxite/f9ALl6+fryVPV2v3U0bK1ThceOVxL4xINOt/Qn+BMzngP7Ox
n9+G9B6KN6Q4/9aQf+6pcz8D7l6BK0qkvJ0OD2iXSPu2PhLSp0d7II/tuf2l
EMi7YoFZpmdHGR1J+aH8iVEH4AK++Q/XMM5VJyUAAA==
====

What were my mistakes trying to extract the program in 100% accuracy?

---

I forgot to mention that I only converted the "best audio" youtube-dl was able to download from OPUS to WAV in order to process that WAV file, not the OPUS one. I'm still not sure about the entire audio "pipeline" configuration before decoding the audio into a TZX file. So, I'm thinking of two ways:

• either my audio processing "pipeline" is wrong so that tzxwave extracts what it actually can (+ there are some more options in tzxwave that I didn't experiment with);
• or the video features a perfect (despite lossy back to the early YouTube days) audio that may provide a real 100% working program, but the featured program generates a tune that slightly differs from what can be heard in the video by design (no intention to share a program track source by the author, copyright grounds, whatever). Why? No idea. tzxwave might do some corrections fixing "R Tape loading error" itself in certain cases, but I'm not sure about this too because I had tape loading errors multiple times before getting an audible result I shared with PasteBin.

Answer 1

First, many thanks for the great question. This may well be my favourite retrocomputing video of them all, so I contemplated having a look at the executable for a while myself. So, this is what I did:

1. To download the audio, I went to the same YouTube video and used 4K Video Downloader (mainly because it clearly shows which audio is the original one, so that I can avoid an extra re-recompression stage).

2. I trimmed the relevant audio using Audacity, just like you did. The contents of the right channel has a large DC offset, so I assumed that the left channel must be closer to the original signal:

3. The quality of the signal is pretty low, but to a significant extent this is due to its very low amplitude. In the areas of pilot tone the signal is quite clean:

4. At the same time, where the actual data is recorded, the quality of signal is pretty poor, with rectangular shapes strongly distorted, I'd guess mostly due to the .mp3 compression:

5. Having said that, I think it is also clear that signals are distinguishable, with the bits in my screenshot being 0, 1, 0, 0, 1, 1, ... etc. This gives us hope that something can be recovered here.

6. There are many programs created for recovery of tape data from audio files. One of the more recent ones is called TapeRecover, written by Andrei Titov (use Chrome to translate the page from Russian). I used this specific program because several people mentioned to me that it works well. It requires a very particular kind of input file: 48 kHz mono .wav file. Transcoding from one discretization frequency to another is not a particularly great step to make, but I had no choice here.

7. As we might have expected, the program struggled to recover the data from our original file. So, I prepared another one, with +40 dB amplification and hard clipping, to get closer to the shape these signals were supposed to have originally. This is what the resulting data looked like:

8. This turned out to be sufficient to recover the original data, which you can download here: http://introspec.retropc.ru/other/james%20houston%20-%20big%20ideas.tap. I verified it and can see that the binary is 100% the same as the one you recovered, so this is reassuring.

Of course, I couldn't just stop here and had a look at what it does. It turns out that the file plays music on AY8912 chip that was installed into every variation of ZX Spectrum with 128K of memory. The actual driver that plays music is extremely primitive; technically, it is a simple .psg-like player. .psg file format describes the values that have to be written into the sound chip during each interrupt cycle (which happen at a frequency close to 50 Hz). Since the information is stored as register values, the original editable file cannot be easily recovered. This is the disassembly of the player in case you are interested:

; this player is, effectively, the v-blank interrupt handler.
; it is automatically called approximately 50 times per second

    ld hl,(CurPos)      ; current position in the track

FrameLoop:
    ld a,(hl) : or a : jr nz,SkipFrame

        inc hl : ld a,(hl)
        cp #FF : jr z,CommandFF     ; end-of-track marker
        cp #FE : jr z,CommandFE

        ; the actual data is a pair of two numbers:
        ; a register number...
        ld bc,#FFFD : out (c),a
        ; ...followed by the register value
        inc hl : ld a,(hl)
        ld b,#BF : out (c),a : inc hl
        jr FrameLoop

SkipFrame:  ; non-zero bytes are decremented until we get to zero,
    ; i.e. they define a wait time in frames.
    ; this means in particular, that the data gets destroyed
    ; during playback (repeated playback is not possible!)
    ld (CurPos),hl
    dec a : ld (hl),a
    ei : ret

CommandFE:  ; the purpose of this command is not clear
    ; (it simply silently skips some bytes)
    ; luckily, it is never actually used
    inc hl : inc hl : ld (CurPos),hl
    ei : ret

CommandFF:  ; at the end of the track colour
    ; the border black and freeze
    xor a : out (254),a
    jr $

CurPos:     dw MusicPSG     ; current position in the track

MusicPSG:   ; music data follows here
    ; (32841-42169,9329)

However, listening to the tune it is clear that not only the main "voice" of the melody is coming out. I know that your assumption has been that it must mean that your capture has been somehow incorrect. However, I do not think that the chances for this are all that high. We used two different methods and recovered identical results. In addition, somewhat tuneless sounds you can hear – they may well be tuneless because they may be driving devices that introduce further distortions (i.e. detuning may be necessary to get them in tune).

In my opinion, all voices you can hear in the video – rhythm section on the printer, base line on the scanner (with the only exception of vocals) – are originally driven by ZX Spectrum's sound chip. My guess is that sound channels which would normally be joined together and outputted onto the speaker have been separated and used to drive other devices.

Last but not least, do not forget that the video itself has been edited and processed. Just as a somewhat relevant anecdote, I was the main coder for the MMCM's chiptune album: The Blossoming Years. Track 24 of this album is an electronic version of the album, effectively, tape recording of the demo program for 48K ZX Spectrum with an external AY interface. The album was released on the same day as the accompanying demo. However, the demo was not fully ready at the time when the album was being mastered, so as the result, the version of the demo that you will find by recovering Track 24 is not the same as the demo that was actually released.

UPDATE (18/04/2020)

Well, I really liked the theory that ZX Spectrum's AY chip was driving all these devices in the video, but sadly it is not the case. My checks of the music data seemed to indicate that instruments "jump" from channel to channel. This tends to happen when the track is not hand-made, but auto-generated from another format, most likely MIDI. Hence, I did a search for MIDI converters for playing tunes back on ZX Spectrum and found this thread on World of Spectrum: midi2ay 0.1. (The program is no longer available from Geocities, but Archive.org still has it.) The converter takes a .mid file and generates a corresponding .tap image automatically. In fact, the source of the assembly re-player there is also included with the program, from which you can immediately see that it is 100% identical to the re-player we downloaded.

Overall, then, my conclusion is as follows: the music was made elsewhere. The converted MIDI file loaded into ZX Spectrum and apparently playing in the video is highly unlikely to actually participate in the final mix.