Re: Disable all checksum verification in flac/metaflac

--===============3886785503266597937==
Content-Type: multipart/alternative; boundary="000000000000cbe83a05ff520290"

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

Hi,

Is it possible for you to compile flac/metaflac yourself? Then you'll only
need to remove a few lines, namely these 4:
https://github.com/xiph/flac/blob/28e4f0528c76b296c561e922ba67d43751990599/=
src/libFLAC/stream_decoder.c#L2118-L2121
and these 7:
https://github.com/xiph/flac/blob/28e4f0528c76b296c561e922ba67d43751990599/=
src/libFLAC/stream_decoder.c#L2141-L2147
As you can see these lines are also disabled on fuzzing.

I think providing an API function and flac+metaflac command line option is
going to be confusing and they will probably be misused. A compile time
option might be possible though, libogg provides that too.

Kind regards,

Martijn van Beurden

Op do 29 jun. 2023 22:28 schreef Manuel Bertsch <[email protected]>:

> Hello all,
>
>
>
> I=E2=80=99m trying to use flac and metaflac as tooling to analyze the gen=
erated
> FLAC files of a new encoder implementation. However, while my own
> third-party decoder can handle the output just fine, flac, metaflac, and
> other tools discard the output since the frame checksum (footer CRC-16) i=
s
> invalid. This is expected, since I have no checksum generation implemente=
d
> apart from the frame header checksum (all other checksums are written as
> 0), but it prevents me from making development process without being able
> to check my outputs against the reference implementation. I looked around
> and I couldn=E2=80=99t find a way to turn off either tool=E2=80=99s check=
sum verification.
> So I=E2=80=99d like to know how one could turn off checksum verification =
in the
> tools, and if that=E2=80=99s not currently possible, I=E2=80=99d like to =
see that as a
> feature in a future version of flac. (In that case I would also try to
> disable the checks in code permanently, though my solution is most likely
> not going to be upstreamable in any capacity.)
>
>
>
> FYI, the third-party decoder is highly compliant according to the spec
> test suite, producing identical audio playback on almost all of the files=
,
> but it also doesn=E2=80=99t verify or error on any checksums. ffplay and =
ffmpeg
> both accept the file and can play and transcode it correctly, although th=
ey
> ignore the sample count in the streaminfo header and will read all frames
> they can find. The latter leads me to believe that checksums are the actu=
al
> issue, even though flac reports the generic =E2=80=9CBad Header=E2=80=9D =
and =E2=80=9CLost Sync=E2=80=9D.
>
>
>
> Greetings and thanks in advance,
>
>
>
> Kleines Filmr=C3=B6llchen
> _______________________________________________
> flac-dev mailing list
> [email protected]
> http://lists.xiph.org/mailman/listinfo/flac-dev
>

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

<div dir=3D"ltr"><div dir=3D"auto">Hi,<div dir=3D"auto"><br></div><div dir=
=3D"auto">Is it possible for you to compile flac/metaflac yourself? Then yo=
u&#39;ll only need to remove a few lines, namely these 4: <a href=3D"https:=
//github.com/xiph/flac/blob/28e4f0528c76b296c561e922ba67d43751990599/src/li=
bFLAC/stream_decoder.c#L2118-L2121">https://github.com/xiph/flac/blob/28e4f=
0528c76b296c561e922ba67d43751990599/src/libFLAC/stream_decoder.c#L2118-L212=
1</a> and these 7: <a href=3D"https://github.com/xiph/flac/blob/28e4f0528c7=
6b296c561e922ba67d43751990599/src/libFLAC/stream_decoder.c#L2141-L2147">htt=
ps://github.com/xiph/flac/blob/28e4f0528c76b296c561e922ba67d43751990599/src=
/libFLAC/stream_decoder.c#L2141-L2147</a> As you can see these lines are al=
so disabled on fuzzing.</div><div dir=3D"auto"><br></div><div>I think provi=
ding an API function and flac+metaflac command line option is going to be c=
onfusing and they will probably be misused. A compile time option might be =
possible though, libogg provides that too.<br></div><div><br></div><div>Kin=
d regards,</div><div><br></div><div>Martijn van Beurden<br></div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Op do 29 j=
un. 2023 22:28 schreef Manuel Bertsch &lt;<a href=3D"mailto:malu.bertsch@gm=
ail.com" target=3D"_blank">[email protected]</a>&gt;:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div link=3D"#0563C1" vlink=3D"#954F72" lang=3D"DE"=
><div><p class=3D"MsoNormal">Hello all,<u></u><u></u></p><p class=3D"MsoNor=
mal"><u></u>=C2=A0<u></u></p><p class=3D"MsoNormal"><span lang=3D"EN-US">I=
=E2=80=99m trying to use flac and metaflac as tooling to analyze the genera=
ted FLAC files of a new encoder implementation. However, while my own third=
-party decoder can handle the output just fine, flac, metaflac, and other t=
ools discard the output since the frame checksum (footer CRC-16) is invalid=
. This is expected, since I have no checksum generation implemented apart f=
rom the frame header checksum (all other checksums are written as 0), but i=
t prevents me from making development process without being able to check m=
y outputs against the reference implementation. I looked around and I could=
n=E2=80=99t find a way to turn off either tool=E2=80=99s checksum verificat=
ion. So I=E2=80=99d like to know how one could turn off checksum verificati=
on in the tools, and if that=E2=80=99s not currently possible, I=E2=80=99d =
like to see that as a feature in a future version of flac. (In that case I =
would also try to disable the checks in code permanently, though my solutio=
n is most likely not going to be upstreamable in any capacity.)<u></u><u></=
u></span></p><p class=3D"MsoNormal"><span lang=3D"EN-US"><u></u>=C2=A0<u></=
u></span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">FYI, the third-par=
ty decoder is highly compliant according to the spec test suite, producing =
identical audio playback on almost all of the files, but it also doesn=E2=
=80=99t verify or error on any checksums. ffplay and ffmpeg both accept the=
 file and can play and transcode it correctly, although they ignore the sam=
ple count in the streaminfo header and will read all frames they can find. =
The latter leads me to believe that checksums are the actual issue, even th=
ough flac reports the generic =E2=80=9CBad Header=E2=80=9D and =E2=80=9CLos=
t Sync=E2=80=9D.<u></u><u></u></span></p><p class=3D"MsoNormal"><span lang=
=3D"EN-US"><u></u>=C2=A0<u></u></span></p><p class=3D"MsoNormal"><span lang=
=3D"EN-US">Greetings and thanks in advance,<u></u><u></u></span></p><p clas=
s=3D"MsoNormal"><span lang=3D"EN-US"><u></u>=C2=A0<u></u></span></p><p clas=
s=3D"MsoNormal"><span lang=3D"EN-US">Kleines Filmr=C3=B6llchen<u></u><u></u=
></span></p></div></div>_______________________________________________<br>
flac-dev mailing list<br>
<a href=3D"mailto:[email protected]" rel=3D"noreferrer" target=3D"_blank">f=
[email protected]</a><br>
<a href=3D"http://lists.xiph.org/mailman/listinfo/flac-dev" rel=3D"noreferr=
er noreferrer" target=3D"_blank">http://lists.xiph.org/mailman/listinfo/fla=
c-dev</a><br>
</blockquote></div>
</div>

--000000000000cbe83a05ff520290--

--===============3886785503266597937==
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

--===============3886785503266597937==--