Convert MP3 to AAC

Nobody starts a project by producing MP3s for a streaming system. This conversion happens because an old library exists: recorded announcements from a phone system that was replaced, station idents from a previous playout setup, prompt sets recorded by a voice artist who is no longer available, or archived programmes whose masters were deleted years ago.

That shapes the sensible expectations. The audio quality was fixed when those MP3s were made and the job now is to move the material into a format the new system will read without making it noticeably worse. This page is about the second half of that, since nothing can be done about the first.

The output is a sequence of AAC frames, each preceded by a header stating the profile, sample rate and channel configuration. There is no file header, no index and no structure containing the frames — which is why a decoder can join the stream at any point and start producing audio within a frame.

Systems designed around transmission want exactly this. A parser that only has to recognise a frame boundary is a small amount of code with few failure modes, which is why embedded firmware, telephony platforms and segmented streaming all converged on it independently.

A transcode between two lossy codecs at comparable bitrates is usually close to inaudible. The trouble starts when the target is much lower than the source, and these systems routinely specify low targets: 64 kbps for a stream budget set years ago, 48 or less for an announcement channel.

Compressing a 128 kbps MP3 into 48 kbps AAC is two rounds of a similar decision, and the second encoder spends bits preserving artefacts rather than audio. If the specification names a ceiling rather than a target, use the headroom. If it names an exact figure, the result is what it is, and matching it is the requirement.

Most material moving through announcement systems, IVR menus and prompt libraries is a single voice recorded in a quiet room, which is the easiest thing a codec ever has to encode. Speech has a narrow spectrum, predictable structure and no cymbals, and it survives a second encode at a low bitrate with its intelligibility intact.

Music is where a transcode announces itself. Hold music, station idents with beds under them, and anything with applause or reverb are the files worth listening to after converting. If a prompt library contains both, check a musical one rather than a spoken one — the spoken files will be fine.

The stream keeps whatever sample rate the MP3 had, which for anything ripped or downloaded is almost certainly 44,100 Hz. Nothing here resamples to suit a destination, and a frame header that honestly states 44,100 Hz is not what a platform expecting 8 or 16 kHz wants to read.

Telephony and announcement systems are the usual place this bites, because narrowband rates are still standard there. If your specification names a sample rate, check the MP3s before converting a library, and use a tool that resamples if they do not match. Discovering the mismatch after loading 400 prompts is the expensive version of this problem.

Once converted, files with matching sample rate and channel count can be concatenated directly. An hour of announcements assembled from forty fragments costs nothing in quality, because no decoder and no encoder is involved in the joining — the bytes follow one another.

This is worth designing around when the alternative is assembling audio in an editor and exporting the result, which would add a third encode to material that has already had two. Concatenating ADTS is the one operation in this chain that is genuinely free.

ADTS has no metadata of any kind. Whatever ID3 tags the MP3 carried — a title, a prompt identifier, a recording date, a version note — have nowhere to go and are absent from the output. A frame header describes the decoder configuration and nothing about the recording.

So filenames become the entire identification scheme, and it is worth getting them right before converting rather than after. If a prompt library relies on tags to track versions, export that information to a manifest first; the conversion will not preserve it and no later step can reconstruct it.

The best version of this task is the one that skips the MP3 entirely. Voice work was usually recorded and delivered as WAV, and those files often still exist on an old drive, in a project folder or with the studio that recorded them. Encoding AAC from a WAV is a first-generation encode with nothing compounded.

It is worth twenty minutes of asking before converting a whole library, because the difference is real at the bitrates these systems use. Where the masters are genuinely gone — and after a decade and a platform migration they often are — converting the MP3s is the right call, made knowingly.

Each drop takes up to a hundred files at 100 MB each, and prompt files are small enough that neither ceiling is ever the issue: an MP3 at 128 kbps runs about 0.96 MB a minute, so 100 MB is well over an hour. The batch comes back as a ZIP with one stream per source file.

Nothing is uploaded at any stage, which matters for material under contract or embargo — unreleased programmes, corporate announcements, recordings a voice artist licensed for one use. The encoder is fetched to your machine where the browser lacks one; the audio never travels in the other direction.