Issue 121 was a regression since v2.84. On this version I switched to a new buffering I/O reader for performance reason, but very long path name support was lost since then.
Issue123
The exact conditions that trigger issue #123 are still unclear, but there are cases where the FLAC stream decoder fails to transition cleanly into the EOF state after reaching the physical end of the file. Instead, it may enter a resynchronization loop. In such cases, even though the actual end of the stream has already been reached, libFLAC repeatedly seeks back and attempts to read again, causing the trailing bytes near the end of the file to be re-read and preventing the decode process from completing.
This release includes two fixes addressing the problem:
- Revised EOF callback behavior
The EOF callback implementation has been updated so that when a short read occurs due to reaching EOF, the decoder is informed that the stream is at EOF from that point onward. Previously, similar to stdio’s feof(), EOF was only reported after a zero‑byte read.
With this change, the abnormal resynchronization behavior observed in issue #123 no longer occurs for the affected file. - Early termination based on STREAMINFO total samples
Decoding now terminates once the number of decoded samples reaches the total sample count specified in the FLAC STREAMINFO block.
This serves as a safety mechanism to ensure decoding completes even if libFLAC fails to transition into the EOF state.