Jump to content

Ken852

Members
  • Posts

    97
  • Joined

  • Last visited

Posts posted by Ken852

  1. 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).

     

    extract-boot-image.png

  3. 12 hours ago, LIGHTNING UK! said:

    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 it does byte level comparison for data discs but not for audio discs?

    12 hours ago, LIGHTNING UK! said:

    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.

    Unless we disable this option?... I will do another set of tests later today and see what I get.

    12 hours ago, LIGHTNING UK! said:

    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.

    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! :lol: 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.)

    12 hours ago, LIGHTNING UK! said:

    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.

    Does that mean that songs will not play on "cue"? :D 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. :lol: 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"! :o 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.

    Quote

    Each CD drive reads audio discs slightly out (a number of samples), if your CD drive supports 'Accurate Stream' it will be a constant value, this value tends to be the same for each particular make and model of CD Drive.

    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.

    13 hours ago, LIGHTNING UK! said:

    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.

    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.

    13 hours ago, LIGHTNING UK! said:

    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.

    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. 10 hours ago, LIGHTNING UK! said:

    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.

    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.

    10 hours ago, LIGHTNING UK! said:

    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/

    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:

    Quote

    What is an read or write offset? When do they occur?

    During extraction or writing of the audio data, nearly all CD-ROM/CD-R drives will add an offset to the position. This is usually around 500-700 audio samples (ca. 1/75 second) on reading and around 0-18 samples on writing (ca. 1/1000 second). So if a program queries a specific sector, it will not receive exactly that sector, but shifted with the number of samples of the offset.

    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.

    Quote

    So, to create an exact (offset corrected) copy of your CD, you would have to compensate the write offset already on reading.

    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. I ran a disc scan on the "ARITA" disc using the Pioneer drive and got this shocking surprise.

    arita-cd-40x-pioneer.png.e3887b35f2c122e7d90e4969ffb5ce13.png

    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).

    amen-cd-40x-pioneer.png.defada421c93dd893e6bf3893c8df912.png

    amen-cd-40x-pioneer-2.png.a2792c3a6d85a0c65b58513d80db3735.png

    amen-cd-40x-pioneer-3.png.b004d403d9bb67f4db435a61b56de544.png

    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.

    amen-cd-16x-samsung.png.5ea5fb75e40c761b7d1a1ee283bd8a32.png

    amen-cd-16x-asus.png.ef508051e1454330029124ef14cbc279.png

    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. 2 minutes ago, dbminter said:

    There are far better tools for doing file comparisons than COMP.  But, I recommended COMP because it's free :) and comes with Windows.  It's a leftover from MS-DOS from like 30 years ago.

    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. :D

    It's quite fascinating to see how fast technology has changed over just two to three decades.

  7. The COMP command doesn't do it justice. If I launch Beyond Compare, this is what I see (all differences displayed).

    compare-pioneer-v3-v4.png.2a7b166210866bd1f531c7fd76769306.png

    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

     

  8. 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

    pioneer-v3-md5.png.a87f98e7208ecc49ca9ea5c77e2457e9.png

    pioneer-v4-md5.png.e232fc078b935f00029dc06764bcc0cb.png

    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?

     

  9. 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

    lg-v1-md5.png.434641bd01ad6a4e3950a1c6577b0365.png

    I'm using HashTab for calculating MD5.

     

  10. 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.

  11. 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.
     

  12. 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.

  13. 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?

     

  14. 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?

     

  15. 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...

     

  16. 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! :drinks:

     

  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. 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.

     

  19. 23 hours ago, ianymaty said:

    I think it reffers to as you can't burn to multiple drives like a duplicator does. 

    Only one session to one drive. Not one session to multi drives. 

     

    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.

     

  20. 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.

    dvd-decrypter-fail-set-data.png.041852023188db4ca5de1c43f6538a01.png

    dvd-decrypter-fail-set-data-2.png.78105dd00edaa509133d52a9f495f1f9.png

    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.

     

  21. 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.

    dvd-decrypter-general-tab.png.00397f6a94eb055b8c792a3e25e54cc6.png

    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.
     

  22. Testing is done and the results are in.

    Assuming that 7135BF384C5E666AAE6873EB3FF33D98 is the hash value for unchanged image (as made by ImgBurn), then the same can be had with Any DVD by disabling the removal of following features in Video DVD - Settings.

    • Software Region Code
    • Hardware Region Code
    • Region Code Scripts
    • Analog Protection System
    • Prohibited User Operations
    • PC-Friendly
    • Copy Protection based on unreadable Sectors

    any-dvd-video-settings.png.4c14495d6a39a7dc41449c54728642c1.png

    All of these are enabled by default in Any DVD, which results in BF6B0935CBC9D13FA8C6523A34F8B123 value when imaging the disc using either one of the two programs, Any DVD or DVD Decrypter. In other words, Any DVD interferes with operation of DVD Decrypter. Same results can be had with DVD Decrypter. It changes what is in fact a "Region 2" disc and makes DVD Decrypter detect it as a "Region 1, 2, 3, 4, 5, 6, 7, 8" (any region) disc. See screenshots of DVD Decrypter below for comparison.

    dvd-decrypter-region-2.png.214c6475c9dcffe67629a04504d9729d.png

    dvd-decrypter-region-1-8.png.3a30ff621365441ce269054125b31d61.png

    In the screenshots above, you are looking at the images made by ImgBurn as they appear in DVD Decrypter when attached to a virtual drive (Virtual CloneDrive), with Any DVD inactive (first screenshot) vs. Any DVD active in the background (second screenshot). I have used a virtual drive to speed up the reading and testing process.

    So one way to get around this and to get the same results with DVD Decrypter is to simply inactivate or exit out of Any DVD when using DVD Decrypter. In addition, to get the same hash value as with Any DVD, you have to disable the option "Remove IFO RC Protection" in DVD Decrypter.

    dvd-decrypter-ifo-rc-protection.png.871ba2840ed4dd6c6ccb54cfb9765da9.png

    This has made me wonder, what does " Remove IFO RC Protection" do?

    It's not enough to just inactivate Any DVD. You only do that to make DVD Decrypter detect the disc properly as a Region 2 disc which it is. But you also have to disable this "Remove IFO RC Protection" option, or in other words you have to NOT remove IFO RC Protection. That way you will get 7135BF384C5E666AAE6873EB3FF33D98  value, same as with ImgBurn.

    Any DVD is somehow able to simulate as if the inserted disc is an all region disc. It appears to be triggered by the Software Region Code option. DVD Decrypter doesn't seem to have any such option.

    To get BF6B0935CBC9D13FA8C6523A34F8B123 (touched)
    Using Any DVD:
    Default settings (simulates Region 1, 2, 3, 4, 5, 6, 7, 8)

    Using DVD Decrypter:
    Default settings (Remove IFO RC Protection: ON)
    Any DVD active (simulates Region 1, 2, 3, 4, 5, 6, 7, 8)

    To get 7135BF384C5E666AAE6873EB3FF33D98 (untouched)
    Using Any DVD:
    Remove DVD Video features: none selected

    Using DVD Decrypter:
    Remove IFO RC Protection: OFF
    Any DVD inactive (Region 2) OR active but no DVD Video feature removed

    (Failure to turn Remove IFO RC Protection OFF results in hash 03BAB370EB2D46CE327E0D7C092D756B, as opposed to BF6B0935CBC9D13FA8C6523A34F8B123.)
     

×
×
  • Create New...

Important Information

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