1

(4 replies, posted in General discussion)

user7 wrote:

They need the subs to properly function, so redump should either add the subs for download or include in the dat.

I'm sure that iR0b0t will get into high gear when reading this post (not)

2

(2 replies, posted in Fixes & additions)

Does the ring really have "Kindrland" ?

3

(2,588 replies, posted in General discussion)

sarami wrote:
Jackal wrote:

but the output dump is 3825798 sectors?

https://www.mediafire.com/file/eq80y20l9cwf48f/file
- fixed: seek position when reading error occurs [xbox only]

Indeed fixed cool

4

(2,588 replies, posted in General discussion)

I dumped with:

dic xgd2swap e nfsu 4 3825924 108976 3719856

but the output dump is 3825798 sectors?

logs attached

I think the bottom line on this is gonna be that we can't verify that the dump is good or bad unless you buy a disc that's already dumped and verify that. It's possible that due to different mastering, the USA disc has more errors.

Here are some places to buy Tropico (Europe):
https://www.medimops.de/tropico-pc-von- … 5AM6R.html (3 EUR shipping to US)
https://www.ebay.com/itm/Tropico-pc-gam … SwWxNYuH-S

Could you post a scan or picture of the disc? I guess I could look for a copy, if it's a different release from the one that's dumped.

It's probably a driver issue. Most drives such as that Optiarc should be able to read single errors with CloneCD.

I think CodeLock is always single errors. If it reads in blocks of 2 or more errors then something is wrong with your drive or drivers or the read mode that is used. The correct error count is most likely 758 for your disc, just like the Europe one. Do you have any other drives that you could try? And no point in retrying sectors. Either the drive reads them or it doesn't. Plextors are unable to read single errors.

9

(2,588 replies, posted in General discussion)

@sarami I tested the xgd2swap command today and it works. The dump matches the 0800 dump from Xbox Backup Creator.

I have some questions though:

D:\dic>dic xgd2swap e prostreet 4 3825924 108976 3719856
AppVersion
        x86, AnsiBuild, 20200711T101216
valid extension was omitted. -> set .bin
CurrentDirectory
        D:\dic
WorkingPath
         Argument: prostreet.bin
         FullPath: D:\dic\prostreet.bin
            Drive: D:
        Directory: \dic\
         Filename: prostreet
        Extension: .bin
StartTime: 2020-07-18T10:24:16+0200
Set the drive speed: 5540KB/sec
Reading DirectoryRecord    3/   3
Creating iso(LBA)  4167012/ 4167012
Hashing: prostreet.iso
EndTime: 2020-07-18T10:37:19+0200

You can see here that I entered 3825924 as size, and the output file has the correct size, but still, the drive reads up to sector 4167012. Is this necessary?

Also, for xgd3swap you would need a swap disc that is 4267015 sectors long. I will see if it's possible to burn a fake TOC, because normal DVD9's (and DVD+R DL) are much smaller.

Try clonecd with a non-plextor drive. It should read single errors and the error sectors are 5 sectors apart, or a multiple of 5 sectors IIRC. That's how you'll know if the dump is correct.

11

(3 replies, posted in Fixes & additions)

Do you have any other disc with audio tracks dumped before where DICUI gives matching checksums?

12

(3 replies, posted in Fixes & additions)

Hi, can you redump again with a plextor drive? We can't trust any other drives.

13

(2,588 replies, posted in General discussion)

Everybody is having problems with the new firmware check, plz remove it!

14

(2,588 replies, posted in General discussion)

sarami wrote:
reentrant wrote:

Can you check check it?

REM LEAD-IN and REM PREGAP are depending on subchannel. I want to check _subReadable.txt (or .sub)

========== TOC ==========
     Audio Track  1, LBA        0 -    19200, Length    19201
     Audio Track  2, LBA    19201 -    38392, Length    19192
     Audio Track  3, LBA    38393 -    68102, Length    29710
      Data Track  4, LBA    68103 -   179233, Length   111131
                                              Total    179234

http://redump.org/disc/69762/

DIC .cue contained 15:08:03 pregap, but it should be 00:02:00 (the dump itself is correct).

04:14:01
04:15:67
04:06:10
02:30:00
00:02:00
----------
15:08:03 is the MSF of Track04, so it's putting this as the PREGAP value instead of calculating the correct one.

15

(2,588 replies, posted in General discussion)

Askavenger wrote:

Using DICUI to dump PC game: Sega Rally Championship.
2 different drives used: PX-755SA (SATA model) and PX-712UF    (USB model)
Same results with both drives, got the following error: 

LBA[271938, 0x42642]: Track[22]: SubV[81]:[0x02] -> [0x00]
LBA[271997, 0x4267d]: Track[22]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
LBA[271997, 0x4267d]: Track[22]: SubFailed to reread because crc16 of subQ is 0

All the output files: https://mega.nz/file/nzgzwKjR#RK0XPadQw … o05AIU4c98

I have tried slower speeds. Also ran it through the Disc Resurfacer and still no change in error.
Any thing that can be done using DIC and different parameters?

16

(13 replies, posted in General discussion)

Do we have anybody who would be able to extract a DPM "signature" from the executable? That way we would be able to get the exact timing ranges that the game is looking for.

17

(1 replies, posted in Fixes & additions)

Thanks, I sent the dumper a message. Is that the only dump in the db with a filesize that doesnt divide properly?

18

(11 replies, posted in General discussion)

Here are all the filenames with - followed by a letter: https://pastebin.com/raw/bq3xtpDN . The vast majority has a capital letter after the -. The only exception seems to be Japanese titles.

19

(11 replies, posted in General discussion)

Tbh I didn't notice it until now, but it used to be A-Spec, which looks better imo... Amarok changed it in 2010, no idea why.

20

(2,588 replies, posted in General discussion)

sarami wrote:

4 discs are "Parallel Track Path", not "Opposite Track Path". I think "LayerZeroSector" number is layerbreak.
e.g.

========== SectorLength ==========
    LayerZeroSector: 1708076 (0x1a102c)
          :
          :
========== SectorLength ==========
    LayerOneSector: 2079572 (0x1fbb54)
    LayerAllSector: 3787648 (0x39cb80)

L0 is 0 - 1708075 (Length is 1708076). L1 is 1708076 - 3787647 (Length is 2079572).

Makes sense, thanks for clarifying

21

(2,588 replies, posted in General discussion)

@sarami, TeamEurope dumped 4 DVD9's but we can't find the correct LayerBreak values in the disc log (logs attached).

If it's supposed to be the "LayerOneSector" number, then 3 of the 4 discs have an odd number. Can this be correct? The new disc form only accepts even numbers.

The last 4 submitted dumps all have even numbers:
http://redump.org/disc/65955/
http://redump.org/disc/65956/
http://redump.org/disc/65957/
http://redump.org/disc/65958/
so I dont know what's wrong.

22

(2,588 replies, posted in General discussion)

We are seeing an influx of dumps that are done with ASUS drives. These drives do not support lead-out overreading. How do you warrant that there are no missing bytes in the last sectors? Does the program prevent dumping such discs?

23

(2,588 replies, posted in General discussion)

If /sf is used, the protection is detected and there are C2 error sectors with invalid sync + msf + mode, then the sync + msf + mode should be generated and the rest replaced with 0x55. The mode should match the rest of the track.

If there is no C2 error on a sector, it should never be modified, also not if /sf is used and a protection is detected.

24

(24 replies, posted in General discussion)

iR0b0t doesnt want yellow dumps in the datfile.

If you change them to yellow, people will discard the dumps and this will hurt preservation. It will not motivate people in any way to buy them and redump them. We're already doing the best we can.

25

(1 replies, posted in Fixes & additions)

I will add these, other moderators leave this alone plz.