I'm making this a P5 and assigning to myself, to give me a chance to learn the codebase better.

Created attachment 73 [details]
Patch for exporting to mono channel MP3.

Simple patch to src/export/ExportMP3.cpp so it can handle exporting to mono.

Ashton, you added your patch while I was writing this, and I have not looked at your patch.   

I agree P5 enhancement is about what it deserves. It only really affects people
who sometime want mono MP3 export but also sometimes work with stereo tracks.
If the user exports a mono track, the current dialogue already exports a
single-channel file.

If you haven't seen it already, see the linked URL. Personally I "think" ATM we
don't need the complexity of a mono tab in the MP3 export options. Just add a
"mono" radio button to "Channel Mode" and decide what it does. I think that is
all most GUI MP3 encoders do. We should look at some of those for ideas.  

Possibly selecting "mono" should grey out parts of the interface if that's
needed, and possibly reduce the currently selected bit rate in the case of
exporting a stereo track. Or if the button said: "Mono - Bit Rate reduced if
exporting stereo track" that might just cover it. RTFM for the details.   

That said, LAME at the command line only use half bit rate with -m m if the bit
rate isn't specified. Otherwise it of course uses the specified rate.

Gale,

The patch I submitted simply adds a radio button and the correct back end links to allow for mono exporting, just as you suggested. I think I can change it so that the bit rate will half if the user is exporting a stereo track. Now should I automatically do that in the UI, thus necessitating doubling the kbps once the user selects stereo or joint stereo again, or should I set this behind the scenes and somehow let the user know that the rate will be halved behind the scene.

Also, what modes would be inappropriate for mono? I'm assuming perhaps Variable or Average? I'm not terribly familiar with LAME, but I'll go RTFM in the mean time, since I'm assuming this patch will wait until after 1.3.13.

(In reply to comment #4)
My feeling would be that if we are going to do this at all we have to have some "half bit rate" feature in it, not just mono at the given bit rate. But mechanistically halving the bit rate for mono export from stereo will give people worse quality in some cases. -m m I think takes into account the bit rate mode and the content in deciding how much to reduce the bit rate. So I wonder if we should have two buttons "mono" and "mono (reduce bit rate)"?  

Looking what -m m does at the command line, it seems it *does* affect the bit rate for ABR and for presets, but not CBR (unless you leave bit rate unspecified). But when I used -b with VBR to set the minimum bit rate, it looked to me as if -m m was not reducing the bit rate. I think you will need to research into exactly what our ranges of bit rates for VBR do. I am no expert. 

I notice that not all the ABR/CBR rates have exact half equivalents in the menu (and may not even be valid if halved). I'm inclined to think "working behind the scenes" for whatever bit rate reductions we do is better than having the selected quality change when you switch to mono. 

Are you any good at Widgets? I would like to see bug 64 fixed - would have saved me a lot of time testing the above...

(In reply to comment #5)

Okay. I'm going to futz about with LAME a bit and determine if there's a way to let LAME automatically determine what bit rate it should use for downsampling, as it does in the command line client (hopefully that logic isn't in the CLI code itself).

For the time being I'm going to have two options, one lets the user decide their own sample rate, and another where all the options are blanked out, either letting LAME or Audacity decide what the bit rate should be. I haven't decided exactly how to word the two options yet though.

(In reply to comment #6)
>  two options, one lets the user decide their own sample rate
I assume that's a typo for bit rate?

> and another where all the options are blanked out, either letting LAME or 
> Audacity decide what the bit rate should be. 
Just to be clear, does the "blanked out" option only come on when you have more than one track, and does this explicitly always force single-channel output? 

How many options are blanked out? You have to specify the bit rate mode, or CLI will just assume 128 kbps CBR. 

As I understand it ... the primary use case is that someone has decided they like the sort of quality that VBR2 or CBR 256 kbps gives them, but they want to reduce that bit rate automatically when exporting to single channel from stereo, because the bit rate then does not need to be as high to give the same quality.

(In reply to comment #7)

Yes, I meant bit rate.

Unfortunately It's not entirely clear to me how the LAME command line tool decides how to downmix non-mono tracks to mono. My experiments with the Audacity source indicates to me that if the quality isn't explicitly set, LAME automatically encodes to the same bit-rate as the original file I was working with. So if the user decided they liked the quality of CBR 256 or VBR2, I'm not entirely clear on how to set the settings to get an equivalent quality.

That being said, I feel that a lot of users will be confused on why Audacity is export to CBR 128 for stereo that was downmixed to mono when they had selected CBR 256, and I feel it's a bit odd to give so much real estate to Mono when most users will not export to it. I think it might make more sense to have a single Mono option (as far as the Mode radio buttons are concerned), and then add presets specifically for Mono that are marked as "Best for spoken words", or something similar.

Raised to P4 as this has attracted more votes in the last couple of years. 

The main feature request is more specific than that in the bug title  - namely that the default MP3 export action (no options changed) should be 64 kbps if the input is mono, as happens if exporting MP3 at the command-line (in Audacity or standalone LAME).

Fixed bug as stated in bug title:
https://github.com/audacity/audacity/commit/b5c5d5

> the default MP3 export action (no options changed) should be 64 kbps if the
> input is mono, as happens if exporting MP3 at the command-line (in Audacity
> or standalone LAME).

In standalone LAME, mono export is 64 kbps CBR if no other options are set.
In Audacity we always specify a "quality". 

Example:
In command line LAME conversion, if 128 kbps CBR is the selected export format and the mono ("-m m") switch is selected, then the MP3 file will be 128 kbps CBR mono. With the added "force export to mono" option selected, Audacity does the same.

If a VBR setting is selected, then the average bit rate IS reduced so as to achieve the desired "quality". Again this is the same in Audacity as in command-line use of LAME.

Tested this on W10 audacity-win-rb5c5d55-2.1.3-alpha-02-apr-16

The new export to mono MP3 seems to work as expected.  The default bitrates are higher than the 64 kbps mentioned earlier in this thread.  Bit then bitrates that users use have tended to go up since 2011 when this thread started, as diskspace has got larger and cheaper (so I support this change).


What puzzles me is why we have to call the checkbox "Force Export to mono" - surely it could just be simply labelled "Mono" - shorter and perfectly clear I would have thought.

(In reply to Peter Sampson from comment #11)
> What puzzles me is why we have to call the checkbox "Force Export to mono"

I don't have a strong attachment to the wording, but the reason is to contrast with the wording for the stereo options.

"Joint Stereo" and "Stereo" are the channel modes that apply 'IF' the project is stereo. IF the project is mono, then selecting either JS or S makes no difference - exporting a mono project ALWAYS produces a mono file.

The new mono option is different. When enabled, the MP3 will be mono, regardless of whether the project is mono or stereo. It "forces" the export to be mono. The "Force Export to mono" is equivalent to the "-m m" command line switch.

For the documentation:
"The input will be encoded as a mono signal. If it was a stereo signal, it will be downsampled to mono. The downmix is calculated as the sum of the left and right channel, attenuated by 6 dB."
http://linux.die.net/man/1/lame

(In reply to Steve Daulton from comment #12)
>"Joint Stereo" and "Stereo" are the channel modes that apply 'IF' the project 
>is stereo. IF the project is mono, then selecting either JS or S makes no >difference - exporting a mono project ALWAYS produces a mono file.

Yes, I noticed that while I was testing - so it occurs to me that IF that is the case, as it is, the surely now that we have the new "Mono" checkbox that when the user is exporting a mono track THEN the "Mono" checkbox should be selected by default AND the two stereo options should be gray-out and unavailable.

It doesn't make sense to be able to choose Stereo as you export otion - only to end up with a mono MP3 surely?

(In reply to Peter Sampson from comment #13)
> It doesn't make sense to be able to choose Stereo as you export otion - 
> only to end up with a mono MP3 surely?

Very briefly, your query is about the presentation of the JS/S modes in the MP3 export dialog, and is not directly about bug 285. Selecting JS or S is NOT setting the export to stereo. In other words, whether you select JS or S, you are NOT choosing to export a stereo MP3. All that you are doing is setting a switch in LAME.

If it were my choice, I'd remove the JS/S options from the interface because:
a) the confusion that you describe
b) very few users know what it actually does
c) very few users understand the pros / cons of each mode
d) much of the information on the Internet about these options is confused/confusing.
e) in almost all case, the JS option is better

Even if we decide to retain the JS/S switch and if we decide that we would like to grey it out when the exported files will all be mono, then it would be quite complex (and not very intuitive) to correctly handle every possible case in Export Multiple.

if this needs further discussion, then I'd suggest starting a mailing list discussion or a wiki proposal.

(In reply to Steve Daulton from comment #14)
I would NOT want to see the Stereo option removed.  

I Use Stereo/CBR/192 an awful lot for professional purposes.

(In reply to Peter Sampson from comment #15)
Whereas "LAME User Interface Guidelines" state:

"a checkbox allows to encode in mono (LAME will downsample). There is no choice between different stereo modes, as the default mode should be optimal. Other modes are likely to decrease quality."
http://lame.sourceforge.net/lame_ui_example.php
(Joint Stereo is the default mode)

(In reply to Steve Daulton from comment #14)
>Very briefly, your query is about the presentation of the JS/S modes in the MP3 >export dialog, and is not directly about bug 285. Selecting JS or S is NOT >setting the export to stereo. In other words, whether you select JS or S, you >are NOT choosing to export a stereo MP3. All that you are doing is setting a >switch in LAME.

Yes but it looks to the user, who has a mono track, when using those dialogs for Export Audio and Export Multiple that theu cann create a stereo MP3 from teir mono track 0 when they in fact can't.

It also looks odd that the S/JS are radio buttons wheras the Mono is a checkbox.

And I still don't like the wording "Force export to ..."

(In reply to Peter Sampson from comment #17)
The simplest (and my prefered) solution would be to remove the Stereo / Joint Stereo radio buttons and change the label of the "Force export to mono" checkbox to "Mono".

This would be following the recommendation of LAME's "User Interface Guidelines" http://lame.sourceforge.net/lame_ui_example.php

However, what we do / don't do with regard to the "Stereo / Joint Stereo" option is a different issue to bug 285.

Thanks, Steve. I tried it on all three platforms but mostly on Windows. 

Tested export multiple as well as straight export. Tested that the new setting persists in different projects and post-session. 

The more popular request for automatic "lame default" bit rate (128 kbps for stereo and 64 kbps for mono) is now at bug 1373. 

> "The input will be encoded as a mono signal. If it was a stereo signal,
> it will be downsampled to mono.
We should be careful to explain what that really means. The sample rate will not change because we set it in project rate. The bit rate will be not be reduced if CBR is selected. 

There always was potential confusion over what the JS/S buttons do when there is a mono track, but I don't recall users querying it. If the track is mono, Audacity forces -m m itself irrespective of the state of the radio buttons or checkbox. And so the checkbox label means in longhand "Force output to mono if it would otherwise be stereo". 

I don't support removing the JS/S stereo radio buttons despite many users don't understand JS and some think S must be better because "purer". If the radio buttons were removed, existing users would probably ask "how do you export stereo?" without even trying. And it's removal of choice. 

Making the mono checkbox a third radio button might even make more users think that you could export a mono track as a stereo MP3. 

My preferred solution ATM would be to keep the new checkbox, and replace the JS/S buttons with an off-by-default "Discrete Stereo" checkbox (it could have another label, but it is the same as the forced L/R stereo we do when selecting "Stereo" now). If unchecked, we do "Joint Stereo". It is greyed out if  "Force export to mono" is greyed out. 

I think it is better to create a new bug for making a better interface for channel mode options.