Native AAC-enocoder doesn't create constant bitrate.

[maxmanus]

Summary of the bug:
How to reproduce:

% ffmpeg -i input -c:a aac -b:a 320k -af aresample=resampler=soxr -ar 48k  ... output
Output is then variable bitrate.

If I just write -b instead of -b:a 320k it creates constant bitrate but then it defaults to 192k

ffmpeg version N-114629-g1590a96adc-20240403
built on ...gcc 13.2.0 (crosstool-NG 1.26.0.65_ecc5e41

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[Balling]

Neither of those produce true constant bitrate, you need -bit_rate_tolerance 0 option. b92af7b64e7acd015aea3ae1da2228c5a7e677bf

Output is then variable bitrate.

it does decrease bitrate if the sound does not need needed amount of data, but bit_rate_tolerance 0 has bugs ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/517a57ef18398a39952fcc1d02e51ef423cf80ae.1726262133.git.pav@iki.fi/

[maxmanus]

Ok, but when I write just -b it does show as constant bitrate in mediainfo.
If -b:a 320k it shows as variable. I want it to show as constant. No way to fix this?
I'm using qaac now because of this, but seems buggy when muxing together after with ffmpeg.

Replying to Balling:

Neither of those produce true constant bitrate, you need -bit_rate_tolerance 0 option. b92af7b64e7acd015aea3ae1da2228c5a7e677bf

Output is then variable bitrate.

it does decrease bitrate if the sound does not need needed amount of data, but bit_rate_tolerance 0 has bugs ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/517a57ef18398a39952fcc1d02e51ef423cf80ae.1726262133.git.pav@iki.fi/

[maxmanus]

Replying to maxmanus:

Ok, but when I write just -b it does show as constant bitrate in mediainfo.
If -b:a 320k it shows as variable. I want it to show as constant. No way to fix this?
I'm using qaac now because of this, but seems buggy when muxing together after with ffmpeg.

Replying to Balling:

Neither of those produce true constant bitrate, you need -bit_rate_tolerance 0 option. b92af7b64e7acd015aea3ae1da2228c5a7e677bf

Output is then variable bitrate.

it does decrease bitrate if the sound does not need needed amount of data, but bit_rate_tolerance 0 has bugs ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/517a57ef18398a39952fcc1d02e51ef423cf80ae.1726262133.git.pav@iki.fi/

Is there any difference though? Quality and support wise on TVs and other platforms?
I started messing with this because I used to convert to 384k before, and noticed sound dropping out on my samsung tv under playback. Might av been because of too high bitrate. Haven't reproduced this issue after changing to 320k.

Is it true that the native encoder at 320k variable is same quality as with qaac 320k constant?

[Balling]

Qaac is much superiour than two-loop in ffmpeg.

That option if for headphones, bluetooth likes close to perfect constant bitrate.

[maxmanus]

Replying to Balling:

Qaac is much superiour than two-loop in ffmpeg.

That option if for headphones, bluetooth likes close to perfect constant bitrate.

I'm not sure I understand.
At that bitrate, shouldn't the quality be the same? I've not heard any difference with 320k with ffmpeg native aac as variable and qaac with 320k constant. Just thinking about support on devices. Strange ffmpeg makes it variable for me, when I specify constant. I used fdk before, but such a hassle to build ffmpeg every time.
Why is this still a problem though with ffmpeg. A good aac encoder should'nt be a big deal in my eyes. I don't get it. I thought aac at these bitrates should be the same.
Now when using qaac standalone together with ffmpeg the duration of the audio and video always slightly different. Can't find sync problems, but I read that if a delay is in the metadata it will get deleted with qaac.

[Balling]

I'm not sure I understand.

Bluetooth A2DP supports AAC. It is literally the only codec in Apple after Apple removed AptX in MacOS.

At that bitrate, shouldn't the quality be the same?

Nah, Qaac from Apple is superior.

Now when using qaac standalone together with ffmpeg the duration of the audio and video always slightly different

That is because Apple uses 2112 samples and we use 1024 samples of priming. those should be removed, as they are just garbage. It is even more complex in HE-AAC(v2).

I read that if a delay is in the metadata it will get deleted with qaac.

Yes, qaac decoder supports sample accurate removal of both two styles of gapless metadata, ITunSMPB and edit lists.

[Balling]

Anyway, here it is said that true VBR is not supported, only ABR

​https://stackoverflow.com/q/59693214

And wiki says the same: ​https://trac.ffmpeg.org/wiki/Encode/AAC

Native FFmpeg AAC Encoder does not do CBR audio encoding.

So...