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

[Martijn van Beurden]

Op ma 14 okt 2024 om 16:06 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>:
>
> Unfortunately that doesn't seem to be the case. I just made a capture
> that is > 30 Minutes with total samples set to 0 and a seek table: All
> players I tried cannot seek in the file and cannot determine it's
> length: VLC, Celluloid and DeaDBeef
>
> I wondered why I can seek files I manually compressed with flac from
> raw: The total samples field is just wrong, the seek table is correct,
> having sample_numer values a lot higher than total samples. The players
> display the wrong length. Seems to be a bug in flac.
>

I meant that when seeking to a certain sample, the stream decoder can
in fact use the seektable despite not knowing a total number of
samples. Of course, players, especially with GUIs, have to deal with
not knowing a total number of samples. When you click on some progress
bar, the input application has to translate your click to a target
number of samples to pass to libFLAC. These application could decide
that they disable seeking when a total number of samples is unkown.
That is beyond the reach of libFLAC. If the total number of samples is
not 0 but wrong, I assume seeking is only possible up to that wrong
number.

However, if you have some kind of decoding application using stream
decoder directly (which I assumed is your use case) that should work
just fine.

>
> Just an idea: Of course the size of the total samples field cannot be
> changed, and a seektable currently doesn't seem to work with total
> samples = 0.
>
> Is it possible to extend the specification with full backward
> compatibility in a way like this?
>
> If total samples is 0, the last seek point in the seek table that is not
> a place holder can indicate the total number of samples:
> In case frame_samples is 0, stream_offset is pointing to the last frame
> and sample_number is the total number of samples.
>
> FLAC__stream_decoder_get_total_samples would check that and return the
> correct value.
>
> Not sure if that breaks any old versions / 3rd party decoder. Another
> option would be to use the first place holder, set stream_offset to the
> total samples and some magic value in frame_samples. That should
> definitly be backward compatible as these values are undefined for
> placeholders.
>
> Another option would of course be to add a new type of
> metadata, like METADATA_BLOCK_STREAMINFO2, but I don't know how
> backwards compatible that is.
>

I have plans to add an API function that returns the total number of
samples if unknown or wrong. It should work by seeking to almost the
end of the file, finding the last frame and returning the number of
samples that follows from it. That way, the data in streaminfo is
bypassed entirely. This would also allow the metaflac utility to add
seektables to files with an unknown number of samples, and for the
flac utility to transcode such files.