flac dev - Oct 2024 - C API: How to get a seektable for very long 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

Op di 15 okt. 2024 16:18 schreef Stefan Oltmanns <stefan-oltmanns at
gmx.net>:
>
> 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.
>
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
> with more than 2^36 samples, this should not affect a lot of people.
>
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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20241015/01a97b66/attachment.htm>