[Mp4-tech] [Audio] SBR decoding

[Andreas Schneider]

Devilal,
the MPEG-4 audio standard has the answer to 1 and 2:
an extension_type of 0 means that this is simply fill data. Such elments 
may be inserted by the encoder to prevent overflows of its bit-buffer. 
They do not contain data that is relevant to decoding.
regarding 3: This is outlined in more detail in the SBR conformance 
standard (ISO/IEC 14496-4:2004/Amd.8:2005). The conformance testing 
procedure needs this layout of the data.
Regards,
Andreas
mp4-tech-bounces lists.mpegif.org wrote on 16.01.2024 11:54:40:
> Hi,
> I am doing SBR decoding with some streams downloaded from ISO 
> website. Some of the streams are: al_sbr_cm_48_1.mp4, 
> al_sbr_cm_48_2.mp4, al_sbr_e_44_2.mp4, al_sbr_i_44_1.mp4, 
> al_sbr_ps_02.mp4(this steams has Parametric Stereo also), 
> al_sbr_sig_48_2_sig1.mp4 and al_sbr_sr_24_2_fsaac12.mp4.
> 
> I have a couple of questions related to SBR decoding:
> 
> 1. In one frame the following syntactic elements are coming - 
> ID_CPE/ID_SCE i.e Channel Pair Element(for Stereo) or Single Channel
> Element(for Mono) 
> ID_FIL - Fill Element 
> ID_FIL - Fill Element
> ID_END - to end the syntactic elements
> 
> My question is why do u need fill elemets two times?
> 
> 
> 2. The fillExtType being decoded is 13 for fist call of fill element
> and is 0 for second time. 
> I understand that 13 is corresponding to EXT_SBR_DATA and 14 for 
> EXT_SBR_DATA_CRC i.e. SBR with CRC which has 10 extra bits in the 
> SBR Extension data element. I assume that we have streams without 
> CRC check, so, the number 13 is corresponding to EXT_SBR_DATA and is 
correct.
> 
> But what is the significance of second fill elements in the 
> syntactic elements? Moreover, it does not do anything in the 
> decoding as it always decodes 0 as fillExtType. 
> 
> 
> 3. In case of fillExtType == 13 (the first time decoding of fill 
> element) it does decode SBR header_flag bit and it is always 0 . 
> After knowing that header_flag is 0 (i.e. header_flag NOT SET), the 
> decoder does not decode SBR header and it just does up-sampling and 
> not SBR decoding(i.e. HF Generation, HF Adjustments and other steps).
> 
> This is happening with all the streams I mentioned above. The 
> reference software from ISO i.e. mp4mcDec is also doing the same 
> thing. Is this correct decoding for these streams or something wrong
> with my decoding? Are there other streams for SBR decoding which 
> follow the missing decoding in the current case?
> 
> -- 
> Regards,
> Devilal 
> 
> --------------------
> Mobile: +91-9986423985
> email: devilal gmail.com
> ------- _______________________________________________
> NOTE: Please use clear subject lines for your posts. Include [audio,
> [video], [systems], [general] or another apppropriate identifier to 
> indicate the type of question you have.
> 
> Note: Conduct on the mailing list is subject to the Antitrust 
> guidelines found at http://www.mpegif.org/public/documents/vault/mp-
> out-30042-Antitrust.php
--
Andreas Schneider
Senior Research Engineer
mailto:snd CodingTechnologies.com
+49 911 92891 -26 (phone)
+49 911 92891 -99 (fax)
Coding Technologies GmbH
Deutschherrnstr. 15-19
D-90429 Nuernberg, Germany
http://www.codingtechnologies.com