Skip ID3v2 tags when decode through errors is enabled

[OwenCochell]

Hello,

The flac command issues an error when a flac file starts with an ID3v2 tag. However, it still emits an error even when decode through errors is enabled. This patch changes this behavior with this option. Instead of quitting with an error, the command skips guessing the filetype from the first 12 bytes. We instead use the type guess from the file extension. When decoding occurs, it correctly skips this chunk and is able to process the rest of the flac file as expected. I have added a test to make sure this functionality is correct.

Let me know if there are any problems! All in all I am very unfamiliar with the flac file format (outside of a quick skim read of the RFC), so I am sure there is something I am missing. I'd be happy to correct any issues.

Thanks,
Owen Cochell

[ktmf01]

Can you please share what error you get without this patch? Skipping ID3v2 tags has been in flac for a long time, so I am unsure why this PR would be necessary.

[OwenCochell]

Sure, if you attach an ID3v2 tag to any valid flac file, it will place it at the start of the file. The input-id3v2.flac file I included with this PR is an example of this, but you can use the id3v2 program to attach this tag to any flac file. If the flac program encounters this tag while trying to deduce the input file type, it will print an error and exit. By default this is normal, as these tags are nonstandard, but it still exits in this way even if errors are asked to be ignored. I propose that the flac program should respect the decode through errors option and continue with the operation anyway.

You can see this behavior in action by asking flac to process a file with an ID3v2 tag:

flac --decode-through-errors -o fix.flac bad.flac

Despite the --decode-through-errors flag, the flac command will exit with a non-zero code and print:

flac 1.5.0
Copyright (C) 2000-2009  Josh Coalson, 2011-2025  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

ERROR: input file bad.flac has an ID3v2 tag

I believe this is a bug. In my opinion, the flac command should respect the flag and continue with the operation. In my tests, this change allows the file to be processed correctly, and the result is free of errors and does not have an ID3v2 flag anymore (you can see my test additions confirming this).

Let me know if you need any more info or clarification.

Thanks!

[ktmf01]

You're trying to re-encode through errors. Functionality is indeed more limited than pure decoding, and this is not the only example.

I'll need some time to review, but following the xz utils backdoor, PRs with binary files need more scrutiny.

[OwenCochell]

For the record, the binary file I included here is derived from:

test/flac-to-flac-metadata-test-files/input-VA.flac

I simply copied this file and added an ID3v2 flag to it using the id3v2 program:

id3v2 -c "test" input-id3v2.flac

After doing this you will see the SHA256 hash is identical to the test file I provided:

0ed170b89fc04b6be44a04a04a21165d9ddb9f482e89ee9a5599da5e5cc24964

Those are the steps taken to create the binary test file. Of course, if you don't trust the id3v2 tool I used then this explanation does not help things. For what it's worth, this tool is included in many distro default repositories, mainly ubuntu and arch linux.

If you have a tool that you trust I would be happy to use that to craft an ID3v2 file using the resources already present in this project. Also, if you want to provide an ID3v2 flac file that you trust, I would be more than happy to alter the tests to use yours instead. Just let me know if there is anything I can do on my end.

Thanks!

[OwenCochell]

Hello,

Any updates on this PR? I'd be happy to implement any suggestions.