Bugzilla

The issue with the files I examined appears to be that the GASpecificConfig depend_on_core_coder flag is true, which requires the following 14 bits to indicate the core_coder_delay.  The entire GASpecificConfig is only 16 bits in this case (and we've already consumed 15 bits) so core_coder_delay is not present and the parser runs out of bits while trying to read it.  As far as I understand, depend_on_core_coder being set doesn't make sense for these files, since there are no other audio layers to reference.

[ffmpeg](https://github.com/FFmpeg/FFmpeg/blob/7730bacb413fcb59f30acef0b2c6d50c5e6382d6/libavcodec/aacdec_template.c#L831) (which Chrome uses for regular media playback) and [VLC](https://github.com/videolan/vlc/blob/e3f38be0ccab13d46041de208bcceb917278f289/modules/packetizer/mpeg4audio.c#L538) both play these files because they happen to ignore short reads during ESDS parsing.  In both cases, the bit reader returns 0 when there are no more bits to consume, and there's no error handling present to notice the short reads.

Other players I tried, including Chrome's MSE playback ([which uses a different AAC ESDS parser](https://chromium.googlesource.com/chromium/src/media/+/refs/heads/main/formats/mp4/aac.cc#258)), reject these files for the same reason as mp4parse-rust.

The AAX converters I looked at all seem to use ffmpeg to convert the file, which is decrypting and copying the track without examining the ESDS at all.  Based on this, the original AAX files must also have this flag set but also have a single audio layer, so I'm not sure why this flag is set.

While trying to find other instances of this, I came across https://rentry.co/n4ost which describes the same issue, also for files converted from AAX.  That site includes a script based on Bento4 to clear the depend_on_core_coder flag, making the files playable with mp4parse-rust and other parsers stricter than ffmpeg.

The issue with the files I examined appears to be that the GASpecificConfig depend_on_core_coder flag is true, which requires the following 14 bits to indicate the core_coder_delay.  The entire GASpecificConfig is only 16 bits in this case (and we've already consumed 15 bits) so core_coder_delay is not present and the parser runs out of bits while trying to read it.  As far as I understand, depend_on_core_coder being set doesn't make sense for these files, since there are no other audio layers to reference.

[ffmpeg](https://github.com/FFmpeg/FFmpeg/blob/7730bacb413fcb59f30acef0b2c6d50c5e6382d6/libavcodec/aacdec_template.c#L831) (which Chrome uses for regular media playback) and [VLC](https://github.com/videolan/vlc/blob/e3f38be0ccab13d46041de208bcceb917278f289/modules/packetizer/mpeg4audio.c#L538) both play these files because they happen to ignore short reads during ESDS parsing.  In both cases, the bit reader returns 0 when there are no more bits to consume, and there's no error handling present to notice the short reads.

Other players I tried, including Chrome's MSE playback ([which uses a different AAC ESDS parser](https://chromium.googlesource.com/chromium/src/media/+/refs/heads/main/formats/mp4/aac.cc#258)), reject these files for the same reason as mp4parse-rust.

The AAX converters I looked at all seem to use ffmpeg to convert the file, which is decrypting and copying the track without examining the ESDS at all.  Based on this, the original AAX files must also have this flag set but also have a single audio layer, so I'm not sure why this flag is set.  Ideally, the AAX converter tools would produce valid files that were playable by all MP4 parsers.

While trying to find other instances of this, I came across https://rentry.co/n4ost which describes the same issue, also for files converted from AAX.  That site includes a script based on Bento4 to clear the depend_on_core_coder flag, making the files playable with mp4parse-rust and other parsers stricter than ffmpeg.