Good idea, thanks for your suggestion.
https://www.sendspace.com/file/pigse9 -- Pier Solar HD for Dreamcast log, DIC has serious problems with the subs decoding (the game itself has a subs-based protection).
some updated.
F1ReB4LL wrote:
https://www.sendspace.com/file/pigse9 -- Pier Solar HD for Dreamcast log, DIC has serious problems with the subs decoding (the game itself has a subs-based protection).
I haven't fixed yet because I don't know what a subs-base protection this is... (not libcrypt, not securom?)
EAN sectors are used for protection. And DIC was unable to detect/decode the tracks layout properly, check the TOC.
DIC was unable to detect/decode the tracks layout properly
============================ TOC on SCSIOP_READ_TOC ===========================
Audio Track 1, LBA 0- 12293, Length 12294
Data Track 2, LBA 12294- 327652, Length 315359
Total 327653Is this improper?
======================== Check MCN, ISRC for track[01] ========================
Session 1, 1st MCN sector is 75, MCN sector exists per 90
Session 1, 1st ISRC sector is 30, ISRC sector exists per 90
======================== Check MCN, ISRC for track[02] ========================
Session 1, 1st MCN sector is 12335, MCN sector exists per 90
Session 1, 1st ISRC sector is -2, ISRC sector exists per 2
======================== Check MCN, ISRC for track[01] ========================
Session 2, 1st MCN sector is 75, MCN sector exists per 90
Session 2, 1st ISRC sector is 30, ISRC sector exists per 90
======================== Check MCN, ISRC for track[02] ========================
Session 2, 1st MCN sector is 12335, MCN sector exists per 90
Session 2, 1st ISRC sector is -2, ISRC sector exists per 2This log is already fixed.
LBA[000030, 0x0001e], Audio, 2ch, Copy NG, Pre-emphasis No, ItnStdRecordingCode [ ], AMSF[ :30], RtoW[0, 0, 0, 0]
binary data
=> 03 96 38 22 0c 96 30 16 30
LBA[000075, 0x0004b], Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [0731453345126], AMSF[ :00], RtoW[0, 0, 0, 0]
binary data
=> 02 07 31 45 33 45 12 60It seems that the ISRC isn't proper. Is this value protected? What is the correct ISRC?
It seems that the MCN is proper. Is this value also protected?
1) Track 1 + Track 2 total size is 770 639 856 bytes, that's OK. But why img and scr files for the same dump are 743 827 056 bytes each? I've thought DIC dumps to scr first, then descrambles to img, then splits the tracks, no? If the scr and img dumps are missing 26 812 800 bytes, how could these missing bytes appear in the split tracks? Same for the sub file, after 00 13 68 (last sector of the 1st track before lead-out) it goes 02 45 69 (1st sector of the 2nd session), the lead-out is omitted from combined images, that's very wrong, IMO. At least the .scr dump should be as raw as possible in this case and contain all the sectors.
I don't have any multisession disc nearby, but if you dump a multisession disc with IsoBuster, does it include the 1st session lead-out sectors into the image or not?
2) Cue says "TRACK 01 AUDIO", why is its contents descrambled, then?
3) Since it's a multisession image, where's "REM LEADOUT 00:13:69" in the cue? where's "REM SESSION 02"?
782 2016-01-22 17:26:13 (edited by sarami 2016-01-25 18:01:57)
I've thought DIC dumps to scr first, then descrambles to img, then splits the tracks, no?
Yes. I code it like that.
If the scr and img dumps are missing 26 812 800 bytes, how could these missing bytes appear in the split tracks? Same for the sub file, after 00 13 68 (last sector of the 1st track before lead-out) it goes 02 45 69 (1st sector of the 2nd session), the lead-out is omitted from combined images, that's very wrong, IMO. At least the .scr dump should be as raw as possible in this case and contain all the sectors.
The size of the lead-out sector of the 1st session + the size of the lead-in sector of the 2nd session = 11,400 sector (=26 812 800 bytes)
I realize that the lead-out and lead-in sector is important for raw dumping. But these sector can't be dumped all (=be dumped only partly).
In case of my plextor drive, this can dump the lead-out only the 100 sector and the lead-in about the 2000 - 3000 sector (readable size of the lead-in is different every time).
I don't have any multisession disc nearby, but if you dump a multisession disc with IsoBuster, does it include the 1st session lead-out sectors into the image or not?
I have a multi-session disc, but Isobuster can't dump the lead-in/out sector of a multi-session disc (also single-session disc).
2) Cue says "TRACK 01 AUDIO", why is its contents descrambled, then?
Really? but I don't know because the bin data doesn't exist. It seems that TOC-PREGAP.bin is all 'data' sector.
3) Since it's a multisession image, where's "REM LEADOUT 00:13:69" in the cue? where's "REM SESSION 02"?
http://forum.redump.org/post/42342/#p42342
I know this and already write in Todo.txt
sarami wrote:
The size of the lead-out sector of the 1st session + the size of the lead-in sector of the 2nd session = 11,400 sector (=26 812 800 bytes)
I realize that the lead-out and lead-in sector is important for raw dumping. But these sector can't be dumped all (=be dumped only partly).
In case of my plextor drive, this can dump the lead-out only the 100 sector and the lead-in about the 2000 - 3000 sector (readable size of the lead-in is different every time).
I've thought the lead-out limit only applies to the last session? If you look into the subdump dump log, it dumped the whole lead-out fine, failed in the beginning of the 2nd session. And the DIC splitted tracks have all the sectors, 1st track is 28 915 488 bytes, 2nd track is 741 724 368 bytes, 770 639 856 bytes total, while img and scm files are 743 827 056 bytes each, why is the split tracks dump complete and both single file dumps (and the sub) are not?
F1ReB4LL wrote:
I've thought the lead-out limit only applies to the last session? If you look into the subdump dump log, it dumped the whole lead-out fine, failed in the beginning of the 2nd session.
I confirmed that it can get the lead-out.
LBA[043931, 0x0ab9b], Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[01], RMSF[04:19:36], AMSF[09:47:56], RtoW[0, 0, 0, 0]
LBA[043932, 0x0ab9c], Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[01], RMSF[04:19:37], AMSF[09:47:57], RtoW[0, 0, 0, 0]
LBA[043933, 0x0ab9d], Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[01], RMSF[04:19:38], AMSF[09:47:58], RtoW[0, 0, 0, 0]
LBA[043934, 0x0ab9e], Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[01], RMSF[04:19:39], AMSF[09:47:59], RtoW[0, 0, 0, 0]
LBA[043935, 0x0ab9f], Audio, 2ch, Copy NG, Pre-emphasis No, LeadOut , Idx[01], RMSF[00:00:00], AMSF[09:47:60], RtoW[0, 0, 0, 0]
LBA[043936, 0x0aba0], Audio, 2ch, Copy NG, Pre-emphasis No, LeadOut , Idx[01], RMSF[00:00:01], AMSF[09:47:61], RtoW[0, 0, 0, 0]
LBA[043937, 0x0aba1], Audio, 2ch, Copy NG, Pre-emphasis No, LeadOut , Idx[01], RMSF[00:00:02], AMSF[09:47:62], RtoW[0, 0, 0, 0]
LBA[043938, 0x0aba2], Audio, 2ch, Copy NG, Pre-emphasis No, LeadOut , Idx[01], RMSF[00:00:03], AMSF[09:47:63], RtoW[0, 0, 0, 0]
LBA[043939, 0x0aba3], Audio, 2ch, Copy NG, Pre-emphasis No, LeadOut , Idx[01], RMSF[00:00:04], AMSF[09:47:64], RtoW[0, 0, 0, 0]
LBA[043940, 0x0aba4], Audio, 2ch, Copy NG, Pre-emphasis No, LeadOut , Idx[01], RMSF[00:00:05], AMSF[09:47:65], RtoW[0, 0, 0, 0]
:
: lead-out is 6750 sector
:
LBA[050682, 0x0c5fa], Audio, 2ch, Copy NG, Pre-emphasis No, LeadOut , Idx[01], RMSF[01:29:72], AMSF[11:17:57], RtoW[0, 0, 0, 0]
LBA[050683, 0x0c5fb], Audio, 2ch, Copy NG, Pre-emphasis No, LeadOut , Idx[01], RMSF[01:29:73], AMSF[11:17:58], RtoW[0, 0, 0, 0]
LBA[050684, 0x0c5fc], Audio, 2ch, Copy NG, Pre-emphasis No, LeadOut , Idx[01], RMSF[01:29:74], AMSF[11:17:59], RtoW[0, 0, 0, 0]
LBA[050685, 0x0c5fd], Audio, 2ch, Copy NG, Pre-emphasis No, Point[a0], AMSF[11:17:60], TrackNumOf1stTrack[03], ProgramAreaFormat[00], RtoW[0, 0, 0, 0]
LBA[050686, 0x0c5fe], Audio, 2ch, Copy NG, Pre-emphasis No, Point[a0], AMSF[11:17:61], TrackNumOf1stTrack[03], ProgramAreaFormat[00], RtoW[0, 0, 0, 0]
LBA[050687, 0x0c5ff], Audio, 2ch, Copy NG, Pre-emphasis No, Point[a0], AMSF[11:17:62], TrackNumOf1stTrack[03], ProgramAreaFormat[00], RtoW[0, 0, 0, 0]
LBA[050688, 0x0c600], Data, Copy NG, Point[a1], AMSF[11:17:63], TrackNumOfLastTrack[03], RtoW[0, 0, 0, 0]
LBA[050689, 0x0c601], Data, Copy NG, Point[a1], AMSF[11:17:64], TrackNumOfLastTrack[03], RtoW[0, 0, 0, 0]
LBA[050690, 0x0c602], Data, Copy NG, Point[a1], AMSF[11:17:65], TrackNumOfLastTrack[03], RtoW[0, 0, 0, 0]
LBA[050690, 0x0c602], Data, Copy NG, Point[a1], AMSF[11:17:65], TrackNumOfLastTrack[03], RtoW[0, 0, 0, 0]
LBA[050690, 0x0c602], Data, Copy NG, Point[a1], AMSF[11:17:65], TrackNumOfLastTrack[03], RtoW[0, 0, 0, 0]
LBA[050690, 0x0c602], Data, Copy NG, Point[a1], AMSF[11:17:65], TrackNumOfLastTrack[03], RtoW[0, 0, 0, 0]
LBA[050690, 0x0c602], Data, Copy NG, Point[a1], AMSF[11:17:65], TrackNumOfLastTrack[03], RtoW[0, 0, 0, 0]
LBA[050690, 0x0c602], Data, Copy NG, Point[a1], AMSF[11:17:65], TrackNumOfLastTrack[03], RtoW[0, 0, 0, 0]
:
: the lead-in is 4650 sector
:And I understood that the lead-out is 6750 sector, the lead-in can't get correctly (repeats the same data) in my PX-5224.
In addtion, it takes time very much to read the lead-in (1 sector per 1min)
F1ReB4LL wrote:
1st track is 28 915 488 bytes, 2nd track is 741 724 368 bytes, 770 639 856 bytes total
2nd track is 741 724 368 - 26 812 800 = 714 911 568. Because the lead-out of the 1st session and the lead-in of the 2nd session doesn't read.
pshd_mainInfo.txt
Skip from Leadout of Session 1 [894, 0x37e] to Leadin of Session 2 [12293, 0x3005]uploaded exe http://www.mediafire.com/download/eq80y … Creator.7z
-added: /raw option for cd command (highly experimental, buggy)
=> For the multi-session at present. I don't test it enough. Probably can get the lead-out of the 1st session but can't get the lead-in of the 2nd session.
-deleted: /i option for valis II etc. (specific ISRC)
=> Because check by the crc16.
[L:1914] Internal error. Failed to analyze the subchannel. Track[01]/[56]Probably this haven't been fixed yet.
sarami wrote:
2) Cue says "TRACK 01 AUDIO", why is its contents descrambled, then?
Really? but I don't know because the bin data doesn't exist. It seems that TOC-PREGAP.bin is all 'data' sector.
https://www.sendspace.com/file/j53q0i -- 1st track only, because 2nd track matches t**rip and should be good.
787 2016-01-26 23:23:47 (edited by sarami 2016-01-27 12:10:46)
F1ReB4LL wrote:
sarami wrote:2) Cue says "TRACK 01 AUDIO", why is its contents descrambled, then?
Really? but I don't know because the bin data doesn't exist. It seems that TOC-PREGAP.bin is all 'data' sector.
https://www.sendspace.com/file/j53q0i -- 1st track only, because 2nd track matches t**rip and should be good.
Thanks. Uploaded 20160127
- fixed: dividing the track for multi-session disc which the track 02 is session 2
- fixed: crash using 'audio' command in the disc with ISRC sector
Why not to generate a good ClrMAMEPro-compliant dat with <header></header>, <game name></game>, etc.? Current DIC dats are unusable in ClrMAME unless you add all the missing fields manually.
It's easy to generate <game name=>, <description>.
It's easy to generate <category>, but DIC doesn't know the ripping data is "Games" or "Applications" or others.
Is <header> necessary?
I've created the directory "C:\test", put the remove.exe tool there and created the datfile using Dir2Dat in ClrMAMEPro:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE datafile PUBLIC "-//Logiqx//DTD ROM Management Datafile//EN" "http://www.logiqx.com/Dats/datafile.dtd">
<datafile>
<header>
<name>-insert name-</name>
<description>-insert description-</description>
<category>Standard DatFile</category>
<version>-insert version-</version>
<date>-insert date-</date>
<author>-insert author-</author>
<email>-insert email-</email>
<homepage>-insert homepage-</homepage>
<url>-insert url-</url>
<comment>-insert comment-</comment>
<clrmamepro/>
</header>
<game name="test">
<description>test</description>
<rom name="remove.exe" size="99328" crc="65f5cd29" md5="8d4616abe8a949362b4b69d5417e678f" sha1="96d36b0cfa9240ef4c0502f4ea0d1f682ba277d9"/>
</game>
</datafile>So the ClrMAMEPro puts directory name into "game name" and "description". I think DIC can put the "filename" name there from the commandline (cd <DriveLetter> <Filename> <DriveSpeed(0-72)> [/a (val)]).
coded. plz test.
http://www.mediafire.com/download/eq80y … or_test.7z
- added: read/write xml for the datfile (using xmllite)
sarami wrote:
coded. plz test.
http://www.mediafire.com/download/eq80y … or_test.7z
- added: read/write xml for the datfile (using xmllite)
Sorry for the late report, but it crashes (APPCRASH) when "Creating bin, cue and ccd (Track)". Even when I don't use C2 reporting and simply run it as "DiscImageCreator.exe cd H: dump 4".
mainError.txt file is empty, I don't see anything describing the crash reason.
794 2016-04-02 13:27:33 (edited by usurper 2016-04-02 13:27:53)
Latest test build crashes for me as well. Looks like it crashes before calculating hashes.
Thanks test but it works fine on my pc... I don't know the reason at the present moment.
Test version is using xmllite.dll. if this dll doesn't exist in your pc, please install it.
if it isn't so, I want the detailed info. (e.g. event viewer)
sarami wrote:
Thanks test but it works fine on my pc... I don't know the reason at the present moment.
Test version is using xmllite.dll. if this dll doesn't exist in your pc, please install it.
if it isn't so, I want the detailed info. (e.g. event viewer)
xmllite.dll is installed, event viewer logs look useless to me:
Faulting application name: DiscImageCreator.exe, version: 0.0.0.0, time stamp: 0x56dd9865
Faulting module name: DiscImageCreator.exe, version: 0.0.0.0, time stamp: 0x56dd9865
Exception code: 0xc0000005
Fault offset: 0x00004ef6Faulting process id, Faulting application start time, Report Id are, of course, always different.
I found the crash occured with relative path. fixed it.
sarami wrote:
I found the crash occured with relative path. fixed it.
Works now, but could you fix the text alignment inside the dat?
https://www.sendspace.com/file/9fgguh -- clrmamepro dat vs. dic dat
Do you hope to fix space to tab? I investigated this.
https://msdn.microsoft.com/en-us/librar … s.85).aspx
When this property is set to TRUE, each level of indentation is two spaces.It seems that this is the specification of the xmllite.
Perhaps I may fix it manually when I have time.
I like the ClrMAMEPro layout more 