MP3 Files: Creating Order From A Jumbled Mess

by Paul Arnote (parnote)

Three months into my discovery of/journey with podcasts (yeah, yeah ... I'm late to the podcast party), I have amassed a fair collection of podcasts from a variety of sources.

When I first started, I wanted to put each serial podcast (like "The Agent") on a MP3 CD to play on the MP3 CD player in my pickup truck. That led to my first article in March 2022 about resampling the MP3 files at a lower bitrate so they could all fit on a single 700MiB CD-R. Since then, I discovered the USB port on my dash that is read by my truck's audio system. So, I bought a few inexpensive 32GiB USB flash drives from Newegg.com. Now, with 32GiB of space to play with, I'm not as concerned about the need to shrink the files down to fit onto a standard CD-R.

But regardless of the medium -- CD-R or USB flash drive -- one problem persisted that had me perplexed. The files were all jumbled on my truck's audio system, as well as on the audio system in my wife's car. Granted, all of the files remained in their folders, but within those folders, the files were all jumbled up, and not in the order I had planned. Not only were the files jumbled, but the playback order was jumbled, too. I soon discovered that the problem was also present on my SanDisk Sansa Clip+ personal audio player, which I covered way back in October 2009. Yes, I still have it, and it still works perfectly (although it might be nice to have a version that connects to my Bluetooth earbuds).

Sure, I could just stream the podcasts over my cell phone. But then what happens when I'm traveling in one of the vehicles, and I'm in a fringe reception area? Yep. You guessed it. No more streaming. This happens for us more frequently than you might imagine. We also like to spend time outdoors, where cell phone reception is spotty at best. So, it's better to have a physical copy of the podcast playing, either on CD, USB flash drive, or in the case of the Sansa Clip, a microSD card. That way, the podcast playback isn't dependent on whether or not I have cell phone reception.

So, the first thing I tried was making sure there was a *.m3u playlist file in each folder, hoping that would set things right. Nope. That had absolutely no effect whatsoever.

Then, I tried renaming the files with numbers, usually starting with "000" and incrementing all the way up to however many files were in the folder. I thought that just maybe the audio system in the vehicles (and on the Sansa Clip) might be using the filenames to determine the order of the files. Nope. That also had absolutely no effect whatsoever, either.

So, the only other "thing" I could think of was that both my Sansa Clip and the audio system in the vehicles were using the track number embedded into the MP3 as ID3v2 data to determine the proper order of the tracks.

Upon checking the tag data in the MP3 files I had downloaded, each and every one had a track number of "1." So, none of my playback devices had any idea of which order to play the files. You certainly don't want to listen to chapter 1, and then hear chapter 9 before you've heard chapters 2, 3, 4, 5, 6, 7, and 8. As a result, the order seemed very random, although consistently so.

Since I use Thunar on Xfce, editing that info is fairly easy. Right click on the file, select "Properties" from the context menu, then select the "Audio" tab in the dialog box that appears. The very top left field is the "Track" number. Set the track number for that particular episode, so the tracks play in the desired order. Then, select the "Save" button, and then the "Close" button. I'm fairly certain that the process is similar on other desktop environments, such as Mate, KDE Plasma, LXQt, etc., and their associated file managers.

Yes, this method works fine. But the drawback is that you have to do each individual file, one at a time. That would be fine if you have just a few files to do, but if you have hundreds, this is going to take up a LOT of time. Just one of my podcasts, a reading of the Federalist Papers from colonial times in America, has 85 separate files.

There has/had to be a faster, easier way than doing them all one individual file at a time.

Thanks to some command line tools and executing them in a bash script, there is a much easier way to assign a unique track number to each file in a folder. So what did I do? I created yet another bash script to handle the task!

Just as when I created the bash scripts to handle the bitrate resampling and to handle adding album art to your MP3 files, I created this script to be run either from the command line, or from a Thunar custom action. It even has a graphical progress bar, courtesy of Zenity.

So, below is the script I came up with. You can type it in (it's definitely short enough), or you can download it from the magazine website. The download file is named mp3-track-renumber.sh.txt. As with the previous two bash scripts, save the file to where you keep your bash scripts, remove the ".txt" file extension, and make the file executable.

This is the shortest of the three MP3-related bash scripts that I've written over the past three months. Including five blank lines, it's only 17 lines long. Size-wise, it's only 388 bytes, so it's not going to break the download quota bank.

Being a bash script, line 1 is the typical shebang that starts off every bash file. Line 3 initializes "n" as an integer we'll need later as we loop through multiple files. It's also the number used to assign a unique, incremented track number to each file later on.

Lines 5 through 15 are the for-do loop that walks through multiple files supplied as command line arguments. Lines 6 through 8 check to see if the supplied filename actually exists. If it doesn't, then it continues on with the next filename. If the file exists, it then processes that file.

Line 10 sets up the text to display in the Zenity progress dialog box. Line 11 calls on the command line program id3v2 to set the track number using the integer that we set up in the third line. I cannot remember if I had id3v2 already installed, or if I had to install it from Synaptic. If you don't have it installed on your computer, definitely install it from Synaptic.

Line 12 sets up the percentage to be displayed in the Zenity progress dialog box, while line 12 increments the integer by one for every file processed.

Line 15 closes out the for-do loop, and displays the Zenity progress dialog box. Line 17 exits the script cleanly.

To be perfectly honest, the script often completes so quickly that I'm not able to get an image of the Zenity progress dialog box when it is displayed. So instead, I can show you the MP3 tag data (above) after the script has been run, which shows the track number set in the ID3v2 data.

Using The Script

Like I mentioned earlier, I designed this script to be run either as a standalone bash script from the command line, or as a Thunar custom action (which is how I will mostly use it). As I've mentioned in my previous articles, I'm sure that this can be added to the context menus of Dolphin or Caja, but because I haven't run KDE Plasma or Mate in quite a while, I'm no longer familiar enough with them to be able to lead you through that process. However, I'm sure fans of those desktops will have no difficulty finding a suitable guide to achieve similar functionality. That isn't within the scope of this article, though.

To ensure that the files are in the order that I want/need, I use Xfce's multi-file renaming utility. Using that, I preface every filename with numbers, usually starting with "000" (I do it this way because I usually also download the "trailer" or "prologue" for the serial podcasts I download, and number that file as chapter zero), and using a dash as a separator between the numbers and the filename.

From the command line, you can specify individual files as command line arguments, or you can use wildcards. If you specify individual files, each file is separated by a space. Using wildcards, first cd to the directory where the MP3 files are stored, and then execute the command mp3-track-renumber.sh *.mp3 on the command line. In short order, your MP3 files will have the appropriate track number recorded in the MP3 tag information.

I've set up the Thunar custom action as shown above. I've named the custom action "MP3 Track Renumber." The command is entered as mp3-track-renumber.sh %N. I've also selected an unused icon from my system to represent the custom action in Thunar's context menu. Under the "Appearance Conditions" tab, I've checked the "Audio Files" selection, and entered *.mp3;*.MP3 as the "File Pattern" to match. Then, all I have to do is select the MP3 files I want to renumber the track numbers of, and select the custom action from Thunar's context menu.

On a side note, your MP3 file names cannot contain spaces. I've covered this previously with the other two MP3 scripts. Because spaces are used as delimiters for command line parameters, spaces in file names will cause the script to not work. At all. It's best practice to eliminate spaces from file names anyway, to avoid any such issues.

Summary

While I was glad to find a couple of ways to listen to podcasts while driving in the vehicles, it was maddening to not have the files listed (and not played back) in the proper order. It took me a bit to figure out exactly why this was occurring, too. To be perfectly honest, I was a bit surprised that a *.m3u playlist didn't resolve the issue, as well. It's not as if *.m3u playlists are anything new, so I felt confident that they should/would be recognized by even the most basic MP3 player. Or so I mistakenly thought. I was also surprised to discover that the filename had no bearing on the playback order, as well.

Nope. The playback order is ruled by the track number assigned to the MP3 file in the MP3 tag information. Who'da thunk it, right? Now that I've discovered the proper way to ensure the proper playback order, I literally have created order out of chaos, and my MP3 files now play in the proper order. And along the way, I created an easier, faster way to number (or renumber) the track/playback order of my MP3 files.