[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