I tried to run the -t parameter in the CLI flac encoder on the file, but it reports no errors.
When playing it in foobar (tried VLC also), at some random points it produces a unpleasant very loud screech (white-noise like). [...]I tried to run the -t parameter in the CLI flac encoder on the file, but it reports no errors.[...]If anyone needs a sample of the problematic file, I can upload it somewhere, it's not copyrighted.
Would Foobar2000's File Integrity tool work for this?
On a file that produces a loud burst of static? That’s very odd. Assuming of course that there’s a reason for that in the data itself, flac.exe should notice it and report an error in the overall MD5 at the very least, if not also the individual block(s) housing the change. Of course, it’s possible you’ve defied the odds and found a hash collision, but y’know, probably not! So, I’m very curious about this. Have you tried the test on more than one file?
you may be able to "correct" the audio with Audacity.if the tracks at not copyrighted, just try to find a legal download (hopefully not violating TOS). no copyright does NOT always equal free.
Yes please, I would like to see the file. If this is true, it might be a *very bad* bug which needs fixing soon, as the devs are working towards a new release of FLAC
[…] the devs are working towards a new release of FLAC
Where would [the File Integrity Verifier] be? I can't find it in fb2k's menus.
It could be in the data itself, maybe Recuva found this file as being damaged for having a few bytes (or blocks as you say) missing and it attempted to plaster those missing bits and make it checksum intact.
Where would that tool be? I can't find it in fb2k's menus.
Here you go. It has ~7sec of silence in the beginning, beware not to set your speakers too loud if you attempt to listen to it =P
Quote from: ktf on 25 January, 2013, 05:14:02 AM[…] the devs are working towards a new release of FLAC I didn’t realise there was much happening with FLAC again; have any plans, etc. been released? Who are the developers now, anyway?
Just a bugfix release, getting FLAC to compile nicely with current compilers. The new maintainers (Erik de Castro Lopo) main concern is libFLAC. Check the mailinglists for more information: http://lists.xiph.org/pipermail/flac-dev/ They are merging support for 7 and 8 channel audio as well. edit: Josh had some unreleased fixes in cvs as well, of course these will get in the new release too.
Notwithstanding that I doubt this or any other undeleting program has tailored support for FLAC or any other format, I would hope that none of them would attempt to cobble together a repair and fudge a checksum without at least asking the user – and advising them of how silly that would be. At least, that’s my expectation based upon the assumption of a rational human world, so you never know!
You might have to download the component. I don't think it's installed with Foobar2000 "out of the box".http://www.foobar2000.org/components/view/foo_verifier
I'm pretty sure that this corruption has happened *before* converting this to FLAC, because for example the first error spans 5 FLAC blocks with start and end somewhere in a block, so it's not aligned.
[...] but it's unlikely FLAC it the culprit.
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...
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...
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.
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, 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.