Hi all, Is there anyone who can tell me what’s happening below? When I zoom in or out the yellow block in the spectrogram can disappear, get fragmented, … When I play this part of the spectrogram, some parts sound okay, others produce (giant) glitches and other parts, without these yellow blocks, can produce short glitches. Is my wav-file corrupt or is there a problem rendering the spectrogram.
No problems here. What OS and some specs on your computer would help.
Windows 11 Pro
64 bits OS, x64
32 GB RAM
12th Gen Intel I9 3.2 GHz
SSD: C (464 GB), D (1,81 TB), E (3,63 TB)
Are you having seeing this in other software? Maybe you should save that part as a separate file, zip it, and send to PG for evaluation.
All my field recordings (wav, 24 bits, 96 KHz) are located on the 4TB SSD. I’ve installed CrystalDiskInfo to monitor the temperature of my disks.
1. Is the computer simply on, doing nothing else: no problems
2. Am I using WaveLab 12 Pro to work on my field recordings: no problems
3. Am I using WaveLab 12 Pro to work on older dual mono files (25 minutes of sound each) and save them as stereo wav files:
After processing a few files (five to ten), generating peak files suddenly becomes agonizingly slow and shows spectrograms like in the image above, often even worse. Can damaged files be the cause of the problems with the peak files and spectrograms? CrystalDiskInfo gives an alarm signal: 4TB ssd getting to hot. Sometimes the 4TB disk suddenly becomes unreachable and the computer freezes upon restart.
What might be happening here? What causes the 4TB disc getting to hot ?
Thanks! I will first wait for a response to my message above.
Hi
What sample rate are you working at?
Paul
Wav 24 bits, 96 KHz. I’ve also added this information to My post above.
Your disc is going bad and the demise is being exacerbated by the load put on it??? Seems like the most likely answer…have you tried saving to a different disc?
BTW thanks for the info on CrystalDiskInfo…I never heard of it before…
Hi
As someone who has recently lost a good brand SSD that apparently reached its ‘read/write’ limit, I have to agree with @Thomas_W_Bethel here. The SSD is a likely suspect.
Other than that, I can add that I use spectrogram every project every day and typically work at 32 bit float 96 kHz without experiencing your issues. Not that this helps, but maybe it does underscore taking a look at your work disk.
How Hot?
I also have 4 TB SSDs, and their temperature are “normal”, between 47 and 55 degrees celcius.
I don’t know if this helps, but you could try to disable the real-time virus checker on the folder or drive where you have your audio files.
I don’t know how the realtime Virus checker works, but I have noted that the Microsoft Virus real-time checker can totally alter your file access performances. After excluding certain folders, I had a 10x performance boost on full text search. I know this is not audio, but who knows what this Virus checker does.
Thanks everyone for helping me taking a closer look at my SSDs and audio files! I have some old and new information (and I also answer a number of questions above).
My audio computer is not connected to the internet, so I don’t have a virus scanner running.
And I, too, recently had to have a new SSD installed because the previous one (also new!) had failed.
When I just shut down my computer, the overall temperature of the 4TB SSD was 64 degrees Celsius and one of the three sensors was 104 degrees Celsius. Now that’s what I call hot! 
It really looks like some of my dual mono files are corrupted. After successfully converting four dual mono files to WAV stereo, things went wrong. Generating the peak files of a subsequent dual mono file took a very long time. Many glitches and other imperfections were visible in the spectrogram. And the SSD had gotten hot. Is it possible that generating a peak file of a corrupted audio file puts a lot of strain on the SSD? I found a copy of the file in question on an old backup, restored it, and Wavelab 12 Pro had no problem at all generating the peak files.
And, like I mentioned before: it’s only the dual mono files causing me this trouble!
Please describe more about your files. Sample rate, duration, bit resolution.
Give some figures.
Generating peak files is normally very fast. I have a fast computer, but here for two dual mono files of 2 hours (48k), it takes one second, using WaveLab 13.0.20
Generating peak files for two 25-minute dual mono files (24 bits, 96 kHz) normally takes between 1 and 2 seconds, and in that case the spectrogram looks good. Just now, I had two dual mono files (also 25 minutes, 24 bits, 96 kHz) for which generating peak files took about a minute. The progress bar frequently froze completely, and generating a spectrogram took about 20 seconds. At first glance, the spectrogram looked good, until I zoomed in: yellow blocks (like above). A subsequent set of two dual mono files presented no problems, and everything looked good. It is almost certain that the files causing the problems are corrupted and that Wavelab 12 Pro cannot handle them. @PG1 Shall I send you one of the files in question?
Yes please. Send me a PM.
Normally, a PCM file, even if it is corrupted, should not cause such a problem.
On the other hand, a float file could cause such a problem.
Is there a way to prevent WaveLab from treating the files as 32-bit float? While the peak files are being generated, there is no way tot stop the process. I would like to prevent this.
No, What for?
I was thinking: how am I going to prevent WaveLab from generating a peakfile for a file that is likely corrupted? How can I even check in advance whether a file is corrupted?
I meant that if the file contains values stored as float values, then if some float values are damaged, that could lead to trouble. As far as the file contains float values, WaveLab has no other choice but to handle them as such.
I am taking a break from this topic for a moment. First, I am going to have some extra cooling installed in my computer, as that is apparently the main problem. I do still have a pressing question: are all lossless compressed files (osq, wavpack, …) float files, and therefore more vulnerable, because as soon as a few bits ‘flip’, the file becomes harder or even impossible to read.