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 fromhttp://www.bustrace.com/products/devfilter.htm
reports for your burner? With InCD 220.127.116.11 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 v18.104.22.168 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.