It happened few times that I had corrupted FLACs, probably 3-4 files in my entire library. One day I converted them to WAV then reconverted back to FLAC, the audio CRC ended up to be the same but the FLAC was no longer corrupted. Is this a real way to fix the corrupted FLAC? Why wasn't the WAV corrupted like the FLAC originally was?
It depends on converter used and how you determined the FLAC was corrupted.
It is possible the converted wave had the corruption error, which when re-converted back to FLAC, well the new FLAC file takes the wave file as is, and as wave has no method of determining it is corrupted...
If whilst converting the converter told of the corruption, then the wave file is corrupted also.
I was thinking about that too but since the audio CRC is the same, is it possible the corruption was somewhere else outside of the audio stream?
I don't remember the exact error, I checked them with foobar2000's File Integrity Verifier (http://www.foobar2000.org/components/view/foo_verifier) component.
Audio CRC; do you mean the MD5sum in the FLAC file? If you use foo_verifier, it tells you whether the MD5 is OK or not. Expand the column, and it will state «(OK)» or «(Fail)».
You still have a copy of the corrupt file?
If you use foo_verifier, it tells you whether the MD5 is OK or not. Expand the column, and it will state «(OK)» or «(Fail)».
Seriously?
You still have a copy of the corrupt file?
"I don't remember the exact error" was supposed to be intended as I no longer do.
So again, is it possible the corruption was somewhere else outside of the audio stream?
I managed to reproduce your error. I have a file which – for reasons unknown to me – has had corruption for a few years, maybe ever since ripping.
foo_verifier:
MD5: 3D344C869031CB7EF4D771F44448EE94
CRC32: D78996C2
Warning: Reported length is inaccurate : 4:48.120000 vs 4:47.597551 decoded
Error: Corrupted FLAC stream
Error: MD5 mismatch
Converted to .wav and back to .flac:
MD5: 3D344C869031CB7EF4D771F44448EE94
CRC32: D78996C2
No problems found.
As you can see, foo_verifier displays what the checksums were calculated to during decoding (which is of course identical to what the new copy has), not what they should have been.
Thanks for trying that. Do you think the file is fixed now? Do you think the audio stream was not damaged even on the corrupt file? Again, is it possible the corruption was somewhere else outside of the audio stream? I am asking this over and over because I am not a programmer, I'd just like to know if the component of a FLAC file can break without touching the audio stream.
No, I think the damage is permanent. Just like a scratch in a recording from a vinyl; you have copied it with the scratch sound, but encoded it to a new file. The new file cannot tell whether the scratch was supposed to be there, all it knows is that the file integrity is OK (meaning, it contains what it was fed, which includes the scratch).
My best guess is as follows:
Checksum #1 was created from a best-effort decoding of a damaged file.
That best-effort decoding is encoded to a new file.
That new file decodes to the same thing as the best-effort of the first one. Only now it does not warn, because it does not know that it was fed a damaged audio stream.
If I'm not wrong, metaflac --show-md5sum option shows md5 checksum of full input data stream at encode time. If something went wrong during or after encoding and musical data are corrupted, comparing this value with an md5 of the decoded wav (which as Porcus said must be considered decoder's best effort to recover original data) will result in a mismatch.
I guess that's what foo_verifier does.
Edit: of course a new FLAC file which uses the newly decoded wav as input stream will hold the new md5 value and next test will not fail.
If I'm not wrong, metaflac --show-md5sum option shows md5 checksum of full input data stream at encode time.
Yep, it does. (FLAC also has a CRC (8-bit) per frame, not in the metadata block, but presumably those are used to detect corrution too.)
No, I think the damage is permanent. Just like a scratch in a recording from a vinyl; you have copied it with the scratch sound, but encoded it to a new file. The new file cannot tell whether the scratch was supposed to be there, all it knows is that the file integrity is OK (meaning, it contains what it was fed, which includes the scratch).
My best guess is as follows:
Checksum #1 was created from a best-effort decoding of a damaged file.
That best-effort decoding is encoded to a new file.
That new file decodes to the same thing as the best-effort of the first one. Only now it does not warn, because it does not know that it was fed a damaged audio stream.
Hi.
Just for my curiosity ... the FLAC file you say is corrupted ... has it an audible effect? I mean, is it sounding bad? Do you HEAR clicks or pops or whatever annoying noise? Thanks for a kind reply. Cheers. Alberto