dr_flac: Do not use the seektable if pcmFramIndex is not coverd by it.

[Bendrien]

The seektable of some .flac files might start with a pcm frame greater then 0. Therefore a requested pcmFrameIndex could be from before the beginning of the seektable. This in turn confuses the computation of byteRangeLo and byteRangeHigh down the road.

This is a simple fix of the issue by early returning from drflac__seek_to_pcm_frame__seek_table(...) to fall back to the next available seek method. I guess the best would be to always fall back to the brute force method, right?

[mackron]

Thanks for this. I just took a quick look at the FLAC spec, and indeed they don't explicitly mention that the first seekpoint should start at frame 0, just that they need to be sorted properly. I think a fallback to brute force in this case would be acceptable because in this scenario, you would expect the seek target to be close to the start of the file so it shouldn't be too bad.

I'll review this when I get a chance and report back.

[mackron]

I've reviewed this and I'm happy with your change. I was considering the idea of inserting a seekpoint that always points to PCM frame 0 if one doesn't already exist, but what you've got here is all you really need and is the simpler solution.

Merged into the dev branch and will be released soon. Thanks for this!

[mackron]

This has been released.