sorn Posted April 6, 2021 Posted April 6, 2021 Hello. Im trying to preserve a prototype game disc that looks really clean, only a few light scratches, no pinholes. But im getting the following errors upon analysing tracks, specifically track 4. E 10:00:14 SENSE: 70 00 03 00 00 00 00 0A 00 00 00 00 11 05 00 00 00 00 E 10:00:14 SENSE SK Interpretation: Medium Error E 10:00:14 SENSE ASC/ASCQ Interpretation: L-EC Uncorrectable Error I 10:00:14 [0:0:0] HL-DT-ST BD-RE WH16NS40 1.05 (D:) (SATA) I was wondering if there was anyway that I could get past this or substitute the data from a donor? Or any other software that might deal with error correction and ignore these medium errors? I would really at this point like to be able to ignore the read error and see what outcome there is. Thanks to everyones help and advice.
dbminter Posted April 6, 2021 Posted April 6, 2021 You might have better luck with a drive other than your LG one for reading. LG drives have a long history of failing reading discs that other drives have no problem with. The WH16NS series has been better than most LG drives, but there are the occasional ones it fails on. Try finding a USB drive (Easier to install and try/test with.) from someone other than LG and see if you have better luck.
sorn Posted April 6, 2021 Author Posted April 6, 2021 Thank you, i've tried on a TSSTcorp and it does appear to handle it better. Still many errors but it appears to be pushing through them instead of getting stuck on that specific sector and looping. Do you know if there are firmware upgrades for the WH16NS that would allow it to read medium better? Or is it a issue with the optical lens itself?
dbminter Posted April 6, 2021 Posted April 6, 2021 As for the firmware update, you can check for yourself. In Write mode, right click on the drive letter and choose the last option in the context menu for checking for upgrades. Or check the LG web site for updates. However, there's no need in your case as 1.05 is the latest firmware released in the public by LG. Sometimes, LG releases firmware updates they only apply at the factory, like the 1.02 for the WH16NS60. They released patch updates for 1.01 and 1.03, but only applied 1.02 in the factory. It's not a lens issue as this particular problem has persisted across LG DVD drives in the past, too. Well, I guess it could be a lens issue, though. There are 2 different lasers in a BD burner: one for CD and DVD and the other for BD. However, I'd THINK there's only one lens, though. This problem has persisted for years, so, I suppose, despite my initial statement, now that I think about it, it could be a lens issue.
sorn Posted April 7, 2021 Author Posted April 7, 2021 (edited) 23 hours ago, dbminter said: As for the firmware update, you can check for yourself. In Write mode, right click on the drive letter and choose the last option in the context menu for checking for upgrades. Or check the LG web site for updates. However, there's no need in your case as 1.05 is the latest firmware released in the public by LG. Sometimes, LG releases firmware updates they only apply at the factory, like the 1.02 for the WH16NS60. They released patch updates for 1.01 and 1.03, but only applied 1.02 in the factory. It's not a lens issue as this particular problem has persisted across LG DVD drives in the past, too. Well, I guess it could be a lens issue, though. There are 2 different lasers in a BD burner: one for CD and DVD and the other for BD. However, I'd THINK there's only one lens, though. This problem has persisted for years, so, I suppose, despite my initial statement, now that I think about it, it could be a lens issue. I had meant 3rd party firmware to improve the read but thank you for the extended reply. 24 hours later its still stuck on track 4 on the TSSTcorp Im getting lots of ASC/ASCQ Interpretation: Logical Block Address out of Range errors. Anyway to fix that? Edited April 7, 2021 by sorn
LIGHTNING UK! Posted April 7, 2021 Posted April 7, 2021 That doesn’t sound right. Lba out of range means it’s beyond the end of the disc. Can you provide a log showing that stuff at all please?
sorn Posted April 7, 2021 Author Posted April 7, 2021 6 minutes ago, LIGHTNING UK! said: That doesn’t sound right. Lba out of range means it’s beyond the end of the disc. Can you provide a log showing that stuff at all please? Sure thank you! http://paste.ee/p/HHahB
LIGHTNING UK! Posted April 7, 2021 Posted April 7, 2021 Thank you. Can you now go into Read mode and copy + paste all of the info from the box on the right when that disc is in the drive please.
sorn Posted April 7, 2021 Author Posted April 7, 2021 1 hour ago, LIGHTNING UK! said: Thank you. Can you now go into Read mode and copy + paste all of the info from the box on the right when that disc is in the drive please. http://paste.ee/p/aoMIR
LIGHTNING UK! Posted April 7, 2021 Posted April 7, 2021 Sorry to be a pain... can I get 1 more log please?! Load the program and go into Read mode. Press the F6 key to enable Program Debug Mode (you'll notice a log entry) and then start the read again. *do not enable I/O debug mode (F8)* You don't need to leave it repeating the same thing over and over when it gets to track 4, just long enough to capture whatever it's looping on. I'll need the complete log of that session please. Don't crop it as I want to follow the program logic right from the start. Thank you!
sorn Posted April 8, 2021 Author Posted April 8, 2021 6 hours ago, LIGHTNING UK! said: Sorry to be a pain... can I get 1 more log please?! Load the program and go into Read mode. Press the F6 key to enable Program Debug Mode (you'll notice a log entry) and then start the read again. *do not enable I/O debug mode (F8)* You don't need to leave it repeating the same thing over and over when it gets to track 4, just long enough to capture whatever it's looping on. I'll need the complete log of that session please. Don't crop it as I want to follow the program logic right from the start. Thank you! Pain? Your the best dude ever. Never thought I would get the author to debug my issues haha Im super appreciative! https://paste.ee/p/eSSsn
LIGHTNING UK! Posted April 8, 2021 Posted April 8, 2021 This is a bit of an impossible problem to fix (nicely). Your drive is returning some bogus info as the program tries to detect the real start of the track (what would be knowns as Index 0 / the pregap). D 18:52:11 Sub-Channel - LBA: 146991 (32:41:66), Raw Data: 01 16 02 04 4E B2 00 64 82 CC 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146991 (32:41:66), Got: 294132 (65:23:57) D 18:52:11 Sub-Channel - LBA: 146991 (32:41:66), Raw Data: 01 06 02 04 4E B2 00 64 82 CC 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146991 (32:41:66), Got: 294132 (65:23:57) D 18:52:11 Sub-Channel - Bogus response data! D 18:52:11 Sub-Channel - LBA: 146992 (32:41:67), Raw Data: 82 02 02 C0 01 74 00 32 41 67 54 0C 00 00 00 80 D 18:52:11 Sub-Channel - Wrong Type! D 18:52:11 Sub-Channel - LBA: 146993 (32:41:68), Raw Data: 01 04 00 00 01 73 00 32 41 68 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146993 (32:41:68), Got: 146993 (32:41:68) D 18:52:11 Sub-Channel - LBA: 146993 (32:41:68), Raw Data: 01 04 00 00 01 73 00 32 41 68 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146993 (32:41:68), Got: 146993 (32:41:68) D 18:52:11 Sub-Channel - LBA: 146993 (32:41:68), Raw Data: 01 04 00 00 01 73 00 32 41 68 00 00 00 00 00 00 Your drive is returning invalid subchannel info for sectors 146991 and 146992 and that info is causing the program to loop as it attempts to find the real start of track 4 by applying an offset based on what the drive is reporting. For example, the '16' in the top line's 'Raw Data' is supposed to be the track number. Well... there aren't even 16 tracks on the disc! It also then magically changes it to 6 and yet everything else is the same. (6 is still wrong) That bit of code that is responsible for 'Analysing Tracks' is actually quite a complicated due to the fact that some drives have to be told to return info on sector X to get info on sector Y. It isn't just a case of trying sector Y and if you don't get the info, moving on. You have to work out what it's given you after your initial request and then apply an offset to what you ask it for the 2nd time. Some also jump around, so you'll ask for X and it'll give you Y+10. Then you'll ask again and it'll give you Y-5. It's a real pain in the a***. The best thing I can probably do in this situation (and what I've now done) is to implement a timeout whereby if no progress is made into narrowing down the true start of a track (and therefore end of previous track) within 30 seconds, it times out and moves onto the next one. I can see the current code narrowed yours down to just being left with those 2 problems sectors pretty quickly (around 3 seconds), and if the pregap is out by 2 frames (2/75th of a second) due to those issues, so be it. It's better it moves on (using what it has successfully figured out) than gets stuck for all eternity trying to perfect it. D 18:51:57 Session 1 -> Track 4 -> ISRC -> None Found! D 18:51:57 Sub-Channel - Previous Track End LBA: 0 (00:02:00), Current Track Start LBA: 147142 (32:43:67) D 18:51:57 Sub-Channel - LBA: 147141 (32:43:66), Raw Data: 01 04 00 00 00 00 00 32 43 66 00 00 00 00 00 00 D 18:51:57 Sub-Channel - Original: 147141 (32:43:66), Wanted: 147141 (32:43:66), Got: 147141 (32:43:66) D 18:51:57 Sub-Channel - New Current Track Start LBA: 147141 (32:43:66) ... D 18:52:00 Sub-Channel - Previous Track End LBA: 146990 (32:41:65), Current Track Start LBA: 146993 (32:41:68)
sorn Posted April 8, 2021 Author Posted April 8, 2021 15 minutes ago, LIGHTNING UK! said: This is a bit of an impossible problem to fix (nicely). Your drive is returning some bogus info as the program tries to detect the real start of the track (what would be knowns as Index 0 / the pregap). D 18:52:11 Sub-Channel - LBA: 146991 (32:41:66), Raw Data: 01 16 02 04 4E B2 00 64 82 CC 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146991 (32:41:66), Got: 294132 (65:23:57) D 18:52:11 Sub-Channel - LBA: 146991 (32:41:66), Raw Data: 01 06 02 04 4E B2 00 64 82 CC 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146991 (32:41:66), Got: 294132 (65:23:57) D 18:52:11 Sub-Channel - Bogus response data! D 18:52:11 Sub-Channel - LBA: 146992 (32:41:67), Raw Data: 82 02 02 C0 01 74 00 32 41 67 54 0C 00 00 00 80 D 18:52:11 Sub-Channel - Wrong Type! D 18:52:11 Sub-Channel - LBA: 146993 (32:41:68), Raw Data: 01 04 00 00 01 73 00 32 41 68 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146993 (32:41:68), Got: 146993 (32:41:68) D 18:52:11 Sub-Channel - LBA: 146993 (32:41:68), Raw Data: 01 04 00 00 01 73 00 32 41 68 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146993 (32:41:68), Got: 146993 (32:41:68) D 18:52:11 Sub-Channel - LBA: 146993 (32:41:68), Raw Data: 01 04 00 00 01 73 00 32 41 68 00 00 00 00 00 00 Your drive is returning invalid subchannel info for sectors 146991 and 146992 and that info is causing the program to loop as it attempts to find the real start of track 4 by applying an offset based on what the drive is reporting. For example, the '16' in the top line's 'Raw Data' is supposed to be the track number. Well... there aren't even 16 tracks on the disc! It also then magically changes it to 6 and yet everything else is the same. (6 is still wrong) That bit of code that is responsible for 'Analysing Tracks' is actually quite a complicated due to the fact that some drives have to be told to return info on sector X to get info on sector Y. It isn't just a case of trying sector Y and if you don't get the info, moving on. You have to work out what it's given you after your initial request and then apply an offset to what you ask it for the 2nd time. Some also jump around, so you'll ask for X and it'll give you Y+10. Then you'll ask again and it'll give you Y-5. It's a real pain in the a***. The best thing I can probably do in this situation (and what I've now done) is to implement a timeout whereby if no progress is made into narrowing down the true start of a track (and therefore end of previous track) within 30 seconds, it times out and moves onto the next one. I can see the current code narrowed yours down to just being left with those 2 problems sectors pretty quickly (around 3 seconds), and if the pregap is out by 2 frames (2/75th of a second) due to those issues, so be it. It's better it moves on (using what it has successfully figured out) than gets stuck for all eternity trying to perfect it. D 18:51:57 Session 1 -> Track 4 -> ISRC -> None Found! D 18:51:57 Sub-Channel - Previous Track End LBA: 0 (00:02:00), Current Track Start LBA: 147142 (32:43:67) D 18:51:57 Sub-Channel - LBA: 147141 (32:43:66), Raw Data: 01 04 00 00 00 00 00 32 43 66 00 00 00 00 00 00 D 18:51:57 Sub-Channel - Original: 147141 (32:43:66), Wanted: 147141 (32:43:66), Got: 147141 (32:43:66) D 18:51:57 Sub-Channel - New Current Track Start LBA: 147141 (32:43:66) ... D 18:52:00 Sub-Channel - Previous Track End LBA: 146990 (32:41:65), Current Track Start LBA: 146993 (32:41:68) Thanks for the detailed response! Should I just expect that the code changes will be pushed with the next release? Any chance on getting something compiled to test?
dbminter Posted April 8, 2021 Posted April 8, 2021 Ah, so it looks like LUK may actually meet his stated expectation to release a new version this year!
Recommended Posts