Search options (Page 4 of 4)

2020-03-24 16:28:42

Thanks a lot!

2020-03-19 21:53:11

Hey,

Would like to have a wiki write access to improve PSX missing lists.

2020-03-07 15:42:06

sarami wrote:

ok, BW-16D1HT was recognized from Bus Hound. As a result, my drive couldn't get the last sector +3, +4 etc.
But I added reading code until the last sector +10. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
Test plz. I want to see these logs.

I might be a bit out of the loop but recently I started having issues with last data sector on my BW-16D1HT (last 32 bytes have garbage).
Logs: https://www.dropbox.com/s/odkm87xmc34o6 … AD.7z?dl=0
Plextor is dumping fine though.

2020-02-20 23:11:01

Disney Tarzan (Spain) autogenerated verification:

Common Disc Info:
    Title: Disney Tarzan
    Foreign Title (Non-latin): (OPTIONAL)
    System: Sony PlayStation
    Media Type: CD-ROM
    Category: Games
    Region: Spain
    Languages: Klingon (CHANGE THIS)
    Disc Serial: SCES-01519

    Ringcode Information:
        Mastering Code (laser branded/etched): (REQUIRED, IF EXISTS)
        Mastering SID Code: (REQUIRED, IF EXISTS)
        Data-Side Mould SID Code: (REQUIRED, IF EXISTS)
        Label-Side Mould SID Code: (REQUIRED, IF EXISTS)
        Additional Mould: (REQUIRED, IF EXISTS)
        Toolstamp or Mastering Code (engraved/stamped): (REQUIRED, IF EXISTS)
    Barcode: (OPTIONAL)
    EXE/Build Date: 1999-10-06
    Error Count: 1
    Comments: (OPTIONAL)
    Contents: (OPTIONAL)

Version and Editions:
    Version: (REQUIRED, IF EXISTS)
    Edition/Release: Original (VERIFY THIS)

EDC:
    EDC: No

Extras:
    Primary Volume Descriptor (PVD):

0320 : 20 20 20 20 20 20 20 20  20 20 20 20 20 31 39 39                199
0330 : 39 31 30 30 36 31 37 30  38 33 31 38 36 00 30 30   9100617083186.00
0340 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 00 30   00000000000000.0
0350 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 00   000000000000000.
0360 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30   0000000000000000
0370 : 00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

Copy Protection:
    Anti-modchip: Yes
SCES_015.19 @ 0x3ac88: EN
SCES_015.19 @ 0x3acdc: JP

    LibCrypt: Yes
14485    03:13:10    41 01 01 03 13 10 00 03 53 10 50 ec    SEC    8001 068d
14490    03:13:15    41 01 01 43 11 15 00 01 13 15 23 1e    MIN    8001 338d
14579    03:14:29    41 01 01 03 12 09 00 03 14 2d 04 73    FRM    8001 c831
14584    03:14:34    41 01 01 03 1a 34 00 03 04 34 e2 cf    SEC    8001 8e30
14899    03:18:49    41 01 01 03 1e 49 00 03 08 49 32 c5    SEC    8001 8e30
14904    03:18:54    41 01 01 01 16 54 00 43 18 54 d4 79    MIN    8001 fd4f
15056    03:20:56    41 01 01 03 18 57 00 03 20 d6 bc 27    FRM    8001 bbd8
15061    03:20:61    41 01 01 03 38 61 00 03 24 61 91 a9    SEC    8001 79cd
15312    03:24:12    41 01 01 03 02 12 00 03 20 12 49 43    SEC    8001 79cd
15317    03:24:17    41 01 01 03 22 07 00 03 24 1f 3a b1    FRM    8001 0553
15919    03:32:19    41 01 01 03 30 59 00 03 32 1b 2c c6    FRM    8001 b12b
15924    03:32:24    41 01 01 03 20 24 00 03 3a 24 e6 ac    SEC    8001 132c
16101    03:34:51    41 01 01 01 32 51 00 43 34 51 d7 a9    MIN    8001 fd4f
16106    03:34:56    41 01 01 03 33 56 00 03 b4 56 c0 9a    SEC    8001 de39
16167    03:35:42    41 01 01 03 32 42 00 03 b5 42 69 e2    SEC    8001 de39
16172    03:35:47    41 01 01 03 33 07 00 03 35 45 1a 10    FRM    8001 b12b
42432    09:25:57    41 01 01 09 23 53 00 09 25 77 21 03    FRM    8001 2d65
42437    09:25:62    41 01 01 0b 23 62 00 49 25 62 68 4c    MIN    8001 fd4f
42580    09:27:55    41 01 01 0d 25 55 00 29 27 55 ae 41    MIN    8001 c701
42585    09:27:60    41 01 01 09 25 61 00 09 27 e0 e7 0e    FRM    8001 bbd8
42813    09:30:63    41 01 01 0b 28 63 00 49 30 63 ed 18    MIN    8001 fd4f
42818    09:30:68    41 01 01 09 29 68 00 09 b0 68 b0 8c    SEC    8001 de39
43012    09:33:37    41 01 01 29 31 37 00 0d 33 37 6c 68    MIN    8001 3237
43017    09:33:42    41 01 01 09 31 4a 00 09 33 52 7c 8b    FRM    8001 901d
43354    09:38:04    41 01 01 01 36 04 00 19 38 04 9c df    MIN    8001 50cf
43359    09:38:09    41 01 01 09 36 0b 00 09 38 49 6c 08    FRM    8001 8c46
43963    09:46:13    41 01 01 09 44 1b 00 09 46 03 78 0d    FRM    8001 901d
43968    09:46:18    41 01 01 09 46 18 00 09 06 18 25 99    SEC    8001 068d
44159    09:48:59    41 01 01 09 44 59 00 09 08 59 6e 0a    SEC    8001 068d
44164    09:48:64    41 01 01 49 46 64 00 0b 48 64 a4 60    MIN    8001 338d
44312    09:50:62    41 01 01 09 08 62 00 09 52 62 03 5a    SEC    8001 8c73
44317    09:50:67    41 01 01 19 48 67 00 01 50 67 70 a8    MIN    8001 1edb

Tracks and Write Offsets:
    DAT:

<rom name="Disney Tarzan (Spain) (Track 1).bin" size="485916144" crc="b44f6cb7" md5="c9fe6e4620e0dfc2b303505985aba18f" sha1="b478cb578f04bed72809f3498e84997387779777" />
<rom name="Disney Tarzan (Spain) (Track 2).bin" size="32104800" crc="9b94ea54" md5="65aea234c174ee35fb574d981fe3fc4f" sha1="bd1fde88c2b79e3cf8821c969373460d51f3155a" />

    Cuesheet:

FILE "Disney Tarzan (Spain) (Track 1).bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 01 00:00:00
FILE "Disney Tarzan (Spain) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00

    Write Offset: -647

2020-02-20 17:11:09

GitHub: https://github.com/superg/redump_info
Download: https://github.com/superg/redump_info/r … 0505pre.7z (Windows 64-bit release binaries)

Basically working on my PSX dumps and verification submissions I realized that I spend too much time on routine things like running psxt001z and edccchk, libcrypt mumbo jumbo, double check IsoBuster date, exe names and so on, if you dump PSX you know what I am talking about. So some time ago I started writing a batch tool which will simplify as much as it can to make my life easier. At this point I've been using it for a few weeks and I can say that the basic functionality is there and all is left is to make the command line more user friendly before it can be used by a wider audience.

So what it is and how that works:
Let's say you dumped a lot of PSX discs using DIC and now you have to come up with the submission information for every dump. If you used DICUI you have !submissionInfo.txt file you have to fill and that will be used to submit a new disc or a verification. Or you can just run the tool in the directory with your dumps (or one dump, doesn't matter), it recursively scans all the dumps and creates !submissionInfo_<GameName>.txt per game with all the information by analyzing the image files and getting as much information from redump DAT file. The only things that aren't filled are barcode and ring codes. It doesn't depend on DICUI at all and it's detached from DIC output as much as possible (*_disc.txt file is needed to get write offset and *.sub is needed for PAL libcrypt games). In fact it will generate a submission info file using just *.cue and *.bin file set.

Features:
1. redump DAT lookup, useful for verifications or just to identify some random dump, will fetch maximum information it can from the DAT
2. extract exe filename / serial / local date from SYSTEM.CNF, that is performed on the image file by traversing ISO9660 filesystem, it will not hang like psxt001z for the games where exe is named differently than retail game. No IsoBuster is needed as the date is coming directly from ISO directory record.
3. errors count calculation, that includes subheader warnings count checked by edccchk. Simply you don't have to run edccchk as you will get the final number to enter into redump
4. EDC is always determined properly, no hex viewing and psxt001z is needed.
5. Anti-modchip string search is performed on ISO9660 file level, that saves a lot of time because you don't need to dump with DIC "/am" option which saves one DIC full pass. Also because it's performed on a file level it's able to find more comparing to DIC - currently DIC is unable to find strings across sector boundary so we should have more anti-modchip games in redump than we currently have (I already found some)
6. libcrypt is detected by analyzing *.sub file, the implementation is so much simpler then psxt001z. Output format is as close to redump as I could do, SBI file is generated as well (all SubQ's with incorrect CRC).
7. PVD, DAT info and other stuff is done exactly like DICUI, I calculate all the checksums myself and it doesn't depend on DIC

All this is really a bigger framework than just this tool, I can mass process a lot of roms and get some statistics, like exe filenames, anti-mod games etc, anything I need. I will make the source available as soon as I clean up the things and figure out command line interface. If anybody wants to try it now, let me know and I can send the binary.

Basic usage:
redump_info submission --dat-file <path to redump DAT file> <path to process>

This is work in progress, I will add some proper examples a bit later.

2020-01-29 22:26:24

sarami wrote:

Thanks, uploaded test version. http://www.mediafire.com/file/eq80y20l9 … st.7z/file

I've just dumped "Aitakute... - Your Smiles in My Heart - Oroshitate no Diary - Introduction Disc (Japan) (Track 1).bin" with the last test version and it went through reading directory records just fine, thanks!

2020-01-28 18:22:07

sarami wrote:

superg wrote:
I didn't dump the other stuff
Then, you can upload only the error directory record sector by using IsoBuster or your tool.

Here are the sector dumps of corrupted directory entries. Just 1 sector dump per game.
https://www.dropbox.com/s/gzd59ao7d2tl0 … ds.7z?dl=0

2020-01-27 15:06:55

sarami wrote:

I got tokimemo rev4 and confirmed a corrupt directory record in LBA 14515. Also, can you upload all logs of these discs you reported except for tokimemo rev4.

All Star Racing 2 (Europe): https://www.dropbox.com/s/r2secinhnagzg … 29.7z?dl=0
I didn't dump the other stuff but I wrote a tool which detects invalid directory entries in the image file so the list came from it. I also checked it with IsoBuster and it's reporting errors for all these files.

2020-01-25 16:09:08

sarami wrote:

Can you upload LBA 16 of these discs?

Here you go:
https://www.dropbox.com/s/bhvp3xudv66qg8i/lba16.7z?dl=0

sarami wrote:

Does it still need? I added that If the valid extension was omitted, ".bin" is set to path automatically in the latest test version.

Not neccessarily, if it all works and you think it's good enough that's totally fine. I just don't like leaving things halfway done so I fixed it in splitPath.

2020-01-24 23:24:12

Totally unrelated thing to dots in the path .

Some PSX discs have corrupted directory entries and that prevents DIC from proceeding further to the dump.
It just hangs on "Reading DirectoryRecord". I recently got "All Star Racing 2 (Europe)" disc and that was problematic to dump.
Based on my findings here (I wrote a tool) here is the list of PSX titles which have corrupted directory entries:

Aitakute... - Your Smiles in My Heart (Japan) (Disc 1) (Track 1).bin
Aitakute... - Your Smiles in My Heart (Japan) (Disc 2) (Track 1).bin
Aitakute... - Your Smiles in My Heart (Japan) (Disc 3) (Track 1).bin
Aitakute... - Your Smiles in My Heart (Japan) (Disc 4) (Track 1).bin
Aitakute... - Your Smiles in My Heart - Oroshitate no Diary - Introduction Disc (Japan) (Track 1).bin
All Star Racing 2 (Europe) (Track 1).bin
All Star Racing 2 (USA) (Track 1).bin
Formula GP (Europe) (Track 1).bin
MLB 2005 (USA).bin
Strike Force Hydra (Europe) (Track 1).bin
Tokimeki Memorial - Forever with You (Japan) (PlayStation the Best) (Track 1).bin
Tokimeki Memorial - Forever with You (Japan) (Rev 2) (Track 1).bin
Tokimeki Memorial - Forever with You (Japan) (Rev 4) (Track 1).bin
Truck Racing (Europe) (Track 1).bin

A tricky but IMO a good way to validate directory entry is to compare little endian offset and data_length to it's big endian counterpart.

// iso9660 definitions
struct uint64_lsb_msb
{
    uint32_t lsb;
    uint32_t msb;
};
struct DirectoryRecord
{
    uint8_t length;
    uint8_t xa_length;
    uint64_lsb_msb offset;
    uint64_lsb_msb data_length;
    struct RecordingDateTime
    {
        uint8_t year;
        uint8_t month;
        uint8_t day;
        uint8_t hour;
        uint8_t minute;
        uint8_t second;
        uint8_t gmt_offset;
    } recording_date_time;
    uint8_t file_flags;
    uint8_t file_unit_size;
    uint8_t interleave_gap_size;
    uint32_t volume_sequence_number;
    uint8_t file_identifier_length;
};

// check
DirectoryRecord &dr = *(iso9660::DirectoryRecord *)&buffer[i];
if(dr.offset.lsb != endian_swap(dr.offset.msb) || dr.data_length.lsb != endian_swap(dr.data_length.msb))
    // invalid record, skip the sector
    ;

How I did it in your codebase execScsiCmdforFileSystem.cpp snippet:

BOOL DirectoryRecordValid(
    LPBYTE lpDirRec
) {
    // check if stored LSB data is the same as MSB data
    return lpDirRec[ 2] == lpDirRec[ 9] && lpDirRec[ 3] == lpDirRec[ 8] && lpDirRec[ 4] == lpDirRec[ 7] && lpDirRec[ 5] == lpDirRec[ 6] && // offset
           lpDirRec[10] == lpDirRec[17] && lpDirRec[11] == lpDirRec[16] && lpDirRec[12] == lpDirRec[15] && lpDirRec[13] == lpDirRec[14];   // data length
}

BOOL ReadDirectoryRecordDetail(
    PEXEC_TYPE pExecType,
    PEXT_ARG pExtArg,
    PDEVICE pDevice,
    PDISC pDisc,
    LPBYTE pCdb,
    INT nLBA,
    LPBYTE lpBuf,
    LPBYTE bufDec,
    BYTE byTransferLen,
    INT nDirPosNum,
    UINT uiLogicalBlkCoef,
    INT nOffset,
    PDIRECTORY_RECORD pDirRec
) {
    if (!ExecReadDisc(pExecType, pExtArg, pDevice, pDisc
        , pCdb, nLBA + nOffset, lpBuf, bufDec, byTransferLen, _T(__FUNCTION__), __LINE__)) {
        return FALSE;
    }
    BYTE byRoop = byTransferLen;
    if (*pExecType == gd) {
        byRoop = (BYTE)(byRoop - 1);
    }
    for (BYTE i = 0; i < byRoop; i++) {
        OutputCDMain(fileMainInfo, lpBuf + DISC_RAW_READ_SIZE * i, nLBA + i, DISC_RAW_READ_SIZE);
    }

    UINT uiOfs = 0;
    for (INT nSectorNum = 0; nSectorNum < byRoop;) {
        if (*(lpBuf + uiOfs) == 0) {
            break;
        }
        OutputVolDescLogA(
            OUTPUT_DHYPHEN_PLUS_STR_WITH_LBA_F(Directory Record), nLBA + nSectorNum, nLBA + nSectorNum);
        for (;;) {
            CHAR szCurDirName[MAX_FNAME_FOR_VOLUME] = {};
            LPBYTE lpDirRec = lpBuf + uiOfs;
            if (lpDirRec[0] >= MIN_LEN_DR) {
                if (!DirectoryRecordValid(lpDirRec) || (lpDirRec[0] == MIN_LEN_DR && uiOfs > 0 && uiOfs % DISC_RAW_READ_SIZE == 0)) {
                    // SimCity 3000 (USA)
                    OutputVolDescLogA(
                        "Direcory record size of the %d sector maybe incorrect. Skip the reading of this sector\n", nLBA);
                    nSectorNum++;
                    break;
                }

I didn't want to mix it in with the dot fixes before you approve the pull request so here it is if you think it's useful.

2020-01-22 23:28:59

sarami wrote:

>superg
This has been written to KnownIssue.txt as "Extension problem" since several years ago.
If you want to escape this problem without new coding, you should specify the extension.

sarami, I modified my splitPath implementation so it behaves exactly like _tsplitpath except the case where path has multiple dots: last dot is used as an extension start (in contrary to _tsplitpath where the first dot is used as an extension start).
I tested the following cases:
1. Absolute path with filename, extension and additional dots in the path and filename:
command line: 'cd G "E:\temp\ISO\TEST Vol. 9 (USA)\TEST Vol. 9 (USA).bin" 20 /c2 20 /nl'
DIC debug output:

CurrentDirectory
        E:\temp
WorkingPath
         Argument: E:\temp\ISO\TEST Vol. 9 (USA)\TEST Vol. 9 (USA).bin
         FullPath: E:\temp\ISO\TEST Vol. 9 (USA)\TEST Vol. 9 (USA).bin
            Drive: E:
        Directory: \temp\ISO\TEST Vol. 9 (USA)\
         Filename: TEST Vol. 9 (USA)
        Extension: .bin

result: "e:\temp\ISO\TEST Vol. 9 (USA)\TEST Vol. 9 (USA)*.*"

2. Relative path with filename, extension and additional dots in the path and filename: (that's how DICUI is passing the command line)
command line: 'cd G "ISO\TEST Vol. 9 (USA)\TEST Vol. 9 (USA).bin" 20 /c2 20 /nl'
DIC debug output:

CurrentDirectory
        E:\temp
WorkingPath
         Argument: ISO\TEST Vol. 9 (USA)\TEST Vol. 9 (USA).bin
         FullPath: E:\temp\ISO\TEST Vol. 9 (USA)\TEST Vol. 9 (USA).bin
            Drive: E:
        Directory: \temp\ISO\TEST Vol. 9 (USA)\
         Filename: TEST Vol. 9 (USA)
        Extension: .bin

result: "e:\temp\ISO\TEST Vol. 9 (USA)\TEST Vol. 9 (USA)*.*"

3.Filename without extension:
command line: 'cd G "TEST Vol_ 9 (USA)" 20 /c2 20 /nl'
DIC debug output:

CurrentDirectory
        E:\temp
WorkingPath
         Argument: TEST Vol_ 9 (USA)
         FullPath: E:\temp\TEST Vol_ 9 (USA)
            Drive: E:
        Directory: \temp\
         Filename: TEST Vol_ 9 (USA)
        Extension:

result: "e:\temp\TEST Vol_ 9 (USA)*.*"

4.Filename with extension:
command line: 'cd G "TEST Vol_ 9 (USA).bin" 20 /c2 20 /nl'
DIC debug output:

CurrentDirectory
        E:\temp
WorkingPath
         Argument: TEST Vol_ 9 (USA).bin
         FullPath: E:\temp\TEST Vol_ 9 (USA).bin
            Drive: E:
        Directory: \temp\
         Filename: TEST Vol_ 9 (USA)
        Extension: .bin

result: "e:\temp\TEST Vol_ 9 (USA)*.*"

5.Filename with extension and additional dot in the name:
command line: 'cd G "TEST Vol. 9 (USA).bin" 20 /c2 20 /nl'
DIC debug output:

CurrentDirectory
        E:\temp
WorkingPath
         Argument: TEST Vol. 9 (USA).bin
         FullPath: E:\temp\TEST Vol. 9 (USA).bin
            Drive: E:
        Directory: \temp\
         Filename: TEST Vol. 9 (USA)
        Extension: .bin

result: "e:\temp\TEST Vol. 9 (USA)*.*"

6.usurper previously failing command line:
command line: 'cd G Track 20 /c2 20 /nl'
DIC debug output:

CurrentDirectory
        E:\temp
WorkingPath
         Argument: Track
         FullPath: E:\temp\Track
            Drive: E:
        Directory: \temp\
         Filename: Track
        Extension:

result: "e:\temp\Track*.*"

In my first implementation I was unaware that filename can be specified without the extension and that's legit. Let me know if you think I'm missing some additional usecases.

2020-01-22 13:53:58

sarami wrote:

usurper wrote:
What am I doing wrong? Latest DIC version doesnt dump Disc in a certain dir when running from it. Instead it put its files one level up when running usual command: DiscImageCreator.exe cd e Track 2 /c2 10 /ns /sf from dir: D:\REDUMP\LEGO Football Mania
Files goto: D:\REDUMP and named LEGO Football ManiaTrack*.*
EDIT: ./Track in that command line does the trick for now, but that doesnt seem to be normal.
Uploaded
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
https://github.com/saramibreak/DiscImageCreator/pull/33
His code is buggy now. I reverted the code until he fixes it.

I will look into it. Too bad I've seen this message only today .

Search options (Page 4 of 4)

Posts found: 76 to 87 of 87

76 Reply by superg 2020-03-24 16:28:42

Re: [DONE] Wiki account (3 replies, posted in Guests & account requests)

77 Topic by superg 2020-03-19 21:53:11

Topic: [DONE] Wiki account (3 replies, posted in Guests & account requests)

78 Reply by superg 2020-03-07 15:42:06

Re: DiscImageCreator (3,531 replies, posted in General discussion)

79 Reply by superg 2020-02-20 23:11:01

Re: redump_info tool WIP (10 replies, posted in General discussion)

80 Topic by superg 2020-02-20 17:11:09

Topic: redump_info tool WIP (10 replies, posted in General discussion)

81 Reply by superg 2020-01-29 22:26:24

Re: DiscImageCreator (3,531 replies, posted in General discussion)

82 Reply by superg 2020-01-28 18:22:07

Re: DiscImageCreator (3,531 replies, posted in General discussion)

83 Reply by superg 2020-01-27 15:06:55

Re: DiscImageCreator (3,531 replies, posted in General discussion)

84 Reply by superg 2020-01-25 16:09:08

Re: DiscImageCreator (3,531 replies, posted in General discussion)

85 Reply by superg 2020-01-24 23:24:12

Re: DiscImageCreator (3,531 replies, posted in General discussion)

86 Reply by superg 2020-01-22 23:28:59

Re: DiscImageCreator (3,531 replies, posted in General discussion)

87 Reply by superg 2020-01-22 13:53:58

Re: DiscImageCreator (3,531 replies, posted in General discussion)

Posts found: 76 to 87 of 87