Jump to content

Ken852

Members
  • Content Count

    97
  • Joined

  • Last visited

About Ken852

  • Rank
    ISF Member

Profile Information

  • Location
    Europe

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ken852

    Bootable Disc - Incorrect function

    Solved! I used this guide to get around the boot image file requirement: https://www.intowindows.com/how-to-create-bootable-windows-iso-from-filesfolders/ Little did I know there was a nearly identical guide on the ImgBurn forum itself: https://forum.imgburn.com/index.php?/topic/11194-how-to-create-a-windows-vista-7-8-installation-disc-bootable-using-imgburn/ I just needed to supply the "etfsboot.com" file which was already on my USB drive. So I copied all files and folders from the USB drive to a new folder on the desktop (C drive) before adding that folder to ImgBurn as source, and then specifying the boot image file from within that folder. I wanted to make a backup copy of the Windows 10 build that's already on my USB drive (it's the May 2020 update and still supported) before I format the drive, and I also wanted to see if it's possible to make it bootable (just for learning how it's done). I have not this sort of thing in years. Most guides I found on the web explain how to use existing Windows ISO files to create bootable CD/DVD/USB. I wonder why the extraction function is not working? Is that for Windows XP only?
  2. I'm trying to make a copy of my Windows 10 USB installation drive using ImgBurn by making a bootable ISO file which I plan on writing to a new USB drive. There are options for making images bootable but for some reason it requires that I provide the boot image, and although there are options for extracting one from my current system this fails for some reason. I get this error: DeviceIoControl(IOCTL_DISK_GET_PARTITION_INFO) Failed! Reason: Incorrect function. Followed by: Operation Failed! I'm not too sure why this is. Correct me if I'm doing this wrong, but the way I do it is I open ImgBurn in Build mode and then add the drive letter of the Windows 10 USB to Source and a file location on Desktop as my Destination. Then I go to Advanced tab, Bootable Disc and click on the blue floppy disk icon with my Windows C drive selected in the list (to extract image from).
  3. Ken852

    ID CRC or ECC Error

    So it does byte level comparison for data discs but not for audio discs? Unless we disable this option?... I will do another set of tests later today and see what I get. I see... and such a test can be done in ImgBurn even without a disc image to compare to? I see the option "Verify Against Image File" can be disabled. I mean what does it do if I disable vs. enable this option? In both cases it's doing a check to see if it can read the sectors (on disc itself vs. disc and disc image)? I think I understand what you mean. This is why I am running the resulting image files through an MD5 hash function. The drive may not be able to tell me when something is wrong. But surely I can see that myself by comparing MD5 values? I mean if 2 different drives (Samsung and ASUS) are producing image files with the MD5 value of 5156E70FFD665CEE3E5224CE8935B6F9 and the image file coming from a third drive gives me AD984790F32ECA9770029C2A101D21DE then I think it's safe to assume that the third drive is in error. The more drives that produce images with the same MD5 the more it's safe to say that any drive that deviates from this is not doing its job properly. In regards to error correction, I found an old thread where someone was using EAC to extract audio tracks from disc image files made with ImgBurn. Is it true that C2 error codes have no relevance in the context of ImgBurn? Of course, ImgBurn is not a CD ripper like EAC, but that discussion brings up some interesting questions and it touches on the topic of "offset" issues (that's how I found it). But if I understand this issue correctly, Daemon Tools is to blame for offset problems, not ImgBurn. Not that I'm looking for ways to blame ImgBurn! I'm just a curious amateur when it comes to these things. From my perspective, it's Daemon Tools that does the reading of the virtual disc, not ImgBurn. So Daemon Tools is to blame if it doesn't know how to detect and use C2 error codes. (But I think he was making the argument that Daemon Tools fails to do so because ImgBurn has no option to do offset correction when the images are made.) Does that mean that songs will not play on "cue"? Or maybe it will just skip a few seconds of a given track at beginning or end? Forgive me for opening this Pandora's box. I have a vague memory of reading discussions about the whole "offset" problem. I think this was a hot debate in late 1990s when I purchased my first CD burner (some Sony model). I may have even used EAC back then. My memory of this is probably "vague" because I have suppressed it, not because my memory is bad. Digital trauma! I came across this long list of drives and their offset values: http://www.accuraterip.com/driveoffsets.htm Surprisingly I found my brand new Pioneer on that list (BDR-212M, this is the device name given by Windows). It's said to have an offset of "+667"! That's a bit more than 20. But I also seem to recall values of 6 to maybe 14. Maybe this is because this is a more modern drive with Blu Ray disc support. They talk about number of samples. Perhaps these offset values are indicating number of samples rather than bytes? It doesn't say clearly what they measure it in. Yeah, I think there was a Lite-On drive and some discs that were used as reference by the guy/team behind the EAC and AccurateRip. This may as well explain why Lite-On drives were highly prised by enthusiasts. I have actually purchased a second Pioneer unit, same model. It should be interesting to compare these two. I will try changing cables and SATA ports as well. I can't seem to change the reading speed? I can set it to 16x in ImgBurn but the log still says "Read Speed - Effective: 40x" Here are the specs for my Pioneer drive: https://pioneer-blurayodd.eu/products/bdr-212ebk/index.php Maximum reading speed is said to be 40x for CD-R. That's as high as it will go. But it won't go lower than that?
  4. Ken852

    ID CRC or ECC Error

    So if ImgBurn says "Operation Successfully Completed" when verifying a physical disc against a disc image, what is it saying? If I understood correctly, it is saying "I found all the sectors on the physical disc that you have in this disc image file". It's not verifying their binary contents, it's simply verifying that they are present? Essentially it's counting sectors? If it can read all the sectors then they are all present. Does that mean then that it requires at least one whole sector to be missing (unable to read at all) before ImgBurn says something is wrong? Again, if I understood this correctly. I have no experience working with the Verify mode in ImgBurn. Can I make it verify at byte level? I can see the option "Ignore CD-DA Data". I'm not sure what it does, but it doesn't sound like the right option. I will note that it makes no matter what drive the disc image comes from. I can make the image with the LG drive and then compare it against the physical disc using the Pioneer drive. Or I can make the image with the Pioneer drive and then compare it against the physical disc using the same drive (or the LG drive or whichever drive that will read the disc). The verification will pass. (And I think I understand now why.) Also, it doesn't have to be this particular problem disc, I can take a good disc and get the same results. I don't quite understand this. I understand what you said about what goes in is not what comes back out. But this doesn't make much sense. It sounds like a design flaw. What is the purpose of such thing? It doesn't sound reliable or predictable. When I think of data storage in general, if I save a picture of my aunt on a USB flash drive for example, I don't expect the picture of my dog to come back out when I open the file on the big screen for the whole family to see ("and this is my aunt!"). I understand that CD-DA is technically not data (or so I've been told many times). But similarly, if I have a music disc by ABBA for example, I don't expect The Beatles to play on track 3 all of a sudden (but it would be a nice surprise). From the EAC page: What kind of offset are we talking about? Offset of what to the position of what? They fail to answer the question because they don't see the forest for all the trees I'm afraid. Does ImgBurn have any of this read/write/combo offset mambo jumbo? Do I have to use EAC in combination with ImgBurn to get these details right? This all seems very complicated. But what I got from all of this is that my Samsung and ASUS drives create disc images that are as they say "offset corrected". Am I right? Because it's only with these two drives that I can insert a good disc (audio CD or otherwise) and repeatedly and consistently get exactly the same ISO or BIN or IMG files that are exactly the same down to every byte (you will recall matching MD5). I'm using ImgBurn of course. By contrast, with the Pioneer drive I get inconsistent reads and mismatching binary files, even with known good discs. This must be due to this offset mambo jumbo?
  5. Ken852

    ID CRC or ECC Error

    I ran a disc scan on the "ARITA" disc using the Pioneer drive and got this shocking surprise. This doesn't look good at all. As a reference I used a pressed audio CD (Astral Projection - Amen) that has not been used much and here is what that looks like on the same drive (3 runs). For some reason I can't set the read speed to anything but 40x on this drive. I will blame the sudden C2 peaks on that. When I insert the same disc in the Samsung or Asus drive the C2 sits firmly at zero (at 16x). I have read that a perfectly pressed disc (master) has a C2 value of 1 in worst case. Pick any one of these images and compare to the first one and the difference should become immediately obvious. What a horrible disc! I should consider myself lucky if I can get anything off of this. But how is this disc failing I wonder? I have no prior experience with disc rot, but this disc doesn't look anything like on the pictures where people are discussing disc rot or laser rot. There is no obvious discoloration at the bottom side. It sure has some surface scratches and blemishes, but it doesn't look like anything major, at least not to my untrained eyes. The label side is solid white, with transparent segments for brand name, and writing lines for Date and Title and overall visual style (I can post a picture later). There are like a million tiny little bubbles on the white stuff, but I'm pretty sure this is normal and a result of creating the surface during production. It looks like a sandy and rough paint.
  6. Ken852

    ID CRC or ECC Error

    And what doesn't fit we write on paper? Now we are playing with Terrabytes!
  7. Ken852

    ID CRC or ECC Error

    Haha!
  8. Ken852

    ID CRC or ECC Error

    Yeah, I understand that. Thank you for suggesting it! In all these years I never knew Windows had something like this built in, and I have used MS-DOS quite a lot. I think COMP may be better suited for textual data or relatively small binary files. Back in the olden days, an entire hard disk drive would take up 582 MB. It's quite fascinating to see how fast technology has changed over just two to three decades.
  9. Ken852

    ID CRC or ECC Error

    The COMP command doesn't do it justice. If I launch Beyond Compare, this is what I see (all differences displayed). I have actually never used the COMP command before. I suspect it's only capable of doing one sided comparison. So I would probably have to reverse the order of arguments in the command line to see how the other file compares to the first file, or vice verse. It may also be limited to only displaying the first 10 differences. You can see from the screenshot here that there are many more differences. Make note of the offset address 05A18120 on the right hand side of the image in the status bar. This is the current position of the cursor which you can see at the top next to a string of hex value starting with 67 and ending with DC. This is what the COMP command displayed for us. Now you can appreciate how many more differences there are between the two files. Both of these files were made by the Pioneer drive and they both verify as OK against the disc using ImgBurn. Why is that? Update: Indeed, the COMP command doesn't seem to be able to handle more than 10 differences. It just flips file1 and file2 in the output if I change the order of arguments, it doesn't help discover more differences. C:\Users\Me\Desktop\CD>comp "Ver 4 Pioneer - Copy\Image.bin" "Ver 3 Pioneer - Copy\Image.bin" /M Comparing Ver 4 Pioneer - Copy\Image.bin and Ver 3 Pioneer - Copy\Image.bin... Compare error at OFFSET 5A18120 file1 = 67 file2 = 23 Compare error at OFFSET 5A18121 file1 = DA file2 = CB Compare error at OFFSET 5A18122 file1 = E6 file2 = 22 Compare error at OFFSET 5A18123 file1 = C5 file2 = BE Compare error at OFFSET 5A18124 file1 = 96 file2 = AA Compare error at OFFSET 5A18125 file1 = E1 file2 = CA Compare error at OFFSET 5A18126 file1 = ED file2 = 5C Compare error at OFFSET 5A18127 file1 = C2 file2 = C0 Compare error at OFFSET 5A18128 file1 = 2D file2 = 82 Compare error at OFFSET 5A18129 file1 = DC file2 = A9 10 mismatches - ending compare
  10. Ken852

    ID CRC or ECC Error

    Using COMP command to compare the Pioneer images I get a few errors. C:\Users\Me\Desktop\CD>comp "Ver 3 Pioneer - Copy\Image.bin" "Ver 4 Pioneer - Copy\Image.bin" /M Comparing Ver 3 Pioneer - Copy\Image.bin and Ver 4 Pioneer - Copy\Image.bin... Compare error at OFFSET 5A18120 file1 = 23 file2 = 67 Compare error at OFFSET 5A18121 file1 = CB file2 = DA Compare error at OFFSET 5A18122 file1 = 22 file2 = E6 Compare error at OFFSET 5A18123 file1 = BE file2 = C5 Compare error at OFFSET 5A18124 file1 = AA file2 = 96 Compare error at OFFSET 5A18125 file1 = CA file2 = E1 Compare error at OFFSET 5A18126 file1 = 5C file2 = ED Compare error at OFFSET 5A18127 file1 = C0 file2 = C2 Compare error at OFFSET 5A18128 file1 = 82 file2 = 2D Compare error at OFFSET 5A18129 file1 = A9 file2 = DC 10 mismatches - ending compare They are both same size: 582 MB (610,489,824 bytes) But different MD5. Version 3 is: 9DB3F79BEBE64DFB2CC11C21587D425A Version 4 is: 1A3F7DE456B476CD8DC7AD281FD86DF2 How can both of these verify OK in ImgBurn? What's interesting about this is that all the errors are at adjacent offset addresses, from 5A18120 to 5A18129. What sector or sectors is that then?
  11. Ken852

    ID CRC or ECC Error

    Using COMP command to compare the LG images I get "OK". C:\Users\Me\Desktop\CD\Ver 1 LG - Copy>comp Image.bin "..\Ver 2 LG - Copy\Image.bin" /M Comparing Image.bin and ..\Ver 2 LG - Copy\Image.bin... Files compare OK They are both the same size: 582 MB (610,489,824 bytes) And same MD5: B77A12DC681B95D37B5088D6E8E365CF I'm using HashTab for calculating MD5.
  12. Ken852

    ID CRC or ECC Error

    Now I have verified the disc against the LG made images and they too verify OK. I must be misunderstanding something? Surely for the same input MD5 must produce the same output? The LG drive produces images that are binary identical, each time. The Pioneer drive does not. But the images made with either one of them still verify OK against the physical disc using the Pioneer drive (I have not done verification using the LG drive yet). I will do some more testing with different discs and drives and see what I get.
  13. Ken852

    ID CRC or ECC Error

    The Pioneer verifies the disc as OK against its own images using the Verify operation in ImgBurn. This I did not expect, given that they all show a different MD5 value. So I made 2 more images using the Pioneer drive with the following MD5 values. 9DB3F79BEBE64DFB2CC11C21587D425A 1A3F7DE456B476CD8DC7AD281FD86DF2 These 2 verify OK as well against the physical disc. What kind of magic is this I wonder? So the Pioneer drive verifies OK against all 6 images. 37BED8010252848C3A88869199FC5090 6F49D87F71740C5D2E322A849FB149B6 290D56075425D96F59A1FC72369FAD86 BF46730C0CAC6D93CC451F21C71EC9CD 9DB3F79BEBE64DFB2CC11C21587D425A 1A3F7DE456B476CD8DC7AD281FD86DF2 Why do I get different MD5 for each of the images if they all verify OK against the physical disc? I will verify the disc against the LG made images next.
  14. Ken852

    ID CRC or ECC Error

    I have invested in 2 new optical drives, one DVD drive and one BD drive, the Asus DRW-24D5MT and Pioneer BDR-212EBK respectively. The Asus drive is no better or worse than the Samsung drive. I have yet to see the Asus drive get past track 3. The Samsung drive has returned to getting stuck at track 3. Occasionally it gets past that and then gets stuck at track 9. I have only been able to read and image the disc with the LG and the new Pioneer drive, but I have only had consistent reads with the LG drive. I mean the MD5 checksum is different for every time I read the disc with the Pioneer like you see below. 37BED8010252848C3A88869199FC5090 6F49D87F71740C5D2E322A849FB149B6 290D56075425D96F59A1FC72369FAD86 BF46730C0CAC6D93CC451F21C71EC9CD With the LG drive I get the same checksum. I have only made two images with it. B77A12DC681B95D37B5088D6E8E365CF B77A12DC681B95D37B5088D6E8E365CF I have not done anything drastic yet to try to retrieve the data (throwing money at it not included). I'm curious what would cause the Pioneer drive to give me different checksums each time? I have only ever seen that kind of behavior with one pressed CD-ROM music disc that gives a lot of C2 errors (with the Samsung drive). I would say that it's allowing itself to do a lot of guesswork. Because ideally, the checksum should be the same, right? No matter what drive you use to read it.
  15. Ken852

    ID CRC or ECC Error

    I have a CD with some music and I'm having issues reading the data off of it. If I insert it in my Samsung drive, it gets stuck at "Analysing Track 3". It has 16 tracks in total. It stays like that for good 5 minutes or more before my patients runs out and I cancel the operation. If I insert it in my LG drive which has already rescued me in similar situations before, analysis gets past track 3. It finishes analysing all 16 tracks. It even reads the disc, all the way to track 12 where it starts to complain about issues reading certain sectors. You can see the latest log below. W 22:38:17 Destination File renamed to: Image.img I 22:38:17 Operation Started! I 22:38:17 Source Device: [0:0:0] HL-DT-ST BD-RE GGW-H20L YL05 (F:) (SATA) I 22:38:17 Source Media Type: CD-R (Disc ID: 97m31s01f, Ritek Co.) I 22:38:17 Source Media Supported Read Speeds: 10x, 16x, 24x, 32x, 40x I 22:38:17 Source Media Supported Write Speeds: 4x, 8x I 22:38:17 Source Media Sectors: 259,562 I 22:38:17 Source Media Size: 610,489,824 bytes I 22:38:17 Source Media File System(s): None I 22:38:17 Read Speed (Data/Audio): MAX / MAX I 22:38:17 Hardware Read Error Retries: 2 I 22:38:17 Destination File: C:\Users\Me\Desktop\Optical Discs\Image.img I 22:38:17 Destination Free Space: 112,973,783,040 Bytes (110,325,960.00 KiB) (107,740.20 MiB) (105.22 GiB) I 22:38:18 Destination File System: NTFS I 22:38:18 File Splitting: Auto I 22:39:08 Read Speed - Effective: 40x I 22:39:08 Reading Session 1 of 1... (16 Tracks, LBA: 0 - 259561) I 22:39:08 Reading Track 1 of 16... (AUDIO/2352, LBA: 0 - 16532) I 22:39:58 Reading Track 2 of 16... (AUDIO/2352, LBA: 16533 - 34483) I 22:40:47 Reading Track 3 of 16... (AUDIO/2352, LBA: 34484 - 51977) I 22:41:30 Reading Track 4 of 16... (AUDIO/2352, LBA: 51978 - 64576) I 22:42:00 Reading Track 5 of 16... (AUDIO/2352, LBA: 64577 - 80476) I 22:42:36 Reading Track 6 of 16... (AUDIO/2352, LBA: 80477 - 95336) I 22:43:07 Reading Track 7 of 16... (AUDIO/2352, LBA: 95337 - 114406) I 22:43:46 Reading Track 8 of 16... (AUDIO/2352, LBA: 114407 - 129979) I 22:44:16 Reading Track 9 of 16... (AUDIO/2352, LBA: 129980 - 149359) I 22:44:53 Reading Track 10 of 16... (AUDIO/2352, LBA: 149360 - 166821) I 22:45:24 Reading Track 11 of 16... (AUDIO/2352, LBA: 166822 - 178414) I 22:45:44 Reading Track 12 of 16... (AUDIO/2352, LBA: 178415 - 197024) W 22:45:50 Failed to Read Sectors 178415 - 178441 - Reason: ID CRC or ECC Error W 22:45:56 Failed to Read Sector 178415 - Reason: ID CRC or ECC Error W 22:45:57 Retrying (1 of 20)... W 22:46:03 Retry Failed - Reason: ID CRC or ECC Error W 22:46:03 Retrying (2 of 20)... W 22:46:09 Retry Failed - Reason: ID CRC or ECC Error W 22:46:09 Retrying (3 of 20)... W 22:46:15 Retry Failed - Reason: ID CRC or ECC Error W 22:46:16 Retrying (4 of 20)... W 22:46:22 Retry Failed - Reason: ID CRC or ECC Error W 22:46:22 Retrying (5 of 20)... W 22:46:28 Retry Failed - Reason: ID CRC or ECC Error W 22:46:28 Retrying (6 of 20)... W 22:46:34 Retry Failed - Reason: ID CRC or ECC Error W 22:46:35 Retrying (7 of 20)... W 22:46:41 Retry Failed - Reason: ID CRC or ECC Error W 22:46:41 Retrying (8 of 20)... W 22:46:47 Retry Failed - Reason: ID CRC or ECC Error W 22:46:47 Retrying (9 of 20)... W 22:46:53 Retry Failed - Reason: ID CRC or ECC Error W 22:46:54 Retrying (10 of 20)... W 22:47:00 Retry Failed - Reason: ID CRC or ECC Error W 22:47:00 Retrying (11 of 20)... W 22:47:06 Retry Failed - Reason: ID CRC or ECC Error W 22:47:06 Retrying (12 of 20)... W 22:47:13 Retry Failed - Reason: ID CRC or ECC Error W 22:47:13 Retrying (13 of 20)... W 22:47:19 Retry Failed - Reason: ID CRC or ECC Error W 22:47:19 Retrying (14 of 20)... W 22:47:25 Retry Failed - Reason: ID CRC or ECC Error W 22:47:26 Retrying (15 of 20)... W 22:47:32 Retry Failed - Reason: ID CRC or ECC Error W 22:47:32 Retrying (16 of 20)... W 22:47:38 Retry Failed - Reason: ID CRC or ECC Error W 22:47:38 Retrying (17 of 20)... W 22:47:45 Retry Failed - Reason: ID CRC or ECC Error W 22:47:45 Retrying (18 of 20)... W 22:47:51 Retry Failed - Reason: ID CRC or ECC Error W 22:47:51 Retrying (19 of 20)... W 22:47:57 Retry Failed - Reason: ID CRC or ECC Error W 22:47:57 Retrying (20 of 20)... W 22:48:04 Retry Failed - Reason: ID CRC or ECC Error W 22:48:39 Failed to Read Sector 178415 - Reason: ID CRC or ECC Error I 22:49:11 Reading Track 13 of 16... (AUDIO/2352, LBA: 197025 - 211341) I 22:49:35 Reading Track 14 of 16... (AUDIO/2352, LBA: 211342 - 227184) I 22:50:00 Reading Track 15 of 16... (AUDIO/2352, LBA: 227185 - 244024) I 22:50:26 Reading Track 16 of 16... (AUDIO/2352, LBA: 244025 - 259561) I 22:50:50 Operation Successfully Completed! - Duration: 00:12:31 I 22:50:50 Average Read Rate: 793 KiB/s (4.0x) - Maximum Read Rate: 1,570 KiB/s (7.9x) I tried to wipe the disc with a cloth, it didn't help. I then tried to spray it with window cleaner and wipe it clean. That now helps my Samsung drive get past analysis of track 3 but then it gets stuck analysing track 9. I have reapeted this several times, Samsung now always gets stuck on track 9 for whatever reason. The LG drive however reads it just as it did before, with all the same results and sector issues on track 12. Any other tips on what I could do to maybe try to "fix" this CD? I'm assuming the problem is the disc itself, and not the drive. It does have some scuffs but there are no major scratches or cracks in that I can see. This is a very dare disc to me. I received it by mail from an old friend of mine many years ago. I like to think it's been kept in good storage condition. It's always been stored in one of those plastic translucent CD sleeves, inside the envelope it came in, and locked away in a file cabinet. It's a CD-R with the brand name "ARITA". I had never heard of this brand before when I got the CD and I have never heard of it since. I take it these are not very good? I 22:45:44 Reading Track 12 of 16... (AUDIO/2352, LBA: 178415 - 197024) W 22:45:50 Failed to Read Sectors 178415 - 178441 - Reason: ID CRC or ECC Error W 22:45:56 Failed to Read Sector 178415 - Reason: ID CRC or ECC Error I wonder if this means that only sector 178415 is at fault or if the entire range of sectors are at fault?
×

Important Information

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