<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op di 15 okt. 2024 16:18 schreef Stefan Oltmanns <<a href="mailto:stefan-oltmanns@gmx.net" target="_blank" rel="noreferrer">stefan-oltmanns@gmx.net</a>>:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I see, but that would require changes in the software using libflac and<br>
require the file to be easily seekable to be able to skip to the end and<br>
depending on how far away the seek points are, it could take a while.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I know this is not the cleanest way, but as this only for the rare cases<br>
with more than 2^36 samples, this should not affect a lot of people.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div></div>