You are not logged in. Please login or register.
Redump Forum → Posts by F1ReB4LL
Added this, but still buggy, I think.
Works almost fine for me. The dump is correct, but the cue is missing the CATALOG entry (the drive itself reads the subchannels correctly).
Also, the image sizes (and the checksums) of the .scm and .img files are incorrect (too small). Split tracks are correct.
And why doesn't it show any progress (which sector is being read) during the dumping process?
http://redump.org/disc/32569/ -- this disc was used.
Any DVD gurus? While I do understand, why do we add CSS-protected discs decrypted, what's about other schemes? What's about bad sectors-based ones? What's about the ones with the modified UDF system? http://redump.org/disc/51036/ -- an example of the latter one.
"Asia, USA"
"Asia, Europe"I believe you said that no-intro follows (Japan, USA, Europe) order, if going by that all those should be correct.
I'd say USA, Asia and Europe, Asia. Would like to see some examples, though.
Something should be done with the "Europe, Australia" region. http://redump.org/disc/708/ -- both European and Australian releases share the same ID, while it's ok to use "Europe, Australia" for the game region in db, the datfile names should be (Europe).
Still no idea why does cherokeelzzS get weird DIC dumps with certain discs? Other tools don't have any problems.
Finally, at least one Call of Duty game is useful for something 
I see, but a problem exists. It is that the swap disc can't use TOC.
Of course But it's not a problem.
Solution 1: User inserts disc normally, DIC reads the TOC and leadout (to know the image length), then ejects it and asks to do the swapping (like, "insert the trap audio disc and press any key" => "swap the disc and press any key").
Solution 2: User runs DIC after swapping, DIC reads data and subchannel into .scr + .sub, then ejects the tray, then inserts the tray, then reads the TOC and leadout, then cuts the image to tracks and does the descrambling. Or you can ask the leadout value via .exe parameter (to know how many sectors to read into image) and read only TOC after ejecting/inserting the tray.
I mean, you can swap the CD with some Audio CD (like in the GD mode), then you read all the sectors and descramble them. This way, many non-d8 NEC, Optiarc, etc. drives could be supported. Could be done as a separate "swapcd" mode
Any chance to add the first 16+512? bytes from LBA 0 sector (45000 for "gd" mode) into maininfo.txt? So we wouldn't need to ask the dumpers to provide these for Saturn, Mega CD, Dreamcast dumps.
And have you thought to add the support for the swappable non-Plextor drives? DIC could read scrambled sectors with 0xBE command in this mode and people could use more common drives to dump properly.
Ah, so it works now. Last month another dumper has shown me some DIC error logs for the Alien Gate (also CD-i Ready).
Track mode is audio, but doesn't the data part in pregap have its own track number in this case?
Any news about CD-i Ready format support? People ask me about it sometimes, the last person was iR0b0t
DIC needs to read the audiotrack + pregap with data starting from LBA 0, then to descramble data sectors (I think the data track in the pregap has its own track number somehow, so it's not really correct to leave all the data sectors as scrambled).
Nope, only mods and admins. iR0b0t could probably do it via some SQL selects, though.
http://forum.redump.org/post/19495/#p19495 -- yes, just nobody cares. I always use the (Demo) tag. The only doubtful case is when the edition presents even on the title screen.
I think you should request a password reset via http://forum.redump.org/request/password/
What happened?
F1ReB4LL wrote:DIC should restart the dumping process when that happens?
Do you want to restart when how many errors are counted?
I think it shouldn't depend on error count. If 3-4 sectors were read, AMSF doesn't match the expected ones and each of them has the same offset, you should probably change the subchannels offset value, reread that section again and continue to read with the new sub offset value upto the end of the disc or until you detect another sub offset change. TruRip and Subdump work the similar way.
https://mega.nz/#!RZkWxACJ!gllef6IbSF3_ … gL5j5TGbqo
https://mega.nz/#!sMFiRaAR!bpSobINe4Co6 … _bgfP_G-js
Sarami, why does it happen? Same drive, same command, lots of suberrors in the first case case (every sector is "fixed" due to sector shift?), 10 times less in the 2nd case. Maybe DIC should restart the dumping process when that happens? Or does it need to eject/insert the tray and swap again for a chance of a better dump?
No. But how will we know? Checking each .sub manually is a hard work.
- added: cue file of GD-ROM image
Out of curiosity, does it check for CATALOG, ISRC, FLAGS, CD-TEXT fields in GD mode? Very unlikely to see them there, but still
SubQ channel errors is detected using crc16 but there are not these in SubP and RtoW.
RtoW area has checksums when it has data there (CD-Text or CD+G), for other cases there's no point, since all the bytes should be the same, if any of the bytes differ - it's an error.
I have noticed a minor bug: if the dirs "dat" or "audio" don't exist, produce an exception when click in the point 3 (Choose dat).
There are other exceptions, like, when you try to run it offline and load the TOSEC dat, it crashes, because it can't load the .dtd file from the url in the dat.
F1ReB4LL wrote:LMS lost connection to Intel(R) MEI driver
I have never seen this error...
I can upload this version and provide the exact command string, if someone wants to test
Just tried to dump TOC & pregap with one of the last year's test versions (15.11.17) and got an immediate black screen & system hang with an error record "LMS lost connection to Intel(R) MEI driver" in the events log. Earlier and later versions work fine. Just to warn you that DIC can be dangerous
And should the Turbo-CD database be split based on which version of the System Card they use?
Not really. Many of the Super System titles have some fancy screens if run on 1.x/2.x cards. Dracula X even has a mini-game there. And you can't run Win32 programs on Win16 at all (there's a Win32s extender for Win 3.x, though, but it's a different story).
Win16, Win32, Win64 sections should be enough, Win95/98 can go to the comments, though, there are titles that require exactly Windows 95 and can't be run on Windows 98 as well as titles that want Windows 98 or newer and can't be run on 95.
OS Tag isn't enough for these. Also, x64 soft requires x64 hardware and it is way different from x86, that's just not correct to put them into the same section.
1. (World) is a replacement for (Japan, Europe, USA), all the other cases of its usage are incorrect. Australian releases usually match the European ones, so it sounds more like (USA, Europe), but, ofc, it should be proven the Australian release matches the European one first.
2. 3DO/PSX Return Fire has Arabic.
Redump Forum → Posts by F1ReB4LL
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.