Olivier Langlois's blog

Everyone located near Montreal and is reading this blog is welcome to join!

http://www.linkedin.com/groups?gid=2035024

The group description:

Local group for C++ professionals located in the Montreal region desiring to discuss and meet other professionals of the Montreal C++ programming industry. Join and grow your network to beat all obstacles in your career. Discuss, Seek or Share your valuable knowledge with all group mates.

Also, you are welcome to visit my LinkedIn profile to know more about me:

http://www.linkedin.com/in/olivierlanglois

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:

Definitions:

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]

0<=bit_reservoir_state[frame]<=max_bit_reservoir

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.

This book has been published in 1993 and iostreams has changed a lot since then so this book is a bit outdated. Things that were not there in 1993 include:

• extension less header files
• std namespace
• IO stream classes were not templates
• No locale and facet classes
• classes that are now deprecated strstream

Surprisingly even with all these changes, most of the code in the book would still compile today. This is one sign that C++ designers took a great care to not break existing code unless absolutely necessary. The book is divided into different chapters. Materials that have still value today are:

• The first 3 chapters that explain why a programmer should prefer using io streams over printf
• The next few chapters describing the translator classes (istream,ostream,etc)
• Even if the code is rather cryptic in my opinion, there is a chapter that shows how to write table based extractor and inserter functions (operator<< and operator>>). One application of such function, for instance would be to implement a regular expression processor with a DFA.

There are easier ways to implement regular expressions with the boost library. The value that I see in the third point is that I have always kept my own operators << and >> very simple and I have found this part of the book was eye opening to what was possible to do with these functions.

The chapter that I have found to have failed the test of time is the last and very lengthy chapter that presents close to 50 small test programs so you could test that your iostream implementation was compliant with the latest C++ draft specifications for iostreams. At the publishing time, it was perhaps needed as C++ implementations were trying to catch up with a moving standard but today, iostreams specifications have been stable for many years. I think that it is safe to take for granted that your iostreams behavior is compliant with the standard or it should be a total shame for the library developer if it is not the case.

To conclude, since the book is still accurate on most points, it can still be handy as a reference if it is hanging around. However, at the same time, since iostreams have changed in subtle ways since the publishing date, I would recommend looking for a more recent book for a new purchase. I have not read it but 'Standard C++ IOStreams and Locales' might be a better choice.

I have got interested in this book because I have read from many sources on Mr. Koenig involvement in several key elements of the C++ language such as argument dependant lookup (ADL), also called the Koenig lookup, and the intersect rule for function overloading. In fact, if you read the book 'The design and evolution of C++', Andrew Koenig name is omni present throughout the book. So I was curious to see what Mr. Koenig had to say on C++.

Reading this book has been like a roller coaster ride. First, the cover is intriguing with its recursive pattern where you can see a girl under a tree in a field with cows in the background reading the 'Ruminations on C++' book with the same cover repeating itself over and over. Then the book is divided into six parts and, in my opinion, not all parts are equally good. The first part is taking a more philosophical view on what the C++ language aims to achieve. This part is not too technical and it has somehow a lot of appeal to my eyes. While reading this part, I was thinking that this was very promising for what was to come.

Then at the second part, it is where things are getting spoiled. Part 2 is describing basic C++ techniques. It is not bad but by having read tons of C++ books, to appreciate one of them, I must find some originality that I haven't found in part 2. This part of the book is average.

Finally, I have changed another time my opinion on the book when I have reached part3. Part3 covers templates and more specifically it recreates the whole though process that the STL designers went through to create STL. I see a lot of value to this kind of activities as I believe that understanding why certain things are done in a certain way can help you to better use those things.

In conclusion, I can recommend this book because I feel that mister Koenig goes beyond just the language syntax and try to teach a though process that someone has to go through to solve programming problems. This is a pedagogical approach not found in every programming book.

I had to create a XML schema at my job for the very first time. This is something that I have never done before and I was a total neophyte on XML schemas. A coworker has lent me this book and I would say that after having been through the book in 2 days, it did its job. I have been able to complete my task and I have created a fairly complex XML schema. One quality that I appreciate in technical books is when the book is entertaining and interesting to read. I know that for the non initiated, technical and entertaining might seem incompatible but I have read such books. XML Schema does not have that quality. However, it has the quality to be extremely good to make its readers learn XML schema. If you need to learn XML schemas, you can read this book. It will not be fun but once you are done with it, you should have a pretty decent understanding on the topic.

Another aspect that I have noted is that on very rare circumstances, that book was lacking clarity in my opinion. There are few sections that I was really trying to understand what the author wanted to explain but after many readings of the same section, I did gave up on trying. The section named 'Asymmetry of these two methods' in chapter 7 is one example of what I am describing.

In conclusion, after weighting in the qualities and the problems of this book, I can recommend this book with confidence for anyone that must learn XML schemas.