[chrizzchrizz]

Problem

Decoders output the encoder delay (priming) and padding (remainder) of AAC and MP3 as if they were audio. processPacketTableInfo already reads kAudioFileStreamProperty_PacketTableInfo, but only uses it for the duration. So between two queued entries there is a short silence: for AAC 2112 priming frames plus the remainder of the previous file, about 50 ms. On continuous material (DJ mixes, live albums) this is audible as a stumble at every transition.

Change

• processPacketTableInfo stores priming, valid and remainder frames on the entry.
• While decoding from the start of the stream, only the decoded frames in [priming, priming + valid) are kept. Leading frames are dropped by moving the kept frames to the start of the decoded segment in the ring buffer.
• After a seek the decoded position is not exact (e.g. MP3 bit reservoir), so instead the remainder is dropped from the end of the buffer at end of file (trimTrailingGaplessPadding(), called in endOfFileOccurred after the final flush; same lock order as the renderer). The same fallback applies when an entry is re-read from a seek offset, or when the packet table info arrives after decoding has started. A seek to the start of the data keeps the exact position, so the priming is still dropped.
• Frame counts are converted from the source to the output sample rate; the end of the kept range is rounded once, to avoid an off-by-one with resampling.
• Repeated packet table info is ignored once the values are set.
• Streams without packet table info are unchanged.
• The trim math lives in GaplessTrim and is covered by unit tests (GaplessTrimTests: chunks inside the priming, straddling the start, inside the valid range, straddling the end, after the end), plus a test for the decoded position after reset.

Measurement

Two files cut from one continuous 440 Hz sine (66273 + 66027 frames at 44.1 kHz), played with play + queue, output captured through frameFiltering:

Files	Before	After
AAC (afconvert)	2328 frames of silence right after the first file's 66273 valid frames	no silence, phase jump 0.0 samples
AAC (ffmpeg)	silence	no silence, 0.0
MP3 (lame)	silence	no silence, 0.0
AAC 48 kHz (resampled to 44.1 kHz)	silence	no silence, 0.0
AAC / MP3 with a seek in the first file	silence at the transition	no silence at the transition

The short silence at the seek position itself is the same with and without this change (it varies between runs). A seek to 0 also plays the transition without silence. The full test suite passes (71 tests, including the new ones). The measurement itself relies on real-time playback, so it is not part of the test suite; I can add it if you want it in the repo.

Also verified on device (iOS) in an app that uses AudioStreaming: the stumble between tracks of an AAC DJ mix is gone.

[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 gap is gone, but I need your expertise for the final assessment.

Thx
Chrizz