Re: C API: How to get a seektable for very long files?

--===============3621285416145666835==
Content-Type: multipart/alternative; boundary="000000000000b452e4062486efcd"

--000000000000b452e4062486efcd
Content-Type: text/plain; charset="UTF-8"

Op di 15 okt. 2024 16:18 schreef Stefan Oltmanns <[email protected]>:

>
> 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.

--000000000000b452e4062486efcd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">Op di 15 okt. 2024 16:18 schreef Stefan Oltmanns &lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank" rel=3D"noreferrer">st=
[email protected]</a>&gt;:</div><blockquote class=3D"gmail_quote" style=
=3D"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=3D"auto"><br></div><div dir=3D"auto">No, se=
eking to a specific sample can take a while because of all the back-and-for=
th, but seeking to almost the end of the file is very quick.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;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></b=
lockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">There a=
re already a lot of applications reading FLAC, with and without libFLAC. Ch=
anging behavior and the spec like this is going to break some of them, beca=
use the changes you propose also affect files with fewer samples. total sam=
ples being 0 can and does happen for files that were created by a streaming=
 encoder for example.</div><div dir=3D"auto"><br></div><div dir=3D"auto">So=
, adding an API function that applications need to adopt is a feature, not =
a bug. I really don&#39;t want to modify existing behavior when it is not s=
trictly necessary.</div></div>

--000000000000b452e4062486efcd--

--===============3621285416145666835==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
flac-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/flac-dev

--===============3621285416145666835==--