Ttyjfyk

I have many MP3 audio files which are ADTS encoded. Unfortunately, my car radio doesn't support ADTS, so I need to convert them to normal MP3 files without a transport stream.

There are many people out there who asked the same question, but the only answers I found was converting to wav and then use lameenc to convert it back to MP3

I'm sure there is a way to convert these files without decoding/reencoding them.

I already experimented with ffmpeg/avconv, but the parameter -acodec copy doesn't seem to output anything different than ADTS.

I also played around with GStreamer. Funnily, I think it's the module aacparse which at least understands the format, but it's not a demuxer.

Which tool can I use for this?

$ file badfile.mp3 goodfile.mp3
badfile.mp3: MPEG ADTS, layer III, v2, 64 kbps, 22.05 kHz, JntStereo
goodfile.mp3: Audio file with ID3 version 2.4.0

An example file can be found here (Overview)

Update:
I'm still testing, but it seems that 1) Also lame produces ADTS files and 2) ADTS is not really the problem for my car radio, it must be something different. I'm testing now with different profiles and bitrates, VBR and CBR. But it is still helpful if someone knows something more about ADTS.

There is no way to convert MPEG ADTS to MP3 without decoding and reencoding them. They are fundamentally different formats/encodings. Any conversion utility you use that claims to do a direct conversion is in fact doing that behind the scenes--decoding to some lossless format and reencoding to some version of MP3. With that in mind, I highly recommend sox for audio format conversions. It really isn't exaggerating when it refers to itself as the "Swiss Army Knife of Audio Manipulation." Syntax is simple: sox infile outfile, but the available options put ffmpeg to shame.

It is some time ago and I don't have the car with the radio anymore. Currently, I can't even say anymore which radio make it was, but here is what I finally did. (The answer is somehow off-topic because the final solution was not exactly what I initially asked. But it's still interesting because it helps detecting problems with limited mp3 players, and I also write this because of the increasing numbers of upvotes for the question :-). The really interesting thing is not the result itself but how I found it):

My approach was the following:

• Generate lots of sample files with different encodings


• Play all of them on the radio and mark the good and bad ones on a paper

But listening to long audio samples took a lot of time. Playing fast samples and keeping both the display and my paper in view didn't work for me, I always skipped lines. So finally I decided to use a tts (text-to-speech) tool to include the number of the given test acoustically into each test file, so that I hear something like:

• A 1


• B 1


• B 3

Which means: test A1, B1 and B3 were good, while A2, B2 and A3 didn't play at all. Writing all this down finally resulted in a list which helped me preparing the following chart using libreoffice's pivottable feature:

This is the script which I used to generate the test files:

for enc in aconv lame; do
 i=1
 case "$enc" in
 aconv)
 test=A
 ;;
 lame)
 test=B
 ;;
 esac
 mkdir "$test/"

 for freq in 8000 11025 12000 16000 22050 24000 32000 44100 48000 ; do
 for bitrate in 8 16 24 32 40 48 56 64 80 96 112 128 144 160 192 224 256 320 ; do
 echo "=== $test $i $freq $bitrate ==="
 basename="$test/`printf "%s_%03d_" $test $i`"
 rm "$basename"*
 basename="$basename$freq_$bitrate"
 espeak -v german "$test $i" -w "$basename.wav"

 case "$enc" in
 aconv)Selection_001
 cmd=( avconv -i "$basename.wav" -b "$bitratek" -ar "$freq" "$basename.mp3" )
 ;;
 lame)
 cmd=( lame --resample "$freq" -m s -b "$bitrate" "$basename.wav" "$basename.mp3" )
 ;;
 esac

 "$cmd[@]" || continue

 [ -s "$basename.mp3" ] || continue
 t="`file -b "$basename.mp3"`"
 [ "$t" != "$ot" ] || continue
 ot="$t"

 echo "$test;$i;$enc;$bitrate;$freq;"$basename.mp3";"$cmd[*]"" >"$basename.csv"
 i=$((i+1))
 done
 done
done
cat ?/*.csv >alltests.csv
rm ?/*.wav ?/*.csv

Note: As you can see: in the above version of the implementation, $i doesn't exactly match for the encoders A and B in case some formats didn't convert, but this is not a limitation for the final analysis, only a bit confusing for the listener, and easy to fix if too confusing.