I dumped an audio CD and got a regular .cue file but also one suffixed "(Subs indexes)".
What's the subs indexes version and how is it calculated differently?
1,476 2018-07-23 14:08:55
1,477 2018-07-24 04:26:07
- ajshell1
- Dumper
- Offline
sarami wrote:
ajshell1 wrote:I've dumped the game disc four times so far
Perhaps, your disc has c2 errors.
Possibly, but I just managed to get DCDumper and CDTool to produce output tracks with identical checksums. I'd be willing to bet that this is a result of my TS-H352C not having C2 support, while DIC seems to depend heavily on C2 support.
1,478 2018-07-24 10:50:15
FatArnold wrote:
one suffixed "(Subs indexes)"
It failed to get the correct subchannel. This suffix is only used by pce disc (1988 - 1989?).
I'll fix subchannel reading and don't output the suffix except pce.
ajshell1 wrote:
DCDumper and CDTool to produce output tracks with identical checksums.
Your disc is 'light' damaged disc, and these tools run multiple reading by default to get the identical checksums. So, checksums match (by chance) but it is short of reliability.
If your disc is 'heavy' damaged disc, DCDumper and CDTool probably can't dump it because such disc possibly outputs identical bad checksums.
1,479 2018-07-24 13:53:21
- iR0b0t
- Administrator
- Offline
sarami wrote:
It failed to get the correct subchannel. This suffix is only used by pce disc (1988 - 1989?).
I'll fix subchannel reading and don't output the suffix except pce.
I am pretty sure i have had PC discs with TOC vs SUB differences.
PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
1,480 2018-07-24 14:39:44
Audio CDs are known to have them as well - http://redump.org/disc/27432/
Why don't you want to improve the subchannels fixing algorithm? I've explained how it should work, maybe worth to discuss it? The root of misdetections is the incorrect fixing and "don't output the suffix except pce" is not a solution, it's a kludge, that will only result in more bad dumps.
1,481 2018-07-24 16:16:05
4.1. If Q-CRC of QCurrentSector doesn't match: QGenSector = QNextSector - 1 frame (MSF - 1, AMSF - 1, fix Q-CRC).
4.2. You do a binary compare (96 bits vs 96 bits) between QCurrentSector and QGenSector and count a number of bits that differ. If their count is <= FixLevel: QCurrentSector = QGenSector and go to p.5.
1. What FixLevel? Default of subdump is 96?
2. If QNextSector is 1st pregap sector, Is QGenSector really correct?
3. If QCurrentSector is track 1 and QNextSector is track 2, is QGenSector really correct?
4. If QCurrentSector is index 1 and QNextSector is index 2, is QGenSector really correct?
5. If QCurrentSector is ctl 0 and QNextSector is ctl 4, is QGenSector really correct?
4.3. If QEAN != null, you do a binary compare between QCurrentSector and QEAN and count a number of bits that differ. If their count is <= FixLevel: QCurrentSector = QEAN and go to p.5.
4.4. If QISRC != null, you do a binary compare between QCurrentSector and QISRC and count a number bits that differ. If their count is <= FixLevel: QCurrentSector = QISRC and go to p.5.
6. If adr of QCurrentSector is 1 but actually QCurrentSector is EAN sector, is the adr really fixed?
7. If adr of QCurrentSector is 3 but actually QCurrentSector is EAN sector, is the adr really fixed?
8. If adr of QCurrentSector is 2 but actually QCurrentSector is ISRC sector, is the adr really fixed?
9. If adr of QCurrentSector is 2 but actually QCurrentSector is normal sector, is the adr really fixed?
10. Does this algo support all SecuROM (at least 4 patterns) and Libcrypt?
1,482 2018-07-26 04:50:53
bparker wrote:
Hi @sarami, could you push your current code with the linux support to github so I can take a look at some of the issues? Thanks!
Uploaded in test branch.
1,483 2018-07-30 04:12:31
Returning to the conversation about PS4 kiosk discs (BD-R):
I bought some retail PS4 discs to test dumping, the result was great, they dumped fine and the non-missing ones verified redump entries properly.
However...
Back to dumping PS4 official kiosk discs, which are on BD-Rs, different hashes and iso sizes are returned every dump.
Near the last 5-10% of the dump the dumping sector progress slows WAY down and starts sputtering even a little bit. My discs are in perfect condition so that's not the problem. I'm guessing these require some kind of encryption / keys? Maybe they even use BD-Video keys? Anyone have experiencing dumping encrypted BD-Video can advise so I can test?
All my posts and submission data are released into Public Domain / CC0.
1,484 2018-07-30 04:18:50
user7 wrote:
Back to dumping PS4 official kiosk discs, which are on BD-Rs, different hashes and iso sizes are returned every dump.
user7 wrote:
I dumped with ISO Buster twice, different checksums and different sizes both times, discs are in flawless condition.
I have no idea about this problem now. Is the other general BD-Rs same result, not PS4 official kiosk discs?
1,485 2018-07-30 04:32:45 (edited by user7 2018-07-30 04:32:56)
Official Kiosk discs are BD-Rs. Same as Wii U did with CAT-R for their kiosk discs. I guess they didn't want to spend money pressing kiosk discs.
On a separate subject, Wii U CAT-R discs must be dumped on Wii U kiosk machines since they use a special Dev key (they're essentially no different than burnt dev discs in that regards).
I wonder if PS4 has a similar mechanism, but no key is required for dumping regular PS4 retail discs, so not sure...
I can send you a PS4 kiosk disc if you wish to investigate.
All my posts and submission data are released into Public Domain / CC0.
1,486 2018-07-30 07:21:44
Uploaded test version. http://www.mediafire.com/file/eq80y20l9 … r_test.7z.
added: Output PARAM.SFO into _disc.txt -> I only checked PS3 discs.
user7 wrote:
Official Kiosk discs are BD-Rs
Firstly, I want to know whether or not general BD-Rs output different checksums and sizes. (I can't test it because I don't have BD-R drive.)
1,487 2018-07-30 14:43:41
sarami wrote:
1. What FixLevel? Default of subdump is 96?
FixLevel defines an acceptable level of errors. More errors than FixLevel - reread, do not fix. Each channel is 12 bytes/96 bits. 'Default' for subdump is 1 (it's not changeable). 1-bit errors are fixed automatically; if any of the channels from the read sub sector is different to the generated one in 2 or more bits - subdump rereads that sector (then counts the different bits and accepts the rereading results if the number of different bits lowered).
sarami wrote:
2. If QNextSector is 1st pregap sector, Is QGenSector really correct?
3. If QCurrentSector is track 1 and QNextSector is track 2, is QGenSector really correct?
4. If QCurrentSector is index 1 and QNextSector is index 2, is QGenSector really correct?
5. If QCurrentSector is ctl 0 and QNextSector is ctl 4, is QGenSector really correct?
No, that's why we check for Q-CRC. Even if the QCurrentSector is different to QNextSector, but QCurrentSector's Q-CRC is good, you continue to read.
Of course, you can try to generate all kinds of sectors and compare against them.
6. If adr of QCurrentSector is 1 but actually QCurrentSector is EAN sector, is the adr really fixed?
7. If adr of QCurrentSector is 3 but actually QCurrentSector is EAN sector, is the adr really fixed?
8. If adr of QCurrentSector is 2 but actually QCurrentSector is ISRC sector, is the adr really fixed?
9. If adr of QCurrentSector is 2 but actually QCurrentSector is normal sector, is the adr really fixed?
Same, it checks for Q-CRC and rereads, if it doesn't match.
And I've remembered one more important step. When we're trying to fix 1-bit errors in subdump, we're just trying to change each bit to opposite. Like, for "001101010101" Q-sector with failed Q-CRC, we're checking the validity of Q-CRC for "101101010101", "011101010101", "000101010101", etc. So you don't need to know the sector type to fix 1-bit Q-channel errors. Not sure if it's effective for 2-bits errors and above (too many variants to check).
10. Does this algo support all SecuROM (at least 4 patterns) and Libcrypt?
Subdump - no, but you can add additional Q-CRC checks for these.
Also I forgot to mention the P and R-W channels fixing. Subdump analyzes the channel and if 7 or more bytes are equal, we define it as a 'padding byte' for this channel of this sector, then we compare 12 bytes of the read sector with the generated sector with all 12 bytes = padding byte, then we compare the difference in bits with the FixLevel value. CD+G channels won't have any 'padding' bytes, so they won't be fixed, just ignored. There are many PSX discs with 0x01, 0x02, 0x03 bytes in R-W, this pattern should be implemented somehow to avoid the unwanted fixes.
1,488 2018-07-30 16:56:30
Like this?
if (Q-CRC of QCurrentSector is bad) {
create QGenSector from QNextSector - 1
compare 96bits of QCurrentSector and QGenSector
if (these sectors have 1-bit error) {
try to change each bit to opposite (Max 96 times?)
}
else if (these sectors have 2 or more bit errors) {
reread sector (*1)
}
}Question
(*1). How many times subdump reread the sector? If it can't get the good Q-CRC, is the sector written to file with being bad?
1,489 2018-07-30 18:02:37
Near sector it slowed down/chopping progress: 22600000/23652352
I dumped the same disc twice with the new test build.
dump 1:
<rom name="dump1.iso" size="48440016896" crc="eeb8ef26" md5="e94131750b44decbab717a68165d355c" sha1="db7fe92fbe5d337ec1f9f5e464ab76f543963e42" />
dump 2:
<rom name="dump2.iso" size="48440016896" crc="8f96853a" md5="2a08985a14c6362c65645dee4aed3e91" sha1="ed0b1a3b22221335eb2b569d10d9a6a59cee77e1" />
Hmmm at least the sizes are the same.
All my posts and submission data are released into Public Domain / CC0.
1,490 2018-07-31 14:49:16
sarami wrote:
Like this?
if (Q-CRC of QCurrentSector is bad) { create QGenSector from QNextSector - 1 compare 96bits of QCurrentSector and QGenSector if (these sectors have 1-bit error) { try to change each bit to opposite (Max 96 times?) } else if (these sectors have 2 or more bit errors) { reread sector (*1) } }
More like:
if (Q-CRC of QCurrentSector is bad) {
create QGenSector from QNextSector - 1
compare 96bits of QCurrentSector and QGenSector
if (these sectors have >[FixLevel]-bit error) {
QCurrentSector = QGenSector
}
else {
try to change each bit to opposite (Max 96 times) // for the case when QCurrentSector and QGenSector are different
if not success {
reread sector (*1)
}
}Or:
if (Q-CRC of QCurrentSector is bad) {
create QGenSector1 from QNextSector - 1
compare 96bits of QCurrentSector and QGenSector1
if (these sectors have >[FixLevel]-bit error) {
QCurrentSector = QGenSector1
}
else {
create QGenSector2 from QPrevSector + 1
compare 96bits of QCurrentSector and QGenSector2
if (these sectors have >[FixLevel]-bit error) {
QCurrentSector = QGenSector2
}
else {
try to change each bit to opposite (Max 96 times) // for the case when QCurrentSector and QGenSector are different
if not success {
reread sector (*1)
}
}
}Comparing with both QNextSector-1 and QPrevSector+1 would help with pregap areas.
Also, you can try to change not only 1 bit to opposite, but [FixLevel] bits, should be something like 96^2 variants for FixLevel=2, etc., but I don't know about the speed of such calculations.
Question
(*1). How many times subdump reread the sector? If it can't get the good Q-CRC, is the sector written to file with being bad?
Defined by -rereadnum commandline option.
1,491 2018-07-31 15:45:26
1-bit errors are fixed automatically
if (these sectors have 1-bit error) {
QCurrentSector = QGenSector
}
Who fixes the 1-bit error of QCurrentSector? Isn't it fixed by changing each bit to opposite?
I can't understand how to use the FixLevel/[FixLevel] bits.
1,492 2018-08-03 13:00:56
sarami wrote:
I can't understand how to use the FixLevel/[FixLevel] bits.
FixLevel = 1
if (Q-CRC of QCurrentSector is bad) {
create QGenSector1 from QNextSector - 1
compare 96bits of QCurrentSector and QGenSector1
if (the difference is 1-bit) {
QCurrentSector = QGenSector1
}
else {
create QGenSector2 from QPrevSector + 1compare 96bits of QCurrentSector and QGenSector2
if (the difference is 1-bit) {
QCurrentSector = QGenSector2
}
else {
try to change each bit to opposite (Max 96 times) // for the case when QCurrentSector and QGenSector are different
if not success {
reread sector (*1)
}
}
}
FixLevel = 2
if (Q-CRC of QCurrentSector is bad) {
create QGenSector1 from QNextSector - 1
compare 96bits of QCurrentSector and QGenSector1
if (the difference is 2-bit or less) {
QCurrentSector = QGenSector1
}
else {
create QGenSector2 from QPrevSector + 1compare 96bits of QCurrentSector and QGenSector2
if (the difference is 2-bit or less) {
QCurrentSector = QGenSector2
}
else {
try to change each bit to opposite (Max 96*96? times) // for the case when QCurrentSector and QGenSector are different
if not success {
reread sector (*1)
}
}
}
FixLevel = 3
if (Q-CRC of QCurrentSector is bad) {
create QGenSector1 from QNextSector - 1
compare 96bits of QCurrentSector and QGenSector1
if (the difference is 3-bit or less) {
QCurrentSector = QGenSector1
}
else {
create QGenSector2 from QPrevSector + 1compare 96bits of QCurrentSector and QGenSector2
if (the difference is 3-bit or less) {
QCurrentSector = QGenSector2
}
else {
try to change each bit to opposite (Max 96*96*96? times) // for the case when QCurrentSector and QGenSector are different
if not success {
reread sector (*1)
}
}
}
sarami wrote:
Who fixes the 1-bit error of QCurrentSector? Isn't it fixed by changing each bit to opposite?
Comparing QCurrentSector and QGenSector1 and QCurrentSector and QGenSector2 are 2 operations, changing the bits is 96^FixLevel operations, much longer. So it's faster to compare with the generated sector first. Maybe also worth to add a flag not to use the bit changing, if the difference between QCurrentSector and QGenSector1 or QCurrentSector and QGenSector2 is FixLevel+1 ... FixLevel+9 bits then not to use the bits changing for this sector.
For example:
FixLevel = 1
compare 96bits of QCurrentSector and QGenSector1
QCurrentSector = 0101010101
QGenSector1 = 0111010111
Difference: 2 bits. 2 bits is between "FixLevel+1 ... FixLevel+9", so you don't change the bits, you reread the sector.
Or:
FixLevel = 1
compare 96bits of QCurrentSector and QGenSector1
QCurrentSector = 010101010101
QGenSector1 = 101010101010
Difference: 12 bits. 12 bits is more than FixLevel+9, so we assume the sector is probably of a different type than generated sector and we're trying to change the bits before rereading.
1,493 2018-08-03 19:16:25 (edited by user7 2018-08-03 19:17:14)
Back to the PS4 Kiosk discussion, I've been able to get ISO Buster to output the disc i'm testing with repeatable hashes 3 or 4 times. DIC still outputting different hashes each time. Perhaps DIC isn't reading the sectors correctly or reporting read errors properly, or maybe ISO Buster just keeps making the same mistakes and so the result is the same hashes...
All my posts and submission data are released into Public Domain / CC0.
1,494 2018-08-05 08:12:10
Up http://www.mediafire.com/file/eq80y20l9 … r_test.7z.
> create QGenSector1 from QNextSector - 1
> create QGenSector2 from QPrevSector + 1
added.
Others haven't added yet.
user7 wrote:
maybe ISO Buster just keeps making the same mistakes and so the result is the same hashes...
How about other tool except DIC and IsoBuster?
1,495 2018-08-05 09:53:07
>How about other tool except DIC and IsoBuster?
I also dumped with IMG Burn and Dvdisaster once, both gave different hashes than the rest (and sizes I believe).
All my posts and submission data are released into Public Domain / CC0.
1,496 2018-08-06 02:27:41
- andoryuu3
- New member
- Offline
sarami, thank you so much for your work on DiscImageCreator. I am an Xbox1/Xbox360 addict, and have heaps of old games to rip.
I'm posting here at request of dizzzy from the discord server to share a little discovery I made ripping my retail copy of Halo 2:
Discord Server: August 3rd 2018 wrote:
[6:46 PM] andoryuu3 [USA]: Does anyone know off hand if there is a way for sarami's DiscImageCreator to preserve random padding in Xbox 1 dumps?
[6:59 PM] dizzzy [USA]: Not sure, I read your post about that. DIC produces the same hashes as Xbox Backup Creator tho
[9:00 PM] andoryuu3 [USA]: Well apparently I was wrong about FreeCell/XBC (the post was actually about these two), which is fine. But when I tested ripping Halo 2 via DIC with my SATA Kreon drive (J), it only produced an image about 2.6GB in size. The command I used was simply "DiscImageCreator.exe xbox J: Halo2.iso"
[9:01 PM] andoryuu3 [USA]: So either a major glitch happened due to read errors, or DIC doesn't seem to do random padding. FreeCell/XBC does though
DiscImageCreator is supposed to preserve random padding right? I ask because without it some Xbox 1 games won't run at all.
Thanks again for your work!
1,498 2018-08-06 06:04:49
He got a 2.6GB image instead of the standard 7825162240-bytes one.
1,499 2018-08-06 06:37:16
>andoryuu3
Only Halo2? or all xbox disc you have? or all DVD you have?
And please read 1st post. http://forum.redump.org/post/37654/#p37654
Attention
1. Before you report a bug, could you try the latest test version http://www.mediafire.com/file/eq80y20l9 … r_test.7z.
Nevertheless a bug exists, could you upload all created file except bin, iso, img and scm.1,500 2018-08-10 03:24:37
sarami wrote:
bparker wrote:Hi @sarami, could you push your current code with the linux support to github so I can take a look at some of the issues? Thanks!
Uploaded in test branch.
Thanks, how do we build this for Linux? I don't see a Makefile anywhere.