Sometimes the chunk sizes are not computed correctly.
The background is that these are computed based on the size of the source files (i.e. the damaged files). The computed chunk sizes are only correct if the restored file is exactly as big as the damaged file. While this is correct in most cases, it does not hold true if:
custom start or end offsets are used
if the header is destroyed completely and the audio data does not start at the default offsets (by default, audio data is copied starting from offset 44 for WAVE files and at offset 512 for AIFF files)
if files are partially restored
This is a bit tricky because at this point it is not yet clear which chunks will be written, so the write operation has to be delayed.
A good approach would probably be to analyze the input file completely, detect the chunks that are still intact (if any), compute a plan which chunks should be written (including their sizes) and then finally write the complete file with correct chunk sizes.
Sometimes the chunk sizes are not computed correctly.
The background is that these are computed based on the size of the source files (i.e. the damaged files). The computed chunk sizes are only correct if the restored file is exactly as big as the damaged file. While this is correct in most cases, it does not hold true if:
This is a bit tricky because at this point it is not yet clear which chunks will be written, so the write operation has to be delayed.
A good approach would probably be to analyze the input file completely, detect the chunks that are still intact (if any), compute a plan which chunks should be written (including their sizes) and then finally write the complete file with correct chunk sizes.