laserfan

Thanks Peru but I found a freeware app that seems to do just what I want, called CDBurnerXP. It allows me to create "Open session" data discs, and then when such CD-RW is re-inserted to my drive, it asks if I want to add to the existing session. Looks like a winner so far.

Ouch. Well, thanks mmalves for your fast reply. I've done some more surfing on this and apparently if I want to do this I need "packet-writing" software, whatever that is. Anything but Nero!!!! If anyone here knows how best to do this please chime-in. All I want to do is use a CD (or DVD) -RW or -R to be able to add files on a regular basis until the disc is filled-up, for backup purposes (like a floppy works!!!!).

I thought there was a way to format a CD-RW such that one could continue to add files to it (in new sessions) until full. Am I wrong? Can't seem to find anything in the Guides or forum about this...

Thank you mmalves for your reply! I will give that a try!

Searching here (& guides) did not yield an answer to my question: What file system should I choose for writing data files to a DVD+R that a Macintosh (iMac with SuperDrive and Leopard) can read? I need to burn so my Mac-equipped recipient can just plug & read the files on the disk (mostly jpegs & txt & such that should require no conversion from Windows to Mac). ISO9660? ISO9660+UDF? UDF-only (what version)? Sorry but I can't seem to find a definitive answer anywhere (else)!

Neither am I, but I can Google with the best of 'em, and I have patience 2nd to no one! Thanks for clarifying. You'll probably never know (as I don't know what specifically fixed a Verify problem I was having, but it is indeed fixed) but my money's on the mysterious Paging file, by your description of what you did. FWIW I'd also been having some BSOD problems which felt Pagefile in nature, having tried putting it on a diff. drive myself, but in the end have put it back on C: and it's working fine so I'm not looking back. I never noticed any speed improvements w/using it on another drive anyway.

I don't understand. You're saying the problem all along has been a single DVD+RW rewritable disc you've been using for testing? If yes, why the 1-2-3 i.e. just throw away the disc!? Or a combination of the "dodgy" disc and something else you changed? Guess that's it. I'd say 3. or 1., or 4. () but not 2. FYI among the (many) things I tried when I was getting verify errors was to change my signalling method from Cable Select to Master/Slave (jumpering). But I can only guess that if you had an angled connector (not properly seated) or something that might have created an addressing problem that caused the process to fail at a specific point. Or wrt Page File that your memorysize-vs-pagefileneed was such that again a specific memory size became an issue. One suggestion I have is for you to write-down somewhere everything you've tried/done so that if this comes up again at least you can try to refresh your memory about it.

Phil, I was having Verify problems too, though not a consistent "fails at 66%" problem like yours. But I'm wondering if, in your new PC setup, you've used the hard drives from your old setup? My PC was created a few years ago, and was built from-scratch using hdds from still Older computers, and developed a problem where I couldn't get Verify to work properly. A couple things I did that may inspire something for you: 1. I'd had my Paging File assigned to a non-C:\ drive. Internal, but a separate drive. I was sometimes getting BSODs and I think it had to do with Windows being confused about drive letters--because I'd also assigned DIFFERENT DRIVE LETTERS THAN WHAT WINDOWS BUILT-IN ALGORITHM WOULD NATURALLY ASSIGN. 2. I also found my way to my MountedDevices key in the Windows registry, which should have had just a couple dozen entries, but instead had almost 200! This is the place where XP keeps track of what partitions you have, and what letters are assigned. You can clean it up by deleting the entries and re-booting. I also had a suspicious drive, i.e. I wondered if one of my internal drives wasn't overheating and glitching-out on me after being worked hard. Dunno if that was right or not but I swapped it out. Just thinking maybe the "66%" might have something to do with temporary or paging files, and the way your PC is partitioned. Wild ass guess.

STILL wrong! This is not the "magic" or purpose of ISO at all! As LUK said the packaging of short files into a single file can be done many other (and much better) ways, the most obvious of which is .zip files. An ISO is a bit-accurate *image* of a CD or DVD, which allows one to re-create (with the right burning software, as ImgBurn is) the CD or DVD from which that ISO was made, in not only content but also structure (i.e. exactly where the content is actually located on the disc). The "magic" is that burning from an ISO makes a disc that is identical to the original from which the ISO was made, irrespective of what is actually on the disk (could be anything--DVD/VIDEO_TS, programs, files, avis, etc.).

Reminds me of something one of my High School "teachers" used to say whenever he encountered a student's response to a question, "I forgot". His retort: "In order to Forget, first you must Know!"

Many thanks!

Can you (or anyone) explain briefly how to "create MD5 hashes and verify" or what the RAR + recovery method is?

After a month of fiddling with this computer literally day-and-night (I'm retired), which as Blutach said was clearly Not Quite Right, while I can't say "it's fixed" indeed it's working a lot better, though I just had, after 4 or 5 perfect burn/verify cycles in a row, another (solitary though) "miscompare". Among the things I've done: 1. Replaced my 1Gb of RAM with 2Gb 2. Replaced the hard drive that was my Startup/system drive 3. Turned-on OPC and have been using 2x w/ImgBurn despite that my discs are 16x A lot of other things have been done, including switching from Cable Select to Master/Slave jumpering, but in the end I think there's a possibility of all of these things coming into a "perfect storm" to thwart my burn/verify efforts: 1. Too little RAM and too much use of the hdd-based Paging file for these huge files I'm burning (many >4Gb) 2. A flaky disk drive that might have been glitching-out when overheated; man this one's a bitch and I'm still wonderin' about it 3. A marginal 100disc cake of Verbatims? My storage location isn't "cool & dry" enough here in the hot, humid, sunny South? Regardless, I now own & use a passel of PC integrity/torture testers, including not just MemTest86+ but also HCI Memtest, Prime95, TestIO, and Bart's Stuff Test. Highly recommended to anyone who wonders if their PCs are Perfect, or maybe Not Quite. I'd still like to see an option w/ImgBurn to Not Stop on a miscompare, as I noted in another thread, but didn't want to leave this thread go unresolved so there you have it. I think I'm done...whew!!! Thanks to all who stopped-by...

Not sure if you mean "return the cake to the store for another" or "Verbatim offers a lifetime guarantee so send the defectives to them for replacement"? This latter is something I've never tried but I wonder who here has, and how easy-or-difficult it might be to deal w/Verbatim. It's occurred to me to just set-aside all coasters and then load 'em up and send to Verbatim but I've never done it...

Actually there's a new utility DiscSpeed 4.11.2.0 just out. My scans look good...nothing there that I can see. Took me a second or two to decipher NQR in your post--got it! Indeed! Grasping at BIOS straws now, like 32bit transfer mode & such. I will come back if I ever get this fixed...

I'm surprised DVD-R discs work in your Sony; in my experience DVD+R are more compatible. Get a cake of Verbatim DVD+R this time.

Do you mean from How to check if your burn is a good one? Although last updated in 2005, is CDSpeed still preferred or is DVDInfoPro (I don't have) better? I notice also your Burn guide suggests 4x burning; I've been using 8x with 16x Verbatim media. Although 4x isn't listed as a supported speed for the Verbatim, is that speed still OK to use? Thanks for your patience. I'm off to run the CD Speed tests.

Thanks blu, I was doing just that as you were posting. First, I made an .ISO from a video titleset, mounted that ISO using VirtualCloneDrive, and did a Verify, which came-out perfect: I 18:46:28 ImgBurn Version 2.4.1.0 started!I 18:46:28 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 2) I 18:46:28 Total Physical Memory: 1,048,044 KB - Available: 693,616 KB I 18:46:28 Initialising SPTI... I 18:46:28 Searching for SCSI / ATAPI devices... I 18:46:28 Found 1 DVD-ROM, 1 DVD-RW, 1 DVD

So if I understand this correctly, even when ImgBurn is burning from hdd directories/files, and not an .iso image, it first Creates For Itself an iso image (is this what "Building Image Tree" and "Preparing Image" are doing? in the logs), burns it to disc, and then verifies the just-burned disk sector-for-sector against the (temporary) image it's created for itself? If that's correct, where is the temporary image created, on the ImgBurn drive (in my case C:\Program Files\ImgBurn)? Or perhaps "ImgBurn Images" or "Queue" from the File Locations Setting? Many thanks for your detailed replies, and your indulgence. I've just run an exhaustive check of drives to match my RAM testing and all looks fine. Next step is to try more RAM I guess, assuming a possible WinXP issue, then finally a complete re-install (yuk!) of Windows...

Please bear with me--this is very curious: Yesterday I used ImgBurn to make an .iso of a fileset and then mounted that .iso with VirtualCloneDrive and compared files with WinMerge. Three VOB files failed to compare (about 20 files total in set). Then I tried another tool Folder2Iso and made another .iso and mounted it. Got one VOB file that mis-compared with WinMerge. Then I did this fileset again with ImgBurn, mounted it, and got all files to compare OK. But just one good ISO out of three, so something is definitely wrong w/my setup (in no case did I even burn a disc to DVD+R) but I'm not convinced of a hardware problem (yet), because... A couple days ago I'd run Memtest+ (from disc) overnight and then yesterday ran HCI Memtest into this a.m. and get Zero errors. None. Clean bill of health for the CPU and RAM. Using 3 hdd here, one for System & one for the fileset and a third for saving the ISOs to--yesterday I chkdsk-ed and defragged the heck out of them and they all seem fine. But it occurred to me that it's always a VOB file that miscompares, a 1Gb file, in every case. After googling a bit yesterday I came across some info that some people have memory problems with gaming, and in particular 1Gb machines tend to be a problem. I have a 1Gb RAM machine. So I'm going to tinker w/PagedPoolSize in the Registry and also look to acquire some more memory, maybe boost mine PC to 3Gb. Anyone here share my hunch? Possible WindowsXP issue w/1Gb RAM and 1Gb files I'm comparing??? One (more, other) question: If ImgBurn is set to assure 32K padding, does this mean that if padding is applied, that the READ file will miscompare with the BURNED/ISO'ed file, or does Verify know to ignore this somehow? Thanks for bearing with me; it appears we are out of the realm of possible ImgBurn issues, but if I have a setup problem then maybe others here do as well...

Try to find out exactly what this is via the sector viewer, for example. If it really is an 0x18, then ImgBurn is reading it OK. If it's actually 0x98, then you might have a reading issue with the drive emerging (or a memory issue). Thanks for your reply; I'm having trouble understanding this though. Assuming the "Offset" value in the error log is in Decimal; when I look at the burned disc using any of my drives using Sector Viewer, at LBA 879596, offset x32C (812) I note that it is 18. But according to the log, the "Image File" (actually it's not from an image, I just burned the files off the hdd) suggests the original was 0x98, that what's on the disc is incorrect i.e. that ImgBurn burned it wrong??? Is there a way this specific location/value can be ID'ed in the original file on the hard disk, or even on the original DVD, from the LBA/Offset values? I suppose I can try to look for a pattern match in the VTS_01_2.VOB file... Or are you saying simply that since WinMerge said "file on DVD+R = file on hard disk drive" then the log is saying ImgBurn read a different value from the hdd due to some memory error (or hdd read error or even virtual memory/hdd glitch somewhere I suppose). I have been experiencing "verify" errors with all 3 of my drives (Pio 103 and 109, brand-new LG GCC-H20L) so I am indeed beginning to suspect a hardware problem, though Memtest+ certainly gives my RAM a clean bill of health. Maybe I have a glitch on a hard drive, but this seems like a long shot given the different hard drives I burn from...

Hi, I've seen a number of miscompares using Verify, and most of the time the burns are of video DVDs that are backups, so that on playback whatever errors might be on the disc don't show. But today again after burning one disc and getting one "miscompare", I checked all the files using the binary mode of WinMerge and it showed them all to be identical. Maybe no one else uses WinMerge in Binary mode as I do, or maybe there's an alternate/better file comparator someone might recommend, but I wonder why ImgBurn might throw an error yet the files appear identical? ; //****************************************\\; ImgBurn Version 2.4.1.0 - Log ; Saturday, 26 April 2008, 17:32:51 ; \\****************************************// ; ; I 17:19:44 ImgBurn Version 2.4.1.0 started! I 17:19:44 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 2) I 17:19:44 Total Physical Memory: 1,048,044 KB - Available: 705,912 KB I 17:19:45 Initialising SPTI... I 17:19:45 Searching for SCSI / ATAPI devices... I 17:19:45 Found 1 DVD-ROM, 1 DVD-RW, 1 DVD

Having trouble with "miscompares" using Verify mode, and wondering if there is any way to have an unattended operation. As it is, for each "miscompare" ImgBurn pops-up a dialog asking if I want to continue or abort. Is there any way to tell ImgBurn to just scan the whole disc and let me look at the errors afterward in the log?

Thanks guys, your replies are very helpful to me!

Both Sonic and Winamp (probably Pro) includes the Px engine. It does stick-around even after un-installing these, but I have been successful eradicating it by finding & deleting the px* entries in /windows/system32 and /drivers directories as well as registry entries. Don't know if it causes any problems but since I ditched Sonic and Winamp I see no need for it to hang around. I followed this procedure substituting of course the px* files for the gear files and it worked great.