Audacity Forum

Let me just have another go with that first one in case the download screwed it up somehow.
I'll post when it's done.

I don't understand, even the first step (that I didn't upload) is corrupted. What are you looking for in step 2? Just curious.

Cwluc wrote:I don't understand, even the first step (that I didn't upload) is corrupted.

How long was the recording?
What was the recording format?
Was that totally un-edited, un-processed and still corrupt?
Did you try playing the recording before you saved the project?
Does your system notify you of "xruns" during recording?

steve wrote:

Cwluc wrote:I don't understand, even the first step (that I didn't upload) is corrupted.

How long was the recording?
What was the recording format?
Was that totally un-edited, un-processed and still corrupt?
Did you try playing the recording before you saved the project?
Does your system notify you of "xruns" during recording?

(it's now deleted so you know - I mean I deleted it before you last posted, they were corrupt so I didn't think it mattered)
It was well over an hour. Close to 2.
Same as the others, 24/96.
Yes
No, but now I will definitely pay more attention to it. Usually when I first record I don't. By the time I'm done recording I'm tired, so I save the file and come back later before my next day of actual work (the paying bills kind).
xruns? I'm sorry I don't follow.

I've re-downloaded that file now so feel free to delete from Dropbox.

I'll come back to xruns.

Rats. with https://www.dropbox.com/s/clyi6q3bra7oc ... 20cuts.rar I've got a bad download.

Unpacking it I'm getting an error:

I was maxed out on space. Apparently they won't allow me to restore it. I'm considering running a dummy test with a duplicate record I have, record it for more than an hour... Hmm.. I wonder if I actually need to actually record anything, maybe silence for 2 hours...

xruns (or x-run) is a buffer under-run or over-run.
They occur if either the audio buffers are not filled fast enough so that incomplete buffers are written to disk, or the buffers are not emptied fast enough so that the captured audio data has nowhere to go.

Some ASIO applications will display x-runs in their interface (such as Cakewalk Sonar).
In Linux, "jack audio system" is usually run from "jack control" which keeps a count of any xruns that occur.

Occasional xruns can cause clicks in the audio, either because there is one or more samples missing (dropped samples because the buffers were all full) or short gaps (because the buffers were not completely full when written to disk. If there are a lot of xruns the sound can get badly mashed up.

Cwluc wrote:So there are a few takeaways from this. Definitely check the entire record before commenting.

Yes definitely, though hopefully if we can get this working reasonably reliably then simply checking a few random selections will be sufficient rather than needing to listen to the entire thing.

Cwluc wrote:Also to make sure it's under an hour for now (any ideas how/when that might get fixed?)

I'm not at all certain that this was the problem. For an unprocessed recording that problem should not kick in until well after 2 hours at 96 kHz.

Could you post a short section (just a couple of seconds) from a corrupted section in 32-bit float WAV format. WAV files up to 1 MB can be uploaded directly to the forum using the "Upload attachment" feature below the message composing box.

steve wrote:xruns (or x-run) is a buffer under-run or over-run.
They occur if either the audio buffers are not filled fast enough so that incomplete buffers are written to disk, or the buffers are not emptied fast enough so that the captured audio data has nowhere to go.

Some ASIO applications will display x-runs in their interface (such as Cakewalk Sonar).
In Linux, "jack audio system" is usually run from "jack control" which keeps a count of any xruns that occur.

Occasional xruns can cause clicks in the audio, either because there is one or more samples missing (dropped samples because the buffers were all full) or short gaps (because the buffers were not completely full when written to disk. If there are a lot of xruns the sound can get badly mashed up.

After reading the whole thread again I realized I missed your comment "You could also try increasing the latency in your ASIO settings." Was that what you are referring to or am I way off base? Could I hear "dropped samples" while I'm recording? Would it sound like static? I have heard that, not often, but from time to time.

steve wrote:

Cwluc wrote:So there are a few takeaways from this. Definitely check the entire record before commenting.

Yes definitely, though hopefully if we can get this working reasonably reliably then simply checking a few random selections will be sufficient rather than needing to listen to the entire thing.

Noted.

steve wrote:

Cwluc wrote:Also to make sure it's under an hour for now (any ideas how/when that might get fixed?)

I'm not at all certain that this was the problem. For an unprocessed recording that problem should not kick in until well after 2 hours at 96 kHz.

Could you post a short section (just a couple of seconds) from a corrupted section in 32-bit float WAV format. WAV files up to 1 MB can be uploaded directly to the forum using the "Upload attachment" feature below the message composing box.

Umm once I am sure the recording isn't of use (for me) I try and get rid of it. I'm struggling with free space considering I have an entire library of records to record. Do you mean from the now deleted files of this last record or my test? I know for a fact the last file was under 2 hours and you heard what happen.

Cwluc wrote:I'm struggling with free space

Me to, so I deleted the files that I downloaded from you, then realised that I really need to take a closer look at that distortion.
Oh well, just post a couple of seconds of scrambled audio if/when it happens again, or if you still have a bit lying around. I'll keep an eye out for new posts to this thread.