InCD 4.0.1.0

[KCK]

Nice to see you back at CDRLabs, Craig!

In addition to some installation problems, this thread has exhibited the following basic issues:

1. Dates and times aren't preserved for files copied to MRW discs

2. InCD doesn't autoplay when a blank disc is inserted

3. Excessive memory consumption by incdsrv.exe and InCD.exe

4. Slow reading and writing relative to InCD 3.x

Do you know if your Q&A team in Germany could duplicate these issues?

I guess you are fixing bugs on a daily basis for your OEM's, but apparently upgrades will be released on Ahead's website at the beginning of each month only. If yes, you won't get much feedback.

Right now, InCD 4.0.1.0 is useless for me because of the time stamping problem. If this problem is not resolved quickly, I'll revert to InCD 3.52.40 (which is fine).

As for the future, I wouldn't mind switching between InCD 3.52.40 and newer versions for tests, provided they uninstalled cleanly via Add/Remove Programs. I had no (un)installation problems with InCD 3.x, but InCD 4.0.1.0 made a lot of changes in my registry.

Thus I have a basic question: Can you guarantee that InCD 4.0.1.0 will uninstall cleanly? Or should I get a new version of Nero-CleanTool? If yes, why is Nero-CleanTool still not available on Ahead's website?

To sum up, unless a new version becomes available within the next few days, I'll remove InCD 4.0.1.0. If I then find that registry editing is required, I'll probably stay away from InCD 4.x for a couple of months.

[Inertia]

KCK,

Thus, apparently for InCD 4.0.1.0 there is no other way of checking capacity except via Explorer | Properties | General.

Yes, this seems to be true and probably why I didn't check the capacity in Nero properties with InCD 4.

Now, if I understood correctly, while using InCD 4.0.1.0, you got 442 MB for a 74min MRW disc formatted with InCD 4.0.1.0. (The latter aspect needn't be important, unless Drag-to-Disc was used for formatting, since on my XP box InCD 4.0.1.0 reports correct (original) capacities for MRW and non-MRW discs formatted by InCD 3.31, 3.51.91 and 3.52.40.) Well, since our capacities differ so much, it would help if other users reported their capacities for MRW discs with InCD 4.0.1.0.

The 442 MB capacity in Windows properties didn't come up again with InCD 3.5, so I am willing to treat it as a fluke with InCD 4. Especially so since I didn't believe it anyway.

Since you only mentioned different capacities reported by Explorer and InCD 3.x properties for this single disc formatted by InCD 4.0.1.0, I'll check if this also occurs for discs formatted by InCD 3.x once I revert to 3.x.

On the other hand, if Drag-to-Disc reports 527 MB capacity for a 74min MRW disc formatted by InCD 3.5.x, then something is definitely wrong, and InCD 3.5.x needn't be the culprit. Could you tell us what capacities are reported by Drag-to-Disc and InCD 3.5.x for MRW discs formatted by Drag-to-Disc?

I have discovered the reason for most of the confusion. Roxio Drag-to-Disc is apparently using the MB system used by disc manufacturers, where 1 KB = 1,000 bytes instead of 1,024. Drag-to-Disc reports 559 MB for a non-MRW disc, when in fact it is 533 MB using the traditional computer measurement. Roxio must have switched horses in mid-stream with this capacity system, as DirectCD 5 uses the traditional 1,024 bytes = 1 KB.

In my earlier post where I reported that Drag-to-Disc was reporting 527 MB for the same disc that InCD reported as 503 MB, the fact is that the capacity is exactly the same but the reporting method is different.

I just did a full erase and MRW reformat with InCD 3.5.24.0. It took about 20 seconds to format the disc to prepare it for writing. WinXP properties shows free space of 527,659,008 bytes or 527 MB. The MB as shown in WinXP general properties is incorrect, as those bytes translate to 503 MB. The InCD property sheet shows the same number of bytes and the correct 503 MB. This discrepancy is probably because I have both InCD and Drag-to-Disc loaded, and Windows is picking up the Roxio capacity system.

In case anyone is wondering why I have both InCD and Drag-to-Disc loaded, it is just to be a technical resource to those needing help. It is not a recommended installation, as it serves no practical purpose. I have done it because it will operate this way in WinXP without noticeable conflicts and it is easier for me to help people without installing and uninstalling every time a different system comes up. I would say that because of this configuration it can confuse results as noted, although when I tested InCD 4.0.1.0 it was the only packet writing software loaded.

[KCK]

Inertia:

If Drag-to-Disc indeed uses the decimal prefixes 1K = 1000 and 1M = 1,000,000 instead of the binary prefixes 1K = 1024 and 1M = 1,048,576 which are standard for reporting file sizes under Windows, then this bug should be reported to Roxio; I just wonder how long it will take for Roxio to fix it!

Could you tell us what capacities are reported by Drag-to-Disc and InCD 3.52.40 for MRW discs formatted by Drag-to-Disc? This would allow us to compare overheads used for data integrity purposes, if any.

To this end, you would probably need to uninstall InCD 3.52.40; otherwise, how would you know whose drivers (Ahead's or Roxio's) were involved in formatting? In other words, are you really sure that when DrgToDsc.exe (or InCD.exe, resp.) is called to format a disc, Ahead's (Roxio's, resp.) drivers don't interfere, and everything proceeds as if only Drag-to-Disc (InCD, resp.) were installed?

I'm just curious how Drag-to-Disc and InCD are supposed to coexist on the same box. Could you tell us what the filter-driver-load-order utility from

http://www.bustrace.com/products/devfilter.htm

reports for your burner? With InCD 4.0.1.0 on my XP box, it reports: Upper Class Filter InCDPass, Upper Device Filter redbook, Device Object OXFORD IDE device (my external burner), Lower Device Filter imapi.

[MediumRare]

I have discovered the reason for most of the confusion. Roxio Drag-to-Disc is apparently using the MB system used by disc manufacturers, where 1 KB = 1,000 bytes instead of 1,024. Drag-to-Disc reports 559 MB for a non-MRW disc, when in fact it is 533 MB using the traditional computer measurement. Roxio must have switched horses in mid-stream with this capacity system, as DirectCD 5 uses the traditional 1,024 bytes = 1 KB.

Isn't this a classic case where the use of proper binary multipliers would obviate the entire confusion? It was the first thing I thought of when I read 503/528 MB in your earlier post, Inertia, and was cofirmed by

used space 38,912 bytes 38.0 KB, free 529,885,184 505 MB, capacity 529,924,096 bytes 505 MB

If that had been 505 MiB (MiByte), no one would have looked for the missing bytes!

G

[Inertia]

If Drag-to-Disc indeed uses the decimal prefixes 1K = 1000 and 1M = 1,000,000 instead of the binary prefixes 1K = 1024 and 1M = 1,048,576 which are standard for reporting file sizes under Windows, then this bug should be reported to Roxio; I just wonder how long it will take for Roxio to fix it!

MediumRare and KCK,
I may be a cynic, but I feel certain that Roxio knows about this and did it on purpose. They are a marketing oriented company, and could easily rationalize this change by using the same logic that the storage (hard drive) industry has used to change to decimal capacity instead of binary capacity. See the explanation at Storage Capacity Measurement Standards. CD-R media can be used for storage, and it would be easy to use this as a justification for changing from binary to decimal as the storage industry has already done.

I don't think that Roxio would consider this to be a bug, but you can report it to them if you want. They are generally unresponsive to input in my opinion.

Could you tell us what capacities are reported by Drag-to-Disc and InCD 3.52.40 for MRW discs formatted by Drag-to-Disc? This would allow us to compare overheads used for data integrity purposes, if any.

To this end, you would probably need to uninstall InCD 3.52.40; otherwise, how would you know whose drivers (Ahead's or Roxio's) were involved in formatting? In other words, are you really sure that when DrgToDsc.exe (or InCD.exe, resp.) is called to format a disc, Ahead's (Roxio's, resp.) drivers don't interfere, and everything proceeds as if only Drag-to-Disc (InCD, resp.) were installed?

I uninstalled InCD and formatted with Drag-to-Disc with MRW. The 74 minute disc shows 527,462,400 bytes free and a decimal 527 MB in both Drag-to-Disc and WinXP General properties. The WinXP properties appear to be a virtual clone of the Drag-to-Disc properties, using the Roxio icons and measurements, etc. This is true even when InCD is also installed.

I then reinstalled InCD and rebooted. InCD 3.52.40 properties has the same 527,462,400 free bytes, but reports a binary 503 MB available. As I stated earlier, there is no overhead or capacity difference in the two programs, just a different reporting method of decimal vs. binary. DirectCD 5 uses the binary system as InCD does, but Drag-to-Disc 6 uses the decimal system.

I'm just curious how Drag-to-Disc and InCD are supposed to coexist on the same box. Could you tell us what the filter-driver-load-order utility from

http://www.bustrace.com/products/devfilter.htm

reports for your burner? With InCD 4.0.1.0 on my XP box, it reports: Upper Class Filter InCDPass, Upper Device Filter redbook, Device Object OXFORD IDE device (my external burner), Lower Device Filter imapi.

Packet writing software with embedded system drivers is normally not supposed to coexist without conflicts when more than one program is installed. Apparently WinXP is more forgiving than the Win9x systems. I had always warned everyone not to try to install more than one packet writing system, and then read a post at CDRLabs from someone who had installed InCD and DirectCD 5 together successfully in WinXP before I could tell him it wouldn't work.

I was skeptical, but tried it myself to see what would happen, and it didn't cause any obvious conflicts and seemed to be the exception to the rule. I don't remember who first tried this now, but an experienced user should have known better. Dumb luck has its payoffs.

When the Filter Driver Load Order utility is loaded, it appears that the Roxio drivers have taken over most of the filter functions:
Upper Class Filter - cdralw2K.sys, a Drag-to-Disc v6.0.0.171 file
Upper Device Filter - redbook.sys
Device Object - LITE-ON LTR-52246S
Lower Class Filter - cdr4_xp.sys - Drag-to-Disc
Lower Class Filter - bsstor.sys - Nero (BHA)
Lower Device Filter - imapi.sys

As you can see, the InCD bsstor.sys file is retained as a Lower Class Filter.

[KCK]

Inertia:

I just hope that Ahead doesn't follow Roxio's example in using cheap tricks to confuse users about their "superior" formatted capacities.

For the benefit of other users, let me add that recent standards on prefixes for binary multiples were discussed in this thread:

http://www.cdrlabs.com/phpBB/viewtopic. ... 5867#55867

Leaving Drag-to-Disc's reporting aside, what matters is that for MRW discs, InCD 3.52.40 reports 527,630,336 bytes free for D-to-D's discs, and 527,659,008 for InCD discs. This relatively tiny difference makes it unlikely that much different schemes are employed for data integrity purposes.

Your filter driver load order looks reasonable, since bsstor.sys also appeared as a Lower Class Filter on my XP box with InCD 3.52.40. It makes me wonder whether the lower class filter order depends on which program is installed first, and whether it matters for correct operation of each program. I also wonder why nobody seems to have tried installing DirectCD or Drag-to-Disc on top of InCD 4.0.1.0 so far!

[dodecahedron]

I'm just curious how Drag-to-Disc and InCD are supposed to coexist on the same box.

Packet writing software with embedded system drivers is normally not supposed to coexist without conflicts when more than one program is installed. Apparently WinXP is more forgiving than the Win9x systems. I had always warned everyone not to try to install more than one packet writing system, and then read a post at CDRLabs from someone who had installed InCD and DirectCD 5 together successfully in WinXP before I could tell him it wouldn't work.

I was skeptical, but tried it myself to see what would happen, and it didn't cause any obvious conflicts and seemed to be the exception to the rule. I don't remember who first tried this now, but an experienced user should have known better. Dumb luck has its payoffs.

here ya go:
http://www.cdrlabs.com/phpBB/viewtopic.php?t=7273

[CCampbell]

Hi KCK,

We have seen a number of this issues, among others. And we have resolved a number of them or are working on them. To address yours directly...


1. Dates and times aren't preserved for files copied to MRW discs

A) I will have to search our Database and see if this issue has been entered. It should be a simple item to fix.

2. InCD doesn't autoplay when a blank disc is inserted

A) This has been reported. Seems to occur with some drives and not others. Our Engineers are working on this issue now.

3. Excessive memory consumption by incdsrv.exe and InCD.exe

A) This issue has been reported and fixed.

4. Slow reading and writing relative to InCD 3.x

A) This has also been reported. It will be worked on, but other bugs that are more critical take prescedence.

We are fixing bugs on a daily basis true, but our OEM's are not getting upgrades on a daily basis. Can't create a new master for them after every new build of InCD. I will try and get a new version posted sooner than each month, but the standard practice is to post a new version each month. Sorry.

We are coming out with a new InCD Cleaner and Nero Cleaner to be sure Nero as well as InCD is removed cleanly from any system. We are also working to have InCD 4 uninstall cleanly through the Add/Remove Programs feature, so that the clean tool is not needed.

You can download our Nero Clean Tool, and our InCD Clean tool from the below links. We have a new version of each to work with our new InCD 4, as well as Nero 6 when it's released. Not sure if Germany has uploaded the latest versions. I will check on this tonight and ask them to update them by tomorrow if they have not already. But anyone who finds when they download these tools that InCD 4 is not being cleanly removed from their system, can send an Email to me directly at techsupport4@nero.com and request the utilities and I will provide it to them.

ftp://ftp9.nero.com/attach/Nero-CleanTool.zip
ftp://ftp9.nero.com/attach/InCD-CleanTool.zip



Best Regards,

Craig

[KCK]

CCampbell:

Many thanks for your extensive and quite reassuring reply!

The executables in your links are dated Dec. 3, 2002, i.e., that version of Nero-CleanTool has already been tested by us. Please let us know when new versions become available.

[Inertia]

dodecahedron,
Thanks for the link about the dual installation of InCD and DirectCD in WinXP. This is the one to which I referred.

KCK,
Thanks for the link to the discussion about measurements. I missed this very interesting thread.

Leaving Drag-to-Disc's reporting aside, what matters is that for MRW discs, InCD 3.52.40 reports 527,630,336 bytes free for D-to-D's discs, and 527,659,008 for InCD discs. This relatively tiny difference makes it unlikely that much different schemes are employed for data integrity purposes.

The 527,630,336 bytes above was the total capacity of the disc and was reported in error. The free space reported was actually 527,462,400 bytes, exactly the same for both Drag-to-Disc and InCD. My original report has been edited to correct this error.

For the sake of experiment, I tried to format a disc with both InCD 3.5.24.0 and Drag-to-Disc installed and observed the following results:

Formatted with InCD - The disc is named InCD by default and returns 167,936 bytes used - 527,659,008 free - 527,826,944 capacity. This is the same result received when Drag-to-Disc was uninstalled.

Formatted with Drag-to-Disc - The disc is named Roxio2 by default and returns 167,936 bytes used - 527,462,400 free - 527,630,336 capacity. This replicates my previous experience when formatting with Drag-to-Disc.

Not surprisingly, this did finally uncover some system conflicts as I experienced a couple of blue screens after formats were completed when trying to read the discs. After rebooting the system seemed stable and the discs were readable without problems.

The results seem to indicate that either program can be used to format, and the insignificant differences observed in free space and capacity can be attributed to program activities.

[CCampbell]

I have been assured from our IT administrator that the new clean tools will be posted on our website tomorrow.

And the Timestamp issue for InCd 4 had not been reported, so I created a bug report and we have an Engineer working on this issue now.

Regards,

Craig

[Inertia]

Thanks for the feedback, Craig.

I'd also like to welcome you back to CDRLabs. It's always a pleasure to have you here helping us.

[Inertia]

I just hope that Ahead doesn't follow Roxio's example in using cheap tricks to confuse users about their "superior" formatted capacities.

KCK, the more I think about the way that Roxio is using the decimal system to represent capacity on CD-RW, I think that attributing this action as "cheap tricks" is being kind. I am by no means a diehard supporter of the binary capacities used by computers. I could give my reasons for these misgivings at length, but this is not the appropriate thread. My objection with Roxio's method is that it is worse than a cheap trick, and closer to fraud. Nowhere else in computer memory or storage is this decimal capacity used, and particularly not on hard disks where it would be expected to be found (if anywhere). The confusion with hard discs arises when retail information states the capacity in decimal units, and the computer "undersizes" it to binary units. Instead, it seems that Roxio has unilaterally "oversized" the recognized standard for computers for their own purposes without regard for consistency or principles.

I have a hard time believing that this is a bug when the entire structure of computer reporting is based on the binary system. I may be wrong, but it would seem to me that Roxio went out of their way to create this confusing and inconsistent capacity system. If this is so, in my opinion, it would be more of a fraudulent action than a "cheap trick". I have installed the most recent update for Drag-to-Disc and it still uses decimal based capacities. Their Drag-to-Disc system is even more bizarre considering Easy CD/DVD Creator 6 still uses the standard binary system when reporting the capacity of CD-R discs. Maybe the Drag-to-Disc decimal system is a bug, as unlikely as it seems. Any other explanation is even more unbelievable.

I would send Roxio an email about this, but there is no way to contact technical support about a bug without paying for the privilege. I tried to access information on the Roxio discussion board, which is one of the most frustrating experiences available on the internet. I had so many problems with the incompetence of the board operation in the past that I quit going there. When I went back as a last resort they had changed my login to inertia98457x with a new 16 character alphanumeric password, needless to say without my requesting the change. I was unable to change the login back to Inertia, as it was reported as already taken. So I changed it to inertiaa, which is as close as I could get to the original.

I wouldn't have bothered, but I wanted to see if I could find anything related to the decimal capacity in Drag-to-Disc. The next obstacle is that it required a login every time anything was requested. Open a topic, go to next page, search, no matter what the request it was necessary to login again. After logging in about 20 times or so I finally gave up as it wasn't worth the effort. I see that the Roxio discussion board has kept its horrible operation intact.

I used to be an Adaptec/Roxio supporter, but if any company deserves to circle the drain, they do.

[KCK]

Inertia:

Thanks for the additional formatting details. There was a typo (spurious K) in the used space, i.e., 167,936 B = 164 KiB. Incidentally, the overhead of Drag-to-Disc relative to InCD was precisely 196,608 B = 192 KiB.

I agree completely with your assessment of Roxio's "oversizing", and I thank you very much for sharing your insight on Roxio's technical support and discussion forum.

[Inertia]

KCK,

To be concise
I was bitten by bytes
But fed it
By edit.

Thanks again for keeping me honest.

[dburg]

Two other issues that have been reported in this thread have been fixed for next version of InCD 4:

1) Incorrect available size after format

2) Compability issue with new BenQ MRW capable fw

[KCK]

Welcome to CDRLabs, David!

I've not been hit by these issues, but I'm sure other users will appreciate these fixes.

[Hazey]

Two other issues that have been reported in this thread have been fixed for next version of InCD 4:

1) Incorrect available size after format

2) Compability issue with new BenQ MRW capable fw

Well it's great to hear that the problems I had with InCD 4 and my BenQ burner may soon be a thing of the past . Thanks Ahead for all your work.


Cheers .

[Traveller]

BTW, as I sidebared in an other post(s), InCD 4.0.1.0 (as well as EasyWrite Reader 4.x -> incdpard.vxd 4.0, , incdrm 1.0 & incdudfr.vxd 4.0) exhibits a curious anomaly with [my] Windows 98SE setup in that one or more process threads is in an infinte loop, causing the CPU to constantly run at full load. Terminating "InCD.exe" does not eliminate the problem.

If anyone knows of a utility that not only displays processes (& their threads) but the CPU utilization for each process, please let me know as I can than identify the culprit.

[Inertia]

You can download and try the shareware TaskInfo2003.

It shows CPU utilization for all running tasks (including threads if desired), and has helped me fix many a problem.

[dburg]

Let us know about your findings Traveller!

[CCampbell]

I have been assured from our IT administrator that the new clean tools will be posted on our website tomorrow.

And the Timestamp issue for InCd 4 had not been reported, so I created a bug report and we have an Engineer working on this issue now.

Regards,

Craig

Sorry, we had a few issues and changes, so this tool was not posted on our website as I had promised.

However, I have been assured it will be posted on our website by tomorrow. And we do not anticipate any problems this time. We now will have only one General-CleanTool_1135 that will do it all.

Regards,

Craig

[Traveller]

Let us know about your findings Traveller!

Well, I'm afraid I can't offer much in terms of findings....

I DLed Taskinfo (thx 4 the tip, Inertia ) and it simply shows the idle "process" (& 1 thread) @ 98%, which is exactly what it looks like when InCD or EasyWrite 4.x isn't installed. Even worse, there is a field in TaskInfo (under the system tab) that lists both %idle (98%) & % Idle priority threads (blank!). This is where I had hoped to see some form of "background" process that runs with a priority of idle, but nada, nichts, niente, no proof to be seen anywhere.

The only other item that might be of interest is the "priority" field, which displays a 13/13 in the one idle tread. Last but not least, I ran a little pgm called Wintop, which listed 7 threads under the "Idle" process....

Still, I guarantee you that even if you were to think that Motherboard Monitor was "whacked", I can assure you that the thermistor taped to CPU'S HSF is not!

I'm out of ideas...

... no I'm not! (addendum)

Back when I was running W98SE on P2s & Klamath P3s, I used a routine called Rain (aka CPU Idlers - Waterfall & CPUIdle are two other such pgms that come to mind). Well, I re-installed InCD 4 & I ran RAIN & guess what, the temps fell back to std "idle" values! Not only that, but this "% Idle Priority Threads" I mentioned above is now @97% & the Idle thread's priority field's now showing 4/0 instead of the previous 13/13.

Now, I have no idea how new/ updated OSes & newer CPUs deal with "true" idling, but somehow, the installation of InCD 4 on my W98SE setup is blocking this process. I did some googling, but couldn't find any info on the subject (so far). All I know is that pgms like Rain issued a HALT instr (because in the "old days", an idling CPU was equivalent to an active CPU constantly issuing an "noop" instruction, waiting for some task to come along.

Wild, ain't it?!?

[Inertia]

Traveller,

If you have a misbehaving thread consuming CPU utilization, it will show up as a reduction in the idle (available) %. The problem consumption in TaskInfo will show as an abnormally high CPU % in a loaded application or thread underneath.

In other words, when it occurs the problem is not likely to be found in the "idle process" or its threads, but in a misbehaving application.

For instance, on my Win98SE computer I sometimes have a runaway CPU consumption that causes balky operation. This has been traced to the Windows 32-bit VxD Message Server, or the MSGSRV32.EXE file. Normally the activity of this file may be about 0 to 0.01% of CPU capacity. When it goes bonkers, the CPU % of various applications bounce up and down in the highest available CPU % range while the Windows 32-bit VxD Message Server will be consuming unreasonably high CPU capacity, i.e. 30-60%. When this happens I right click on the Message Server and select Terminate Process. This causes no system problems and restores everything to normal operation.

[Traveller]

.... Now, I have no idea how new/ updated OSes & newer CPUs deal with "true" idling, but somehow, the installation of InCD 4 on my W98SE setup is blocking this process. ....

Servus, Gruß Dich, David!
Do you think you could ask around @work if there is any possiblity that InCD 4.0.1.0 could somehow have disabled (or be in conflict with) W98SE's ability to [automatically] issue the HALT instruction...?

Your help would be much appreciated!

mfg,