Seek and ye shall find…

My car stereo (a JVC that accepts USB thumb drives) is really slow at seeking to a specific position in long audio files [To be fair regarding long seek times, the JVC does seek faster off a CDR disk. However, it’s not much faster and then you’re left with a pile of disks that have been played only once.]. So, if you loose your place in a long podcast (e.g. the kids want to listen to something) you can spend up to 15 minutes holding down the fast forward button just to find your place again. It also jumbles up the play sequence for all the audio files within a folder. Both problems can be easily solved on the computer or when you put the audio files onto the USB drive.

My solution to the first problem is to split the audio file into multiple files, each file being 5 minutes long. mp3splt is a free utility that splits mp3 or ogg files without decoding the file into another format first, so there is no lossy decryption and encryption step. It is also pretty neat in that mp3splt tries to split on silent areas of the file (in between words), and the newer versions can preserve the ID3 tags within the file.

Here is the incantation that I’ve worked out to call mp3splt:

mp3splt -g %[@o,@N=1] -t 5.00 -a -o @n_@t YOUR_AUDIO_FILENAME

A brief explanation of the various command line switches:

Note that the ‘-g’ clause of the above was not available from the Debian Lenny repository version of mp3splt (that version is very old).

Optional extra: On BSD/Unix/Linux systems instead of remembering that whole string, I would recommend putting the above incantation line into a file with executable permissions in the /bin folder called say /bin/mp3s. Replace the YOUR_AUDIO_FILE part with $1. So you could then easily split an audio file called SOME_FILE simply by typing: mp3s SOME_FILE and it’s not necessary to remember the complex switches as above.

The solution to the second problem (scrambled audio files within a folder) where files seem to be playing in some random order is really trivial. It seems that windows users have never encountered the problem because when they copy an entire folder to the USB drive, the file modification information is in the same sequence as the filenames. For instance, if a windows user were to copy a folder with three tracks in it

track01.ogg
track02.ogg
track03.ogg

to the USB disk the top file would be the oldest one and the bottom file would be the youngest one. If you did the same thing on a Linux workstation, say by copying a folder with

cp -r somefolder /mnt/usb/

The bottom file from the list might not necessarily be the youngest one (in other words the file modification time is not in the same sequence as the alphabetical sequence). The solution is really trivial, copy your files like this:

cp somefolder/* /mnt/usb/somefolder/

The asterisk (*) gets expanded by the shell to a file list in the same order as you see when you list your files sorted by filename.