By the way I had gapless = true.
Maybe this could be the reason why?

Actually, even with gapless = false I still get the issue.

After reading the flac demuxer, it turns out that it currently ignores both gapless and the seek mode.

This loop seems suspicious to me, it seems that the loop can only forward. Maybe I don't understand correctly what those function do.

I've opened #262

Maybe this is what happens:

1. the binary search cuts too close to the desired seek point, yet it cuts before it
2. the algorithm then switches to the linear search which skips over the desired seek point, there's a comment "overshoot ..."

I believe the linear search doesn't work, maybe when it is at the edge?

By the way I could run flac -a and flac -t on the file in question and it didn't report any problem.
So I think that the issue is in Symphonia.

Thanks for this. I think your PR and solution makes sense. I'll give it some testing on my end.

The goal of the binary search is to find the FLAC frame that contains the sample with the desired timestamp. The timestamp of the FLAC frame is the timestamp of the first sample in that frame. So it would make sense to use >= instead of >. That may have been a typo.

After reading the flac demuxer, it turns out that it currently ignores both gapless and the seek mode.

FLAC is naturally gapless and contains enough timing information to implement a cheap accurate seek, so these two options are not relevant to FLAC!

The PR isn't enough to fix the issue.
I've added the following behavior in my reader to workaround this issue and it worked:

1. seek Accurate to N
2. if seek didn't work, seek accurate to N - M * K until it seeks before N
3. read up to N

I'd suggest that symphonia does something similar in order to honnor the interface contract.

seek(pos, is_accurate)
{
   do_seek(pos, is_accurate);
   if (is_accurate)
   {
      assert did_seek_accurately;
      if (!did_seek_accurately)
         seek_accurately_using_workaround(pos);
   }
}

Could you provide a test vector that reproduces your problem?

Asserting is not an acceptable solution since that will panic the end-user application. It is very conceivable that a broken (e.g., a file with missing FLAC frames), or malicious file could trigger a failure.

A fix should be implemented for well-formed files, but for other cases I think the behaviour is acceptable.

@pdeljanov yes, I can share one file with a seek offset, but not publicly as it isn't free music. How to send it to you?

@abique Thanks. You can send it to philip (dot) deljanov (at) gmail (dot) com.

@pdeljanov sent.

Thanks! Fixed!