1 Reply by ssjkakaroto

(18 replies, posted in General discussion)

Hi reentrant, is this an alternative to DIC?

Go to forum: General discussion

2 Topic by ssjkakaroto

(0 replies, posted in Verifications)

http://redump.org/disc/101361/

Edition: Original
Region: Brazil
Disc serial: PPSA-04610
Barcode: 7 2267413021 9
Disc label ID: 13021DLPORT
ID above barcode: 13021INPORT

LAYER 1(outer ring)
Mastering Code: P5D-A07639901STP<tab>06
Mastering SID Code: IFPI L392

LAYER 2(inner ring)
Mastering Code: P5D-A07639901ST2<tab>05
Mastering SID Code: IFPI L392

Mould SID Code: IFPI 6630

Go to forum: Verifications

3 Reply by ssjkakaroto

(10 replies, posted in General discussion)

Agent47 wrote:

If you are going to dump CDs you should invest in a CD-only plextor. They have the best read rates. For DVDs, there is zero reason to use a plextor, any dvd drive can dump those discs properly. DVD PX models are trash amd the laser is known for wearing out. If you plan on dumping CDs they should not be recommended ever, yet people still preach buying 716 or 760 drives for dumping cds. No, full stop.

DIC does not allow CD-only plextors to dump multisession CDs. A Plextor DVD drive is required.

Go to forum: General discussion

4 Topic by ssjkakaroto

(0 replies, posted in General discussion)

It seems Blazin64 was able to fix NTFS dumping with wudump.

https://github.com/FIX94/wudump/pull/18

He also provided a compiled version within the PR. Can anyone report if it's properly working?

Go to forum: General discussion

5 Reply by ssjkakaroto

(3,534 replies, posted in General discussion)

I think the issue is this part of the code:

    if ((*pExecType == cd && ui64Avail.QuadPart > 3000000000) ||
        (*pExecType == swap && ui64Avail.QuadPart > 3000000000) ||
        (*pExecType == data && ui64Avail.QuadPart > 3000000000) ||
        (*pExecType == audio && ui64Avail.QuadPart > 3000000000) ||
        (*pExecType == gd && ui64Avail.QuadPart > 4000000000) ||
        (*pExecType == dvd && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == xbox && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == xboxswap && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == xgd2swap && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == xgd3swap && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == sacd && ui64Avail.QuadPart > 9000000000) ||
        (*pExecType == bd && ui64Avail.QuadPart > 130000000000)
        ) {
        OutputString("\t => There is enough disk space for dumping\n");

All values are hardcoded instead of being calculated per disk.

Go to forum: General discussion

6 Reply by ssjkakaroto

(24 replies, posted in General discussion)

scsi_wuzzy wrote:

I hope for that reason alone we can get all the kinks worked out with the ASUS / LG drives. They seem to be better readers. That might just be because they're less aged and worn, but I suspect it's also just because they're newer technology.

There's another critical reason to use those drives: they're still being sold!
Finding a Plextor is getting more difficult by the day. The ones you can find on ebay cost a kidney and there's no guarantee they're in good condition. My 760A is useless now (Servo failure with all discs) and both my Premium and 708A are only reliable with slow speeds.

Go to forum: General discussion

7 Reply by ssjkakaroto

(3,534 replies, posted in General discussion)

Can't the scrambled hash be calculated as the disc is being dumped?

Go to forum: General discussion

8 Reply by ssjkakaroto

(4 replies, posted in General discussion)

Thanks fuzzball. Using injector worked.

Go to forum: General discussion

9 Reply by ssjkakaroto

(4 replies, posted in General discussion)

fuzzball wrote:

This is probably a fix for "psxt001z --fix" issue.

How can I fix the dumps that used that option?
Also, where can I read about that issue? A quick search for psxt001z didn't help much.

Go to forum: General discussion

10 Topic by ssjkakaroto

(4 replies, posted in General discussion)

http://redump.org/disc/344/
http://redump.org/disc/345/

Up until 2011 those discs had been dumped by HwitVlf, huygens, iR0b0t, osam and pepsidrinker and were verified.
In January of 2011, the dumper Nakian was added but all hashes changed. In 2019 the dumper superg was added verifying the new hashes.

What happened here? Were the previous dumps faulty for some reason? Or were the dumps by Nakian and superg another revision that were erroneously added to the original dumps?

Go to forum: General discussion

11 Reply by ssjkakaroto

(6 replies, posted in General discussion)

Why would anyone try to crack the hashes of games' images? SHA-1 is even an overkill for the purposes of redump.org, SHA-256 would be absolutely redundant.

Go to forum: General discussion

12 Reply by ssjkakaroto

(9 replies, posted in General discussion)

The emulator BizHawk (https://github.com/TASVideos/BizHawk/releases/) comes with a tool called DiscHawk that also merges bin+cue files into ccd+img. You can try that.

Go to forum: General discussion

13 Reply by ssjkakaroto

(3,534 replies, posted in General discussion)

user7 wrote:

sarami, do you have all the info to add proper multisession dumping / cue info?

We would love to start submitting these discs smile

http://forum.redump.org/topic/20409/dis … ssion-cue/

From what I understand there isn't a consensus on the format, it would be a waste of time for him to implement something that could be changed at any time.

Go to forum: General discussion

14 Reply by ssjkakaroto

(9 replies, posted in General discussion)

There is some discussion about this here: http://forum.redump.org/topic/12334/con … orgformat/

Go to forum: General discussion

15 Reply by ssjkakaroto

(27 replies, posted in General discussion)

Thanks sarami, the test version worked.

It did output the message:

This image was ripped by a drive of 0 offsets

between tracks 3 and 4. Is that correct?

Here's the full output: https://pastebin.com/ni7vpRSc

PS: The correct term at the end should be "Succeeded" not Successed

Go to forum: General discussion

16 Reply by ssjkakaroto

(27 replies, posted in General discussion)

Same issues with the versions from 2012 and 2014.

Maybe the problem is actually with track 4, but Conv2multiBin is not outputting track 3 before it encounters the issue.

Take a look of this output from findcrcs:

E:\findcrcs-0.3-bin-win64>findcrcs "Interstate '76 (World) (Disc 2) (Play CD).img" 29821008 43f89d66
388986906  43f89d66  57396ad442565debbf8844a2034c44c9
453115152  43f89d66  74028f15fe72f8d6127dbdaf3acc087c

The same CRC is found twice inside that file, but only once it has the correct MD5. Maybe Conv2multiBin doesn't know how to deal with this situation.

Go to forum: General discussion

17 Reply by ssjkakaroto

(27 replies, posted in General discussion)

Yes, you can see the dat here: https://pastebin.com/a0sLbVeg

Go to forum: General discussion

18 Reply by ssjkakaroto

(27 replies, posted in General discussion)

Yes, it's going to be updated. I've already talked to Jackal.

The correct hash is from what I posted here.

Go to forum: General discussion

19 Reply by ssjkakaroto

(27 replies, posted in General discussion)

@Sarami for some reason Conv2multibin is failing on track 3 of a dump I made with DIC. Tracks 1 and 2 work ok.

Console log

The .img file is good, the .dat too and I can find the segment using findcrcs 0.3.

E:\findcrcs-0.3-bin-win64>findcrcs -q "Interstate '76 (World) (Disc 2) (Play CD).img" 22482768 dafad881 a6d30b96bc50389c88235f9aa1bf2a86
430632384 dafad881 a6d30b96bc50389c88235f9aa1bf2a86

I tried using the following offsets:
0 0
760 0
760 30
0 -30
-760 0
790 0

Dat file
DIC files

Go to forum: General discussion

20 Reply by ssjkakaroto

(3,534 replies, posted in General discussion)

You should probably take some time to familiarize on how redump.org and DIC work before criticizing.

Go to forum: General discussion

21 Reply by ssjkakaroto

(3,534 replies, posted in General discussion)

Type "DiscImageCreator /?"
Arguments between <> are mandatory and arguments between [] are optional.

The arguments work fine.

Go to forum: General discussion

22 Reply by ssjkakaroto

(3,534 replies, posted in General discussion)

sarami wrote:

Adopted IsoBuster sector.
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
See *_mainInfo.txt

Thanks a lot sarami!

I noticed that if you have a filename with a dot, DIC will truncate it at the dot, for example "Game name (v1.2)" becomes "Game name (v1".
Is there a way to escape characters? I tried using a backslash before the dot but it just created a new directory.

Go to forum: General discussion

23 Reply by ssjkakaroto

(3,534 replies, posted in General discussion)

Thanks for the update sarami.

BTW can you modify the *_volDesc.txt log so that it also has the Primary Volume Descriptor (PVD) in the format that the "New Disc" form requires?

Go to forum: General discussion

24 Reply by ssjkakaroto

(27 replies, posted in General discussion)

@darksabre76: I mounted this disc using gBurner and this was the result

gBurner Virtual DVD-ROM 1.0A (Unknown)
Current Profile: CD-ROM

Disc Information:
Status: Complete
State of Last Session: Complete
Erasable: No
Sessions: 1
Sectors: 152,213
Size: 311,732,224 bytes
Time: 33:51:38 (MM:SS:FF)
Supported Read Speeds: 32x

File System Information:
Sectors: 151,913
Size: 311,117,824 bytes
Time: 33:47:38 (MM:SS:FF)

TOC Information:
Session 1... (LBA: 0 / 00:02:00)
-> Track 01  (Mode 1, LBA: 0 / 00:02:00)
-> LeadOut  (LBA: 152213 / 33:51:38)

Track Information:
Session 1...
-> Track 01 (LTSA: 0, LTS: 152213, LRA: 0)

Here's what it looks like with the CCD mounted with Virtual Clone Drive:

ELBY CLONEDRIVE 1.4 (SCSI)
Current Profile: CD-ROM

Disc Information:
Status: Unknown
State of Last Session: Unknown
Erasable: Unknown
Formatted: Unknown
Sessions: Unknown
Sectors: 297,098
Size: 608,456,704 bytes
Time: 66:03:23 (MM:SS:FF)

TOC Information:
Session 1... (LBA: 0)
-> Track 01  (Mode 1, LBA: 0 - 152362)
-> Track 02  (Audio, 03:13:39, LBA: 152363 - 166876)
-> Track 03  (Audio, 03:07:35, LBA: 166877 - 180936)
-> Track 04  (Audio, 03:05:70, LBA: 180937 - 194881)
-> Track 05  (Audio, 02:58:08, LBA: 194882 - 208239)
-> Track 06  (Audio, 03:04:73, LBA: 208240 - 222112)
-> Track 07  (Audio, 02:55:52, LBA: 222113 - 235289)
-> Track 08  (Audio, 03:08:54, LBA: 235290 - 249443)
-> Track 09  (Audio, 03:09:59, LBA: 249444 - 263677)
-> Track 10  (Audio, 03:07:42, LBA: 263678 - 277744)
-> Track 11  (Audio, 02:52:71, LBA: 277745 - 290715)
-> Track 12  (Audio, 01:25:07, LBA: 290716 - 297097)
-> LeadOut  (LBA: 297098)

Go to forum: General discussion

25 Reply by ssjkakaroto

(27 replies, posted in General discussion)

I have a few games in "redump format" that I'd like to play, but to do that I need to mount the images. Virtual Clone Drive can mount single track .bin files (without a .cue), but multi-track images need to be in .ccd to work with it.

Go to forum: General discussion