I’ve run into an issue with a little portable music player I have – it doesn’t make reasonable assumptions about the order in which to play the tracks of an audio book. Even when the files are named sequentially with numbers, when the timestamps are in the order they should be played back, when there are valid and correct track numbers in the ID3 tags, and regardless of the order in which they are copied to the device (corresponding to the order of their entries in the filesystem lookup table), they always play in what seems like random order (this doesn’t happen with music, which works as one would expect). I’ve found that the easiest solution to this is to just wrap them up into a single large MP3 that contains the whole book. There are many ways to accomplish this, and here I’ll show a tool called mp3wrap that worked simply and reliably for me.
mp3wrap is my favorite method because there’s very little syntax to remember, it’s incredibly simple, it’s reversible, and it’s incredibly fast.
The basic use case goes like this:
mp3wrap newfilename *.mp3
This will join together all of the mp3 files in the current directory into a new file named, in this case, newfilename_MP3WRAP.mp3. You can rename this file if you like, or leave it as it is if you think you might have a reason to split it later.
You can also specify individual files instead of using a wildcard:
mp3wrap newfilename foo.mp3 bar.mp3
I haven’t done extensive testing with mp3wrap, but from what I understand, it strips the header information from the tracks and collects it together to build a new header to go at the beginning of the whole mess. It then concatenates all of them together into one stream. Because it doesn’t have to encode/decode any of the data, only copy it, it is extremely fast.
Down the road, should you decide you want to pull the tracks apart, you can do so with the mp3splt tool. It will pull the data from the wrapped file and give you the original files back. This works best (easiest) if you’ve left the _MP3WRAP tag in the name of the wrapped file.
Note that these tools come with siblings called oggwrap and oggsplt for working with Ogg Vorbis files in the same way.
In some cases it is possible to actually concatenate the files as they are with one another into a single file. So, that command might look like:
cat track1.mp3 track2.mp3 track3.mp3 > wholething.mp3
The downside to this method is that none of the metadata is updated, meaning most players won’t report track length or playback progress correctly. Many will also hiccup (or some stop altogether, depending on the robustness of the implementation) when it hits track boundaries because it’s trying to decode the metadata (that previously came at the start of each of the other files) as audio.
There are also other tools that will decode the audio from each of several files and re-encode them together as a single file. These methods work, but are not preferred both because of the time they take (to decode and encode) and because this is a lossy process, you will lose audio fidelity. The only reason to do this is if you want a smaller file by decreasing audio quality on the re-encode, which is often acceptable for spoken word like lectures, audio books, etc.