I have a question regarding the "directory" part of the xHE-AAC audio super frame. This directory consists of Frame border index (12 bits) + Frame border count (4 bits). Frame border count is evaluated in Dream 2.2 in the xheaacsuperframe.cpp file in the XHEAACSuperFrame::parse() function, in the variable frameBorderCountRepeat. The DRM specification (https://www.etsi.org/deliver/etsi_es/201900_201999/201980/04.01.02_60/es_201980v040102p.pdf) says that Frame border count in the Directory portion should equal Frame border count in the Header portion, and even if the Header is corrupted (fails Fix Header CRC check), the decoder should still be able to get Frame border count from the Directory portion.
I am using an xHE-AAC based test DRM wav file for my input, and the Fixed header CRC check always passes. However, for some iterations I get frameBorderCountRepeat != frameBorderCount (that is, Frame border count information in Directory does not match the one in Header; keep in mind that I never get CRC error in header). Is this normal? This does not happen for all frames but for the first 20 or so frames. If this is not normal, how serious of a problem is it? What I mean is, if (frameBorderCountRepeat != frameBorderCount ) happens for a particular audio super frame, does it corrupt the decoding of all following audio frames, or only those audio frames related to the erroneous superframe? If I find just one (frameBorderCountRepeat != frameBorderCount ) error, should I expect my whole input to be undecodable from that point onwards?
Last edit: mahaju 2019-10-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
for some iterations I get frameBorderCountRepeat != frameBorderCount (that is, Frame border count information in Directory does not match the one in Header; keep in mind that I never get CRC error in header).
I guess the most likely immediate cause is corruption in audio super frame payload. I have not this problem with OTA broadcast signal or the test file hosted on SourceForge. Better check your SNR or your DRM signal generating source. BTW, you can also check with CRC for each audio frame after frame parsing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have rechecked the code and I can now confirm that this happens on the first 3 superframes and does not happen after that. I just want to confirm, would a problem like this make the whole DRM file undecodable, or can subsequent superframes still be deocded since this error does not happen in them?
Last edit: mahaju 2019-10-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Problems like this only cause temporily drop-out. After that , the decoder will resync and proceed to produce correct audio output , provided you data is correct after resync.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a question regarding the "directory" part of the xHE-AAC audio super frame. This directory consists of Frame border index (12 bits) + Frame border count (4 bits). Frame border count is evaluated in Dream 2.2 in the xheaacsuperframe.cpp file in the XHEAACSuperFrame::parse() function, in the variable frameBorderCountRepeat. The DRM specification (https://www.etsi.org/deliver/etsi_es/201900_201999/201980/04.01.02_60/es_201980v040102p.pdf) says that Frame border count in the Directory portion should equal Frame border count in the Header portion, and even if the Header is corrupted (fails Fix Header CRC check), the decoder should still be able to get Frame border count from the Directory portion.
I am using an xHE-AAC based test DRM wav file for my input, and the Fixed header CRC check always passes. However, for some iterations I get frameBorderCountRepeat != frameBorderCount (that is, Frame border count information in Directory does not match the one in Header; keep in mind that I never get CRC error in header). Is this normal? This does not happen for all frames but for the first 20 or so frames. If this is not normal, how serious of a problem is it? What I mean is, if (frameBorderCountRepeat != frameBorderCount ) happens for a particular audio super frame, does it corrupt the decoding of all following audio frames, or only those audio frames related to the erroneous superframe? If I find just one (frameBorderCountRepeat != frameBorderCount ) error, should I expect my whole input to be undecodable from that point onwards?
Last edit: mahaju 2019-10-21
I guess the most likely immediate cause is corruption in audio super frame payload. I have not this problem with OTA broadcast signal or the test file hosted on SourceForge. Better check your SNR or your DRM signal generating source. BTW, you can also check with CRC for each audio frame after frame parsing.
I have rechecked the code and I can now confirm that this happens on the first 3 superframes and does not happen after that. I just want to confirm, would a problem like this make the whole DRM file undecodable, or can subsequent superframes still be deocded since this error does not happen in them?
Last edit: mahaju 2019-10-21
Problems like this only cause temporily drop-out. After that , the decoder will resync and proceed to produce correct audio output , provided you data is correct after resync.