1

I have a really strange problem with an audio recording from my Tascam DR-60DMKII linear PCM audio recorder.

I recorded about 40 minutes of audio using DUAL ST mode, where two audio streams are recorded at once: one at 0db and one at -6db.

When I was getting ready to stop the recording, the plug came out of the device, which powered it off while still recording (thus not finalizing). When I turned the device back on, the new recording didn't appear on the device.

I ran a recovery program and found the RAW PCM file that was being written. I imported it into Adobe Audition using the File > Import > Raw Data... mechanism, and that seemed to succeed.

The problem I'm having is that when I play the file, I hear the 0db recording and the -6db recording on the same channel, so it essentially sounds like an echo. Oddly enough, I pulled a totally different recording from the device that did complete successfully, and that one exhibits the exact same "echo" problem.

I believe these are supposed to be PolyWave-type files, so it seems like there's just some interleaving that needs to be de-interleaved, but I can't figure out how to do it and my Google skills are failing in this area.

Anyone know anything about this type of problem? (I'm not an audio professional by any means, so forgive my lack of proper terminology.)

6
  • Matt, I may be able to fix this for you. Can you upload a copy of the original file for me somewhere to download.
    – Mark
    Commented Oct 7, 2019 at 7:57
  • @Mark, thanks for the offer! You can grab the file from here: dropbox.com/s/x0r4pduwrsyxf2h/… (sorry the file name is super weird, but that's how it came off the SD card, and I just left everything as-is) Commented Oct 8, 2019 at 0:52
  • Hey Matt. dropbox.com/s/1m7hcvfwa7g49aa/fixup2-ptout.wav?dl=0 The file really only goes pear-shaped about 1/3 of the way through this. The problem doesn't sound like a sample interleave problem - it's more of a buffering problem inside the recorder. I have never seen anything like this before from a Tascam box. It might be fixable with further work and analysis but it will take a while. Will require stripping out the data chunk and working out where the 'echo' boundaries are - if they are consistent it might be do-able.
    – Mark
    Commented Oct 8, 2019 at 14:14
  • ok so the 'echo' blocks are approximately 196352 samples in duration. It will be necessary to delete alternate 'blocks' to recover the audio. It might not be exactly 196352 samples. I have had to resample this up to 96kHz and then stretch it for some reason to get the audio working.
    – Mark
    Commented Oct 8, 2019 at 14:33
  • Thanks @Mark. That's definitely more to go on than I had before... Commented Oct 9, 2019 at 17:40

0

Browse other questions tagged or ask your own question.