On macOS, for MP4 -> AAC we have bit depth options of 16, 24 and 32. If Windows does not have these options, this suggests that the options are provided by the OS encoder. Therefore, it's possible that the Windows encoder does not have the necessary option, in which case there's nothing BMD can do about that besides using a different encoder.
I did some research which I believe confirms this.
Here's the documentation for the Windows AAC Encoder.
The Microsoft Media Foundation AAC encoder is a Media Foundation Transform that encodes Advanced Audio Coding (AAC) Low Complexity (LC) profile, as defined by ISO/IEC 13818-7 (MPEG-2 Audio Part 7) .
It only supports 16bit PCM as input:
I guess in the Quicktime case a different encoder must be used. That does raise the question of: why are different encoders used, and couldn't the encoder that's used for Quicktime also be used for MP4? Especially as in both cases it's ffmpeg's LibAV that writes the container. Perhaps there's some technical or legal reason for this use of two different encoders, but on the surface it does seem a bit odd.
In general, I was rather confused why Windows was limited to 16bit, and why on macOS you have to choose between 16 vs 24 vs 32. AAC, like MP3, has a variable bit depth that changes from sample to sample. I think it's usually regarded as being 32-bit float?
So logically you would think one should just pass in the source audio - at its native bit depth. With ffmpeg you'd certainly do that, and it would use whatever source audio you had to create the AAC.
But as we see from the Windows AAC docs, it seems these OS encoders require PCM input of a fixed bit depth, so there's an unfortunate but necessary conversion step first. I couldn't quickly find docs for the macOS equivalent
I tested on macOS, doing three test renders where I rendered out a video with WAV dialogue track to MP4 H264 AAC with the AAC export bit depth set to:
- 16-bit
- 24-bit
- 32-bit
My source audio in Resolve for these exports was 24bit PCM.
I then imported these exports into Reaper and inverted the phase of the 24-bit version. I then did two test renders: 16 + 24bit (inverted phase), and 24bit (inverted phase) + 32bit.
The second render was a 100% null; there was no difference between 24bit and 32bit renders.
But the 16bit and 24bit test did show some minor differences between those two outputs.
This implies that choosing 16bit when the source audio is 24 will involve a conversion down to 16bit which can lose data. I assume choosing 24bit when source audio is 32bit would do likewise.
Therefore if in future I use MP4 with AAC I will always be choosing 32bit as the source option. If my audio is lower bit depth (24 or 16), it will make no difference to the output. But it ensures I don't accidentally select 16 when my audio is actually 24, or select 24 if my audio is 32bit.
For Windows users I would recommend always using the Quicktime output, then remuxing to MP4 using ffmpeg or Shutter Encoder.