Skipped spots in recording, dying HDD or what?

[Mind Riot]

I've been doing some book narration and have noticed this happening several different times. In the middle of a take, usually a long one, I'll be reading a phrase and suddenly the recording will skip over a word or two and the phrase will be blurred together for a moment.

It sounds like it would if I had split the take and cut the word then pulled both sides together and cross faded them, but of course I didn't and the waveform is one long solid take.

I've never run into this before, and I don't know what it's indicating. I believe I'm running the latest version of Reaper. I know other people record live shows with much longer takes with no problems, and I'm only recording a single input. I'm not pushing my interface at super low latency; it's set at 512 samples, though I've used it at super low latencies and it does fine.

Could this be an indication of a dying hard drive? I keep all my audio projects and files on a one terabyte HDD and run a small SSD as my system drive. The HDD is about five or six years old and has never given me any trouble before. It's defragged regularly and all music files are backed up to an external drive and the cloud with a backup service.

The PC is an Intel i5 quad core with 8 GB of RAM, and has also been trouble free.

Anyone else run into this sort of thing? Any ideas what it could be? Thanks to all for any insight.

[Jimmy James]

For me, 5 or 6 years on a HDD is a long time, but more on that later. Are you running Windows 7, 8, or 10?

edit: what is your Mobo, and interface, just so we know. You can never give to many specs

[karbomusic]

I'd be curious if CPU bound during the issue, what the disk throughput in Reapers perf window shows and what the System event log says in relation to disk errors (Start > run > Eventvwr.msc) and, how long is the file and/or how large is the final file in MB/GB? I know some of this is after the fact but the curiosity is there.

[serr]

If the file both appears uncorrupt and is truly missing chunks of audio like that, a buffer underrun leading to dropped samples is the explanation that fits that.

If it were something else like losing communication with the audio interface, Reaper would throw up an error message when that happened. Reaper lights up the transport red for a buffer underrun but you'd have to be staring it down during that to see it.

But...
Whole words missing? That would be millions of samples missing. A buffer underrun is usually a few buffer-fulls of samples missing.

I'd still shotgun that drive first.

[karbomusic]

Originally Posted by serr

But...
Whole words missing? That would be millions of samples missing. A buffer underrun is usually a few buffer-fulls of samples missing.

I'd still shotgun that drive first.

It's only 48 thousand samples in a second at 48k so I doubt a couple words is millions.

[Jimmy James]

Originally Posted by karbomusic

I'd be curious if CPU bound during the issue, what the disk throughput in Reapers perf window shows and what the System event log says in relation to disk errors (Start > run > Eventvwr.msc) and, how long is the file and/or how large is the final file in MB/GB? I know some of this is after the fact but the curiosity is there.

Yea i think that could be it as well. I would really love to see what 16gb of ram would do for the OP as well.

OP, if you CPU temps are good. And your hard drive test are good. Than it could be bottleneck as Karbo stated. Just start marking one thing at a time off the list.

[serr]

Originally Posted by karbomusic

It's only 48 thousand samples in a second at 48k so I doubt a couple words is millions.

You'll have to excuse my butt for that factor of ten there.

But that's still an awfully long dropout!

You're definitely not running out of ram recording a single track with 8GB! (Or if you are, then something else is very wrong.) Don't go buying more ram...

I'd still shotgun the drive.
Got a backup clone of a known good OS? Boot into it and test any corrupt OS theories.

[Mind Riot]

Originally Posted by Jimmy James

For me, 5 or 6 years on a HDD is a long time, but more on that later. Are you running Windows 7, 8, or 10?

edit: what is your Mobo, and interface, just so we know. You can never give to many specs

Don't know the MOBO offhand, I'll take a look a bit later. This whole thing is actually happening right when I'm about to upgrade my little 120GB system SSD to a brand new 500GB one, so I'll be pulling the side off the case pretty quick here.

Interface is a Steinberg UR44. It's been great since I got it a few years back, but I haven't checked for new drivers for a while, guess I should probably do that.

Oh, and I'm running Windows 7 64 bit.

Originally Posted by karbomusic

I'd be curious if CPU bound during the issue, what the disk throughput in Reapers perf window shows and what the System event log says in relation to disk errors (Start > run > Eventvwr.msc) and, how long is the file and/or how large is the final file in MB/GB? I know some of this is after the fact but the curiosity is there.

Hooboy. That would all be pretty difficult. You see, I was under a pretty tight deadline for finishing this audiobook when I noticed these problems, but I didn't have time to do anything about them. I would just record another take and keep going. THEN, tens of thousands of words spoken later, I would edit them for timing and to remove mistakes and whatnot. To make this easier, I used Reaper to dynamically split all these transients and silences and automatically delete the silences, so say ten or so larger files that added up to a half hour long chapter reading became several hundred very small files spaced apart where silences between them used to be.

THEN, the company has standards for their audiobooks that must be met, and one of them is that the finished product must be rendered as a 192khz .mp3. So the size of the finished files doesn't reflect what they would be if they had been kept as .wav or FLAC files and mixed down that way, like we might usually do. A half hour chapter .mp3 would come out to about 30 to 35 MB.

So basically what I'm saying is that I noticed the problem but I was in a time crunch and I recorded over the problem parts and did a dozen or so more hours of work before the project was done, and the kind of detailed data you're talking about is buried so deep by now I wouldn't even know where to begin.

Originally Posted by serr

I'd still shotgun the drive.
Got a backup clone of a known good OS? Boot into it and test any corrupt OS theories.

Okay, now I know this might make me look uncool, but is 'shotgunning' the drive a slang term for some technical procedure I don't know about, or are you just suggesting I get a new drive and destroy the one I have?

I mentioned above that I have a new SSD to replace the one that's in there. I was just going to clone everything from the old drive to the new one and just keep on groovin'. Should I do something different with it? I use AOMEI Backupper and there's a full backup a couple months ago with weekly incremental backups since. I'm not sure if I understand what you mean. Are you saying I should restore from one of those backups then run CHKDSK and such from within Windows?

Thank you very much for the advice. I promise, I'm not thick in the head, I just haven't had to do this sort of thing for a while and I need to shift gears and warm up.

[serr]

Haha, sorry...

To "shotgun" something means to try a solution for a common problem first even if you don't yet see 100% evidence. "This looks like something that's usually 'X' 8 out of 10 times I see it. Let's just try the solution for that first before we look further."

I'm not actually sure where the expression comes from or how an actual shotgun may have been involved!