That explains it I guess - let me add that if someone enabled this option in a version prior to 14.3 that you might want to cure this issue during the update/re-installation of the new release.
I have also noticed some funny stuff with the uninstaller. Every time I had a crash (BSOD) and thereafter (even after a clean re-installation), the uninstaller did not want to start. I am still getting the following message if I try:
"Error: 2 - The system cannot find the files specified."
I guess something goes wrong here to. I can confirm this based on R14.2 but had the same with R14.3Beta.
Please let me know once you pushed a new beta and I will try it again!
BTY, I can confirm that all the drive related settings are shaded! Thanks for that!
All the best for building the next release.
Cheers!
Well I am trying the beta now for the first time and it's displaying the proposed CLI as -V 0 -q 2 -strictly-enforce-ISO -t -noreplaygain and I am thinking how can i add my desired -q 0 ? It would be added to the end of the propsed command line? Edit: Just saw your post about setting quality to normal, will try that.
I hope I'm not derailing this thread, but according to the following discussion, if you use any of the VBR options in any recent LAME version (any version from 2006 or later), then -q 0 is automatically used by default so there is no need to separately specify this:
Bug Fix: Fixed issue causing BSOD on systems with Intel Storage Matrix driver installed (actually is a bug in Intels driver...)
As someone who (once) was obsessed with the T10/T13 documentation for optical drives, I am curious what it is that Intel appears to be doing wrong in their driver...not handling/translating certain buffer sizes correctly? What did you have to do to work around it?
Brendan
PS - looks like there are several other optical drive / disc buring apps out there that have seen BSOD's with several versions of that driver...
We had to pass the exact required buffer size in for 1 call, if the buffer is bigger the BSOD (but a bigger than needed buffer is valid according to the spec)
We had to pass the exact required buffer size in for 1 call, if the buffer is bigger the BSOD (but a bigger than needed buffer is valid according to the spec)
Ouch. That's quite a ridiculous bug in their driver.
Wish I had read this thread two days ago (spent hours trying to interpret Windows 7 dump files after BSOD).
Anyway, just to report, the 14.3 Beta has fixed the following problems I experienced: (i) BSOD on eject in CD ripper; (ii) BSOD on selecting prevent auto run in CD ripper options; (iii) ripper now successfully rips all tracks including last 2. So thank you!
Last (and basic) question. I'm a registered user, so can I auto update to 14.3 when the authorised version comes out?
Comment