Ken852 Posted April 15, 2021 Posted April 15, 2021 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?
dbminter Posted April 15, 2021 Posted April 15, 2021 Probably the fault of the Ritek disc you used. They're known to be problematic for some drives. I'm surprised you had better luck with an LG because my experience has been LG DVD drives won't read in discs other drives do. What I'd do at this point is put this disc in a CD player and try to play Track 12 all the way through. If the CD player won't play the track, then the disc is probably unreadable at that point and there's nothing you can do.
LIGHTNING UK! Posted April 16, 2021 Posted April 16, 2021 The program asks the drive to return data for a range of sectors. If it returns an error, it then asks for 1 at a time. That then narrows down the problem sector. You can have it ignore the bad ones by clicking continue or whatever, where it’ll then move on to the next one and the bad one is zero filled. Once you have your image with as much of the data as you can get,, you can start looking at more aggressive disc cleaning techniques. I think it was Skip Dr. that made a disc resurfacing tool. Such tools were popular with the rental companies.
Ken852 Posted April 27, 2021 Author Posted April 27, 2021 (edited) 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. Edited April 27, 2021 by Ken852
LIGHTNING UK! Posted April 27, 2021 Posted April 27, 2021 Audio sectors don't have the same error correction capabilities that data sectors do - because it's using all 2352 bytes for CD-DA. Therefore, it doesn't really know that it hasn't read it correctly. Your findings, where the LG performs the best, matches with what I remember from many years ago. For problem discs, I always had (still have, actually) a collection of LG drives to fall back on. It might be interesting to verify the disc in the pioneer against the LG image to see which sectors are different. The MD5 or whatever being different doesn't really tell you much. As 1 sector is 1/75th of a second's worth of audio, you're very unlikely to notice if just a few bytes or sectors have changed.
Ken852 Posted April 28, 2021 Author Posted April 28, 2021 (edited) 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. Edited April 28, 2021 by Ken852
dbminter Posted April 28, 2021 Posted April 28, 2021 If you're really curious, you could always open a Command Prompt and use the COMP command to compare one ISO against the other to see if the contents are exactly the same. Or, to save some time, since that will take a bit to run that COMP, you could use Properties in File Explorer for each ISO and check their file sizes against each other.
Ken852 Posted April 28, 2021 Author Posted April 28, 2021 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.
Ken852 Posted April 28, 2021 Author Posted April 28, 2021 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.
dbminter Posted April 28, 2021 Posted April 28, 2021 I know pretty much nothing about MD5's, so I can't say. I don't think I've ever used a single hash file before in my life. I have ImgBurn set to generate them, but I've never used them before.
Ken852 Posted April 28, 2021 Author Posted April 28, 2021 (edited) 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? Edited April 28, 2021 by Ken852
Ken852 Posted April 28, 2021 Author Posted April 28, 2021 (edited) 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 Edited April 28, 2021 by Ken852
dbminter Posted April 28, 2021 Posted April 28, 2021 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.
Ken852 Posted April 28, 2021 Author Posted April 28, 2021 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. It's quite fascinating to see how fast technology has changed over just two to three decades.
dbminter Posted April 28, 2021 Posted April 28, 2021 582 MB! HA! The HD in my first x86 PC in 1992 was a whopping 40 MB!
Ken852 Posted April 28, 2021 Author Posted April 28, 2021 17 minutes ago, dbminter said: 582 MB! HA! The HD in my first x86 PC in 1992 was a whopping 40 MB! Haha!
Ken852 Posted April 28, 2021 Author Posted April 28, 2021 And what doesn't fit we write on paper? Now we are playing with Terrabytes!
dbminter Posted April 28, 2021 Posted April 28, 2021 I can remember when it was a light year leap to have 100 MB "floppies" when the Zip drive came out. I had one in 1996 and it seemed like such a vast amount of removable storage. And it was 25 years ago.
Ken852 Posted April 28, 2021 Author Posted April 28, 2021 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.
dbminter Posted April 28, 2021 Posted April 28, 2021 I've no personal experience with Arita recordable discs, but my memory of past posts on the board is that they were cheap quality media. It probably has nothing to do with rot as it probably started going bad long before disc rot would have been factored in. Cheaper media just gets parts where it can't be read anymore over time. Sometimes, the entire disc is not recognized by a drive. I began a project to convert all my non MCC and TY discs, which are the quality stuff, to TY discs. I came across two MXL GR03 DVD's recorded in like 2003. One was fully readable, but one had data on it that couldn't be read, yet the rest could. I've learned a few things. For instance, Ritek DVD-R have lasted almost 19 years. Lead Data DVD-R as well, but VIVASTAR and those MXL GR03 had read issues after roughly the same amount of time.
LIGHTNING UK! Posted April 29, 2021 Posted April 29, 2021 Sorry, when I suggested to use Verify mode and compare the image made by one drive to the disc in another drive, I'd totally forgotten about the program defaulting to not verifiying CD-DA at byte level. That's why verify passed - it was essentially just testing the optical drive could read all sectors on the disc. CD-DA causes a real headache when it comes to verifying because drives have a read and write offset for it. The data I tell the drive to write to a sector won't always be what it returns when I read it back (unless the drive's write/read offsets cancel each other out) If you want to explore that minefield, take a look here - https://www.exactaudiocopy.de/en/index.php/support/faq/offset-questions/
Ken852 Posted April 29, 2021 Author Posted April 29, 2021 (edited) 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? Edited April 29, 2021 by Ken852
LIGHTNING UK! Posted April 29, 2021 Posted April 29, 2021 Verify mode would normally do a byte comparison of the sectors on the disc Vs the sectors in the file. That's just turned off by default for CD-DA sectors. So for CD-DA sectors, it's basically just a test to see if the drive can read the sector on the disc - which is in itself not guaranteed to be accurate and that's why you can re-read the same disc in one of your drives and get a different image each time, but without the drive ever actually telling you there's any sort of problem. Again, that's due to the lack of error correction available in CD-DA sectors. The 'Ignore CD-DA Data' option is exactly the option you'd be turning off if you want the program to perform byte level comparison of CD-DA sectors. I won't pretend to know why the whole read/write offset thing exists for CD-DA sectors, it just does. Different chipsets within drives use different offsets. The offsets are in bytes... normally something around 10 - 20. So that's 10 - 20 bytes within a single sector... which is only 1/75th of a seconds itself, so a few bytes is nothing. The offset basically shifts everything (the entire track) a bit. All the data is still there (I think), it's just a few bytes earlier/later. For audio, that doesn't really matter. Obviously it's a complete deal breaker for data tracks and they do not suffer from this 'offset' stuff. Like I said.... minefield. No, ImgBurn doesn't have any special handling of offsets. If it tells the drive to write some data to a sector, it expects to be able to ask it to read that same sector back and get exactly what it wrote. I vaguely recall favouring my LiteOn drives for CD-DA stuff because they were one drive where I could use them to read an audio cd, burnt it in the same drive and then read it back again to a new image and it would match perfectly. The offsets a drive uses doesn't change, so if your pioneer constantly gives you a different image when reading anything with CD-DA tracks, that's just down to it being a bad reader. If you aren't already doing so, maybe limit the speed when reading audio tracks - it could help. I think the default used to be 8x.
Ken852 Posted April 30, 2021 Author Posted April 30, 2021 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! 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"? 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. 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?
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now