M4A(AAC) Export does not honor the user's quality settings for bit rates below 196kbps in the export dialog

[petersampsonaudacity]

Bug description

M4A(AAC) Export does not honor the user's quality settings in the export dialog

a) At rates of below 196 kbps all seem to be exported at 196kbps

b) 200-320 seem to be reasonably close

Note too that the quality field in the export dialog can have numbers below 98 - but if you set a low number and then click elsewhere in the export dialog the rate changes to 98kbps (which I'm guessing is the minimum that Audacity/FFmpeg can handle

Steps to reproduce

1. import a 3 minute stereo song
2. Export as M4A(AAC) at various kbps bitrates
3. Use Explorer to examine the files' kbps and size
4. Observe: none are entirely accurately honored
   a) Rates above 200kbps seem OKish - better on Mac than on Windows
   b) rates of 196 and below all export at 196kbps

Expected behavior

Audacity should
a) honor the user's required set kbps rate
b) limit itself to only offering rates that can be realistically honored

Ideally it would limit itself to offering only the practical stepped rates that say iTunes offers for its AAC conversions:

Actual behavior with stereo exports

Windows 10
Updated tested results following an upgrade to the latest FFmpeg that @crsib recommended
Set rate / actual rate - stereo
64 - 196
98 - 196
128 - 196
160 - 196 (this is the default setting AAC export)
192 - 196
189 - 196
200 - 200
224 - 224
235 - 231
256 - 233
320 - 235 (this implies that 235kbps is the best we can achieve)

Mac - macOS 12.6.3 Monterey
Set rate / actual rate - stereo
98 - 198
128 - 198
144 - 198
160 - 198 (this is the default setting AAC export)
192 - 198
196 - 198
200 - 202
224 - 227
256 - 262
320 - 321

Audacity Version

3.2.4 and 3.3.0 alpha master

Operating system

Windows 10 and macOS 12.6.3 Monterey

Additional context

The user can use the up/down arrows to set the quality to be any integer value between 98kbps and 320kbps.

Or the user can type into the quality field
a) values below 98kbps are (silently) forced to 98
b) values above 320kbps are (silently) forced to 320

If we are going to offer the granularity of any integer number between 98-320kbps then we really ought to be honoring the user's setting.

But My thinking is that it would be much better of Audacity limited itself to a set of practical rates as Apple does with Music/iTunes as can be seen in the image above in the Expected Behavior section.

Flagging @Tantacrul @DilsonsPickles and @LWinterberg as this is a UX/design issue as much as it is a technical Audacity/FFmpeg issue.

[petersampsonaudacity]

I have not yet tested this on Mac - but when I tested last year
The slider setting value for AAC/MP4 export is not honored by Audacity - and the slider cannot make precise settings #1818

I found then:

No matter what I select for the requested rate the rate of the output file I get is always 196kbps and the file size is always 3.1MB

Also on Mac the last-used rate is never "remembered" and re-offered on the next visit to File Export as AAC - instead Audacity always offers the default rate of 160kbps

[petersampsonaudacity]

Incidentally this is my FFmpeg library - should I be using a later one? If so how does one manage an FFmpeg upgrade?

[LWinterberg]

If I understand this bit correctly:

audacity/src/export/ExportFFmpeg.cpp

Lines 446 to 456 in ea8163f

	case FMT_M4A:
	{
	int q = gPrefs->Read(wxT("/FileFormats/AACQuality"),-99999);
	q = wxClip( q, 98 * mChannels, 160 * mChannels );
	// Set bit rate to between 98 kbps and 320 kbps (if two channels)
	mEncAudioCodecCtx->SetBitRate(q * 1000);
	mEncAudioCodecCtx->SetProfile(AUDACITY_FF_PROFILE_AAC_LOW);
	mEncAudioCodecCtx->SetCutoff(0);
	break;

the value is clamped between 98 and 160 kbit/s per channel, meaning that stereo is clamped at 196-320 kbit/s.

Further, mediainfo reveals that stereo output is encoded in VBR while mono output is encoded in CBR.

I don't know why it switches, or why AAC refuses to use all of the bitrate it's being granted, I'd propose being explicit about when VBR vs CBR is used - and I given that AFAICT AAC-LC supports all modes that MP3 supports as well, it may be possible to just re-use the MP3 options

[petersampsonaudacity]

I don't know why it switches, or why AAC refuses to use all of the bitrate it's being granted, I'd propose being explicit about when VBR vs CBR is used - and I given that AFAICT AAC-LC supports all modes that MP3 supports as well, it may be possible to just re-use the MP3 options

Sounds like a plan Leo ...

---

@LWinterberg

the value is clamped between 98 and 160 kbit/s per channel, meaning that stereo is clamped at 196-320 kbit/s.

But that doesn't explain the 258kbps file that I got when I exported at 320kbps (I don't see much "c;lamping" there.

---

Further, mediainfo reveals that stereo output is encoded in VBR while mono output is encoded in CBR.
Which is not explained to the user in either the Export dialog or in the manual.

I can and will do some work on the AAC Export page in the manual as it is still showing the slider and still talks about it.

[crsib]

AFAICT AAC-LC supports all modes that MP3 supports as well,

I'm not sure what exactly do you mean.

---

As it has been previously discussed, we use something called native FFmpeg AAC encoder. It only allows to set preferred bitrate or preferred quality, and that's really it. It won't behave exactly as iTunes encoder does. It does not support "MP3 modes".

Please do not open issues claiming that current implementation does not work "as iTunes", because it will not work as iTunes. This is how FFmpeg works, we are not using iTunes to create AAC files. On top of that you have a very old FFmpeg version. Please download newer one from Buanzo. The version you have is very bad at hitting the bitrate target. It is 8 years old.

Right now, Audacity has a weird limitation Leo mentioned. It was carried over from the original FFmpeg implementation. It will likely be removed in the future, as Import/Export refactoring proceeds.

We have plans to add native AAC support on Windows and macOS. However even in this case Audacity on Windows and Audacity on macOS will behave differently. This won't be a bug. And FFmpeg backed compression will still use called native FFmpeg AAC encoder. And it's behavior will be kept intact.

[petersampsonaudacity]

Please do not open issues claiming that current implementation does not work "as iTunes", because it will not work as iTunes. This is how FFmpeg works, we are not using iTunes to create AAC files.

ACK

On top of that you have a very old FFmpeg version. Please download newer one from Buanzo. The version you have is very bad at hitting the bitrate target. It is 8 years old.

I did wonder about that @crsib - I have upfated:

But it begs a question ...

You now have a very nice mechanism for informing users that a newer stable released version of Audacity is available - BUT the user appears to have no similar mechanism for warning them (as in my case) that their FFmpeg is out of date and should be updated.

Is there any chance that we could have such a mechanism for FFmpeg - or even say test at installation time if the user already has an old FFmpeg installed and install it for them? Or possibly a "check for updates" in the Libraries prefs dialog?

[petersampsonaudacity]

OK so retesting with my updated FFmpeg I get better results for settings of 200kbps and above but 196kbps and below ALL export at 196kbps.

Implying that 196 stereo is the lowest that we support - and presumably 98kbps mono?
If this is the case then I can update the manual accordingly.

But it would help the user greatly if the M4a(AAC) Export dialog was a lot clearer about its capabilities and limitations with suitable error trapping and warning

[LWinterberg]

As it has been previously discussed, we use something called native FFmpeg AAC encoder. It only allows to set preferred bitrate or preferred quality, and that's really it. It won't behave exactly as iTunes encoder does. It does not support "MP3 modes".

I'm specifically talking about VBR and CBR encoding modes at different bitrates (or bitrate targets in case of VBR), which the FFmpeg AAC encoder in principle is capable of judging by the output I got earlier. However, looking a bit more into it - according to their docs, b sets CBR while q sets VBR, but their wiki says

This VBR is experimental and likely to get even worse results than the CBR. Native FFmpeg AAC Encoder does not do CBR audio encoding.

Weirder still, when testing with a plain ffmpeg 5.1.1 build I had flying about, a 30s silence always came out as VBR while a 3:30 song always came out as CBR and a 3:30 noise came out backwards (with b being VBR and q being CBR). This makes the bitrate settings and indeed output quality highly unrealiable.

Given all that, it seems like this encoder is massive jank, and exposing any UI regarding VBR and CBR is a lost cause.

Implying that 196 stereo is the lowest that we support - and presumably 98kbps mono?
If this is the case then I can update the manual accordingly.

That is the case. 98-160 mono, 196-320 stereo

---

On the upside, the Windows platform encoder seems simple enough from a user perspective. You get 4 options, take 'em or leave 'em. Their inclusion of HE-AAC v2 as a profile seems kinda weird though, given that Fraunhofer recommends it at bitrates between 8k-56k, and Windows only starts at 98k.

Finally, Apple AAC just looks very competent and unproblematic.

[petersampsonaudacity]

Given all that, it seems like this encoder is massive jank, and exposing any UI regarding VBR and CBR is a lost cause.

I'm strongly minded to agree

[petersampsonaudacity]

Summarizing this:

We are doing our users of AAC export a grave disservice, implying we can deliver more than we are capable of:

1. the default that we have of 160 kbps works fine for mono - but fails for stereo exporting at 196kbps

2. 196kbps stereo and 98kbps mono are the minimum bitrates we support - this is not made clear to the user in the GUI especially for stereo where 98kbps can be set and 196kbps is output.

3. the chosen rate seems good for 200-224, but 256 delivers 233 and 320 delivers a mere 235 - implying the maximum exported bitrate we can achieve is 235kbps (incidentally choosing 235 gets you a file with 231kbps

4. It is poor that the user can type any integer number outside the 98-320 range and is not blocked from so doing - nor are they warned. Rather Audacity just sets silently to 98 or 320 without informing the user, which means the user may well not notice. Note that, in contrast, if you try to type a non-numeric character that is properly blocked

5. The ability in the GUI to set any integer between 98 and 320 implies to the user that we have an ultra-fine level oc control over the kbps AAC export, which we clearly do not.

Recommendation

a) I recommend that we have a picking list rather than the variable integer selection (just as we do for MP3 export)
b) no mention of VBR or CBR or option to select either - as @LWinterberg suggested
c) the picking list should show rates for stereo and mono (in the same list item)
d) the picking list should only offer rates we can support

This would give us a somewhat sparse, but more honest, list:
196 stereo 98 mono
224 stereo 112 mono
256 stereo 128 mono

If the FFmpeg exporter that we use ever gets improved than the picking list can be extended

[petersampsonaudacity]

@LWinterberg @crsib

I updated my Mac today with Monterey 12.6.3, installed 3.2.4 and upgraded my FFmpeg to the latest version from Buanzo's site.

I added the full results to the initial post in this thread - but Mac is broadly similar to Windows except that it performs better for 256 and 320, yielding 262 and 321.

---

One other little oddity of a bear-trap, a residual, that I found while testing on Mac is that

a) if I use the up/down arrows to set the required bit-rate Audacity uses that bit-rate

b) if I type a number into the bit-rate field, the Audacity ignores that "setting" and instead uses the previously used setting

This does NOT happen on Windows, only on Mac.

Do we need a separate issue for this. or is it OK here as a residual ?

[crsib]

Do we need a separate issue for this. or is it OK here as a residual ?

I think this deserves an issue

[LWinterberg]

My preferred solution for this would be the following

• Native AAC support: Windows #3861 resolves this problem for Windows - it'd be a dropdown of the 4 options the encoder supports
• Native AAC support: macOS #3862 resolves it for macOS - a bit more complicated but whatever comes out of it should be more well-behaved
• For linux, it may be worth switching to the technically superior FDK AAC encoder (which is available on debian, ubuntu, fedora, SUSE, arch and others) (and even if not, it's comparatively easier on linux to use it from the (external program) option)

And FFmpeg backed compression will still use called native FFmpeg AAC encoder. And it's behavior will be kept intact.

Do you really want to keep it in the main list and not just remove it from the main dropdown and keep it accessible only through custom ffmpeg exporting?

[crsib]

Do you really want to keep it in the main list

At least for Linux I do

[petersampsonaudacity]

Do you really want to keep it in the main list and not just remove it from the main dropdown and keep it accessible only through custom ffmpeg exporting?

Hell yes - if AAC export was only available through custom FFmpeg exporting, it would likely frighten the life out of most normal users (it frightens and overwhelms me - I've only ever had to use it for QA testing in the past).

Custom export really is an expert level user tool, not for the novice, the ordinary Joe, or the faint-hearted ...

[LWinterberg]

the above is assuming that the platform-specific encoders will replace the FFMPEG encoder as the default option in the main dropdown.

[petersampsonaudacity]

Do we need a separate issue for this. or is it OK here as a residual ?

I think this deserves an issue

Done - see #4320

[petersampsonaudacity]

I have updated the AAC Export page in the manual:

https://alphamanual.audacityteam.org/man/AAC_Export_Options

[petersampsonaudacity]

I have re-run the tests today on W10 and macOS 12.6.8 Monterey with the latest 3.4.0 alpha,

The results have improved somewhat for Windows meaning that both give reasonably close results with stereo for setting of 196kbps and above:

Actual behavior with stereo exports

using the latest FFmpeg that @crsib recommended_

Windows 10
Set rate / actual rate - stereo
98 - 197 - lowest setting
128 - 197
160 - 197
192 - 197
196 - 197
198 - 199
200 - 201
224 - 225
235 - 236
256 - 256
320 - 256

Mac - macOS 12.6.8 Monterey
Set rate / actual rate - stereo
98 - 198
128 - 198
144 - 198
160 - 198
196 - 198
198 - 200
200 - 202
224 - 226
256 - 257
320 - 316

The close result for 256 on both platforms is particularly pleasing as that is a commonly used rate for quality music.