#4954: joint stereo indicator missing from mp3 headers ------------------------------------+------------------------------------ Reporter: pico4743 | Owner: (none) Type: defect | Status: open Priority: normal | Component: avformat Version: git-master | Resolution: Keywords: mp3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+------------------------------------ Comment (by GraniteStateColin): This longstanding bug still exists in ffmpeg. It has to do with the way ffmpeg uses libmp3lame. It does set the header to Joint Stereo, but doesn't actually encode in Joint Stereo. MP3 players that require Joint Stereo will choke on these files (a common requirement among older MP3 players, generally not an issue with newer players). The -joint_stereo 1 option does NOT work as a parameter in ffmpeg. Because it changes the header to "claim" it's Joint Stereo, that's why many here mistakenly believe that there is no bug. There absolutely is a bug and has been for years. For an easy test if the data itself is encoded in Joint Stereo, if you don't have access to an old player to see it fail to play, fortunately there are applications that check the audio data in place of the header/metadata, like the freely available Mp3tag. Its "Mode" column shows "Stereo" for output from ffmpeg. Here's an example of a simplified ffmpeg command that always yields a Stereo file and NOT a Joint Stereo file: ffmpeg -i input_file.mp3 -f mp3 -joint_stereo 1 -id3v2_version 3 Joint_Test_output_file.mp3 Another way to confirm that the problem exists is to use another program to correctly convert to Joint Stereo and then compare. For example, SoX does correctly convert to Joint Stereo. Here's a command I use in Windows to convert files and get around the bug in ffmpeg (where I use a WAV file intermediary to reduce loss from MP3, but this does strip out other metadata, which keeping at as MP3 would not, nor would it be necessary to use SoX if ffmpeg did not have the Joint Stereo bug): for %x in ("*.mp3") do (ffmpeg -i "%x" -f wav -af dynaudnorm -id3v2_version 3 "int_%x.wav" & sox --norm=-3.25 "int_%x.wav" -c 2 -C 192 -r 44100 "ready-%x") If you look at the those resulting files in Mp3tag, you will see that unlike the pure ffmpeg command, after the SoX command, they show a Mode value of "Joint Stereo." This comment should provide enough information to reproduce the problem and confirm if it's fixed. Please correct this longstanding bug in ffmpeg. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4954#comment:7> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker