Scan completed and it didn’t pull up any .au files unfortunately.
Hopefully this was just a weird glitch because of how nyquist’s plugin overwrites data and not a hardware issue. Who knows, maybe I’ll be back on here in a couple weeks with a bum hdd. Hopefully not. Thanks for the advice, everyone!
Hopefully it was a weird glitch, but it’s not because of how the Nyquist plug-in overwrites data, because Nyquist plug-ins don’t overwrite data. That’s why it is weird that the data has gone without trace.
What happens with Nyquist “Effect” plug-ins is that they read the track data from disk, perform all processing calculations in RAM and return the resulting data to Audacity. In some cases Nyquist is able to “read → process → return” the data in blocks, which conserves memory, but in some cases the entire selection needs to be retained in RAM until the process completes. The latter case is why some Nyquist plug-ins have problems with long selections.
As the audio data is returned from Nyquist to Audacity, Audacity writes the data to disk and updates the .AUP file so that it points to the new data. The original data is retained so that you can “Undo” the effect. On closing the project, Audacity cleans up and deletes the Undo data, retaining just the data that is required to recreate the project as it is at that time. If Audacity crashes, then it never gets round to cleaning up, which is why crashed projects usually contain “orphan” files - these are old data files from the project’s “Undo history” which are no longer referenced by the AUP file.
I’ll be back on here in a couple weeks with a bum hdd. Hopefully not.
Hopefully you do. If you don’t, then your show has gone to the Magic Data Sucker in the Sky. It’s difficult to correct for that.
I had a motherboard that had a similar failure characteristic. “Time to do production. Are you feelin’ lucky?”
There are memory checkers that can be run in a continuous loop instead of once at boot. Run for 24 hours. Normal computers handle that no sweat. My machine crashed with a memory strip #2 error sometime after 4:30 AM, test pass number 845.
This testing process also has the advantage that it tests the rest of the machine, too. This can turn up power supply failures.
Do you have good, reliable wall power? I killed off a power socket once.
It’s a wonder these things ever worked.
Koz
We rerecorded the first episode this morning and I can use the noise gate for smaller sections, but if I try to do it for the entire hour and twenty minutes it comes back with the error screen and wipes the data folders. Thanks to you kind folks, I had everything backed up properly before I tried this, but it seems like if I want to use Noise Gate, I’ll have to do it in multiple sections per project instead of all at once. Not the end of the world, but definitely sub-optimal.
The scan didn’t turn anything up from our original recording either.
A repeatable error is development gold.
I can use the noise gate for smaller sections, but if I try to do it for the entire hour and twenty minutes it comes back with the error screen and wipes the data folders.
Can you get it down to a time break? If I go over xxx minutes it crashes?
Koz
Did you tell us how much on-board memory you had?
I’m having flashbacks. My memory crash was in high memory and it only created problems when I edited a complex video segment over a certain length.
Koz
I have 16 gb of DDR3 RAM installed. 2 sticks of 8.
I tried applying the Noise Gate effect in increments to figure out how long of a clip I could apply the effect to without freaking it out. It made it all the way up to an hour and 15 minutes. At an hour and 20 minutes it crapped out. Seems like that’s my rig’s cap.
I should also note that I’m recording in stereo
Nyquist is strictly 32-bit. Anything more than 2 GB of data is a serious problem regardless of how much physical RAM is available.
Anything more than 2 GB of data
So an hour and 15 minutes of stereo show is the natural Audacity production limit.
That would be good to know.
Koz
Side Question:
Is there any benefit to recording in stereo? I just do it b/c it’s the default. Should I be doing mono to save on size and make my life easier?
Mono is always recommended unless there is a specific production reason for stereo. I used to deliver single voice tracks in stereo because I had no storage restriction and I knew that’s what the video editor clients were expecting.
ACX AudioBook recommends delivering readings in mono.
Koz
If it’s a single microphone recording, then no, no benefit, just more data if lossless, or lower quality if exported in a lossy format (such as MP3).
What I see in 2.1.3 and 2.2.0-alpha in Windows 10 is that the memory use is rolled back when it gets too much. 2.2.0-alpha is working code for our next release.
In 2.1.3 the AU files for the entire project are deleted when Audacity quits due to the memory exception, even tracks that were not being processed by Noise Gate. When you try to recover, you have to wait while Audacity writes silent block files for the project. The log is whited out for me so I can’t see what the consistency errors are claimed to be.
Given it is quite common for Nyquist plugins that write to memory to crash Audacity, I am surprised no-one found this before. Perhaps it is a flaw specific to Noise Gate?
2.2.0-alpha is much better in terms of preserving data. There is no exception error. After the memory rollback you see a single message box such as “Audacity failed to read from a file at S:\hgfjgig_data\e00\d03\e00036c9.au”. But there is no information in the log and no indication why the error occurred. However the main thing is that there is no crash, no data loss and you can close and reopen the project normally.
Gale
How many people use NoiseGate on a 90 minute show? Stereo? How many people thought it was their fault, and then how many people turned it in? We are warned against extrapolating massive failures from a single forum post. It works the other way, too.
Koz
See my post above which results I have reproduced many times.
Gale
So that was a bug in Audacity 2.1.3 which has been fixed in 2.2.0 alpha?
I’ve been testing Noise Gate (this version: Missing features - Audacity Support) in Audacity 2.1.3 on Xubuntu.
I’ve tested with well over 2 hours of audio, both mono and stereo, and it’s working perfectly - no crashes.
It does appear to “freeze” for a while when processing long tracks, though it is not actually freezing. The progress indicator bar only monitors the generation of the gain envelope, so it sits at “100% complete” for quite a while the envelope is being applied before the waveform is redrawn. I don’t know how that limitation could be fixed, other than implementing the Noise Gate as a built-in (C++) effect (which would be good to do).
Try it yourself on 64-bit Windows. I guess the safeguarding of data as part of Paul’s wider work on http://bugzilla.audacityteam.org/show_bug.cgi?id=437 has effected the Improvement.
As I recall in previous testing, some 64-bit Linux kernels seemingly do let you store more than 2 GB RAM for Nyquist per Audacity application. I have seen 2.5 GB Audacity RAM use on Ubuntu 16.04, which memory use drops to circa 80 MB when the Nyquist plugin finishes processing.
On Windows 64-bit, 32-bit Audacity, there is an exception error using the plugin at about 1.5 GB of Audacity memory use, in 2.1.3 or 2.2.0-alpha. I have not tried the experimental 64-bit Windows builds of Audacity that are available.
Gale
That seems to be so, and is a pleasant surprise.
Testing Noise Gate on 32-bit Debian with Audacity 2.1.3, Audacity crashes when memory use exceeds 2 GB. It worked fine with 1h 10min mono, 44100 Hz.