dbminter

The reason ImgBurn recognizes the disc as VERBAT-IMf-000 is because Verbatim actually made those discs for Mediarange. Which is actually kind of surprising that they're not using cheap CMC Magnetics for them instead of the good stuff that Verbatim makes. IF those are true Verbatims, of course. The Disc ID can always be faked.

I was actually going to test my Mega Man X 4 disc, too, but chose Strider 2 from Capcom instead.

If ImgBurn had made discs with this drive before, then there's a configuration error somewhere. The ID string of the drive seems to be a generic one, so Windows doesn't seem to think it's an available writer. Have you tried using Windows' built in writing to write a disc and see if it works? Use a rewritable one if you have one available to save using a disc. If Windows won't right to it, then Windows thinks the drive is not a writer but a reader. Now, there's always the chance the drive could have gone bad and needs replacing. However, generally, Windows shouldn't rethink itself if that happens to a drive and call it what it isn't. Windows would just generally keep the old settings even if the drive stopped working correctly. As LUK said, check Device Manager to check the drive's status.

You're welcome. Glad I could help.

Have you tried the nuclear option? Get an entire new PC from a manufacturer you've never used before, get an entirely different drive, and try that? Actually, you may not have to go that far. Have you tried an entirely different burner? Not just putting the burner in an enclosure and testing it. I'm forgetting. I think you said you had tried the drive in an enclosure before and that worked? Or did it also fail on the enclosure. If it works on an enclosure but not internally, it's some kind of problem with the SATA connection. Either on the drive, the cable, which I think you said you tried replacing, the motherboard, or something being installed by ImgBurn or Windows Update that is causing the problem. And, you said everything appears to work fine until you install ImgBurn. So, have you tried a fresh install of Windows 10 with the modem disconnected so Windows Updates can't be installed and then try installing ImgBurn?

Try 4dots Free Audio Converter. I believe that has worked for me before in the past; I currently have it installed, anyway. I also have Hamster Audio Converter installed, but I don't know if I've ever used it for fixing this case. Both utilities are freeware.

Yeah, I hate to say it, but, sometimes, there are no answers, no matter how much you test or how logical your approach. My recent instance was when I got this current PC, it had Windows 8.1 Update 1 installed on it. Out of the box, it wasn't ripping audio CD's to image files correctly. Within the last 3 tracks or towards the end if it's one massive track, there would be missing audio. If I ripped the tracks in Windows Media Player, they'd be fine. It didn't matter what software I used to read to image files, it would do that. I tried restoring to the factory default image I took with nothing else installed, I tried resetting Windows after that, I tried both SATA and USB connected readers, always the same result. No rhyme or reason why it should be doing that. When I updated to Windows 10, the problem apparently went away! Makes no logical sense, but it happened.

Until we see the log, about the only thing I can say is maybe it isn't burner but a read only (ROM) drive. If it is a read only drive, it will find a DVD-ROM but no writers because there are none. The log will list the ID string of the drive, which will tell us what the drive is.

Probably because you built a Data CD and not an Audio CD. Unless you used the Create CUE function, you didn't create an Audio CD but a Data CD. Data CD doesn't care how long the MP3's file are as long as the file sizes don't exceed the side of a CD. And 12 MP3's at 50 minutes each probably don't exceed 750 MB, the amount of data on a CD. As you said, the resulting creation was about 550 MB, which would fit on a CD. You said you used the "build" function, which would create a Data CD. As you say, if you built an Audio CD, there would be no way to put all 12 50 minute tracks on one Audio CD. In fact, you could only fit 1 track per CD if you created an Audio CD.

Well, there's no error message to go by, so, there's really little we can do. I have Mega Man 8 and it still plays in my PS3 so I tested it by attempting to read it in ImgBurn in my Pioneer 2209 BD drive. It failed to read, but I was getting returned error messages. L-EC Uncorrectable errors, so it could be that my disc is not good anymore and is only readable enough to boot on my PS3 but not play all the way through. However, given the fact that you can't read Mega Man 8 either, it seems to more likely be a case that, for whatever reason, ImgBurn can't read Mega Man 8. Which would indicate that some PS1 games can be read by ImgBurn and some can't, since you got some discs read to image files and some not. I ran another test on another Capcom game from a few years after Mega Man 8, Strider 2. ImgBurn read both discs to image files. This backs up my idea that some PS1 games can be read in by ImgBurn for whatever reason and some can't. Also backed up by the results you achieved, where some discs would read and some wouldn't. Why you got no error returns is something down to your drive most likely. And it seems to be dependent on the drive, too. I tried reading the disc in my LG WH16 BD drive and it never completed analyzing Track 2 from Session 1. Even after 10 minutes, where I gave up because if it won't do it after 10 minutes, it won't do it at all. The Pioneer drive seems to be failing at reading Track 2 on Mega Man 8, if I had to hazard a guess. It does seem that certain games can't be copied with certain combinations of hardware and software. I tried reading an image in Roxio NXT 4 on Mega Man 8 and it crapped out at the same place ImgBurn tried to read it at. Now, these "bad sectors" may be Playstation's copy protection method. That it looks for purposefully bad sectors as a way to check for legitimate physical discs. However, I thought these bad sectors existed beyond the end of the disc to look for. Plus, it doesn't explain why Strider 2 worked and Mega Man 8 doesn't, except that Strider 2 is newer. However, I'm more up to thinking it's down to the individual games in question and the hardware and software you use to read it. For instance, ImgBurn and Roxio failed on Mega Man 8, but UltraISO DID read it to a BIN/CUE file. Although, where it crapped out in ImgBurn and Roxio, UltraISO "paused" at the same place, thinking about it. But, it did eventually get an image file read. How accurate/playable that image is, though, I don't know. So, if you have UltraISO, try that. If you don't, UltraISO isn't freeware.

Oh, 7Zip will do that? I didn't know that. I've been using UltraISO for that purpose. Can 7Zip do what UltraISO does and inject files into an existing ISO? Can 7Zip open split images with a .DVD file?

What I do in cases like this is I use some kind of conversion software and convert each of the WAV files to new individual WAV's, without any changes to the source input. Generally, this fixes any sort of input problems I have with creating CUE sheets with ImgBurn.

For CD, a sector is 2352 bytes? What an odd value! It's divisible by 2 but is not a multiple of 2.

I was just going suggest, test the .EXE you downloaded of ImgBurn. If you're willing to test it/have an image you can restore from to test with, try uninstalling ImgBurn on the image of Windows that works and reinstalling ImgBurn. If it fails again, then it could be a corrupt ImgBurn .EXE installer when it was downloaded, if you're using the same executable in all tests. While it seems unlikely to be the case, it could be the case. And, at this point, the only common denominator is installing ImgBurn. If it's already pre-installed, it seems to work. If you install it, it doesn't. However, this doesn't explain why the enclosure works. Unless the installer just happens to be corrupt to the point where it works but doesn't work right and only just happens to fail on SATA. Again, highly unlikely, but what else can you test at this point? And what else have you got to lose at this point, too?

Have you tried using ImgBurn's Create CUE sheet function and imported the source files to see if the CUE file can be created by ImgBurn? I've noticed some CUE editor applications don't make CUE sheets that work with ImgBurn for burning. I forget what it was, but I tried a CUE sheet creation software and ImgBurn wouldn't burn the resulting CUE it created.

Are you using the same SATA cable with this drive in each of the 3 PC's you've tried? If you put this burner in an enclosure and it works and you tried 3 different PC's, if you used the same SATA cable, one would think it's either the SATA cable or the burner itself that is the problem. It can't be the SATA controller on the mobo because it keeps happening across different PC's. So, it has to be something that is common across all 3 PC's and being carried over/replicated on each machine. That would be either the cable or the drive itself. However, this doesn't explain why the drive works on your one system image where Windows 10 was installed before and the drive was working okay. And you've restored this system where Windows 10 was working with this drive and tested it again to make sure it's still working on that system image?

Sometimes, you just never know. While my experience has been, generally, I need to replace optical drives every 7 to 9 months, my Pioneer BD's have done surprisingly well. Just had to replace my 3rd one because it wasn't properly "writing" to formatted BD-RE media. Windows Explorer would say the contents were deleted, but when the disc was ejected and reinserted, the contents were still there. So, I swapped in my first Pioneer which still worked, save for the eject button issue I've encountered on Pioneer BD's. That solved the problem. That 3rd Pioneer I'd been using for like 2 or 3 years before it gave up the ghost. The 1st one still works after 4 years, although it's only been "used" for maybe a year or two. Anyway, glad you resolved the problem. It may be you got faster writes on the same model of the drive because the older drive was going out. So, while it may have been "working" for writes, it may not have been doing them "right," resulting in slower writes.

Now this one was unexpected and inexplicable. Macrium Reflect verifies on this one burn verified in the Windows version of the application, but failed in the WinPE boot version of the application! I test both because I remember Drive Image would do the same thing: Windows application version would verify but booting the disc into DOS and running the application, the verify might fail. I don't remember which drive burned this BD-RE DL. I was burning BD-RE DL from different images in both my Pioneer and LG at the same time, one in ImgBurn and one in Roxio. And I didn't note on the Post It on this particular BD-RE DL which drive wrote it. So, I'm reburning it in the Pioneer since I "know" the Pioneers write Verbatim BD-RE DL properly, where as LG's are nothing but problems writing to them. As I should have said to myself, stick with Pioneers, you fool! Of course, this Pioneer I'm currently using is like 4 years old, sitting the last year or 2 on a shelf. It was still working, save for the eject button issue, after a year and half. When my 3rd Pioneer stopped writing to BD-RE correctly, I swapped it back in while I wait to get a new Pioneer to replace it with. It may not be as good as I think.

Makes sense. I should have thought of that.

Are read speeds for rewritable media slower than for WORM media? I ask because, though I never noticed this on DVD rewritable media, with BD-RE SL and DL, reads/verifies appear to be slower when reading in rewritable BD versus BD-R SL that I've begun to notice. As I said, it doesn't seem to be this way with DVD rewritable media, but maybe I just never noticed it before. Would rewritable media be slower at reading? I know, obviously, it will be slower at writing, but I'd think the read speed should be the same regardless of whether the media is rewritable or not. But, maybe, I'm wrong? Or is it, maybe, it's just slower on BD-RE SL/DL for reads versus reading from BD-R SL? I am taking into account the layer differences because this seemed to be the case even on BD-RE SL. That reading contents from a BD-RE SL in ImgBurn was slower than reading in a BD-R SL. Thanks!

The first disc was apparently bad as the Macrium Reflect verifies failed. I just know that if I continued with these "capped" writes, the data would be corrupt on the 2nd disc that did that, too.

I know very little about X/TL and QL BD media. I've never burned one before, either, but I was wondering something about Verifying an image burned to one of these kinds of discs. With DL DVD+R and BD-RE, which I have burned, Verifying Layer 1 causes the read speed to gradually count down to lower values from the height of the read speed of Layer 0. This is because the reading goes in the opposite direction on Layer 1 when Verify puts the laser to the end of Layer 0. But, what happens when Layer 2 or Layer 3 are read? Does it gradually increase again on Layer 2 to a maximum read speed? And, on Layer 3, does it gradually reverse backwards like when changing from Layer 0 to Layer 1? Thanks!

Yeah, LG's are just at writing Verbatim BD DL media. I did the Roxio test again in a real world application environment. This time, Roxio wrote at less than 1x the entire time and the Macrium Reflect verified on a file on the disc on the first layer. Which meant the drive did not write the disc correctly. Just use Pioneers. That will usually just solve the problem. Actually, may have been the Verbatim BD-RE DL that went bad. I put it in my Pioneer and it, too, was capped at 0.9x write speed. I put in my newest BD-RE DL Verbatim of the same kind and it wrote at 2x in the Pioneer. I put that 2nd BD-RE DL in the LG and tried Roxio again, which wrote to 2x this time. So, I'll see if Macrium Reflect verifies fail this time. It was apparently the 1st Verbatim BD-RE DL that had gone bad. The 2nd one burned fine with Roxio in the LG and verifies passed in Macrium Reflect. Which makes sense. All the tests I ran before said this should have worked. Only a rogue disc wouldn't work, which was the case. HA! Life tried to fool me again! But, I'm too smart for it! A SECOND Verbatim BD-RE DL wrote at 1x in the LG with Roxio. So, I tested it with the Pioneer and STILL 1x. So, I put in a FOURTH Verbatim BD-RE DL in the Pioneer and it writes at 2x! Thus, it will write at 2x in the LG, it would seem. Which it did! So, I still stand by my final statement: just use Pioneers. That will usually just solve the problem.

I was also going to blame the Riteks. Try Verbatims.

Probably because isn't DVD-A really just a series of super long menus? I don't think there needs to a layer break pause on menus. Now, if this DL were large enough that it might take up most of the space of a DL disc, ImgBurn would probably prompt you for a layer break pause. Some menu would span the two layers. As it probably stands now, the amount of contents can probably be easily split across two different layers without bridging one to the other. ImgBurn probably made its own decision about spanning the material. Sort of like if you have a VIDEO_TS that fits on one layer and you add some files to the root directory of the disc that makes the project a DL. ImgBurn is smart enough to keep the VIDEO_TS on one layer, since it fits entirely on one layer, and shutter the other files to the 2nd layer, or span those between the Layer 0 and Layer 1 because those files wouldn't be affected during playback because they don't play in a DVD-Video job.