1 (edited by user7 2018-06-08 22:21:46)

VGPC / Redumper ReignStumble has published 1.0 of his  "DICUI" GUI for DiscImageCreator (by sarami).

Announcement post available here.

You can download the app here.


ALERT: DICUI is looking for code contributors!
The github is here. The app is written in the C# language.

Here's a list of features that are proposed to be added to future revision of DIC GUI:

  • Output a new text file with pertinent information pertaining to the specific console for easy redump.org submission.

  • An incorporation of the separate CLI progress info into a bottom area of the GUI (similar to DVD Decrypter).

  • A "Stop" GUI button to abort dumping.

  • Auto-report maximum read speeds to "Disc Speed" selector (as discussed here).

  • Dreamcast dumping.

All my posts and submission data are released into Public Domain / CC0.

2 (edited by user7 2018-05-14 04:48:18)

1.01 has been added here: https://github.com/reignstumble/DICUI/releases/

Testing for PS4 / XBONE dumping with sg_raw.exe built into the package / dump process.

All my posts and submission data are released into Public Domain / CC0.

Hi!

I tried to use your tool today but it doesn't see my drive for some reason. I'm using a Plextor PX712A connected to a UGREEN USB 3.0 to IDE/SATA then that goes to my PC via USB. Windows sees the drive fine, and I am able to see the disc. What can I provide you with to help troubleshoot?

Thanks,

DICUI development has been booming with darksabre76 adding a ton of updates, fresh off from a major ReignStumble update:

Here are some feature highlights:

  • * edccchk now run on all CD-Roms
    * Discs unsupported by Windows are now recognized
    * Automatic drive speed selection
    * Add ability to stop a dump from the UI
    * Automatic submission information creation

The last bullet in particular is an incredibly helpful feature. It now aggregates all info from the logs into a submission template.

All my posts and submission data are released into Public Domain / CC0.

I have to report two errors:

1. Old Windows XP machine with PX-760A connected to IDE
Program doesn't run at all ("not a valid Win32 executable)
--> Can you please compile a Win XP target as well?

2. New Windows 10 1803 machine with PX-760A connected via Ugreen IDE-USB3 adapter
Drive letter appears when a disc is inserted. Program then crashes when selecting a disc type.
This only happens with ODD connected via USB adapter, it doesn't crash with native SATA drives (I don't have a SATA Plextor, so I can't rip discs properly)

rosewood wrote:

2. New Windows 10 1803 machine with PX-760A connected via Ugreen IDE-USB3 adapter
Drive letter appears when a disc is inserted. Program then crashes when selecting a disc type.
This only happens with ODD connected via USB adapter, it doesn't crash with native SATA drives (I don't have a SATA Plextor, so I can't rip discs properly)

Hello,

I have a similar issue with DICUI.
I'm using Windows 10 Home x64 1803.

I have an IDE PX-716A connected to SATA via this SATA IDE Adapter and Windows reports it as "PLEXTOR DVDR PX-716A"
This setup is working fine with DICUI.

I  also have an USB PX-755UF and Windows reports it as "PLEXTOR DVDR PX-755A USB Device".
I get the same crashing issue as reported by rosewood when selecting a disc type.

Thank you guys for your patience, a major update is due for DICUI very soon, bringing it to 1.07. Lots will be changed under the hood. I hope you will test the new version upon release and report if these problems still exist.

All my posts and submission data are released into Public Domain / CC0.

8 (edited by user7 2018-06-28 02:05:01)

DICUI 1.07 has been released https://github.com/reignstumble/DICUI/releases/tag/1.07

It fixes many quirks/crashes that some of us were experiencing plus offers new features.

  • *Separated system and media type for easier navigation
    *Combined instances of single- and dual-layer discs
    *Removed reliance on sg-raw and psxt001z
    *Added system and disc type to the submission info
    *First attempt at getting current disc type
    *Made the three PSX-specific fields (EDC, Anti-modchip, and LibCrypt) automatically filled in, when possible
    *Many, many, many behind the scenes updates for speed, future features, and stability

Thanks to sarami, ReignStumble, darksabre76, and Jack for your incredible contributions.

All my posts and submission data are released into Public Domain / CC0.

Thanks for the update !
Doesn't crash anymore with my USB PX-755UF.

Thank sarami and DIC for that, not us!

I gave a try with PoPoRoGue (Japan) (v1.0) and PoPoRoGue (Japan) (Yokokuban).
While dumps checksums match, i'm getting different results for this part :

user7 wrote:

*Made the three PSX-specific fields (EDC, Anti-modchip, and LibCrypt) automatically filled in, when possible

PoPoRoGue (Japan) (v1.0) using DICUI 1.07
EDC: Yes
Anti-modchip: No
LibCrypt: No

While you have
EDC: No
Anti-modchip: Yes
LibCrypt: No

PoPoRoGue (Japan) (Yokokuban) using DICUI 1.07
EDC: Yes
Anti-modchip: No
LibCrypt: No

While you have
EDC: No
Anti-modchip: No
LibCrypt: No

12 (edited by sarami 2018-06-28 04:13:48)

Square wrote:

I gave a try with PoPoRoGue (Japan) (v1.0) and PoPoRoGue (Japan) (Yokokuban).
While dumps checksums match, i'm getting different results for this part :

user7 wrote:

*Made the three PSX-specific fields (EDC, Anti-modchip, and LibCrypt) automatically filled in, when possible

PoPoRoGue (Japan) (v1.0) using DICUI 1.07
EDC: Yes
Anti-modchip: No
LibCrypt: No

While you have
EDC: No
Anti-modchip: Yes
LibCrypt: No

There are 3 patterns in Anti-modchip screen.
English: http://bbs.a9vg.com/thread-4478698-1-1.html
Japanese: http://trynet.fc2web.com/psmanual-j.html
Red hand: http://bxk07344.blog.so-net.ne.jp/_page … 2012-09-02

Red hand version is adopted to IQ Final Taikenban and PoPoRoGue. (Only 2? I'm not sure.)

Perhaps DIC can't detect the red hand version yet.

13 (edited by Square 2018-06-29 13:23:55)

Thanks for your input and your work on DIC while i'm at it !
How about the different EDC results ?

Using psxt001z
File: PoPoRoGue (Japan) (Yokokuban).bin
Size (bytes):   119705040 (OK)
Size (sectors): 50895 (OK)
EDC in Form 2 sectors: NO
ID: PROG-E\PPX   <--- Hangs here

Using DICUI 1.07
PoPoRoGue (Japan) (Yokokuban)
EDC: Yes
Anti-modchip: No
LibCrypt: No

<rom name="PoPoRoGue (Japan) (Yokokuban).bin" size="119705040" crc="b7a67488" md5="b6de4492c1e942c41cf32523b704df8b" sha1="803bd2d6225a99ccd58cd113a64a97e69f8616d9" />

Using psxt001z
File: PoPoRoGue (Japan).bin
Size (bytes):   702787008 (OK)
Size (sectors): 298804 (OK)
EDC in Form 2 sectors: NO
ID: SCPS-10050
Date: 1998-10-27
System area: Jap NoEDC

Using DICUI 1.07
PoPoRoGue (Japan)
EDC: Yes
Anti-modchip: No
LibCrypt: No

<rom name="PoPoRoGue (Japan).bin" size="702787008" crc="bbb50ac2" md5="950d12d0cc9d0ecd5d01ea6c96a9b808" sha1="25440784ca1898c1651421d290a2e12b7934dfe8" />

Square wrote:

Thanks for the update !
Doesn't crash anymore with my USB PX-755UF.

I confirm, it also doesn't crash anymore with PX-760A connected via Ugreen IDE-USB3 adapter.

It still doesn't run with Windows XP though...

For the EDC check, the current code sees if there are any missing EDC instances as per the DIC output and then if there are, it says it doesn't have EDC. If this is inaccurate, how many missing instances are needed before saying a disc doesn't have EDC? Is it if the sector count matches the error count? Or is it lower, like 300?

Bump on that EDC question, what's a good identifier from DIC outputs to see if there's EDC or not?

You can basically check only a few sectors or scan the entire data track.
For the second one, if all sectors have EDC bytes set to '00' its a NO EDC.
You can subtract 150 postgap sectors, as they can have EDC bytes set no matter what.

Also, only check MODE2 FORM1 sectors, *corrected*

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Due to *cough* programmer error, we now have an updated check for EDC in a Git branch.

@sarami or @Square: do either of you know how to detect that "red hand" antimod screen? I'd like to see if I can get that working in part of DICUI.

20 (edited by Square 2018-07-22 03:36:58)

I have no idea. sad

All i know is that PoPoRoGue (Japan) (v1.0) (SCPS 10050) uses the Red hand version
https://bxk07344.c.blog.so-net.ne.jp/_images/blog/_c42/bxk07344/m_ePSXe-10-02b0f.png
While PoPoRoGue (Japan) (v1.1) (SCPS 91312 / PSone Books version) use the other one.
http://trynet.fc2web.com/image/keikoku.gif

I verified it on a 1002 equipped with a 1st gen modchip

Maybe someone with the required skills could check and compare both versions to see what has been changed ?

iR0b0t wrote:

because FORM2 sectors have no EDC & ECC.

http://www.multimediadirector.com/help/technology/images/gif/cdsectors.gif

Yeah, that must be correct, i forgot about the EDC bytes in Form 2

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

A new stable build is out: https://github.com/reignstumble/DICUI/releases/tag/1.10

Added many new options for user customization
Added unit testing and an AppVeyor build
Many code refactorings
LOG WINDOW
Separated out protection scan and Unshield ports to new projects
Added "empty drive" support; should help with 3DO and HFS dumping
And much more! See the full Git commit list for more details

Wohoo!! Great work DICUI team smile

All my posts and submission data are released into Public Domain / CC0.

Did you guys fix layerbreak info output? Some people reported wrong layerbreaks, i wonder if they got it from DICUI output or DIC itself by manually copying from a wrong text line.

Edit: an example http://forum.redump.org/topic/18425/
It looks like DICUI was/is taking this information from a wrong text line. In this particular case the correct value is to be find in line 148

LayerZeroSector: 2032592 (0x1f03d0)

If you want to gather it from starting text lines you will have to calculate it:
line 15 - line 13 + 1 = layerbreak value

EndLayerZeroSector: 2229199 (0x2203cf)
-
StartingDataSector:  196608 (0x30000)
+
1
=
2032592

One more question, is the tool named DICUI or DICGUI ?
I see both names appear at some places smile

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

iR0b0t wrote:

Did you guys fix layerbreak info output? Some people reported wrong layerbreaks, i wonder if they got it from DICUI output or DIC itself by manually copying from a wrong text line.

It should be fixed in the newest builds. That was an older issue.

iR0b0t wrote:

One more question, is the tool named DICUI or DICGUI ?
I see both names appear at some places smile

DICUI