Yet another FLAC recovery problem thread
Reply #11 – 2013-01-25 18:01:57
I don't think I would go that far to say that, but there's definately something that Recuva/deleting those files caused those screeches to show up. My other guess is that some files (or fragments of them) were placed over the deleted FLAC files thus damaging them, and so, in a recovery attempt, Recuva tried "extracting" the damaged files with the fragments of the files that replaced the deleted ones. I hope I was descriptive enough with this... But that doesn't explain why the MD5sum is correct. It is highly unlikely that it 'coincidentally' turns out to be the same MD5. Anyway, I took a look at the WAV with a HEX editor, and I saw this:advertisement-top ##.advertisement300x250 ##.advertisement468 ##.advertisementBlock ##.advertisementBox ##.advertisementColumnGroup ##.advertisementContainer ##.advertisementHeader ##.advertisementLabel ##.advertisementPanel ##.advertisementText ##.advertisement_300x250 ##.advertisement_block_468_60 ##.advertisement_btm [...] That's right: plain text! It looks like some kind of webbrowser cache stuff. It looks like parts of the file got overwritten by other things. That's also highly impossible, because I've listened to the audio before encoding (while recording) and after and it didn't have those screeches. Yes, but what if it was corrupted between recording and encoding or during encoding? This plain text showed up in the decoded WAV not in the FLAC-file itself, so it has had to be overwritten while lingering as a WAV file, not while being a FLAC file. That would explain why the FLAC file itself is intact and the MD5sum is correct.With that in mind I suppose there's no automated way to detect the files with the screeches, so I'd probably have to go through the audio files one by one and check their spectrograms X.X Yes, because the corruption took place in the WAV and the WAV container has no checks for corruption or checksums, you'll have to check by hand.