IPB

Welcome Guest ( Log In | Register )

Yet another FLAC recovery problem thread
andoru
post Jan 25 2013, 03:33
Post #1





Group: Members
Posts: 7
Joined: 25-January 13
Member No.: 106166



Just as the other thread in this sub forum, I've had accidentally deleted a FLAC collection of mine and I went to recover it. Unlike the previous user most of my FLAC files turned out undamaged when recovering them but some were overwritten. Although I decided to recover the damaged files too, it went successfully and most of the FLAC files came intact. I played a few of them and I noticed one track that had a problem. When playing it in foobar (tried VLC also), at some random points it produces a unpleasant very loud screech (white-noise like). Now, as I had quite a few FLAC files in that collection, I would like to check them all for those errors, and preferably not through playback as that could be quite painful to the ears XD
I tried to run the -t parameter in the CLI flac encoder on the file, but it reports no errors. Any suggestions on what to use to detect those mishaps? (if it can do it in batch mode that's a plus! )

Software used:

Recording/Encoding - Audacity/libFLAC 1.2.1 20070917
Playback - FooBar, VLC
Recovery - Recuva
File System - NTFS
OS - WinXP SP3 x86

If anyone needs a sample of the problematic file, I can upload it somewhere, it's not copyrighted.

Thanks in advance ^^



This post has been edited by andoru: Jan 25 2013, 03:35
Go to the top of the page
+Quote Post
 
Start new topic
Replies
ktf
post Jan 25 2013, 19:01
Post #2





Group: Members
Posts: 369
Joined: 22-March 09
From: The Netherlands
Member No.: 68263



QUOTE (andoru @ Jan 25 2013, 16:18) *
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:

CODE
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.


QUOTE
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.

QUOTE
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.

This post has been edited by ktf: Jan 25 2013, 19:05


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 17th September 2014 - 14:32