I was trying to reconstruct ADTS headers from a raw AAC data stream and for most of header fields by knowing the stream properties, it is a straightforward task. There is, however, one exception. It is the ADTS 'Buffer fullness'. There is not much information about its purpose and how it is composed anywhere (including the Internet and the ISO IEC standards 13818-7 and ISO IEC 14496-3). After some analysis of the problem I came to the conclusion that 'buffer fullness' is not reconstructable reliably. However, doing this exercise has allowed me to get a better understanding of 'buffer fullness'. So for the next persons who will google 'AAC ADTS buffer fullness' in hope of finding some info, here is what I have learned:
Buffer fullness is a 11 bits field in the ADTS header. Its purpose is not very clear so I will expose what I know about it:
NCC = Number of Considered Channels. In our case 2
minimum Decoder input size = 6144*NCC = 12288
mean number of bits per block:
For a 96 kbps stereo signal at 44.1 kHz
(96000 bit/s / 44100 samples/s * 1024 samples/block) = 2229.1156 bits/block
maximum bit reservoir = minimum Decoder input size - mean number of bits per block
= (12288 bits - 2229.1156) = 10058
bit_reservoir_state[frame] = bit_reservoir_state[frame-1]+mean_framelength-framelength[frame]
adts_buffer_fullness=bit_reservoir_state/(NCC*32) (In other words, the state is shifted to the right to drop the 6 LSBs)
The purpose of the bit_reservoir_state is to control the encoder bitrate. The reservoir value gets lower as the encoder outputs frames longer than the mean framelength. Once the reservoir value gets near to 0, this will force the encoder to send few frames shorter than the mean framelength to refill the bit reservoir. If the encoder has prepared a frame and it is too long to respect the bit reservoir constraint it will perform a second pass on it to compress it further. If it is too short, it will add padding to it (with an AAC raw data block fill element type (FIL)) . The consequence of this is that on average each AAC frame will have the same length and the bitrate will be constant.
One observation is that the bit reservoir state is internal to the encoder and you cannot deduce it from the buffer fullness because you do not have the 6 missing LSBs of the state from buffer fullness.
Also the standard ISO IEC 13818-7 and ISO IEC 14496-3 are not clear about what a decoder can do with the buffer fullness. The open source faad decoder ignores it. The open source faac always set it to VBR (all ones) even if it has been configured to do constant bitrate. WinAmp AAC decoder uses it to display the stream bitrate. If the special value reserved for VBR is used, the displayed bitrate will vary, otherwise it will display a constant value (ie 96kbps) no matter what value it is. It could be a constant arbitrary value (ie:0), random or the values from a true encoder, it does not matter to this decoder.
I guess that a decoder could use the buffer fullness to predict approximately the frame length it risks to encounter down the stream but I have never seen a decoder using it.
AAC is a new audio codec standardized to supersede the MP3 codec. When I hear about new technologies, I am always a little skeptic since I have long understood that newer technology is too often not synonym with better technology. However, at the company that I am working for, StreamTheWorld, we have developed the first system that stream AAC through Flash players. On StreamTheWorld website, there is a demo where the player connects to one MP3 stream and to one AAC stream with the same bitrate of 48 kbps. Both streams contain the same song and the demo consists of slider that allows you to switch between the AAC version and the MP3 version. You must absolutely check the demo! (PS: Make sure that you have the latest Adobe Flash player installed as AAC playback as being added only in the latest release which is 9.0.115) The difference is so convincing that you will probably want to start converting all your music to AAC!
One note about AAC, is that there exist many versions of AAC. I am listing them in the order that they have been released:
All versions provide improvements over the previous versions and also provide backward compatibility. That is you could listen an AACPlus v2 stream with an MPEG2 AAC decoder. However, the additional information contained for AACPlus v2 will be discarded and the resulting audio will only be as good as an MPEG2 AAC audio stream can be. Players supporting AACPlus v2 includes:
iTunes support AAC but not AACPlus v2. Sony with its PS3 and Nintendo with the Wii gaming console have made AAC their official audio codec but I do not know which version they are supporting.
I want you to find in this blog informations about C++ programming that I had a hard time to find in the first place on the web.
|<< <||> >>|