So far from 2.04 on up to current release I can reproduce this issue.
THe audio files are between 1.2 and 20gb but so far the 1.2gb file is easy to reproduce with.
Open file, select “Copy” (vs editing original).
I don’t have the specifics of the offending module as I am at home and it is at the job site.
However, if you load up a large file, select a swath of audio, on ONE channel, select “SOLO”, and then zoom in on this channel it almost always detonates.
I’ll post the debug information from work tomorrow. It may be a Win10 security issue as the computers are hardened for security purposes and run data protection software.
I also wonder if it is because the antivirus is set to scan all files on access.
Anyone else using a fully STIG’d computer and having this issue?
That could very well be a problem.
Most anti-virus applications allow you to white-list specific files. For Audacity, the “.AU” data files should be white-listed. The .AUP file should not be a problem so long as it’s only being scanned once, and not every time it is modified.
So the file is a w64 file, generally 1 to 20gb in size.
Sometimes loaded across the network, but even from local machine it doesn’t matter.
Launch, load file, h it View-Tracks - fit vertically.
Highlight an area of one track, hit SOLO, and then hit zoom.
Maximize, move, or resize window and GPF occurs - not 100% of the time but on his computer with an NVideo 4000 series driver it’s pretty consistent.
I’ll be back with specific module, still trying to reproduce it on my account.
Audacity GPF occurs at the s ame exact point in time that me, as a user, generatesd a request for Setcbprivilege. The security log shows a failuire.
On the working domain, where we don’t have this issue, I see “Audit Success”, and on the failing domain I see “Audit failure”.
The failing domain DOES run Host Based Security System and has all of the EMET (Win10 built in) configured to the max.
Is there something audacity is doing, or requesting through .NET?
Today I renamed the MSVCR120.dll to OLD and forced audacity to use the MSVCR120.dll that was in either SysWow64 or system32. I was able to function for 5 minutes or so and never h ad a GPF until my user showed up, then it began.
Got to have resolution on this today or we have to do away with Audacity, it’s a secured environment with a lot of Security set - if we don’t have an answer we have to go back to Adobe audition or cool edit or some such program
We have found the issue. I want to reproduce it 3 times for verification. I cannot get the GPF on teh working domain, HOWEVER I do get the white screen of death for a good 60-90 seconds.
The issue resides with the Window size under spectrograms.
Go to: Edit->Preferences->Tracks-Spectrograms
Go to Window size: - set to 32768 - most narrowband and load up a mult-channel w64 file.
Change to 16384 and it works. Your array is either off kilter or an API to the OS to redraw the screen to “X” size is off kilter. The resolution of the spectrogram will suffer but at least we are functional, but I’m not sure if our customer will accept less.
FYI we are using the “Hanning” window type but tested all of them.
How do you submit a bug report, 2.2.2 installed has same issue.
The default is 1024.
Using “most narrowband” on a huge file will be extremely demanding and slow, so not recommended.
I’ve tested with Audacity 2.2.2 on Linux with an 8 hour track, mono, 32-bit float, 44100 Hz. The project size is about 5.4 GB. As expected, Audacity becomes very slow, even on a fast i7 with SSD, when the track is in spectrogram view with maximum window size, but no blow up here. (I don’t have a suitable Windows machine to test on).
If the array was off, then I would expect the problem to be reproducible on all platforms.
We’re running 2-30gb files, 16 tracks, w64 - and we need the finest resolution possible for what we do. We’ve loaded larger on Windows, it works fine for the size.
Default FFTSize is 256 (Windows) upon installation but it’s not written into the CFG file and I suspect that is the problem, probably passing a null array or something, not sure.
AFter setting to 16384 and saving, then to 32768 it’s OK - no more GPF’s.
Yes it’s slower and resizes spin like it wants to GPF but then it recovers. We’re OK with that for what we do.
Thanks for your help !! This one has a been a challenge.