Suppose you have an audio codec which is a part of a broadcast system (any system for that matter). What are the possible errors that might creep in the bitstream when it reaches the decoder? (There will be CRC check for each packet in the network layer, but I am concerned about the bitstream when it reaches the decoder.. what are the chances that the bit stream is corrupted?)
Taking AAC HE as an example, Coding Technologies provides erroneous bitstreams for SBR (although SBR has CRC check) as a part of its certification package (wherein for example one bit in every third frame is corrupted - a random corruption!), whereas ISO does not(?) provide erroneous bitstreams. Of what value are erroneous bitstreams to the decoder? Is there a value add in generating erroneous bitstreams for decoders? If so, what is the approach so that it matches what happens in the real time?

Since when does a CRC reliably detect ALL errors in the bitstream ALL of the time?

The probability of errors creeping in till the decoder escaping CRC check is realy very very low(nearly zero)!!! So the purpose of testing decoder against these is not justified!!! And the concealment can be expensive( trade-off)
Under these circumstances , the standard bodies give error streams. What is the purpose??

Well, you can transmit your signal over different transport channels. If your transport channel has no error detection, you need to add it on your own. What about broadcasts? There is no way to ask the server to give you the last record again.

ya. But errors can creep in any part of bitstreams and in any random manner.A single bit error in the header can cause the decoder to crash. So do u think the decoder should be robust enough to handle those kind of errors as well??

A CRC error in your broadcast scenario will flag some bit errors. But you don't know where it happens. Maybe the audio part is intact and the bit error happened elsewhere in the stream, then the decoder may play back the audio at least. The more you know about in which part the error may have been, the more possibilities for the decoder to handel that case. Iff there is one bit error in the SBR part only, the decoder still may play back the LC part instead of muting the whole audio.

CT is the only body which provides error bitstreams. Why in that case there are no erroneous bitstreams for AAC to test the robustness and hence for the compliance?

That's teh difference between theory and real life.
If you have to write a decoder, then in theory you only have to test compliance against correct streams.
In real life, if you really want your decoder to be usable, it has to be robust.
No one would use in its product a decoder that would badly crash when encountering errors in the stream.

There is also the cases where error concealment would be an important feature of your decoder, as in streaming cases. Usually it's a better idea to pass the corrupted packet to the decoder, even if you know it's corrupted, as the decoder might be able to partially decode it. Decoders KNOW how data should be, and how to handle gracefull degradations, while your transport layer has no idea about it, it only knows that current data is wrong somewhere.

fine!! Then why aren't there any erroneous bitstreams(take for eg AAC) available in the market to validate the robustness of the decoder??

Because corrupting streams is easy to do yourself?

Thanks for all the views!!
But , one thing that is bugging is " why CT (coding technologies) market it and not others like ISO??/( little of marketting here not technical)!!!