Jump to content

LIGHTNING UK!

Admin
  • Posts

    30,457
  • Joined

  • Last visited

Everything posted by LIGHTNING UK!

  1. That means the drive initially failed to read the block of sectors, but then managed to read them all when the program switched to reading them one at a time.
  2. What were the 2 files you burnt to the disc?
  3. Test mode isn't going to tell you anything useful anyway. The only way to see if a drive can burn the discs is to actually try burning the discs.
  4. There’s no need for more ‘debug’ info. The drive reported a write error and that’s pretty much all there is to it. You could try enabling the ‘perform opc before write’ option, that may help your drive do its job. As I said though, all you’ve shown us is the log from test mode on a cdrw. Where’s the log from you attempting to burn the actual discs you want to be burning (before the multiple failures prompted you to use cdrw) ?
  5. I couldn’t rename the entire mode just for when the box to compare against an image file gets unchecked Given the choice, you should always verify a disc against the source that created it. When that isn’t possible, I guess a basic read test is better than nothing.
  6. I don't really class that as verifying, but yes, it would work purely as a read test.
  7. Your drive reported a 'write error'. It didn't like something about the disc... which is weird because you've told it to use 'Test Mode' and the drive isn't actually meant to be burning the disc. I can't comment on any failures prior to that one (where you weren't using that CD-RW), as you didn't include log info for those.
  8. No, it won’t work if you didn’t burn from an image file. Do the eject / load button seen under the box where you select your device not work for the pioneer? Maybe the belt is slipping or something. It just sounds like you want to try and get that working correctly again.
  9. I don't actually know. That crash is from something to do with destroying the components on the main 'form' (window), but that's all handled outside of my own code and I've never had it happen to me when in the actual development environment - whereby I might then be able to look into it a bit more. Your issue could be causing that crash. Maybe sometimes the issue doesn't cause the weird characters, but still causes the crash on close. It all depends on how much memory is being overwritten. I expect the only way to catch the issue this topic deals with is to enable additional debugging stuff that checks for anything accessing bits of memory it shouldn't be accessing. Enabling it adds a lot of overhead though, so it would need to be a test build just for you to attempt to recreate the issue again.
  10. The stack dump in that crash report shows a (familiar) crash from when you closed the app down. It didn't capture anything about what happened when the program was open and that weird stuff happened.
  11. As you pointed it at a hdd (your c: drive), it would have saved a copy of your entire hdd - so you’re probably lucky it didn’t work. As for why it failed, no idea. Maybe Microsoft have replaced that ioctl with something else now.
  12. Yeah, you're doing it wrong. There are guides for building OS install discs. If you aren't doing anything non standard with your current USB, why not just download a fresh/up-to-date image from Microsoft and use that?
  13. Make a dummy file and add it to your compilation.
  14. That would probably be a chipset / firmware thing. If the drive seems to be reading slowly, it could be because of it having difficulty reading, so it’s automatically slowed itself down. They can also slow themselves down if they determine it’s a video disc of some sort - so the drive is quiet and it doesn’t interfere with you watching a movie or whatever.
  15. 2.5.8.0 knew how to detect usb 3.0 (as it was at time of release), but Microsoft then changed their minds on how they wanted to do things and now there’s another way to detect it. That’s what 2.5.8.0 can’t utilise. It’s purely cosmetic though and your drive / enclosure will work at whatever speed they’ve negotiated at with the chipset.
  16. Different disc formats use different descriptors for the info.
  17. They're the same thing (in my eyes). One disc format may favour naming the fields in the descriptor for that format as disc id and another may prefer manufacturer id.
  18. Verify mode would normally do a byte comparison of the sectors on the disc Vs the sectors in the file. That's just turned off by default for CD-DA sectors. So for CD-DA sectors, it's basically just a test to see if the drive can read the sector on the disc - which is in itself not guaranteed to be accurate and that's why you can re-read the same disc in one of your drives and get a different image each time, but without the drive ever actually telling you there's any sort of problem. Again, that's due to the lack of error correction available in CD-DA sectors. The 'Ignore CD-DA Data' option is exactly the option you'd be turning off if you want the program to perform byte level comparison of CD-DA sectors. I won't pretend to know why the whole read/write offset thing exists for CD-DA sectors, it just does. Different chipsets within drives use different offsets. The offsets are in bytes... normally something around 10 - 20. So that's 10 - 20 bytes within a single sector... which is only 1/75th of a seconds itself, so a few bytes is nothing. The offset basically shifts everything (the entire track) a bit. All the data is still there (I think), it's just a few bytes earlier/later. For audio, that doesn't really matter. Obviously it's a complete deal breaker for data tracks and they do not suffer from this 'offset' stuff. Like I said.... minefield. No, ImgBurn doesn't have any special handling of offsets. If it tells the drive to write some data to a sector, it expects to be able to ask it to read that same sector back and get exactly what it wrote. I vaguely recall favouring my LiteOn drives for CD-DA stuff because they were one drive where I could use them to read an audio cd, burnt it in the same drive and then read it back again to a new image and it would match perfectly. The offsets a drive uses doesn't change, so if your pioneer constantly gives you a different image when reading anything with CD-DA tracks, that's just down to it being a bad reader. If you aren't already doing so, maybe limit the speed when reading audio tracks - it could help. I think the default used to be 8x.
  19. Sorry, when I suggested to use Verify mode and compare the image made by one drive to the disc in another drive, I'd totally forgotten about the program defaulting to not verifiying CD-DA at byte level. That's why verify passed - it was essentially just testing the optical drive could read all sectors on the disc. CD-DA causes a real headache when it comes to verifying because drives have a read and write offset for it. The data I tell the drive to write to a sector won't always be what it returns when I read it back (unless the drive's write/read offsets cancel each other out) If you want to explore that minefield, take a look here - https://www.exactaudiocopy.de/en/index.php/support/faq/offset-questions/
  20. Audio sectors don't have the same error correction capabilities that data sectors do - because it's using all 2352 bytes for CD-DA. Therefore, it doesn't really know that it hasn't read it correctly. Your findings, where the LG performs the best, matches with what I remember from many years ago. For problem discs, I always had (still have, actually) a collection of LG drives to fall back on. It might be interesting to verify the disc in the pioneer against the LG image to see which sectors are different. The MD5 or whatever being different doesn't really tell you much. As 1 sector is 1/75th of a second's worth of audio, you're very unlikely to notice if just a few bytes or sectors have changed.
  21. You shouldn't be having problems if you're using good discs. If the drive can't burn at 8x on MCC / MKM dye media, you should probably replace the drive. What you're asking for would indeed require modified firmware. I don't suppose anyone modifies firmware these days, but you could ask over at the MyCE forums. https://club.myce.com/ If you can't find any mention of your drive anywhere, you'd probably need to provide the firmware binary by reading from your drive (with the correct tools).
  22. It doesn't need to be in multiple bin files... and that isn't how ImgBurn would have ripped it, you'd have still ended up with a single BIN / CUE file combo. Your disc is just unreadable, that's all.
  23. The program asks the drive to return data for a range of sectors. If it returns an error, it then asks for 1 at a time. That then narrows down the problem sector. You can have it ignore the bad ones by clicking continue or whatever, where it’ll then move on to the next one and the bad one is zero filled. Once you have your image with as much of the data as you can get,, you can start looking at more aggressive disc cleaning techniques. I think it was Skip Dr. that made a disc resurfacing tool. Such tools were popular with the rental companies.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.