[flac-dev] C API: How to get a seektable for very long files?

[Stefan Oltmanns]

Am 15.10.24 um 19:03 schrieb Martijn van Beurden:
>
> No, seeking to a specific sample can take a while because of all the
> back-and-forth, but seeking to almost the end of the file is very quick.
>
> I know this is not the cleanest way, but as this only for the rare cases

Ah, I see, because the frame header also include either the sample
number (variable frame size) or the frame number (fixed frame size). I
assumed the stream would have to be decoded from the point of the last
seekpoint to the end

>
> There are already a lot of applications reading FLAC, with and without
> libFLAC. Changing behavior and the spec like this is going to break some of
> them, because the changes you propose also affect files with fewer samples.
> total samples being 0 can and does happen for files that were created by a
> streaming encoder for example.
>

I think I have an even better idea now that definitely won't break any
decoder:
-Create a normal last seekpoint pointing to the very last frame. Total
samples should be that seekpoint + frame length

To indicate that the last seekpoint is pointing to the last frame, there
should be two placeholders:
First has the offset set to ASCII "TOTALSMP", the next one all zeros.
That some encoder adds placeholder seekpoints with that pattern just by
chance is almost 0.

When the decoder scans the seekpoints, the total_samples is 0 and if it
detects that two placeholders it will set total_samples to that value.

I don't see an issue with that? Old files are treated by new decoder
just like before, new files are treated by old decoder also just like
before, only new file and new decoder will result in that feature.
And this only affects files with more than

> So, adding an API function that applications need to adopt is a feature,
> not a bug. I really don't want to modify existing behavior when it is not
> strictly necessary.
>

I'm not saying a new API call is a bug. But as this is such a niche
case, that I don't think many programs will incorporate that feature,
because the need is not seen (and being able to open the file in an
audio player for quick check and random points is a great feature). If
libflac just returns the correct total sample value you can just
recompile libflac on your system and it will work.
Additionally I think there is one issue: there are only 31 bits for the
frame number, with a frame size of 4096 this is "just" 2^43 samples,
which maybe not enough in every case (SDR with higher sample rate?), and
smaller frame sizes are possible. And for variable block length it's
again 2^36.
Of course in combination with the last seekpoint this could work, but
without a seektable it's again problematic.

Best regards
Stefan