Repository navigation
44.1khz FLAC seek issue #133
Description
Hi, really love the library minus one small quirk I'm noticing. When I seek a 44.1khz FLAC song it seems to seek to the wrong frame, which then propagates all the way to the end where the song plays past its duration. Only happens when I seek and only on FLAC, more specifically 44.1khz FLAC. If I play the song in its entirety without seeking it plays fine. I've tried m4a files and those work fine even with seek.
Compared with other players that support FLAC like IINA, VLC, and SFBAudioEngine and noticed that the player is behind by a few seconds when seeking. So say I seek to 1:13 using the AudioStreaming library, it seeks to where all the other players would be at like 1:09. So naturally the song also ends up finishing past its stated duration.
Thanks for spending the time on this and please let me know if this is a known issue or if there's something wrong with how seek works on FLAC.
Activity
Minidoracat commentedon Oct 5, 2026
I can reproduce this with remote FLAC streams. I ran into it through Amperfy: synced lyrics went out of step after every seek.
The cause is in
AudioFileStreamProcessor.processSeek(). The byte offset is estimated as(time / duration) * dataLength, and the requested time is kept asseekTimeunlessAudioFileStreamSeekreturns an exact offset. While FLAC is streaming it never does, so the proportional guess is always used. FLAC is variable bitrate, so playback resumes from a different frame than the requested time, whileprogresskeeps counting from the requested time. That's the "behind by a few seconds" you saw, and it carries on until the track plays past its duration.On a 44.1 kHz / 16-bit FLAC, comparing where the audio actually was (ffprobe packet table) with what
progressreported:A 320 kbps CBR MP3 of the same track lands within 0.02 s.
I've opened #141 with a fix. After a FLAC seek, it reads the sample number from the first frame header and uses that as the seek time.