dbminter

DVD-R is a WORM, Write Once Read Many, format. It's a one and done affair with writing in ImgBurn. DVD+R and DVD+/-R DL are the same. As LUK said, you need DVD-RW or DVD+RW for erasure.

It's an .IMG file, not a .BIN, but the exact size according to File Explorer is 769,118,112 bytes. ("Size on disk" is 769,118,208 bytes.)

However, there does seem to be some kind of bug here. If the file name is blank, is that preventing the Cancel function from working for some reason? Should there be a check for a blank file name before proceeding? Some kind of warning to the user?

Same behavior with the CUE file. And it doesn't matter from where I had the files stored. I tried it again in the new folder I had moved the files into. Same behavior with the CUE file. I noticed that in the CUE file, there's an entry for FILE NAME, but there is no such corresponding file name entry in the CCD file. Should there be? I've attached the CUE and CCD files if you want to take a look at them. Weird_Al.ccd Weird_Al.cue

If you'd like, I'll put these image files on my OneDrive so you can download them and experiment with them yourself.

I said it could not find the file specified before when I should have said path. My mistake! Sorry. The behavior is still the same. Cancel and the X close button just reload the dialog. Must CTRL+ALT+DEL kill ImgBurn.

Okay, was able to repeat it. Here's the dialog screenshot:

Well, I didn't capture a screenshot because the error was exactly as I stated it. A dialog box with that text in it, an X close button and Retry and Cancel buttons. I'll see if I can recreate it and snag a screenshot. By "see the name," do you mean the name of the file I was burning? I still have the files on hand, although they have been moved to a different folder since burning. I'll try moving them back before attempting another burn.

There was also this on attempting to do a manual Verify against the image file contents: I 11:12:39 Verifying Track 1 of 1... (MODE2/FORM1/2352, LBA: 235847 - 327005) W 11:12:42 Miscompare at LBA: 235863, Offset: 2072 W 11:12:42 Device: 0x91 W 11:12:42 Image File: 0x53 W 11:12:42 Total Errors in Sector: 119 W 11:12:42 Note: The drive probably corrected the EDC Area because it's wrong in the image file. I agreed to let it continue, and another group of sector errors occurred: I 11:12:42 Verifying Sectors... W 11:12:44 Miscompare at LBA: 235864, Offset: 2072 W 11:12:44 Device: 0xEC W 11:12:44 Image File: 0x2A W 11:12:44 Total Errors in Sector: 90 W 11:12:44 Note: The drive probably corrected the EDC Area because it's wrong in the image file. I 11:12:44 Verifying Sectors... After this, it completed. This was an image I had just now made with ImgBurn myself. So, it's not like the image is corrupt, probably. If the image file was made incorrectly, it was done at the time of reading. Whatever the EDC Area is and why it may have been wrong in the image file, I can't say. The data track appears fine. There were 2 files on the data track. I copied them from the CD-R I had just burned and COMPed them to the same files on the original disc. The COMP passed comparisons for both files. I haven't fully played it, but the MOV file on the CD-R does load and starts playing in Media Player Classic. However, as I said, I haven't fully played it to see if it works. I haven't tested the audio tracks yet either, but the miscompares appeared to have come in the data track session.

I was burning a CD that has 2 sessions on it, an audio track and a data track. After cycling the tray for Verify, ImgBurn said "Cannot open file: Reason: The system cannot find the file specified." Pressing Retry, Cancel, or X closing the window just causes it to infinitely reload the window. The only way to close it was to CTRL+ALT+DEL close ImgBurn. The files are there and have not been moved or changed since the burn started. The only difference is I changed the Joliet and ISO9660 Volume Labels in the image set before burning it to CD. Thanks!

Oh, also found this. Don't know if it's the same issue you addressed or not. If you have spaces in the UDF label field, when ImgBurn auto populates the same field data into ISO9660, the spaces are copied over, even though they're not allowed and should be changed to underscores. Is this the same issue you fixed?

Could be the LG drive in question. LG drives are usually not the best at reading things.

Yes, basically, if a disc is suffering from disc rot, it will simply fail to read to an image file. So, you'll know fairly quickly if it is when ImgBurn fails to read the disc fully.

I don't know if this is a bug or not. Begin by creating a job where the UDF Label is Test - Test. Then, add a VIDEO_TS folder to the job. ImgBurn automatically asks if you want to make a DVD Video and set the appropriate settings. If you do, the ISO9660 Volume Label is populated with TEST - TEST. However, the - is not an allowable character and must be changed to _. However, if you do NOT set the UDF Label to Test - Test BEFORE adding the VIDEO_TS and letting ImgBurn make the appropriate settings changes, if you put Test - Test in the UDF Label field AFTER adding the VIDEO_TS and letting ImgBurn make the changes and you press the Copy UDF volume label to other file systems button on the right side of the UDF Label field, the ISO9660 Label field is populated with TEST_TEST, which is the correct, allowable entry for ISO9660. So, is the automatic changes that ImgBurn is making to the IS9660 Label when importing VIDEO_TS with an existing UDF Label correct or is it overlooking the unallowable characters when it should be automatically converting them like the Copy UDF volume label to other file systems button does? Thanks!

Before I was told about the evils of CMC, I spent about $2,000 in discs, new burners, and new DVD video recorders trying to figure out why my discs that had worked fine for so long stopped working. The answer was Optodisc switched to CMC and I never used an Optodisc product again. And now, Optodisc is out of the optical disc business; good riddance! I've only burned a few M-Discs so I don't know from experience. Plus, my M-Disc are nowhere near as old as they need to be to prove any of the claims the manufacturer makes. However, the theory behind M-Discs versus organic dye is that M-Disc is basically akin to a process of chipping pits in stone versus burning ink. So, theoretically, M-Disc should be able to back up its claims. And as long as they make hardware that supports DVD+R reading, M-Disc will never go obsolete.

I've been burning optical discs since 2000, the early days of CD-R. I've never cared a jot about PIE, PIF, and jitter values. As long as they pass Verify/Read tests, that's good enough for me. And if they're DVD Video discs, a play of all contents on a standalone DVD player. The PIE/PIF/jitter values probably don't really come into play in terms of how long a disc will last before it's not readable. A disc will simply become unreadable based on the quality of its dye/metallic oxide. And it's an all or nothing situation, usually. Cheap media will become completely unreadable after like a year or so. Some media will have just a few sectors become unreadable, but if you're not using CMC discs, you generally don't have to worry about discs dying unless your burner doesn't like the dye on that particular disc. Which you'll generally know if it doesn't the minute Write or Verify fails for a particular brand.

M-Disc will, most likely, long outlive the user.

Yes, I believe every single burn has some amount of PIE/PIF/jitter. If it's low, it can generally be ignored. If it's high, then you start to worry.

What were the CD images of? Audio CD's or data discs like some kind of software installers or game discs? If they're Audio CD's or game discs, you probably won't have much luck copying their contents. You can't do it without special ripping software for Audio CD's. And some game CD's require the actual disc to run. And if they're some like Playstation or other console hardware discs, you'd need the images themselves as copying the contents won't necessarily copy all the contents. (Long story.) If they're just plain old data CD's, you can copy the contents to another location and put all the copied contents to an ISO in Build mode. If you have the space on a DVD, copy the CD ISO's to the image, too, as archive copies. If they're not just plain data CD's, you can do like LUK said and archive the ISO's. Then, you can use some kind of virtual drive software to load each CD ISO as a virtual drive for accessing. Even if they are plain old data CD's, you can still archive them to one disc and mount each CD as a virtual drive each time you want to access the files on the discs. You said the CD's are ISO's, which indicates they probably aren't Audio CD's or console game discs.

That's probably a drive or disc issue. Try another drive. Preferably, get a USB one you can easily hook up and disconnect afterwards. TSSTCorp drives have been known to be problematic sometimes. Or the drive may simply be at a point where it's getting old. If a different drive can't read the disc, the issue is most likely the disc has gone bad. The PS2 is almost 21 years old since initial release, so it wouldn't surprise me if a disc has become unreadable, particularly if it was well played.

I have noticed this is related to another issue I had posted about. I didn't know the 2 were apparently correlated, but one crash appears to cause the other. There was another issue I'd posted where in the Disc Layout Editor, dragging and dropping a folder would actually import an entirely different folder on the same drive. It seemed to be a random issue, but I managed to trigger it after one of these crashes where the characters get changed to either Chinese characters, a single bracket, or a lower case D. (Those last 2 were new additions I discovered could happen in addition to the random Chinese characters.) @LIGHTNING UK! If you want me to try out some kind bug enabled logging version of ImgBurn, I'm willing to give it a shot to try and isolate this issue. While I've not been able to determine what causes it, I've had it happened at least once a day every day for the past few days. So, it seems I can reliably expect it to happen at some point. You said this logging would probably be some kind of resource intensive operation, but I'm willing to try it if you are. Just let me know. Thanks!

I wasn't honestly sure that would help. It makes sense, though, because I had read somewhere USB 2.x was too slow for Blu-Ray burning. That's why I went with a USB 3.0 enclosure, just to be certain. And, it makes sense, somewhat. Semaphore timeout errors are a communication drop between the USB bridge and the motherboard on the PC. I suppose data could be coming in too slow for the device and dropping communication, resulting in errors. But, as long as it works, who cares why the problem went away, right?

I use the LG WH16NS60 in a Vantec USB 3.0 enclosure. The NS60 is an internal drive, but you can use it in a USB 3.0 enclosure. The drive itself is about $80 and the enclosure is about half that, so, yes, it's an investment. The NS40 is cheaper, but it does not properly write to BD-R/RE DL media. I've been using the NS60 for years with those Verbatim BD-R you're using with few failures that weren't the result of a dying drive. I use BD-R for a lot of data backups, no BD movies. Their large size is great for system images backups. I can backup my entire Windows partition to 2 BD-R.

At this point, if it still fails, I'd blame the used BD burner. You're using the quality Verbatim VERBAT-IM BD-R, so it's not a disc quality issue. You're burning single layer BD-R; multiple layer BD-R recording can be unreliable depending on what BD model you have. (For instance, the only BD-RE DL burner I've reliably used is the LG WH16NS60.) You've switched to a USB 3.0 port. So, at that point, I'd look into trying a different BD burner.