Opened 7 years ago
Last modified 23 months ago
#4954 open defect
joint stereo indicator missing from mp3 headers
Reported by: | pico4743 | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | mp3 |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
mp3 header files created by ffmpeg do not specify a channel mode of joint_stereo when joint_stereo is performed by libmp3lame.
Details:
libmp3lame provides a switch (-joint_stereo) to select either joint_stereo or plain stereo. The interface to lame works correctly so that the audio frames are fine, but ffmpeg doesn't use the lame library to write the mp3 header.
Instead libavformat/mp3enc.c sets the channel mode to either MONO or STEREO based on how many channels there are.
switch (codec->channels) { case 1: channels = MPA_MONO; break; case 2: channels = MPA_STEREO; break; default: av_log(s, AV_LOG_WARNING, "Unsupported number of channels, " "not writing Xing header.\n"); return -1; } ... header |= channels << 6;
MPA_JSTEREO should be used when appropriate. The repair doesn't seem simple, but I'd be willing to help if someone wants to discuss approaches.
How to reproduce:
use a version with libmp3lame enabled % ffmpeg -i input.mp3 -joint_stereo 1 output.mp3 The relevant bits of the output.mp3 header will be 0 == MPA_STEREO ffmpeg version -- git master fb4d350
Change History (6)
comment:1 by , 7 years ago
Keywords: | joint_stereo header removed |
---|
comment:2 by , 5 years ago
comment:3 by , 2 years ago
Not only does it not set the channel mode bit properly on encoding, it doesn't recognize it on decoding. Using an externally created joint stereo MP3 file (verified with mediainfo
), ffmpeg -i joint_stereo.mp3
will just show stereo.
follow-up: 5 comment:4 by , 2 years ago
Status: | new → open |
---|
doesn't recognize it on decoding
But it decodes it correctly? Then why does this matter? If on the other hand we will add support for this will no it break other players or even hardware ones?
comment:5 by , 2 years ago
Replying to Balling:
But it decodes it correctly? Then why does this matter?
Yes, but it misreports to the end-user.
If on the other hand we will add support for this will no it break other players or even hardware ones?
how? joint-stereo is already enabled by default, but the header is not set to indicate it was used. that itself might lead to issues in some players. how can fixing this discrepancy lead to issues?
comment:6 by , 23 months ago
I do not know what you used to read the data, but joint stereo 2 bit and MS Stereo two bit are set (and on some SS mode is set), just not from the first Frame 0 - Tag (Xing) frame. From the Frame 1.
Much bigger problem is CRC absence, IMHO (at least in the header, by LAME).
Also -joint_stereo 1 is the default, just FYI and not MS/SS was not supported for a long time.
This problem is still a problem. It's very easy to reproduce per pico4743's explanation above.
Another way to reproduce: Install the current released version of ffmpeg for Windows (don't think the OS matters, but that's what I happened to be using) 3.3.2 as of this post. Convert a file from WAV to MP3 using the '-joint stereo 1' flag. Test the status of the file with Mp3tag -- shows Stereo instead of Joint Stereo. Note that the same LAME library used in Audacity correctly sets the file to Joint Stereo.
In my case, I was banging my head against this before finding this bug report which confirms the problem I was seeing. Basically, the -joint_stereo switch is useless, because anything playing the file thinks it's still in stereo, and NOT joint stereo. Programs like Mp3tag report the output files as Stereo and not as Joint Stereo making this easy to test and validate.