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

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.

Am 14.10.24 um 16:30 schrieb Martijn van Beurden:
> Op ma 14 okt 2024 om 16:06 schreef Stefan Oltmanns <stefan-oltmanns at
gmx.net>:
>
> 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.
>
Currently I'm testing and recording sine waves to check everything
works, therefore I'm using audio software right now. I think the decoder
uses ffmpeg, which doesn't use libflac at all.
>>
>> 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.
I see, but that would require changes in the software using libflac and
require the file to be easily seekable to be able to skip to the end and
depending on how far away the seek points are, it could take a while.

My idea would be to modify "read_metadata_seektable_" in the
stream_decoder.c, that it will set
"decoder->private_->stream_info.data.stream_info.total_samples"
if it
finds that special seek point, this should not require any software
change (unless the total_samples are used by the application before the
seektable is read)

As there is a sanity check "seek_table->points[i].frame_samples >
0"
adding a final seekpoint with "frame_samples" set to 0 should work
(not
sure if the specification explictly states how to handle seek points
with frame_samples == 0).

I know this is not the cleanest way, but as this only for the rare cases
with more than 2^36 samples, this should not affect a lot of people.

Best regards
Stefan