Am 14.10.24 um 16:30 schrieb Martijn van Beurden:
Op ma 14 okt 2024 om 16:06 schreef Stefan Oltmanns <stefan-oltma...@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
_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
