How can I (click) Why does my MP3 player play a snippet from the future when going to the next track?

July 9, 2010 2:31 PM

A number of MP3 players I've owned have had a similar glitch: occasionally, when switching tracks, a brief (less than one second) snippet of the song *after* the upcoming track will play. Sometimes, it's from the same track, but later in the song. What causes this?
posted by I EAT TAPAS to technology (4 answers total)

it sounds like a side effect of energy efficiency.
If the mp3 players use a hard drive instead of flash memory, then operating the hard-drive takes the lion's share of the battery power, therefore to achieve a useful battery life, you have to minimize the time that the drive is active.

This is done by using buffer memory. Let's say an mp3 player has 16meg memory. When it powers up the hard drive, it will read the entire mp3 track in a split second and copy it to memory, so that it can then power down the drive, and play the song from memory, (memory requires far less power to operate than a hard drive).

Since the mp3 song is about 5 Mb, and the buffer is 16 Mb, more power can be saved if it reads the next three songs into memory when it powers up the drive - then it won't need to power up the drive again for another 15 minutes!

The problem, of course, is knowing which three songs you are going to play next. If you are using a playlist, it will preload the next songs in the list. If you pick a song from an album, it may assume there is a fair chance that the next song to play will be the next one in the album.

With these songs already cued up in memory, if you decide to select a different song from what it thinks you were going to play, then there is a period of a few seconds during which time the hard drive has to be powered up so the new selection can be copied to memory. During this time, a fragment of the song it thought was next might get played. The bug might also be related to volume fade-in fade-out, whereby the song fades to ease transition to the new song, but for some reason, the fade finishes or is suspended before the song being loaded has loaded (perhaps because the CPU is focusing on IO with the hard drive, and lowers the priority on other tasks?)

I wouldn't expect to see the problem on a flash-based player, but of course, bugs happen.
posted by -harlequin- at 3:01 PM on July 9, 2010

Oh - more detail. Typically, an mp3 player is built around two core chips. One is a chip dedicated to decoding mp3s into music, the other is a CPU, which handles user input, LCD screen, storage devices, and which data to feed into the mp3 decoder chip.

This split in tasks is (I assume) why the bug is common. The mp3 decoder chip will keep on doing what it does until the CPU tells it to do something else. That's it's job - just keep the music playing. So if the CPU is busy because you changed songs, the music can keep playing. If if takes a few seconds to rewrite the buffer memory, that's not going to stop the decoder chip from playing whatever is in the buffer memory it's been (re)directed to, and if something takes longer than expected, while other tasks remain on schedule, then the sequence in which things have to happen to produce a seamless transition might get broken.
posted by -harlequin- at 3:14 PM on July 9, 2010

Thanks, -harlequin-. I should have provided more details:

1) I've experienced this on both hard drive-based iPods as well as a variety of flash-based dedicated MP3 players and phones. I haven't experienced this with computer-based music software.
2) None of the players I've experienced this on have been able to do fading or crossfading.
3) I understand that it's jumping to a point in the buffer, but it seems strange that the glitch would jump so far in the buffer. In a playlist with songs 1, 2 and 3, what's happening is that song 1 plays, there's less than a second of song 3, and then song 2 starts. Wha?
posted by I EAT TAPAS at 3:20 PM on July 9, 2010

If the buffer is being re-written, and the decoder was directed to memory before the rewriting has finished, or not until a short time aftewards, then it's not strange that it could jump far ahead - or not far ahead at all. In order to use all the memory and avoid fragmentation and memory leaks, I assume that when the buffer is refreshed, in many players it is refreshed completely, rather than certain sections left alone and other sections updated. (Eg you can't wipe song-just-finished-playing-song from a slot of memory and replace it with song-just-about-to-play if the later is a larger file size than the former - you'll have to fragment the later, which will make the problem worse the next time around. So you might instead wipe everything and load up the buffer again from scratch).

My guess for your scenario on 3 is that the player is most of the way through the buffered music, so it wants to re-fill that buffer, and it waits until it's between songs to do it so as not to interrupt the music.
Perhaps instead of the re-write being late, it is the decoder redirect that is late. So the decoder continues from song 1 at location A on to song 2 at location B, then song 1 (and all songs before it) get dumped from memory, and the re-write puts song 2 in location A, song 3 in location B, and so on. The decoder happily plays song 3 in location B before it is redirected to song 2 at location A.
The startpoints of locations aren't fixed locations, because the mp3 filesizes are always changing.
posted by -harlequin- at 3:46 PM on July 9, 2010