I am new to this forum and new to Wavelab 8, but have been a user of Wavelab 4 for about 10 years. I edit CD audio and make programmes as an indy for a well known broadcasting outfit.
Under normal W4 environment, I highlight the area to be worked on - whether it is a gain change or a simple delete of a cough or an “ummmm”, and simply do the task. The result was instant - even on an old creaky single core XP machine.
With my new quad core machine with 480G SSD and 8Gb RAM running the super zoomy Wavelab 8, every action takes at least 5 or six seconds. Some things like rendering a portion of speech with a couple of Master section plug-ins seem to have a progress bar which flies - then there is the five second egg-timer rotating circle thingy. I’m working with a 30 minute 24 bit 44.1 file. I am thinking that the fastest way would be to do my normal editing on my XP/W4 laptop, and simply use W8 for the creation of ddp files and checking levels with the LUFS meters. Surely I’m doing something wrong here? Even undo delete or a file save has this 5 seconds of extra magic added to it!
This is not normal, of course. WaveLab 8 is at least as fast as WaveLab 4.
I don’t have an explanation, however 
WaveLab Windows version do you have? Do you the 32 or 64 bit version of WaveLab?
64 bit. It seems as if it is doing an “invisible” file save after every operation - save takes about 5 seconds according to the progress bar in task window, and then you wait for a further five seconds for it to do “something else”. I suppose I should try it with a small file. Broadcast deadlines are looming and I probably shouldn’t have made the switch at this time, but I’m having to comply with the EBU legislation on LUFS and loudness…
Now this is getting interesting. I took a small 10 second chunk of the file and copied it into a new window. Did all the usual normalise, gain change, undo, delete bit, and all happened instantaneously. Just as in WL4. So I copied the 30 minute file into a new window and it behaved the same way. Great, I thought this is the problem solved. I’ll just save this copy and work on it instead. Once saved (under a different name), it starts to behave as the first one. The Save dialogue is complicated I have to say - certainly flexible in its options, but the documentation doesn’t really help. I’m pretty sure that WL8 is writing the entire file to somewhere on the disc after every little thing that I do. Grrr.
Are you perhaps working with files in a network location or not local to the PC itself? Are you not running WL as administrator? Maybe things that could be responsible… I’ve never experiemced anything like this, using the same program versions.
No, Arjan, I’m working on the local C: drive - the SSD was bought because of its speed 
Yes I am the administrator - supposedly!
I have the following two files in my main working directory along with the “proper” files.
They look like the temporary files that WL4 used to leave when it crashed - it normally hoovered them up during an ordered shutdown…
086691d25d43537794afecac7b64ef9a-5335095.$$$ 223Mb (same size as proper .wav file) and
086691d25d43537794afecac7b64ef9a-5335097.$$$ 1.3Mb (same size as proper .gpk file) and the date/time stamps correlate.
I rather suspect that the programme itself isn’t quite right - either by installation or else because it is the 8.0.0 version. I am going to try the 32 bit version. This 64 bit version can be made to crash by trying to reorder the various meter tabs as well. 100% reliable crash every time…
Well, problem at least partly solved by downloading the latest version 8.0.3, and installing the 32 bit version. When presented the first time I automatically plumped for the 64 bit version as I assumed that it must be “better”. I wonder now what the advantages are. Does anybody have any real world evidence that there is a user discernable difference? I can see that the 32bit one works (so far), but I haven’t yet tried the 64 bit 8.0.3 as I’m up against it time wise. What is the opinion of the forum regarding using the 64bit version?
Further to the above, the problem is now solved. The problem is 
editing a file with the loudness window being displayed. This has to be recalculated and it’s much slower than redrawing the edited portion of a gpk file. The 3s, 10s and infinite integrations have all to be redone - when I think about it, it’s sort of obvious. This might be mentioned as a caveat in the manual - I can’t imagine that I’m the first one to run across this operational difficulty. One of the reasons I bought this new version was the loudness metering which is becoming the new must have for programme makers.
Well AFAIK, some VST3 plugins need a 64-bit host, but other than that I don’t think it’s ‘better, faster, stronger’ (to quote Daft Punk).
Ah, makes sense. If you mean the loudness representation of the waveform at hand, that is. Considering you’re working with 30 minute files, I’d say 5 seconds is pretty fast! 