Jump to content

Ken852

Members
  • Content Count

    97
  • Joined

  • Last visited

Everything posted by Ken852

  1. 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).
  2. 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?
  3. 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?
  4. 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?
  5. 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?
  6. 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.
  7. Ken852

    ID CRC or ECC Error

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

    ID CRC or ECC Error

    Haha!
  9. 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.
  10. 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
  11. 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?
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. As I recently started working with DVD Decrypter for my DVD video discs I discovered that it uses capital letters for file name extensions, like in the example below. The New World.ISO The New World.MDS I was wondering if I may change this afterwards without breaking the file name reference? I don't know about other programs, but ImgBurn seems to accept it regardless. I like my extensions all in lower case, so ".iso" rather than ".ISO" and so on. Looking at the MDS file in a hex editor I can see a reference to the original ISO file at the end: The New World.ISO I have manually edited this to say: The New World.iso Do I have to repeat this for all such files? Will these files otherwise fail to load in other programs that use MDS files? Looking at the files I created previously using ImgBurn, I can see that asterisk is used in place of the file name prefix ("The New World") and the suffix or file name extension ("iso") is in lower case. For example, here are my files from the first disc of Ask Video tutorial series on Cubase SX. Ask Video Cubase SX3 Level 1 Tutorial.iso Ask Video Cubase SX3 Level 1 Tutorial.mds The MDS file contains: *.iso Rather than: Ask Video Cubase SX3 Level 1 Tutorial.iso I take it this part is not important then?
  17. I just recently noticed the option "Enable SPTI access in Remote Sessions" as I was installing ImgBurn in a VM. I also noticed that it's not enabled by default during installation. This may explain a problem I was running into previously as I was trying to access my PC using Remote Desktop from another PC. I was trying to do this because my main PC does not have any optical drive. But ImgBurn logged some error or warning, I don't remember now. Do I have to reinstall ImgBurn to enable this? Will I lose my current settings?
  18. Ken852

    Enable remote SPTI access

    Reinstalling ImgBurn worked like a charm, and I did not lose any of my settings as far as I can tell. Thank you!
  19. Ken852

    Enable remote SPTI access

    This seems to be related to admin rights? Running without admin rights: I 10:39:16 ImgBurn Version 2.5.8.0 started! I 10:39:16 Microsoft Windows 8 Professional x64 Edition (6.2, Build 9200) I 10:39:16 Total Physical Memory: 16,688,180 KiB - Available: 13,333,732 KiB I 10:39:16 Initialising SPTI... I 10:39:16 Searching for SCSI / ATAPI devices... E 10:39:18 CreateFile Failed! - Device: '\\?\scsi#cdrom&ven_elby&prod_clonedrive#1&2afd7d61&0&000000#{53f56308-b6bf-11d0-94f2-00a0c91efb8b}' (D:) E 10:39:18 Reason: Access is denied. E 10:39:20 CreateFile Failed! - Device: '\\?\scsi#cdrom&ven_tsstcorp&prod_cddvdw_sh-224db#5&df55e28&0&040000#{53f56308-b6bf-11d0-94f2-00a0c91efb8b}' (E:) E 10:39:20 Reason: Access is denied. W 10:39:20 Errors were encountered when trying to access 2 drives. W 10:39:20 These drives will not be visible in the program. E 10:39:20 You need Administrative privileges to use SPTI. Running with admin rights: I 10:40:26 ImgBurn Version 2.5.8.0 started! I 10:40:26 Microsoft Windows 8 Professional x64 Edition (6.2, Build 9200) I 10:40:26 Total Physical Memory: 16,688,180 KiB - Available: 13,320,744 KiB I 10:40:26 Initialising SPTI... I 10:40:26 Searching for SCSI / ATAPI devices... I 10:40:26 -> Drive 1 - Info: ELBY CLONEDRIVE 1.4 (D:) (SCSI) I 10:40:26 -> Drive 2 - Info: TSSTcorp CDDVDW SH-224DB SB00 (E:) (SATA) I 10:40:26 Found 1 DVD±RW/RAM and 1 BD-ROM/HD DVD-ROM! I will try reinstalling ImgBurn...
  20. Hello, I understand if it's taboo to discuss DVD Decrypter on this forum, and I apologize if it's strictly forbidden to even mention it. But my question is really about ImgBurn rather. I recently hit a road block as I was imaging my collection of optical media for archival purposes. At one point, when I inserted a DVD video disc, ImgBurn revealed that the disc had copyright protection on it. I tried to ignore this warning and continue anyway, but ImgBurn did not work correctly and was unable to read the disc at all. So I turned my attention to alternative software, including DVD Decrypter and Any DVD. I have found one DVD video disc ("The Others" thriller film from 2001) that does not appear to have any copyright protection on it (DVD Shrink also calls it "Not Encrypted"). So ImgBurn is able to read and image this disc without giving me a hard time. However, when I use other software to image the same disc, I get mismatching ISO files. ImgBurn Size: 7.54 GB (8,096,284,672 bytes) MD5: 7135BF384C5E666AAE6873EB3FF33D98 DVD Decrypter Size: 7.54 GB (8,096,284,672 bytes) MD5: BF6B0935CBC9D13FA8C6523A34F8B123 Any DVD Size: 7.54 GB (8,096,284,672 bytes) MD5: BF6B0935CBC9D13FA8C6523A34F8B123 The resulting files do match by size, but not by hash value. I'm curious as to why that is? What's interesting or odd is that the hashes do match between DVD Decrypter and Any DVD, but the two don't match against what I'm getting out of ImgBurn. So is ImgBurn somehow reading the contents wrong? I did not get any errors or warnings in the log, not for this video disc. All three output files can be mounted and played back on my PC.
  21. Thanks for clarifying LUK. Another option would be to disable a few options. On the Registry tab in DVD Decrypter settings, you can remove the following checkboxes. Under "Shell Extensions": "AutoPlay (XP / Server 2003)" "DVD (Me / 2000 / XP Server 2003)" Under "File Associations": CDR, DVD, IMG, ISO, MDS All of these are enabled by default, and disabling all of them will prevent DVD Decrypter from attempting to write to the Windows Registry. This is a tip that @dbminter shared with me in a PM and it worked wonders. Thanks to both of you!
  22. Ken852

    Two instances of ImgBurn running?

    Maybe that's where the authors of Wikipedia got their idea from? The limitation they are describing? But then the duplicator would have to run some kind of Windows? It's needless to say, but being able to instantiate ImgBurn makes it very powerful and flexible. And of course, you are not going to be burning more than one disc at a time per drive. Also, you will probably not want to do things that could affect the overall performance like burning a disc from an ISO file while at the same time reading that same ISO file in a second instance of ImgBurn and burning it to a second drive.
  23. Ken852

    Two instances of ImgBurn running?

    A duplicator? Is that one of those tall tower machines that cost $$$$ and have several trays for discs, with little monochrome LCD displays at the top? That word "session" is confusing me. Is that the same as to say "instance"? In all fairness, I don't think you can compare one of those expensive duplicator machines to ImgBurn. Because ImgBurn runs on a much more powerful platform where you can install almost any number of drives, and with the ability to instantiate ImgBurn, that's like having 1 to 1 duplicators times 10 (that's 10 small duplicators, with each cloning only 1 disc to 1 drive at a time). You can build this at a fraction of the cost for a massive duplicator machine.
  24. I haven't used DVD Decrypter much, almost not at all. I never had a need for it, not until now. I wouldn't know how to check to see whether a disc has Macrovision protection on it or not. Also, each time I exit out of DVD Decrypter it prints out the following error messages. After I click to close the program it displays the first message 1 time, followed by the second message 1 time, followed by first message 6 times. I don't know what it's blabbing about, but none of this seems to affect the quality of the ISO files it produces. It's just annoying. I suspect the number of times it displays the first message has to do with the number of drives in the system (I have a few mounted network drives here). Also, the same messages will appear if I run DVD Decrypter in a VM with Windows 7, but not in a VM with Windows XP. So any Windows version above Windows XP will produce these errors on exit, but it does not seem to affect the image quality, as they are identical to those made with ImgBurn (given the right amount of tweaking the settings). I must say, it's quite impressive to see such an old program still doing quite well on a modern operating system.
  25. I thought so too. But the disc I'm using for testing ("The Others" original from 2001) does not appear to have any sort of copyright protection. ImgBurn for example does not complain about "CSS/CPPM" when I insert the disc, like it does with the other discs when I insert those. The only kind of restriction it does have is Region 2 restriction, as far as I can tell. There is the option "Remove Macrovision Protection" under the General tab in DVD Decrypter. It's ON by default, and turning that OFF has no effect on the ISO file I get. Presumably because there is no Macrovision to remove. As long as DVD Decrypter detects the region code of the disc correctly (Region 2), settings can be left on default with exception for "Remove IFO RC Protection" which needs to be OFF, the ISO file will be identical to that made in ImgBurn. And to detect the region code correctly, Any DVD needs to be either uninstalled, inactivated or at very least its "Software Region Code" option needs to be set to OFF.
×

Important Information

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