You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm encountering an issue with specific WAV files when using --keep-foreign-metadata, where the length of the fmt chunk differs before and after a roundtrip through FLAC.
The problem
The issue seems to be the second to last field of the fmt chunk, which indicates the number of extra format bytes that follows. If it is present, and set to 0x0000, it will contribute to the original size field of the fmt chunk (0x12). However, FLAC does not write the field upon decoding when it is set to 0, opting to leave it out. The size of the decoded fmt chunk is two bytes smaller to match (0x10). However, the verification at the end fails:
$ flac --keep-foreign-metadata -do /tmp/test.wav /tmp/test.flac
NOTE: --keep-foreign-metadata is a new feature; make sure to test the output file before deleting the original.
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.
test.flac: done
ERROR verifying foreign metadata restore from /tmp/test.flac to /tmp/test.wav: stored main chunk length differs from written length
Roundtrip seems to work fine for files that include extra format bytes, and files with no extra format bytes when they also leave out the extra format bytes size, so this problem is specific to WAV files that:
Have no extra format bytes at the end of the fmt chunk
Still include the size field for the extra format bytes (set to 0x00)
Expected behaviour
I would expect one of two things:
The decoded WAV file includes the second to last field even if it is set to zero, as long as the stored information about the original fmt chunk indicates that its size field was set to 0x12 and therefore included the field. This should make the fmt chunk pass verification.
The decoded WAV file leaves out the second to last field (like today), and the verification of the fmt chunk is modified to accept a difference of -2 bytes when the second-to-last field of the original fmt is 0.
Anyways, I'd like to take the opportunity at the end here to thank you so much for your work on FLAC 😄 It has been, and continues to be, of great help 😊
The text was updated successfully, but these errors were encountered:
I'm encountering an issue with specific WAV files when using
--keep-foreign-metadata
, where the length of thefmt
chunk differs before and after a roundtrip through FLAC.The problem
The issue seems to be the second to last field of the
fmt
chunk, which indicates the number of extra format bytes that follows. If it is present, and set to0x0000
, it will contribute to the original size field of thefmt
chunk (0x12
). However, FLAC does not write the field upon decoding when it is set to 0, opting to leave it out. The size of the decodedfmt
chunk is two bytes smaller to match (0x10
). However, the verification at the end fails:Roundtrip seems to work fine for files that include extra format bytes, and files with no extra format bytes when they also leave out the extra format bytes size, so this problem is specific to WAV files that:
fmt
chunk0x00
)Expected behaviour
I would expect one of two things:
fmt
chunk indicates that its size field was set to0x12
and therefore included the field. This should make thefmt
chunk pass verification.fmt
chunk is modified to accept a difference of -2 bytes when the second-to-last field of the originalfmt
is 0.How to reproduce
Download and extract the WAV or FLAC file from reproduction-808.tar.gz.
Create the FLAC file:
You may optionally skip this and use the included FLAC file directly.
Decode the FLAC file:
Anyways, I'd like to take the opportunity at the end here to thank you so much for your work on FLAC 😄 It has been, and continues to be, of great help 😊
The text was updated successfully, but these errors were encountered: