[FFmpeg-trac] #4954(avformat:open): joint stereo indicator missing from mp3 headers

FFmpeg trac at avcodec.org
Thu Jun 22 15:15:29 EEST 2023


#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


More information about the FFmpeg-trac mailing list