Media info not able to differentiate between ESBR and PS extension data.

[patilyash19]

Hi, I have observed some discrepancy with MediaInfo(version 22.12 on Windows) for streams with eSBR data. From the experiments which were conducted, it appears that MediaInfo does not differentiate between various types of SBR extensions. “bs_extension_id” field indicates the type of SBR extension and can either be reserved, or “EXTENSION_ID_PS“or “EXTENSION_ID_ESBR”. MediaInfo always reports the stream as PS (parametric stereo) irrespective of the extension type. I have attached the snippet of the media info tool. I have added an mp4 file for reference. https://user-images.githubusercontent.com/97579762/220100441-eecc0b95-a02d-45b3-97d0-06056f5aef3e.mp4 I have performed the following experiments to verify this: • I tried changing the “bs_extension_id” field to reserved value (0/1). Still, the tool reported the stream as PS. I have added an mp4 file for reference. https://user-images.githubusercontent.com/97579762/220100565-60915020-3be3-465e-a20b-b5cb44a2b718.mp4 • “Format” for eSBR conformace streams is reported as “AAC LC SBR” (which is correct). So, I have analysed its content and found that these streams do not have SBR data in the initial frames. The SBR data appears after few 100s of frame (nearly in the second half of the stream only). When I generated such a stream, MediaInfo seems to report the “Format” as “AAC LC SBR”. It appears that the tool reads initial few frames to update the “Format” and related fields. I have added an mp4 file for reference. https://user-images.githubusercontent.com/97579762/220100680-29694173-d449-4cc1-b374-e79cc18da1f1.mp4 Can you please confirm if MediaInfo can differentiate between the different SBR extensions? And why is such a discrepancy seen with eSBR streams?

[JeromeMartinez]

From the experiments which were conducted, it appears that MediaInfo does not differentiate between various types of SBR extensions.

True. We stopped the development at the PS part, our version of the spec is without another SBR extension.

MediaInfo always reports the stream as PS (parametric stereo) irrespective of the extension type. [...] I tried changing the “bs_extension_id” field to reserved value (0/1). Still, the tool reported the stream as PS

This is due to a big mistake from the stupid (I can say this word because... It was me) developer, who forgot to skip the remaining bits in case of an unknown extension, then the bits are wrongly parsed and PS is wrongly caught. Fix on the way.

“Format” for eSBR conformace streams is reported as “AAC LC SBR” (which is correct).

I don't get this one. It seems that bs_header_flag is never (I checked the 10 seconds) 1 with this file, so SBR is detected but it can not be parsed, so SBR extensions can not be caught. Am I right? If not, how do you catch the eSBR content in this file?

---

Back to the real eSBR file. thanks to public patents I can see the bs_extension_id for eSBR, but now wondering about how to show it, as I see no commercial name for it (the "commercial name" in the track title seems not common at all). right now the PR has this output:

Format                                   : AAC LC SBR eSBR
Format/Info                              : Advanced Audio Codec Low Complexity with Enhanced Spectral Band Replication
Commercial name                          : HE-AAC
Format profile                           : High Efficiency AAC@L5
Format settings                          : Implicit

"SBR eSBR" because eSBR is inside a SBR element and we show the needed feature and fallbacks in case something is not supported (here, if eSBR is not supported, SBR is possible). Does it seem not too weird for someone in the field? Any "commercial name"? Also, we already saw eSBR but in another format (USAC), and the SBR ratio is indicated in the USAC header, here I don't see where it is, and actually it seems that the SBR part already does the job (frequency of 48 kHz), does it mean that eSBR in AAC does not permit a ratio not 2, that eSBR does not add more ratio than the SBR part, as it could be in USAC (8:3 or 4:1 possible ratios)?

[patilyash19]

I don't get this one. It seems that bs_header_flag is never (I checked the 10 seconds) 1 with this file, so SBR is detected but it can not be parsed, so SBR extensions can not be caught. Am I right? If not, how do you catch the eSBR content in this file?

Yes, you are correct. We need ‘ bs_header_flag’ field for detecting SBR. I feel ‘bs_extension_id’ field is the only way to catch eSBR content.

Does it seem not too weird for someone in the field? Any "commercial name"?

Just a suggestion, you can set “commercial name” as “HE-AAC eSBR”.

Also, we already saw eSBR but in another format (USAC), and the SBR ratio is indicated in the USAC header, here I don't see where it is, and actually it seems that the SBR part already does the job (frequency of 48 kHz), does it mean that eSBR in AAC does not permit a ratio not 2, that eSBR does not add more ratio than the SBR part, as it could be in USAC (8:3 or 4:1 possible ratios)?

Yes, eSBR in AAC does not permit ratio other than 2:1.

[JeromeMartinez]

Yes, you are correct. We need ‘ bs_header_flag’ field for detecting SBR. I feel ‘bs_extension_id’ field is the only way to catch eSBR content.

Just for being sure: in this specific file, the SBR (so the eSBR) can not be decoded because the SBR header is never there, right?

Just a suggestion, you can set “commercial name” as “HE-AAC eSBR”.

Will do.

Yes, eSBR in AAC does not permit ratio other than 2:1.

So no change of frequency from SBR to eSBR, I keep the SBR frequency.

[patilyash19]

Just for being sure: in this specific file, the SBR (so the eSBR) can not be decoded because the SBR header is never there, right?

Yes, correct.

[JeromeMartinez]

You may be interested in testing the latest Windows GUI snapshot.