Don't repair subchannel data, on or off?

vbimport

#1

For writing I read this should be on for console games, but what about PC games? Does it matter if I leave this on or off?


#2

The Settings Sticky, pinned to the top of this forum, explains how this ‘trick’ works.

It is only required when an uncorrected P-W subcode channels write is required, which is LibCrypt only.


#3

Ok, so it doesn’t matter wether it’s on or off except for those LibCrypt protections. thanks


#4

Originally posted by FutureProof
It is only required when an uncorrected P-W subcode channels write is required, which is LibCrypt only.
Hmm, i thought it was required for securom & securom new too… not only PSX libcrypt protection.
I think he asked whether he should ever use it when backing up pc games:

Originally posted by Xidus
For writing, I read this should be on for console games, but what about PC games?


#5

its very required for securom and securom new games.


#6

Originally posted by ckin2001
its very required for securom and securom new games.
Not true.[ul][]SecuROM & Libcrypt both have their protection in the Q subcode channel[]SecuROM has no incorrect CRC in the Q subcode channel[]LibCrypt does have incorrect CRC[]A 16 byte write will correct any CRC in the subcodes[]A 96 byte write does not correct subcode CRC[]the “Don’t repair…” feature ‘forces’ a 96 byte write on writers that are capable of +96 but which default to +16[]the feature is superfluous to SecuROM[]the 16 byte & 96 byte write ‘thing’ is an MMC standard[]there’s no escaping fact & science[]bite me ;)[/ul]


#7

Sounds pretty odd to me. I’ve been visiting cdfreaks for almost a year now, and most posts i’ve run into concerning securom implied that it was a must for bypassing it - not to mention that it has worked for me several times in the past.

But as you say it is superfluous (had to look it up !! :bigsmile: ), therefore i’ll never have to use it again. Thanx for clearing that out FP :wink:


#8

Originally posted by Hemispasm

…not to mention that it has worked for me several times in the past.
…hehe…nothing to ‘work’ on! :stuck_out_tongue:

I should have added, if it wasn’t really clear, that a 16 byte write of LibCrypt will correct the ‘incorrect’ CRC data and thus blow your 1:1 copy :eek:


#9

So to make this clear, checking “Don’t repair subchannel data” isn’t always necessary but can’t do any harm? So just to be sure I should just always leave that checked anyway, right?


#10

Originally posted by Xidus
So to make this clear, checking “Don’t repair subchannel data” isn’t always necessary but can’t do any harm? So just to be sure I should just always leave that checked anyway, right?
Correct. Yep :smiley:


#11

then how the heck does securom work? since a writer will normally write the correct error correction stuff anyways…? im just confused at the moment.


#12

Originally posted by ckin2001

then how the heck does securom work? since a writer will normally write the correct error correction stuff anyways
There is a difference in what I previously said about CRC correction. SecuROM has no intentionalCRC errors in the Q channel. A 16 byte, corrected, write makes no difference - because there’s nothing to correct. Neither does a 96 byte write make any difference. SecuROM just checks for the digital signature in the Q channel.

LibCrypt has very intentional errors in the Q channel. The only way to copy the intentional errors over, uncorrected, is to have a 96 byte uncorrected write. LibCrypt simply checks for the ‘bad’ CRC. If it’s been corrected (16 byte write) it won’t run. If hasn’t been corrected (96 byte write) it will run.

Some writers can do both 16 & 96, as we know. Some do neither. Some do only 16 or only 96. The setting ‘forces’ 96 byte capable writers, which default to 16. It’s the only way to get them to do it. Those people who say “you don’t need it”, have a writer that does only 96 (ot there’s no protection ;))


#13

@FutureProof

Are you sure, that always doing a 96 byte write won’t harm the data?
A long time ago I started a thread on the CloneClinic forum, because I wanted to know, why the created sub files are always different, no matter, how often you read the same disc.
Olli replied and said that the subs don’t have any additional error detection/correction and that’s why the differences occur.
And this issue would be corrected on writing, unless you select “don’t repair…”.
Sounds to me, that it’s better to leave the correction on as long as you don’t need uncorrected CRCs (LibCrypt) …


#14

Originally posted by little-endian
[B]@FutureProof

Are you sure, that always doing a 96 byte write won’t harm the data?

Sounds to me, that it’s better to leave the correction on as long as you don’t need uncorrected CRCs (LibCrypt) … [/B]
Am I sure? No. Do I know how it really works? No. But what about the writers which only write in 96 byte ‘mode’? What about the writers that only write in 16 byte mode?

If I understand your post, I never said that it harms anything. I was pointing out that it’s not necessary from a technical, ‘know the reason’ point of view. Appreciate the interest, though :wink:


#15

@FutureProof

You have a strong argument with writers which always write in 96 byte mode. I must agree that I never got a worse copy, only because I used a 96 byte write.
I was only confused, because of Olli’s statement.

Do you happen to know, which CD-writer defaults to a 96 byte write?


#16

Originally posted by little-endian

Do you happen to know, which CD-writer defaults to a 96 byte write?

There were examples on Olli’s old site, (I think), not sure about the new site. I’m looking around.


#17

Originally posted by little-endian
A long time ago I started a thread on the CloneClinic forum, because I wanted to know, why the created sub files are always different, no matter, how often you read the same disc.
Olli replied and said that the subs don’t have any additional error detection/correction and that’s why the differences occur.
And this issue would be corrected on writing, unless you select “don’t repair…”.

Olli is right about the error-detection/correction thing. Only the q-channel has a crc-check. (CRC-check is only error-detection, you can’t correct errors with it.) But did Olli explain why it is impossible to read the same subchannel data on succesive reads? Just like you proved with your data-cd in audio format, if you have a good reader you should be able to get subs like they are on the cd. Did you try to read with the slowest speed possible and did you try different brands?

About the rest of the discussion: FutureProof sums it all up in his post, nothing to add to that. Only 1 question: if you have a writer which only writes 96 bytes of subchannel info and you use this to copy Libcrypt and you don’t tick “don’t repair subchannel data” you still get a working copy?


#18

Originally posted by Upp3rd0G
Only 1 question: if you have a writer which only writes 96 bytes of subchannel info and you use this to copy Libcrypt and you don’t tick “don’t repair subchannel data” you still get a working copy?
Yes; and I’m still looking for that damn information about “96” only. I think it might have been in a post at CloneClinic. Too many threads/posts now, here, to print off Olli’s replies - but I’m still looking!