1 Brief history

If you thought listening to that song 20 times in a row was an amazing feat, that's barely even a start for me. Unlike most who have a hard enough time making 10 plays in a row, I regularly have the same song playing well over 100 times in a row, sometimes even over a thousand times in a row. I started with cassette tapes as a sort of "prank" or "practical joke" on my parents as a way to get them to think I was playing my video games at night when I shouldn't have been, but I only had a cassette playing the music from the game. With the use of the Talkboy, I've been involved with changing the speeds of songs and ever since I got the songs on my computer, I've had extreme flexibility and I've always wanted that on my external players but was too limited in what I could do. With the CD-based MP3 player, I resorted to a system that remained with me for a long time. Once I got a real MP3 player with a 4 GB capacity, all my music-related childhood dreams have almost come true. The 17-step binary logarithmic speed system was in use clear until November of 2006 where I went to a 48-step system instead.

Out Where the Lake Is was my all-time top favorite song for over a decade. It racked up a seemingly unbeatable one million total life time plays but, as of Jan 12, 2006, is no longer the dominate song and is only in 5th place. Four songs have since taken over the lead for Out Where the Lake Is, one of which, Battle Zone, played nonstop for 46 days as roughly 20,000 plays. Just typing this brief section, I've logged another 8 plays of "Go Sailing Along", my third favorite song lasting about 2 1/4 minutes per loop and 80% true speed and I'm still craving for more. After all, it's quite common for me to have 4 and 5-figure play counts in Winamp. By the time I finished writing this article, including saving the screenshots, I've logged about 100 plays of the song without changing speeds, EQ settings, or anything. For an in depth look at my history with music, what the 48-step speed system is, including some FAQs with me and music, see my history on music.

2 Video demonstration

This series of 4 segments demonstrates this very process, complete with narration. The process is quite lengthy otherwise, taking almost an hour, but I take some of this out and keep to the main point. The song processed here isn't the same as what's described in the screenshots below, however.

3 Processing songs

3.1 The tools/software used

I use 4 tools to process my songs: Audacity, The WAV File Sample Rate Generator, a BAT file using lame.exe, and Windows Explorer. Here's an explanation on what these are, considering you may not recognize the second one at all.

3.1.1 Audacity

Audacity is a free, open source audio manipulation program. I happen to use version 1.2.3 because the later versions tend to not work (1.2.6 doesn't play at all (it plays but gives no sound even though 1.2.3 does as well as Winamp), 1.2.4 plays for a bit then just stops a second or so in). It has two uses - preparing and saving the base file of which the next program is used. I usually use about 5 to 10 minutes with Audacity, depending on the song.

3.1.2 The WAV File Sample Rate Generator

So where's this program at? Well, you won't find it in any store or anywhere on the internet. It's a program I wrote, in C, to automate what I once did with the hex edittor in the previous method I used. All the program does is that is reads the base file dumping the contents entirely in memory (100 MB is all that's really needed, nothing much to 1.5 GB - memory since it's far faster than the hard drive) then writes the output in the same way I used the hex edittor in my earlier method. The only difference from the base file and the dozens of output files is a mere 8 bytes, from positions 0x18 to 0x1F. It only takes about 3 minutes to generate 112 files at about 90 MB each (typical of a 100,000 Hz sample rate for true speed), but another 10 to 30 seconds to make a few small modifications to the program (changing the song name, speed range and a few other things).

3.1.3 BAT file and lame.exe

If you're into MP3's, you may have heard about lame.exe. It's a commandline-driven program that converts source files (WAV in my case) into MP3 files. What does a BAT file have to do with it? It's for batch conversion. It creates a loop that executes lame.exe to convert a WAV file into an MP3 file until all WAV files are converted speeding up the process. This part takes the longest time, up to 20 minutes. 2 to 15 minutes is more typical, however.

3.1.4 Windows Explorer

You should know what Windows Explorer is for - dealing with files and directories. I only use it for the final phase and only takes about a minute of the whole process.

3.2 The process I use

It takes only 10 to 40 minutes per song to fully process it, compared to 50 to 200 using my old method, most of which spent during the conversion from WAV to MP3. To view the full-sized 1920x1440 screenshots, just click on them.

3.2.1 Getting the base file

A base file is a file from which derivatives made from, like a source. First, I open up Audacity and choose a song to process. In this case, I'm processing the song Target Zone which has a huge speed range, mostly into the high realm (to quadruple true speed). Because Target Zone has an intro to it, I need to open the original with the intro (and 2 loops) along with the loopable version.

I first need to set the speed to true speed. It's already at 100,000 Hz which happens to be the true speed so I don't need to make this change. Next would be playing it to find the speed range I want starting with the low end. I memorize it as from 70 to 400% true speed. Yeah, 400% true speed. It's the song that goes the very highest while still sounding decent. Due to an annoying thing in Audacity in that the "set rate" thing doesn't allow for values over 100,000, I have to resort to another trick - use the "change speed" feature in the effect menu and use 100 as the adjustment. This doubles the speed making 50,000 Hz true speed instead. Target Zone would still go beyond 100,000 with this so I use this yet again making 25,000 Hz true speed. Once I find it, I use control+Z a few times (or Z-ing it as I often call it) to get the original source back (or, if too many edits were made, then I just close the track and reopen the file). The low end doesn't need the speed change feature, it's only the upper end.

The next step is forming the looping output. The target time is 8 minutes at true speed. How I do it is first selecting the entire song with the intro and get the time. This happens to be 2 minutes, 11 seconds.

This means I use my loopable version, select all, and use the "repeat" option then set the repeat count to something as close to 5 minutes, 49 seconds as possible, rounding down if too close to tell (or, if there are less than 3 loops, until 3 loops are present (this exception is ultra rare). If the song naturally has a pause at the end (such as Carnival Night or Misty Bog), I just leave the source as is without loops since there's no need for them. Target Zone doesn't have this so it needs the loops. It turns out that the value is hard to determine for this particular song as it's around the halfway mark where neither 4 or 5 loops is closer to the targetted 5:49. I use the round down rule in this case meaning 4 loops.

Next, I select the version with the intro and copy it. Following that, I return to the window with the looped version, click the button to put the cursor at the start of the track, then paste what I copied.

Next, I need to counter the bug with my MP3 player where it plays back at different speeds, depending on the sample rate used for MP3. Since Target Zone has a lot of high-pitched sounds involved, I'm using the 16 KHz version which has a speed adjustment factor of -0.0456 (as of Jan 19, 2007, from another experiment (recording with a definite/exact time gap and cropping), this value is actually -0.627804537 (49.0582931945 for the 12KHz speed)*), the result of yet another time-synchronization experiment. This way, when my MP3 player plays the file, it plays it back in real time and is off by time amounts where, if played for a full day, which is 86,400 seconds, it'd be off by a mere 2 milliseconds! That's as short as a single frame recorded on a 500 fps high-speed camera! It'd otherwise be off by about 9.03 minutes.

Because the text field is a bit narrow, not all characters can be displayed in the screenshot. Next, I set the project rate to that of the track's rate. Without doing this, I end up having to redo the above if I close the Window. If I don't, I just need to make the fix and resave. In both cases, I'd have to delete the file I just saved. I'll know if I forget due to it taking 4 times longer than it normally would.

The last step for processing the base file is to export it as a WAV file. I call it "Target Zone base.wav". The "base" indicates that it's a base file from which the output in the next phase is created from.

The export process usually takes about 7 seconds. The "time remaining" value is not trustworthy. Just after I captured this screenshot, it went to 5 seconds, rapidly dropped to 2 again then jumped to 4. It's one of many bugs I know of in Audacity.

3.2.2 Generating the speeds

The base file is now created and now I need to generate the speeds. Before doing this, I need to open Windows Explorer and check to see if previous content is there in case that I forgot to delete from a previous run at this process. The only things present are just the two BAT files and thus empty. If there were WAV and/or MP3 files present, I'd need to delete them. The next step is to take out Visual C++ so I can make changes to my program to generate the source files.

Shown in this screenshot is the key area I focus on. To you nonprogrammers, you may find some of this a bit confusing, but you could make out some of what it says and does. I previously worked on the song "Go Sailing Along", of which I have playing in Winamp at the moment (and about 100 plays since I started rewriting this). I change this, indicated where the cursor is, to "Target Zone" with the quotes since they are needed in the syntax. For the area at the top, I need to use my chart to get the speeds. 50,000 Hz in the file name is always true speed, no matter what the source is, thus the use of the "modifier" variable and the little comment of it's use to the right of it. Target Zone's true speed is 100,000 Hz and thus modifier needs to be 2, which is what it's at. To set the range to get, I use the handy chart just above it. Target Zone is good to only 70% true speed so I look up 35,000 in the chart above to find the starting position, which is -24. Target Zone is good to 400% true speed, which is 200,000 in the chart, so the ending value is 96. This results in 121 files. Why not 120? This is a common mistake others tend to make. Count from 3 to 5 once. It's not 2 numbers you mention (as from 5 minus 3), but actually 3 numbers: 3, 4, and 5. 96 minus -24 gives 120 but always add the 1 to any range.

The line numbers with a green marker are those that got changed. At this point, I'm ready to begin generating the speeds. I just click the "play" button and let the program run.

This is the program running. Yeah, it's a simple command prompt window, but I don't need anything sophisticated. Afterall, this program writes the output 5 times faster than Audacity does, considering the base file is dumped entirely into memory, a much faster piece of hardware than the hard drive but has limited capacity (but since only 100 MB is needed, not much on my 1.5 GB, this is certainly the way to go). In fact, my program only uses 20% of the CPU while my hard drive writes at 55 megabytes per second sustained - Audacity is lucky to sustain just 11 MB per second, but usually does so at 10 MB per second. Note the "time of creation" column and how quickly the program wrote those 85.6 MB files. 36 files have the 6:17 AM time and 40 files have the 6:18 AM time. Note the sample rate column and how it progresses with time.

3.2.3 Converting to MP3 and transferring

Now comes the time-consuming part - converting all those source files to MP3. Since I decided on the 16KHz sample rate for MP3, I double click the one with 16KHz in it and let it run. 15 minutes later and it was done, about the typical time it takes (upper end due to so many files). Note the song durations and how the file size changes with it. Note the sample rate (the number in the file name) and how it compares. This is just bloated with patterns.

The next step is to move the MP3 files to the directory containing the MP3's, under the song's name. To do this, I normally copy the files to the directory I want then delete the originals. This includes the source WAV files (and hey, if I need the WAV files again, I only have a 3-minute wait.

First, I need to transfer the files to my MP3 player so I copy the folder I just pasted the files in and hook up my MP3 player. I delete the existing directory for that song then paste in the new files.

The final step is to delete the WAV and MP3 files to leave only the two BAT files. Instead of sending the files to the recycle bin, I hold the shift key while selecting "delete" from the right-click menu to permanently delete them since I have no need for them any more. I don't delete the base file unless I made a fix to it or obtained an updated version of the song. Off to the next song....

Footnotes:
* How do I know that this is the offset value? It comes from running a time-synchronization experiment. How the experiment was run was by forming something that is exactly 6 minutes, 40 seconds long, exact to the sample. I loop this 9 times to get exactly one hour. I add some "padding" around this (a few seconds of the song), then some silence. Then the one-hour time span begins of the song with silence covering what remains of the song to get exactly 6 minutes, 40 seconds. I extend it further so that, when I begin recording, I'd get the full 9 loops spanning the full one hour and with the starting and ending points definite, it's easy to crop it to within 2 samples' precision. I then convert the WAV file to MP3 at various sample rates (12 KHz, 16KHz, and 22KHz) and add them to my MP3 player as explained in the last part of section 2.2.3. When I run the test, I first find out what effect the computer going into power save mode has on the times and found that it made no difference at all. I started the recording, including the padding on both sides, then cropped the surrounding area with a set definite starting point, the moment the song starts after the self-included silence. This would trim it down to one hour's worth of the actual song and using Audacity's times, I can see exactly how long the recorded song is. Instead of an hour, I got 59 minutes, 37.39896 seconds for the 16KHz version. From there, it's just the matter of finding the ratio (original divided by output) and the result is what I use. The 12KHz value had 89 minutes, 29.09867 seconds and the other one, the 22KHz, had 39 minutes, 43.97864 seconds (but spanned only 40 minutes since the MP3 player's battery died at that time). The 22KHz one is the oddball as it seems quite a bit off, far more than the 12 and 16KHz times (12KHz seems to be played back at 8000 Hz, a standard and thus dividing the time by 1.5 otherwise gives the exact time of the 16KHz to within 2 milliseconds on the day of precision. - 22KHz is off by nearly 30.92 seconds for the day - my old method is about 60 times more precise than that). This is how this value is determined.