Reenigne blog

I was looking at the Windows file defragmentation APIs recently and it made me want to write something that uses them. Not a defragmentation tool necessarily (there are tons of those, and with the advent of SSDs they're becoming irrelevant anyway). But maybe something for visualizing how directories, files and other structures are laid out on disk. At one pixel per sector, this would make for a very big bitmap (~25000 pixels square for the 300Gb drive I use for data on my laptop and ~75000 pixels square for the largest 3Tb drives) so I'd have to make a way to zoom in and out of it. And how should I arrange the sectors within the bitmap? Row major is the obvious way, but a Hilbert space-filling curve might make for nicer results. For colouring, I was thinking of using the file extension as a hint (e.g. red for images, green for audio, blue for video, grey for binary code, yellow for text, black for free space) and maybe making the first sector of a file brighter or darker so that you can see if it's one big file or lots of small ones (though weighting the sector by how much of it is used would have a similar effect). I also want the program to show which sector of which file is under the mouse pointer.

I want to write a little program that takes two sound files and plays them at the same time, but which adds the position of the mouse's scroll wheel to one of the playback positions so that you
can easily twiddle the synchronization between them. I'm not sure that this would be particularly useful for anything, but I think it would be fun.

I couldn't find a good CRC32 checksum utility that properly handled wildcards, so I wrote my own.

I actually first wrote this a very long time ago using DJGPP. Actually, thinking about it it might have been the first 32-bit program I ever wrote. That compiler made it very easy because the command-line handling did the directory recursion for me (though it did mean you had to use the awkward syntax "crc32 ...\*" instead of "crc32 *" or "crc32 .". However, 64-bit Windows won't run DOS programs so it needed a rewrite, and once I had completed the filesystem routines I mentioned before it was just as easy.

This program is very handy for comparing contents of large directories across machines ("windiff -T" would copy everything across the network so would take forever.) Just run it on the two directories locally and compare the output.

I used to use this for weekly backups of my machine. It's nice to see exactly what's changed since the last backup so I can delete the backup files made by my text editor and anything else I didn't really mean to keep. Nowadays I use rsync to a Linux machine which amounts to something very similar but more automatically.

I was writing some audio code recently and it gave me an idea for an audio compression strategy. I don't know enough about audio compression to know for sure if it's been done before, but here goes anyway. The idea is that you have a selection of short, repeating waveforms (e.g. square wave, sine wave, sawtooth wave, white noise) and multiple channels each of which can independently play one of these waveforms at some particular frequency and volume. This is almost exactly the way that my physical tone matrix renders audio.

I was thinking that with enough channels, enough possible waveforms to choose from, enough frequencies, enough volumes and changing the parameters quickly enough, one could make a (perceptually) good approximation to any input waveform. And because the model sort of reflects how most of the things we listen to are created in the first place (a piece of music consists of multiple instruments playing at different volumes and pitches but each generally consisting of a fundamental tone with overtones of various intensities which might change throughout the course of any given note) this might actually give a pretty good approximation in a very small space.

One big problem is how to choose the right pitch, volume and waveform for each channel. The first thing I tried was using a genetic algorithm - the set of waveforms and the pitch/volume/channel information being the "genome" and the rendered waveform being the "phenome". The fitness function is just mean squared error (though eventually I'd like to switch to a more sophisticated psycho-acoustic model like that used by MP3 encoders). There is a population of genomes and the best ones survive, mutate and recombine to make the new population. Recomputing the phenome is not too expensive as the computations are very easy and each pitch/volume/waveform datum only affects a small amount of the phenome. Changing a bit in one of the waveforms is more expensive though as you have to go through all the pieces of the phenome that use that waveform.

Unfortunately it doesn't seem to be converging on the input waveform at all yet (it probably would if I left it long enough, it's just far too slow). The next thing I want to try is seeding the initial genomes with some kind of reasonable approximation to the initial waveform, and seeding the waveforms themselves with some random set of overtones modulated by a range of power laws. To seed the initial genomes, I'll need to break the input waveform into pieces, do an FFT on each piece to find the frequencies, pick the best waveform/pitch/frequency combination for that piece, then subtract it and repeat until we've picked a waveform for each channel.

Even if this codec doesn't beat existing codecs on quality per bitrate metrics, it could still be extremely useful because very little CPU power is required to play it back (I've already proved that a 16MHz Atmel AVR ATMega32 can do 16 channels of this kind of rendering in real time at 16KHz using less than half its capacity). If you premultiply each waveform by each possible volume you can playback on hardware that doesn't even have a multiplier (at significant cost to quality and/or bitrate).

Another fun thing about this system is that you could train it on a large number of sounds at once and come up with a set of waveforms that are good for compressing lots of different things. These could then be baked into the encoder and decoder instead of being transmitted with the rest of the data, leading to further savings. I wonder what the optimal waveforms would sound like.

This idea owes something to Mahoney's c64mp3 and cubase64 demos (unfortunately Mahoney's site breaks inbound links but the cubase64 link is in the 2nd of October 2010 section under "Recent Changes"). However, I think the sound quality of this scheme is likely to be much better than c64mp3 since we're not limited to a one channel plus noise.