Wavelab will not assume file properties for a render in place, so this is normal behaviour - internal resolution is 32 bits, so that’s what the new file will be (possibly with 8 or 16 bits at 0). If the render is to a named file, you have to tell WL what properties the resulting file should have. So if you reduce bit depth to, say, 16, you have to define a 16-bit file format.
Thank you for that! So what its doing is making a 16-bit file then padding zeros out to 32-bit because the internal resolution is set to 32. This is very helpful for someone trying to switch to WL from another title. I’m sure there are 99 other things that I assume work a certain way but I need to learn the WL paradigm.
On the other hand, burning a CD isn’t that outrageous of an assumption. . .
If a drive is not detected, that means the Gear ASPI driver is nor properly installed.
Here one can verify if a driver is properly installed:
Here you can execute the latest driver update:
Brings up a good point I think. Why isn’t there a setting of Match Input Stream under Bit Depth, taking the stream after the Dither section? It makes so much sense to me that that would be a perfect Default setting, to hardly ever have to worry about Sampling Rate, Channels, and Bit Depth, unless I’m just totally missing something.
This happened to me. I cannot burn discs with WL 9.0.35 64 bit but I can burn with WL 9.0.35 32 bit. Never have figured out why. So I just use WL 32 bit for all my burning. I have updated the drivers and run the checking program and no errors found. One of my interns is a computer wiz and he finally through up his arms in disgust trying to figure out why. It was suggested by members of this forum that I reinstall windows (Windows 7 Pro) and maybe sometime in the future when I have nothing else going on and I can afford a week to do that and reinstall all my programs I will. Until then I just burn with WL 9.0.35 32 bit.
A possible reason for this is CD burner firmware.
As an example … I have two apparently identical Pioneer Premium external burners … one with earlier firmware works as expected … with the other a CD can be seen, but cannot be burned. This happens even if the USB port is changed.
Despite reinstalling the drivers and rebooting several times, my new Windows 10 64 system fails the gearsoft installation check with error code 3000000.
GEARAspi.dll (32-bit version) is in the Window\SysWOW64 directory
GEARAspi64.dll (64-bit version) is in the Windows\System32 directory
GearAspiWDM.sys (64-bit version) is in the Windows\System32\Drivers directory but is is not STARTED according to system information.
I can burn a CD with iTunes, Sequoia, Sonaris and any other burner I have on the PC. But not on WaveLab Pro 9.
I suspect this is a permission problem. Is there any way to download the .dll files an manually force them? I can only find the .exe, which fails to install or repair, even when Run as Administrator.
My 30 day trial is almost up and I think this is a show-stopper. Any help would be appreciated on the manual .dll front.
The Gear fixes have luckily worked for me the one time I encountered this.
One quick thing that might be checked is the Windows system files (that was the solution in the Apple Windows iTunes thread below. ymmv). At administrator command prompt run sfc /scannow
There have been a couple of threads here and solutions with registry entries, but if anyone wants to pursue this further, there are a couple of threads at Microsoft and Apple (Windows iTunes) that seem to cover pretty much everything I’ve seen about this:
Windows Resource Protection did not find any integrity errors.
Went to the MS Tech page and ran DRIVEFINDER
Results: CD ROM drive is listen in Up-To-Date Drivers.
Open WaveLab 9 Pro.
Can I burn a CD or (now) import CD?
Must be the filters then, as in the threads.
Try another drive. Or install Wavelab 32 bit instead of, or in addition to 64 bit. Because either of those would probably take care of it.
You could write to Gear and they could probably get it sorted out:
but it should be easier than this, and normally is.
Oh sorry, I just remembered you still don’t have the Gear drivers installed sucessfully (which is what sfc could have possibly fixed), so another drive or 32 bit probably won’t make any difference. (???)
Contact Gear, I guess ?
I have. I’m awaiting a reply. This is very frustrating as every other app on this machine can burn without issue. Even JRiver…
I reproduced your problem exactly on another Windows 10 computer. “service not running”. Actually nothing about the Gear installs and uninstalls would go right, nothing ever removed by the uninstalls. Even tried Gear’s manual uninstall (which was a real pita. Seriously, they can’t make a reg file or script to do that ???), without success. I think they have some real problems with new installs on the latest version of Windows 10. But I hope you get a solution.
My Wavelab on the other Win 10 (not the new Gear installs) continues to work ok though.
Its been three attempts over the past 10 days and I can not get a reply from GEAR. So… I doubt they will reply.
I doubt it too. The page I linked was just general contact because they don’t seem to have general support contact, and it seems like they shut down their forums a long time ago. But I thought they might read the contact emails and make an exception for unresolvable problems. Maybe it’s going to take a contact from Steinberg.
PG, would this ever be possible? The current default Match Source File always gives 32 bit float from montage, no matter what the bit depth of the files in the montage, or the fact there’s no processing or leveling going on, and that’s almost never what I want to be rendering. Match Input Stream (after the dither section) is always what I want to be rendering, whether it’s 16 or 24 bit from the dither plugin, or even if it happens to be 32 bit float if there’s no plugin.
That would make a lot more sense to me, and would save me having to use multiple presets like I do now.
WaveLab does not know what a plugin is doing. To know if a plugin quantizes to 16 bit, WaveLab would need to analyse the whole audio streaming of the montage before making sure this is a quantized stream from A to Z.
Obviously, not a good approach.
Maybe I don’t mean Match Input Stream then. Maybe I mean Match Output Stream. I just always want the rendered file to be the bit depth that’s happening after the dither slot. What’s showing on the bitmeter. A 16 bit file if it’s being dithered to 16, 24 bit if it’s being dithered to 24. I think that’s what the OP expected to happen, coming from another program, and was surprised that it didn’t happen.
I also meant output stream. I can reformulate it otherwise: to know the real bit depth of the montage, the whole montage would need to be rendered internally (for analysis), before knowing to which bit format to save it to disk.
Obviously not a good workflow.