superg / redumper

Low level CD dumper utility
GNU General Public License v3.0
221 stars 20 forks source link

296-byte C2 Support #66

Closed joshstoik1 closed 1 year ago

joshstoik1 commented 1 year ago

I haven't been able to get redumper to recognize C2 error pointer support for my Pioneer BDR-XD05 and BDR-X13U-S drives, but both are capable of returning that information. (Their C2 support is successfully detected and read by other CD-ripping software.)

I'm not a C++ programmer, but I poked around a few different code bases looking for relevant differences, and noticed that CUETools, for example, supports two different possible C2 block sizes — 294 or 296 bytes — while redumper only supports one — 294 bytes. An overview of the two different formats can be found here.

According to this issue, the older of my two drives definitely uses that 296-byte format, but I'm pretty sure my newer one does too.

I can partially work around the issue by setting the drives to "Perfect Mode" — a special Pioneer thing that forces hard SCSI errors for any sector that cannot be read in its entirety — and using the DATA_SUB sector order, but that all-or-nothing approach leads to a lot of unnecessary data loss when the media is in bad condition.

Please let me know if there is any other information I could provide that would be useful to you, or if you'd like me to run any tests, etc.

Thanks!

superg commented 1 year ago

C2 296 bytes block size vs 294 bytes block size error pointer content is equivalent. 296 bytes contains 2 additional header bytes which are always the same (constant sync header) and they aren't involved in error correction. Redumper defines this here: https://github.com/superg/redumper/blob/main/scsi/mmc.ixx#L131 C2_BEB is 296 bytes.

Now, it's true that when reading sector I specify which C2 format I want to receive but so far, every drive that can do 296, can do 294 because it's functionally the same and it's defined in the standard.

If I understand you correctly, you suggest that your drive supports C2, you followed my manual generic drive features evaluation guide and neither DATA_SUB_C2 nor DATA_C2_SUB sector order worked for you.

I can add a way to set 296 C2 format in redumper but I'm not sure that will help. There might be other things at play here. I remember I had a drive that returns C2 information only for data sectors or only for audio sectors but not for both, don't remember exactly but I think it was some bluray Pioneer. Another thing is that sometimes drives lie what is supported in MODESENSE command and that command is used by other software to query drive features. I'm currently in a middle of a move, I'll be able to add that test thing maybe in couple weeks so you can try 296 mode if that helps but meanwhile, try to see if you get C2 for either audio or data, if you already tested data disc, try audio disc with C2.

By the way, this "Perfect Mode", how do you set it for your drive, is it some manufacturer utility? I wonder if that's undocumented vendor SCSI command.

joshstoik1 commented 1 year ago

Thanks for the explanation, @superg!

…neither DATA_SUB_C2 nor DATA_C2_SUB sector order worked for you[?]

Correct, I tried each combination of DATA_SUB_C2/DATA_C2_SUB and BE/BE_CDDA (just in case), but they flooded the terminal with SCSI errors.

DATA_SUB (with either BE/BE_CDDA) works just fine, though it is important to note I have only redumped single-session audio CDs so far. (Judging by this comment in your code, BE_CDDA probably won't work correctly for data.)

Sometimes drives lie what is supported in MODESENSE command

Definitely! I think that's what that CUETools issue was specifically dealing with. The drives in that list said they supported 294, but only actually worked correctly with the 296 variant.

this "Perfect Mode", how do you set it for your drive, is it some manufacturer utility?

Pioneer provides a proprietary "Drive Utility" program for (most of) their optical drives that allows users to view and/or update some of the internal behaviors. Changes can be limited to the current session (in-memory) or persisted (stored on the device). I always persist them because the software is Windows-only, but I use Linux.

The available options and language vary by model, but both of my drives support three different interpolation modes, which is a really cool feature! (It's the main reason I keep buying Pioneer drives. Haha.)

  1. Standard Mode: Optimize reads for realtime playback, interpolating anything that can't be read quickly enough.
  2. Master Mode: Optimize reads for accuracy, retrying stubborn sectors a few different times, a few different ways, resorting to interpolation only as a last resort.
  3. Perfect Mode: Same as Master Mode, but return a hard SCSI error instead of returning iffy data.

I haven't found any software capable of detecting C2 support when the drives are in Perfect Mode, but that is probably because the SCSI errors take precedence.

In Standard/Master modes, Nero and dBpoweramp, for example, detect and make use of the C2 information, giving me detailed counts after a rip has completed.

Try to see if you get C2 for either audio or data, if you already tested data disc, try audio disc with C2

Will do! My computer is in the middle of a long-running task at the moment, but as soon as it's free — tomorrow sometime — I'll run some tests with different types of media and let you know how it goes.

Good luck with your move, and thank you so much for all of your hard work. Incremental recovery is so much smarter than the serial brute-force employed by everyone else.

joshstoik1 commented 1 year ago

Okay, so there appears to be some nuance!

Drive: BDR-X13U-S (Master Mode)
Redumper: 193
OS: Ubuntu Lunar
FS: BTRFS
Kernel: 6.4.3-x64v3-xanmod1
CPU: Intel® Core™ i7-10610U × 8

Audio CD

Order Method Dumpable? Notes
DATA_SUB_C2 BE_CDDA SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_SUB_C2 BE SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_C2_SUB BE_CDDA SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_C2_SUB BE SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_SUB BE_CDDA
DATA_SUB BE
DATA_C2 BE_CDDA
DATA_C2 BE

It is worth noting I was actually able to get C2 data from the drive, but only when omitting subchannel. And I could get subchannel by omitting C2. Haha. Not ideal, but it's a start!

Data CD

Order Method Dumpable? Notes
DATA_SUB_C2 BE_CDDA SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_SUB_C2 BE SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_C2_SUB BE_CDDA SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_C2_SUB BE SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_SUB BE_CDDA ?
DATA_SUB BE ?
DATA_C2 BE_CDDA SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: ILLEGAL MODE FOR THIS TRACK)
DATA_C2 BE ?

Mixed: Audio/Data

Order Method Dumpable? Notes
DATA_SUB_C2 BE_CDDA SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_SUB_C2 BE SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_C2_SUB BE_CDDA SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_C2_SUB BE SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_SUB BE_CDDA Audio✓ Data?
DATA_SUB BE Audio✓ Data?
DATA_C2 BE_CDDA Audio✓ Data?
DATA_C2 BE Audio✓ Data?

Mixed: Data/Audio

Order Method Dumpable? Notes
DATA_SUB_C2 BE_CDDA SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_SUB_C2 BE SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_C2_SUB BE_CDDA SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_C2_SUB BE SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)
DATA_SUB BE_CDDA Audio✓ Data? SCSI error (SC: CHECK CONDITION, SK: MEDIUM ERROR, ASC: UNRECOVERED READ ERROR, ASCQ: 05) (between the two sessions)
DATA_SUB BE Audio✓ Data? SCSI error (SC: CHECK CONDITION, SK: MEDIUM ERROR, ASC: UNRECOVERED READ ERROR, ASCQ: 05) (between the two sessions)
DATA_C2 BE_CDDA SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: ILLEGAL MODE FOR THIS TRACK)
DATA_C2 BE Audio✓ Data? SCSI error (SC: CHECK CONDITION, SK: MEDIUM ERROR, ASC: UNRECOVERED READ ERROR, ASCQ: 05) (between the two sessions)

General/Global Observations

The refine action did not work for me in any of the tests. It just prints a header and quits. (You can see this in the logs that I let run to the end.) The same thing happens when explicitly running redumper refine. I'm pretty sure the last working version was 176. I'll verify that and open a separate issue for you.

Data sessions were iffy in all tests. Their existence caused the split action to fail, even in cases where the dump reported no errors, and triggered an unsupported drive read method warning when using BE.

I don't normally use split or rip data sessions, so maybe this is normal? Regardless, I wasn't sure how to verify the data-data was dumped correctly, so just marked the rows as ? in cases where the scrap/scram had something in the appropriate range.

I used sox to manually extract and verify the audio tracks, so felt better about marking those with ✓.

Here are the corresponding logs for reference. I aborted some of the tests prematurely to save time, but each disc should have at least one complete entry.

Please let me know if there's anything else I can do to help!

joshstoik1 commented 1 year ago

@superg I think you're right. I have been testing both drives with a few different programs and both seem capable of populating the standard 294-byte C2 blocks. I'm going to go ahead and close this out. Thanks again!