[chrizzchrizz]

Problem

Some M4A files carry trailing data after the mdat atom, for example zero bytes left as padding by tag editors. Once the stream reaches it, AudioFileStreamParseBytes fails with kAudioFileStreamError_InvalidFile ('dta?'), although every audio packet has been parsed already. The player then raises streamParseBytesFailure while the entry is still playing, about one buffer length before the audible end of the track.

Seen with a real file: ftyp, moov, free, mdat (ends at byte 4885649), then 32648 zero bytes up to the end of the file. The same happens with a plain AudioFileStream outside the library, and all 7756 audio packets are delivered before the error.

Change

• AudioFileStreamProcessor tracks the stream byte offset of the data passed to the parser (reset on open, set to the seek offset in processSeek).
• If parsing fails for an M4A/MPEG4 stream once that offset is past dataOffset + audioDataByteCount, the error is ignored and the rest of the stream is dropped. The final flush is skipped in that case.
• All bytes are still passed to the parser as before. Nothing is truncated ahead of time, so no audio can be lost even if audioDataByteCount is smaller than the mdat atom (e.g. chapter tracks inside mdat). Errors inside the audio data are reported as before.
• Other formats are unchanged.

Tests

Mp4TrailingDataTests:

• A small AAC m4a fixture with 4096 zero bytes after mdat, fed in 1 KB chunks through AudioFileStreamProcessor: all chunks and the final flush return noErr and no error is raised. Without the change this test fails with 1685348671 ('dta?') at the chunk that crosses the end of mdat.
• Unit tests for the boundary check (inside, at the end, after the end, unknown byte count).

The full test suite passes on macOS.

[chrizzchrizz]

Audio streaming isn't my area of expertise. So I had to rely on Claude Code to fix the issue. In my opinion, it worked well and the bug is gone, but I need your expertise for the final assessment.

Thx
Chrizz