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.
Sorry, had no idea this was so complicated.
You say Wavelab can’t know if a plugin (like the dither plugin) quatizes to 16 bit.
Can Wavelab play a tiny random sample from the montage, and tell what the bitmeter is saying? That would accomplish the same thing to automate what I’m talking about.
That’s all I’m doing manually. Looking at the bitmeter for a very short random period of time, and setting the output file format to have the same bit depth as that, for the whole montage.
Sorry if I’m being a pain about this. On the surface it just seems to me that I’m now manually setting the file format to a fixed value based only on what I’m seeing on the bitmeter at any small random time I pick to play in the montage. And that works for me. Would just like to have it happen automatically.
I can think of a scenario if I’m not using a dither plugin where this might need to be analyzed for the whole montage I guess, but not if I’m using a dither plugin as the final thing, I wouldn’t think.
Can Wavelab play a tiny random sample from the montage, and tell what the bitmeter is saying?
Not sufficient. A montage could start with a 16 it clip, then some 32 bit clips could follow.