Computer Laboratory

2021-2022 Part II Project Suggestions by Frank Stajano

The project ideas below are © Frank Stajano. They turn into project proposals with a substantial contribution from a suitable candidate in the context of a constructive discussion and negotiation. You are expected to have done some background research on the topic before discussing it with me. In particular, you have to flesh out these ideas by answering two important questions: (1) what’s the challenging computer science bit you’re going to solve? (2) how are you going to evaluate the project? Watch this video of mine for advice on choosing a great project, and this other one for advice on how to write it up. Note that a standard condition of me offering these projects is that all work performed (code and write-up) be released as open source.

I generally supervise 0 or 1 projects per year, exceptionally 2, from people who got a First in Parts Ia/Ib. A number of my supervisees received first class marks for their projects. One even became a professor many years later (I am proud of that but I admit the correlation between the two events is rather tenuous). Supervising an undergraduate project is also a way to look for great students whom I might like to supervise for a PhD, and you are welcome to treat this experience in the same way---would you like me to be your supervisor for a much more ambitious project? (If you are thinking about that one day, I produced a video on doing a PhD as well.)


A few decades ago, hifi nerds like yours truly would lust after some magnificent and totally unaffordable cassette decks with extremely elaborate mechanics and electronics to overcome the inherent limitations of the cassette medium (unstable time base, noise and non-linearities). There were also “computer cassette decks” that did very advanced things such as letting you skip ahead a few tracks... Nowadays you could do all that and more with a Raspberry Pi Zero. So, well, why don’t you? Source an old, non-working tape deck for a few pounds, gut its insides and replace them with a Raspberry Pi (a Pico if you’re super cool) and make it work again as a digital recorder. The keys, LEDs, vu-meters, audio inputs and outputs should all work. Bonus points for hacking SD cards into audiocassettes so that you can insert a physical (hacked) cassette in the deck and have the music from it play. This project requires a modest amount of hardware hacking but the important constraint is that, once it’s done, it must all work like an appliance, WITHOUT A COMPUTER---no ssh’ing into the Pi to make it work, and ideally no 30-second delay when you press the on button.


Build a library and toolkit that allows a non-computer-scientist hifi nerd to recreate the look-and-feel of any vintage cassette deck given a high-resolution photograph of the front panel and the instruction manual. The user must define what the parts of the picture are (this is the play button, this is the record button, this is the -8 dB LED segment of the left VU meter, this is the -6 dB one and so forth) and what they do, using some suitable description language invented by you, and then your thing should just work, including actually recording and playing music. Some bits won’t have any effect (selection of tape class, fine tuning of bias and azimuth etc) and some elaborate “tape transport” functions can be left as an optional extra, but it would be great to have working replicas of a few famous decks such as the top-class Nakamichi, Tandberg, Aiwa, Pioneer, Sony and so on. This is purely a software project, with a substantial software engineering component and some amount of user interface design, to be programmed on a tablet.


The iphone’s in-built music player is a pain because it only works if you let Apple manage all your music with its own software. This can be a delight for some and a pain for others, especially those who like to manage their own music library on their own terms (e.g. with FLAC, sensible names etc). In this project you build your own music player on the iphone that syncs with the user’s audio library in some useful and non-annoying way (defining which is part of your preliminary work) and then plays it, with controls that are friendly to a glove-wearing cyclist in British weather (you figure that one out).


CD-ROM drives are very cheap nowadays, of the order of ten pounds, so it is conceivable you could assemble a bank of enough of them (10? 20? 30?) that, assuming they all work as soon as you insert the disc, by the time you’ve finished loading a CD in the last one, the first one has already finished ripping and can be loaded with a new disc. This would then be a CD-ripping machine that can digitize your whole collection to FLAC in just the time it takes to put each CD in its drive. For extra credit this should work without a (visible) computer, just as an appliance. You are allowed and encouraged to reuse parts of other open source ripping programs. Your back-end must be smarter than usual in order to allow for no-interaction operation, particularly when doesn’t know about one of your CDs or has several options. Stupid programs stop the ripping and ask you to choose one of the options. Your program should be smart enough to store the CDs under their ID and download the relevant gnudb cards in source format, and match them up with a database in a way that allows corrections and re-linking after the fact. Hard links could be used to give the directories and tracks sensible names on the file system, even though each CD image is still identified primarily by its ID.


MythTV is an open-source digital video recorder. It's brilliant, but it depends rather unhealthily on a central database of metadata (conceptually similar to the dreaded Windows Registry or the equally dreaded iTunes) without which its archive of recorded files becomes practically unusable: the database contains the names and dates of the shows, the cutlists describing the parts you edited out (commercials and head/tail) and so forth. This makes the system rather unstable because, if the database gets corrupted, then your terabytes of thousands of hours of recorded video become practically unusable. If you get fed up and reinstall from zero on a new hard disk, it's practically impossible to merge two video archives. In this project you will address this problem by first providing an export and mergeback facility for the video archive (the current backup/restore does not support merging) and then, more substantially, by redesigning the architecture so that each video recording is atomically associated with its own metadata (e.g. by introducing a new file type consisting of an archive with both the video and its metadata).


A number of banking-related websites have adopted the misguided practice of asking you, besides your password, a random selection of characters from a second password. This generally defeats the in-browser password manager. Since it is objectively impossible to remember a different “second password” for every website, this practice forces you into some less secure alternative and therefore ultimately reduces security. In this project you will build an alternative password manager, possibly in the form of a browser plugin, that is able to cope with those types of login at minimal hassle to the user. You will develop heuristics for parsing the login web page to figure out which three characters are being requested (a suggestion might be a “learning mode” in which you collect two or three instances of the page, so that by comparing differences you can find out where to read which characters are being asked and where to write them) and you will investigate and implement the available alternatives for storing the password as securely as possible.


The todo.txt format is a simple human-readable plaintext-based format for storing a todo list. In this project you will write todo.txt clients for Emacs (so you'll learn Lisp) and iPhone (so you'll teach yourself Swift) and find some simple way for the two to share the same file. Conflict resolution in case of simultaneous edits, apple watch client, and privacy protection from server-side snooping, are left as optional extras. If you complete the core work (emacs, iphone and sync) by Xmas to a good standard, I'm happy to lend you an apple watch during Lent to work on the relevant optional extra task.