Infinite Buggles

Working through my circle of friends have been links to The Infinite Jukebox, an amusing web site which takes a song, analyzes points at which clean edits can be made, and then randomly jumps through them so that the song just never ends. The idea is neat, and its visual representation of the song and the places where it can — but doesn’t have to — jump forward or back can be captivating. My Dearly Beloved has been particularly delighted with the results on “I Am A Camera”, by the Buggles, as it has many good edit points and can sound quite natural after the jumps if you aren’t paying close attention to the lyrics. I recommend playing that at least a bit so you get some sense of how it works, although listening to an infinitely long rendition of the Buggles, or any other band, is asking for a lot.

One question that comes naturally to mind, at least to my mind, is: given there are these various points where the song can skip ahead or skip back, how long should we expect such an “infinite” rendition of a song to take? What’s the average, that is the expected value, of the song’s playing? I wouldn’t dare jump into analyzing “I Am A Camera”, not without working on some easier problems to figure out how it should be done, but let’s look.

I’ll start with a simple model. Imagine a song that’s by original composition three minutes long. And imagine also that there’s just two break points where the song might jump. I’ll say the first of them is at the one-minute mark, and that the second of them is at the two-minute mark. This, I think, models the most important pieces of this concept: there’s the original length of the song, there’s at least one jump forward and at least one jump backward, and I know how far forward or back we can jump.

I can’t make the model simpler. If there were no break points, or just the one break point, then there’d be no jumps possible, and then we wouldn’t have an Infinite Jukebox; we’d just have playing the song straight through. If we had just the jump forward we’d be able to shorten the song but never lengthen it. If we had just the jump backward we’d be able to lengthen the song but never shorten it. It seems to me the chance to shorten and to lengthen are both essential, so we need two jumps, and at least two break points. So this is the model of an Infinite Jukebox song that’s as simple as possible without losing interest.

What’s the probability of making a jump? That’s something embedded in the code and not answered in the Infinite Jukebox FAQ, but we don’t really need this. We can say the probability of jumping is the number p and work out the problem that way. Or if we just want to get a feel for how to analyze the problem — and right now, I do — we could even pick a specific number, such as , and see what happens. After we have a feel for how the work goes we can go back and redo it with the unknown p instead, and that’ll let us learn how the expected length of the song differs with different jump probabilities.

For this nice simple model we have two possible jumps. There’s the probability that we jump ahead, shaving one minute (the length of the cut) off the song, when we reach the first break point. So there’s a probability of that the song’s length will be reduced by one minute. When we get to the second break point there’s a probability of that we’ll jump back one minute, increasing the song’s length by one minute.

This suggests that the expected length of the song would be changed by minutes, or become no longer — and no shorter — than the original tune was. It’d be three minutes, on average.

This analysis is wrong, as a quick “sanity check” — could this answer possibly be right? — indicates. There’s at least one major problem in that above reasoning, and there’s at least one minor problem in the setup, even if we accept the rest of this very simple song model as correct. I leave it, for right now, to the readers to spotlight how badly wrong this has gotten, and how to fix it.