You are not logged in. Please login or register.
Redump Forum → Posts by sarami
@sarami
Please see this topic. http://forum.redump.org/topic/38579/
The error occurs only on the PX-760A. Do you know why?
http://forum.redump.org/post/91255/#p91255 and see mainError.txt
I think this is plextor bug.
My primary concern is that in my new dump the split is 1 sector earlier comparing to what we have in the DB.
e.g. in the new dump the data track last sector is audio track but in the DB it's not and it seems more correct. I have to identify which dump is correct, old or new.
279144 belongs to track 1.
Can't extract either.
Unfortunately, their cabs do not support it.
(Subs indexes)
Try to use "/s 2"
Maybe I am doing it wrong I can't extract the files.
Also try i6cmp13b.zip
https://www.sac.sk/files.php?d=7&l=I
they are InstallShield cabinet files instead of Microsoft ones
Can you extract them of the _setup directory manually using i6comp.exe?
on Nintendo disc with DiscImageCreator I get:
fixed. https://www.mediafire.com/file/eq80y20l … st.7z/file
But Nintendo disc dumping is extremely slow. If you merely want to dump the iso, use RawDump or cleanrip on wii.
Dumped again with /mscf flag.
There is not IOSLINK.VXD.
No, not replaced with 0x55 but they can be "cleaned" somehow. I think the sectors match surrounding sectors except for the random error bytes which need to be cleaned so that they match (besides header). Perhaps it can be accomplished by rereading sectors and keeping the bytes that are most consistent between reads.
Ok, but who guarantees the kept bytes is correct?
Is there anything that be done about this problem or did I miss the solution?
The problem may be that there is not EDC in LBA 16. Perhaps it can read using 0xbe, not 0xa8. I don't fix it yet.
The installed game will have these two files
There are some cab and hdr files in the disc. If they are Microsoft cabinet files, you need to use /mscf to detect DiscGuard.
The protection of 7K2 was detected as DiscGuard.
Detected a protected file [IOSLINK.VXD]. LBA 302 to 330I think there were some sectors without EDC where the random errors needed to be cleaned manually.
According to the 3 logs of Neon Beast, LBA 299 to 1498 do not have EDC. These should be replaced to 0x55 like SafeDisc?
Dumped HoMM 3 again, still got different hashes.
How about the other 2 discs?
According to CD Media World https://www.cdmediaworld.com/hardware/c … uard.shtml, DiscGuard has IOSLINK.VXD and IOSLINK.SYS but your HoMM 3 doesn't have them.
Uploaded test version. I don't have DiscGuard discs. Test plz.
https://www.mediafire.com/file/eq80y20l … st.7z/file
t has DiscGuard protection, don't know if this is causing the problem.
c2 errors exist.
LBA[000302, 0x0012e] Detected C2 error "00 F0 F0 F0 00 00 00 0F 0F 0F 00"
This error can't be fixed by plextor drive. Needs to dump it by non-plextor drive and replace itThis is known as the plextor drive bug but may be the problem of the DiscGuard? I'm not sure about this protection.
It's just a waste of time for everyone dumping a lot of discs and not worth adding just because someone thought the feature would be neat imo.
When hashing, DIC doesn't access the disc, so you can eject it and insert the new one and start dumping by the other DIC (instance).
If you hope to eject the disc automatically like CloneCD, I can add it.
sarami, DiscImageCreator has problems properly dumping a Hasbro VideoNow disc.
As noted by F1ReB4LL, it's supposed to have 18032 bytes of zeroes + 71808 bytes that were cut at the start of the first track. This seems to be a DIC problem.
Use this.
/vn Search specific bytes
For VideoNow
val Combined offset is shifted for negative direction if positive value is set
/vnc Search specific bytes
For VideoNow Color
/vnx Search specific bytes
For VideoNow XPit requires going through a website interface rather than a direct file link which could be pulled down via an automated process.
I tried AppVeyor but I have no idea how to build by resolving the dependency of the external library.
user7 wrote:Is there anyway to prevent dic from hashing .scm and .img to save time? is it necessary?
Thanks <3<3
Agreed. This would be awesome for those of us stuck dumping with older hardware.
http://forum.redump.org/post/57032/#p57032
is it possible to make the latest dic test build a static link on GitHub (not Mediafire)?
Why Mediafire's link is bad?
I have tried different speeds and different drives so far and no consistent matches.
Try the latest test version. https://www.mediafire.com/file/eq80y20l … st.7z/file
@NovaAurora
Updated EccEdc.exe https://www.mediafire.com/file/2quudw2b … st.7z/file Test, plz.
sarami wrote:Jackal wrote:Can the shifted offset be explained by ASUS drive or a Linux bug?
I have no idea about it. Which sector is shifted?
The audio data is shifted 1 sample (4 bytes) between the 2 dumps.
homm2.zip is an old (20191223) version that has a bug for asus dumping.
You say below.
For now we are no longer accepting new dumps from non-Plextor drives for discs with audio tracks.
asus dumping that is already registered in the database should be done to all yellow status or deleted?
Trying to dump a PC CD and it took like 3 hours to dump with Plextor+MPF and failed
There are many c2 errors. Change the disc and/or drive.
Should I submit the Plextor+CloneCD dump
should I be using CloneCD for the non-Plextor verification?
It's ok for your private preservation but redump.org does not accept these.
Positive SecuROM 4 detection with DIC and PID, 0 Errors reported by DIC. 1 Error detected by CDMage in track 1.
Ah sorry, EccEdc only checks 4th from the last sector but should check 4th from the last data sector. I'll fix it.
Can the shifted offset be explained by ASUS drive or a Linux bug?
I have no idea about it. Which sector is shifted?
And you get bogus "errors" like this inside audio tracks:
LBA[019483, 0x04c1b], audio
LBA[019484, 0x04c1c], MSF[00:00:00], zero sync
LBA[019485, 0x04c1d], audio
The control flag of subchannel of the 19484 is incorrect.
Same # of errors reported, same hashes.
These errors are all lead-in sectors of the 2nd session. DIC does not support generating ecc/edc yet when unreadable sectors are generated.
Weird multisession dump & logs
Uploaded.
https://www.mediafire.com/file/eq80y20l … st.7z/file
He successfully dumped others discs.
By plextor?
Did you got this behavior before?
No.
but it should probably additionally create a fixed image and we should probably add the fixed images somehow
I agree for your thought.
"dump" and "dump (fixed)"?
Is it "dump.scm" and "dump (fixed).scm" and "dump.img" and "dump (fixed).img" ?
This is a list to support.
disc | non fixed image | fixed image
---------+-----------------+------------
Silpheed | yes | no
---------+-----------------+------------
Video CD | |
Music | yes | no
Sampler | |
---------+-----------------+------------
FMT | no | yes
---------+-----------------+------------
CD-i | yes | no
----------------------------------------Anyway, I'll get someday these mastering error discs to create the "dump" and "dump (fixed)" automatically...
@user7
Tell me the ebay or amazon or discogs link of "HighlightsVCD", please.
I can't see any way to make DIC ignore the errors and complete the dump.
Execute without /c2.
Silpheed (Sample) lefts 68255 sectors scrambled as far as I see the comments. Then, some CD-i (and FMT) discs should be so?
Can it not be descrambled or what is the issue?
Some CD-i discs have a similar problem to FMT discs.
* http://redump.org/disc/45432/
* http://redump.org/disc/70481/
* http://redump.org/disc/73334/
These 3 titles have 2 write offset due to the mastering issue of the pregap sector. 1st write offset is used by the pregap sector only, so DIC descramble the main (non-pregap) sector using the 2nd write offset.
CD-i discs that user7 reported have also 2 write offset due to the mastering issue of the main sector.
e.g. https://drive.google.com/file/d/1FEVCLK … sp=sharing
To descramble all sector
1. descramble LBA 0 to LBA 948 using 1st write offset.
2. descramble LBA 950 to last sector using 2nd write offset.
3. pad all 0 bytes and put in LBA 949.
or cut the excessive 120 bytes of LBA 949.
Redump Forum → Posts by sarami
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.