Corrupt WAV File?

qazwsx

qazwsx

Well-known member
I have a 50 minute WAV file recorded to an 32GB SD Card via a Tascam DR-70D (16bit, two channels, 48khz).

I've copied the file over to several locations, but When I play it back it's very choppy, like there's 1 second of silence inserted after 1 second of audio and going back and forth like that through the whole file. Within those gaps, there's no audio missing, it's literally like there is silience inserted and it pushes the audio forward, so if you take out those gaps, you will hear uninterrupted sentences.

However, while the clip is 50 minutes, and we recorded 50 minutes of audio, if you remove the blank spots there would then really only be 25minutes of audio recorded, the rest is blank.

Does anyone know if the full audio clip is recoverable? Or how something like this could've happened?

We previously successfully recorded 2.5 hours of audio on the same recorder. The only thing that changed was swapping the SD card, but that SD card was previously being used to record AVCHD video. Could that have caused it?


Thank you for any help
 
Was the card formatted in the Tascam before you recorded the audio and was the card certified/approved for use in it? When I first got my SD 664 years ago I initially used Lexar cards(CF & SD) that more than met the required speed, but weren't certified/approved by SD. The cards were fine with the WAV files, but MP3's were crap on CF and SD(fortunately this was during testing). I switched to approved San Disk cards and WAV and MP3's were both fine on both card types.
 
After the card was inserted, the Tascam prompted us to format, so we did. The card is in fact a Lexar card, and after looking up the tested media document, the closest spec it matches is to one of the "NG" SanDisk cards.

Thank you for your response and your help. I believe this is the issue and that there's no chance of recovering the missing parts of the audio files. Lesson learned.
 
I wouldn't give up completely. It seems to me that it's very unlikely this is caused by random corruptions, or an uncertified SD card. There's basically no way that could cause every other second of audio to be shifted forwards.

This sounds more like a format problem. Whatever software you're using is interpreting the format of the data wrongly; like it's getting the wrong number of channels. In fact it sounds like it's recorded in stereo, but playing back as mono -- I assume you were only using one channel? So what you're hearing is the left and right channels interleaved, where one of those channels is silence.

(Because that's how stereo is actually written into a file -- it saves a chunk of one channel, then a chunk of the other, and so on. The file doesn't actually have two separate streams of data.)

Why would it do this? Well, it could be a corrupted header in the WAV -- which might be theoretically recoverable, if you know how to use a hex editor.

Or it could be that the software you're playing back with is duff -- try different software. Or maybe it just got confused; maybe you dropped a stereo track into a mono timeline, or something, and it failed to notice the issue.

I have a DR-70D, BTW, and never hit this.

Also BTW, I always record in 24-bit WAV. There's just no reason not to, and it gives you more headroom so you can be a little more casual with your levels.
 
It could indeed be a corrupted header as AtticusLake stated. I've recovered problem PCM files (wave and aiff) by changing the extension to <.raw>, which opened, played back and re-saved w/o issue in Sound Forge Pro. I not sure which other audio editors or DAWs will open a .raw audio file.

Always test new cards prior to actual use, even an 'approved' card could be a turkey or counterfeit.. Always format the card in the recorder that will be used.
 
I didn't see this mentioned by the OP:

Have you listened to the audio using the recorder. Is it corrupted within the recorder environment? If it plays clean, that would indicate something amok with your edit software.

Grant
 
All of the above could be the problem. Another may be the transfer itself. You said you copied the file a number of times but were these new transfers off the card or did you copy it off the card once and move that file around. If the later I would try copying off the card again. I would also try copying it using a different card reader.

If I had to put money on it a bad transfer or corrupt header info would be my first two choices. And that might also explain your missing data. The header tells the format and the length. So if it says it's stereo and it's 50 min long, but it is really mono and 50 min long you would end up with a gapped file like you have but since the headers says it's only 50 min long that is where it stops reading the data.

I'm not sure I explained it correctly but the point is that it is quite likely that the data is in the file but not playing back because of incorrect header info. I have actually seen this a long time ago with transferring some files from a Mac (~OS 6) to a windows system (Win 89?).

I would try a new transfer, if you haven't already done that, since it might just be a glitch when you originally transferred. If that doesn't work then I would try the raw route.
 
You might also look at the file size. Is the file size actually large enough for the recording? If there is enough data on the card, it might be there but as others have mentioned, might not have the correct protocols to be read.

Grant
 
Thank you all for all of your help.

- The programs I was using to review the clip were: VLC, Audacity, Audition and Vegas. All had the same issue with the file.

- The filesize seemed to be correct, a working file of similar length reported a similar filesize.

- The file also played back with the same issue inside the DR-70D.

- We recorded a test clip to the same card and it sounded fine.


I did try editing the header with a hex editor and then tried importing it as raw in Audacity and it worked! I was able to export the audio file and it plays fine and it's there in its entirety.

I still don't know what could have caused the issue so we can avoid it in the future. Just random corruption? Regardless, we're definitely making sure the next card we use is on the tested media list.

Thanks again for all the help and the encouragement to not give up on it.
 
qazwsx said:
I did try editing the header with a hex editor and then tried importing it as raw in Audacity and it worked!
Click to expand...

Fantastic! Glad you got it working, and good job on figuring it out.

Just one thing I would mention -- the chances of this being some kind of random corruption, or a bad SD card, are virtually nil. Yes, I know that back in the bad old days, there were issues with SD cards keeping up with the data rate; but today's SD cards are designed for VIDEO, at 1,000 times the bitrate we need for audio. And yes, you can always get a truly bad SD card -- typically because it's a fake. But then you're going to see atrocious errors, like it will just start overwriting itself past the first 8GB.

The idea that some random event caused ONE specific field in the file header to be bad, when SD cards (like all storage) are written in blocks (like a kilobyte), and are erased in pages (typically megabytes), is basically absurd.

Given that the recorder itself had the same problem playing it back, this is far more likely to be a software bug in the recorder. Something caused it to set the format of the file to mono when it was actually stereo. This may have been because of some particular thing you did when setting up the recording, which triggered the bug. The point is, if it's a software bug, then it will happen again in the same circumstances. So if you can figure out what those are, you can avoid them.

You should also check that the firmware is up to date -- you should be on version 1.14. (Firmware updating on the Tascams isn't too hard, if you haven't done it yet.)

HTH...
 
Actually I would disagree slightly. It could be a firmware glitch and I would certainly check that out. But drives and cards get "bad blocks" rather often. The part of the OS that deals with storage or the drive it self set aside these bad blocks so that they will get skipped over. So while it's rather long odds that you would have a block go bad that happened t contain your header it is not "absurd".

But what is probably more likely is a glitch when the recording stopped. A place holder header is written when the recording starts and then updated when you stop the recording. So anything that caused a glitch then could screw up the file. I think it's a misleading assumption to think that just a field of the file was corrupted. Since it was imported as RAW the header was ignored so the whole thing could be junk. If he had "fixed" the header he wouldn't have had to load the file as RAW. He might have and then you would know how trashed the header was but we don't know that. And since this file started close or at the start of the card it will have had more read/writes than other parts of the card so the odds of having a block go bad at that place in the card is higher, how much higher would depend on how many R/W cycles it has gone though.

It wasn't a slow write issue or you would have had actual dropouts, so the data was writing fine. What ever caused the glitch it would have almost certainly happened right after recording was stopped.

You are not getting repeatability so it's kind of hard to narrow it down. I would lean toward a card issue because if it was a software issue you would probably have seen other posts about the issue. So either it's a bug that is very rare, like it only happens with files over a certain size etc, or it was a hardware write error. This type of thing does happen with some recorders if they loose power. Most now will do a header update before shutting down. But if say you pulled the card out before the header was completely written it cause a corrupted header.

Bottom line check your firmware because if nothing else it's almost always best to have the latest firmware. And do some test recordings with the card and the recorder and see if you can get a repeat. As part of that I would do a reformat on the card and try a few tests. Re formatting should keep or create a bad block map. So one weird possibility would be that since the card was used in a different device, that format may have created a bad block map that wasn't read by the recorder and if you did a fast format it might have missed a bad block that is now correctly mapped. Something like that would probably be almost impossible to make repeatable. With out some heavy duty diagnostic software you probably can't even find out where your bad blocks are.
 
You must log in or register to reply here.
Back
Top