8

With a wav file for example you can easily distinguish between bit depths

24-bit

Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, 
                    s32, 2116 kb/s

16-bit

Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo,
                    s16, 1411 kb/s

However AAC seems inscrutable

Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo,
                         fltp, 151 kb/s
Zombo
  • 1
  • 24
  • 120
  • 163

3 Answers3

12

AAC is a lossy format (like MP3), and as Wikipedia (indeed, the same article you linked to) explains:

Bit depth is only meaningful in reference to a PCM digital signal. Non-PCM formats, such as lossy compression formats, do not have associated bit depths. For example, in MP3, quantization is performed on PCM samples that have been transformed into the frequency domain.

Zombo
  • 1
  • 24
  • 120
  • 163
Karan
  • 55,947
  • 20
  • 119
  • 191
9

ffprobe reports correct bit depth but only when there is a bit depth to report, otherwise it reports correctly that "bit-depth" is not applicable (N/A).

In FFmpeg's report of the data field "bits_per_raw_sample" and per Karans answer, "bit-depth" is misnomer for AAC encoded audio.

If you are trying to probe the data file, you might want to grep -e for "codec_name" to discern which streams (video, audio, text) the "bits_per_raw_sample" is reporting. This makes it easy to know if the reported bit-depth status pertains to the video codec or the audio codec:

$ ffprobe -show_streams <input_file.mp4> | grep -e codec_name -e bits_per_raw_sample

...example of a resulting video and audio datafile report:

codec_name=h264           <----- video
bits_per_raw_sample=8     <----- 8-bit depth video
codec_name=aac            <----- AAC audio
bits_per_raw_sample=N/A   <----- bit depth is "Not Applicable" to AAC audio

You might enjoy this article, "Audio Encoding Demystified"

Bit depth

Along with sample rate, there is also bit depth to consider. The bit depth is the number of digital bits of information used to encode each sample. In simple terms, bit depth measures “precision”. The higher the bit depth, the more accurately a signal can communicate the amplitude of the actual analog sound source. With the lowest possible bit depth, we only have two choices to measure the precision of sound: 0 for complete silence and 1 for full volume. The higher the bit depth, the more precision one has over their encoded audio. As an example: CD quality audio is a standard 16-bit, which gives 216 (or 65,536) volumes to choose from.

Bit depth is fixed for PCM encoding, but for lossy compression codecs (like MP3 and AAC) it is calculated during encoding and can vary from sample to sample.

...so, to address the question, "How to determine AAC bit depth?" I suppose you'd have to do it on a sample per sample basis.

Community
  • 1
MmmHmm
  • 738
  • 11
  • 24
  • *for lossy compression codecs (like MP3 and AAC) it is calculated during encoding and can vary from sample to sample* -> there will still be a ceiling on the bit depth. If a MP3 is encoded from a 16-bit PCM source, then one wouldn't expect 24-bit precision upon decoding. – Gyan Feb 01 '17 at 05:51
  • @Mulvya, ffmpeg is in ongoing development. If you want to, you could author an feature for ffmpeg which analyzed each sample's bit depth and reported that range, however, "bits_per_raw_sample" is not a constant integer with AAC and the authors of ffmpeg have seen fit to address this standard of digital audio by reporting that the term "bit-depth" is "not applicable" (N/A) to AAC files. – MmmHmm Feb 01 '17 at 06:03
  • @Mulvya, likewise, it could be useful to know the range, but I don't really see how except in edge cases and what would be gained by calculating the entire range as part of a meta-data print out? FFmpeg is built for speed. Like i said, tho, this option could be added as a feature if and when you want ffmpeg to report such, however, for the industry standards "bit-depth" is misnomer for describing AAC files. – MmmHmm Feb 01 '17 at 06:12
  • @Mulvya to be clear, you make a valid and sound point. If you deem the question or answer useful, please vote accordingly. Thanks! – MmmHmm Feb 01 '17 at 06:20
1

Truth that those formats are not exactly bit size per sample, but you can take an approximation by having in mind two variables: sample rate and bitrate.

If you know that the sample rate means how many samples per second (for example if you have 44100 Hz, that means that 1 second 44100 samples are played) and the bitrate (in my case is 95kb/s) then you know that 95000 bytes/second divided by 44100 samples/second = 2.1542 (approximately) bytes/sample. That are a bit more than a 16-bit quality encoding. So, you can decode greatly to 24 bits per raw sample at 44100Hz, with the following command of ffmpeg:

ffmpeg -i input.mp4a -acodec pcm_s24le -f s24le -ar 44.1k -ac 2 out.pcm

It won't be exactly 24 bits so it may be oversized, but you won't lose quality if you convert to a lower quality.

help-info.de
  • 1,822
  • 5
  • 17
  • 19
Nayara
  • 11
  • 2
  • Also, if you want to know the coding information, you can use just: ffmpeg -i input.mp4a instead of ffprobe. – Nayara Aug 03 '23 at 13:14
  • Welcome to Super User! Before answering an old question having an accepted answer (look for green ✓) as well as other answers ensure your answer adds something new or is otherwise helpful in relation to them. Here is a guide on [answer]. There is also a site [tour] and a [help]. – help-info.de Aug 03 '23 at 14:26
  • The answer gives a tip but not a clear example, so my answer adds a suitable information. – Nayara Aug 03 '23 at 14:46