Loopy Tunes (part 2)

Well, Sorta, Kinda, Not Really, But Yes

Here's the deal: in an environment where bandwidth is measured in tens of kilobytes, but RAM is available in hundreds of megabytes (though not yet even one gigabyte), the important thing is how much compressed data you can squeeze through the "soda straw" modem, not how big the uncompressed file takes up in memory. With a ten-to-one compression rate, MPEG let me utilize one megabyte of sample data, and post it to the Web in a hundred kilobyte package -- suh-weet!

More importantly, MPEG compression (even at low kbps rates) sounds SO much better than the heavily-downsampled, lossy algorithms I'd been working with, it ain't even funny. When you come from an 8-bit, 8kHz, μ-law world, MP3 sounds like freakin' paradise!

Even better, this Web-based version of the Beatnik engine supported MPEG compressed instrument samples, with loops, thank you very much. I'd make looped samples (like the harpsichord in part 1), import them into the Editor, and apply MPEG compression at various rates. I could then use all the little tricks of the trade to play the samples at various pitches, and apply envelopes and filters. But the best thing about it: the position of the sample loop points was saved in the RMF instrument definition.

The web plug-in would play the looped MPEG instruments in the RMF file, no problem, and it sounded quite lovely. The trick, of course, is that you're simply using the MPEG compression algorithm to squeeze the data for delivery, then expanding **the whole thing** into memory on playback. That little 100Kb package blows up into the original 1Mb in RAM ... which was a perfectly acceptable strategy for a desktop PC circa 2000.

(Loop "Row" 3x) Your Boat, Gently Down The Stream

A colleague of mine likes to say "MP3 isn't a file format, it's a train wreck!" and that's partly because it's not really a file format at all - it's a psycho-acoustic compression algorithm some Germans came up with in the '90's. Of course, now that it has evolved into the most prevalent audio format of all, it can be many things to many programs. Even so, currently nobody decompresses the entire file and plays it from memory anymore. These days, it's all about "streaming" ...

Streaming is a good strategy when when you've got a fast CPU, but limited RAM or bandwidth. You use the power of speedy processors to decode MPEG data on the fly, frame by frame, and toss the uncompressed sample data into an audio buffer. As long as you keep that bucket full enough, the audio stream will play uninterrupted, even when the CPU is off doing something else (like playing a game, or downloading more data). The process works great whether you're broadcasting audio across the Internet, playing patches on a GigaSampler, or listening to your iPod.

The thing about a stream, though, is that it's linear in one direction, like a movie reel. A stream starts, plays frame after frame, completely sequentially, until it runs out of data. Then it stops, period, end of story. A stream does not play faster or slower, does not shift pitch, never changes tempo, and certainly does not loop back on itself, not even from last sample to first. Oh, sure, you can loop MIDI or PCM audio or video or animation, but a stream? No, a stream starts and plays, that's it. As they say, "You can't push the river."

And yet, whenever I hear that, I'm reminded of the time I was looking for a certain item at Fry's, and an eager but clueless clerk tried to help me. I described what I was looking for, and he frowned, saying "Let me ask my manager about that." While he was gone, I found the item, and was about to go purchase it, when the clerk reappeared saying, "Sorry, we don't carry that!"

In The Bucket

Here's what I don't get: why is looping an MP3 such a freakin' problem!? I mean, a wave is a wave is a wave, and as long as the uncompressed data in the bucket describes the wave in the MP3, you should be able to keep the loop going without a hitch, and without loading up the entire file:

SO let's say you're playing an MP3 ringtone, which was generated from a pefectly loopable, first to last, WAV sample of the hook of a song. The player starts the stream, reads frame 1, 2, 3 ... n - 2, n - 1, and finally, the nth frame of compressed data. Usually, the player then says, "OK, I played the last frame, I'm done. Oh wait, I'm in 'loop mode', so now I'll go back to the start of the file, do my entire initialization routine again, fire up the Fast Fourier Transforms, and start playing the stream again." In the meantime, the buffer's run out (or worse, been destroyed!), so you get a lovely little glitch, a conspicuous gap, a few hundred milliseconds of blessed silence, maybe a little pop, click, and crackle, if you're lucky.

What you don't get is a seamless loop. Playback engines never seem to go, "OK, now I'm on the second to last frame, now I'm on the penultimate frame, Hey! I'm in loop mode! I should get ready to load the *first* frame of data, right after I load up the *last* frame, and I must NOT destroy the buffer! The show must go on, the bucket must not empty, the flow must be constant and unbroken!!" A glitch in the middle of the stream would be considered simply unacceptable, but nobody (except me, apparently) thinks that a glitch at EOF is just as bad.

Eye Dee Three Pea Oh, INT!

And that's just for looping the entire sample! We're not even talking about looping an instrument sample, and you can just fuggedabout the damn coda! The conventional wisdom always says the same thing: MP3s don't have a header block, like a WAV or MIDI file, so there's no place to even store the loop point locations. And that's true ... but it's also one of those times I think about that Fry's clerk.

Because there's these things called ID3 tags! They're basically just metadata (information about the data file), and can contain all kinds of stuff, like album art and lyrics and copyrights. Are you telling me that a format capable of caching high-quality graphics can't store a "loop mode on/off flag" and a coupla freakin' numbers!? And not even frame numbers, I'm talking *milliseconds* here! The processing required to pull off a seamlessly looping, streaming MPEG instrument is maybe a little hinkier than just a regular stream, but as long as you "connect the dots" in the uncompressed data you're sending to the audio buffer, you should be golden.

Now, the fact that I seem to be the only person who thinks a "loop info" ID3 tag is a "Really Good Idea" makes me figure:
a) I must be missing something
b) nobody cares about this stuff but me
c) I might be a radical misunderstood visionary
d) I might be waaay crazier than I realized
e) none of the above
f) or possibly, all of the above

But I do know one thing: I ain't done yet!! (hell, I ain't even tired!!) Next up, Mobile Looping and the future of portable audio ... stay tuned!

   - pdx

Can you explain why MP3's don't loop? Leave a comment, or write to the annoying audio guy ...