You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 7 of 9)
I checked idlord's logs and the issue is because subchannels are corrupted.
Listing the different protection schemes for the 8 subcoding channels...
Channel P: no protection, Channel Q: 16-bit CRC, Channels R to W:
[FONT=Arial][SIZE=2][SIZE=2][FONT=Arial][SIZE=2][FONT=Arial]To protect the data in the subcoding channels R to W, a (24, 20) Reed-Solomon error correction code is used. To improve the burst error correction capability, 8 times interleaving is added to this error-correction system. The first two symbols in a PACK have additional protection with a (4, 2) Reed-Solomon error correction code.
[/FONT][/SIZE][/SIZE][/FONT][/SIZE][/FONT]
https://club.myce.com/t/subchannel-issues/195516/9
Sarami maybe you could take the CRC16 from Sub Q and attempt to detect single bit errors by bit swapping each bit in Sub Q and checking if CRC16 matches (CRC16 could also be corrupted). cdgtool is using such approach to clean the subs for random bit errors. Could you implement this simple algorithm. That could solve issue with such rotting CDs...
Sector 16, offset 320-370 in isobuster.
Newest DIC puts PVD to one of the log files.
It's this:
if(sector[0x10] == sector[0x14] && sector[0x11] == sector[0x15] && sector[0x12] == sector[0x16] && sector[0x13] == sector[0x17]) { OK } else { FLAGS_NOT_SAME }
Try to read discs with positive and negative write offsets...
What OS ? Recent OS can screw the protectors...
So in case of this 1024B sector is DIC going to have support for this?
Sarami: Could you made a commit to git with latest changes? I think I have a DVD that fails to dump and I'd like to debug it...
sarami wrote:http://redump.org/disc/43476/
File system doesn't corrupt, but CD-ROM that "Logical Block Size" isn't 2048 byte is perhaps rare or irregular. So, I think the OS that is newer than WinXP doesn't support it.
Nice find. Also some tools do not support it either (Total Commander) + 7z.
In this case it's possible to reimage from mounted image in virtual drive
It's not a bug in DIC. DIC correctly parses the data. It's disc fault. New operating systems do not detect anything on the cd. Only old Windows show the data (I guess those old versions do not handle Path Table records).
I just had a small morning debugging session and one of the dumpers found a CD which has corrupted Path Table Record. I inspected it under debugger and basically all fields are off. I think Path Table Records related values in PVD are wrong.
Please add an option to disable reading Path Table Record via command line in order to fight such weird CDs...
It could this: http://redump.org/disc/42279/
Also Ring PROTECH cannot be dumped with Plextors.
1) Extract AUDIO using DIC.
2) Extract DATA using OptiARC.
This is the only solution...
I checked under debugger that pDirRec[*nDirPosNum].uiDirNameLen = 0. It's an error during mastering phase?
> Is this solved ?
I forgot which dics it was 
Also I found one bug in CD-Text dumping. In function: SetAndOutputTocCDText -> strlen(pTmpText + uiIdx) crashes. iuIdx has some big value. This only happens with PX760. Other drive reads it correctly. Maybe before parsing those data structures subchannels should be corrected (packed mode read?).
Only DIC can rip it properly. There should be 10 errors...
sarami wrote:Escaped 0 length.
if (pDirRec[*nDirPosNum].uiDirNameLen > 0) {
:
:
}
else {
OutputVolDescLogA(
"\t Length of Directory Identifier: %u\n", pDirRec[*nDirPosNum].uiDirNameLen);
break;
}
Is 0 correct value? I want to look the *mainInfo.txt and *volDesc.txt
When I terminate program mainInfo.txt is empty and volDesc has:
========== LBA[000018, 0x00012]: Volume Descriptor ==========
Volume Descriptor Type: 255
Standard Identifier: CD001
Volume Descriptor Version: 1
========== LBA[000019, 0x00013]: Path Table Record ==========
Length of Directory Identifier: 1
Length of Extended Attribute Record: 0
Position of Extent: 21
Number of Upper Directory: 1
Directory Identifier:
I checked under debugger that pDirRec[*nDirPosNum].uiDirNameLen = 0. It's an error during mastering phase?
There seems to be some inifite loop in function: OutputFsPathTableRecord:
pDirRec[*nDirPosNum].uiDirNameLen is 0 in my CD and it casues infinite loop
I don't have logs from: http://redump.org/disc/42648/. Usurper has them...
Sarami there's a small regression in latest version of DIC. When you specify /rc switch and no protection is detected a warning pops up with message /rc is ignored. For some discs (when protection cannot be detected) this is causing a regression and some sectors are not properly dumped. Please provide a way to override /rc so that it's always active.
Is it possible to glue valid sector ranges from all your copies?
"it uploaded a dozen or so junk files" - what?
I'd go with subchannel analysis as it describes cd at lower level than sync concept. Data tracks are based on audio tracks with added correction schemes and basically from low level point of view every cd we analyze is audio cd.
Subchannels don't have that great error correction schemes like 2352 data. I have CDs that look like they just came from factory but data on them is barely readable. I bet your CD is an example of poor quality master that has some unstable data in subchannels area + DIC might have a bug somewhere and incorrectly repairs the subchannel.
Subdump: http://forum.rawdump.net/viewtopic.php?id=13
Posts found: 151 to 175 of 221