joint stereo indicator missing from mp3 headers

[pico4743]

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

[GraniteStateColin]

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.

[mrapp]

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.

[Balling]

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?

[mrapp]

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?

[Balling]

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.