Redump Forum

Posted: **Thu Jan 21, 2016 6:19 pm**

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"?

Posted: **Fri Jan 22, 2016 11:26 am**

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"?

/viewtopic.php?p=23246#p23246
I know this and already write in Todo.txt

Posted: **Sun Jan 24, 2016 7:11 pm**

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?

Posted: **Mon Jan 25, 2016 11:42 am**

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.

Code: Select all

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)

Posted: **Mon Jan 25, 2016 7:31 pm**

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

Code: Select all

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.

Code: Select all

[L:1914] Internal error. Failed to analyze the subchannel. Track[01]/[56]

Probably this haven't been fixed yet.

Posted: **Mon Jan 25, 2016 8:13 pm**

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.

Posted: **Tue Jan 26, 2016 5:23 pm**

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

Posted: **Mon Feb 29, 2016 7:32 am**

small updated

Posted: **Sat Mar 05, 2016 6:39 pm**

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.

Posted: **Sat Mar 05, 2016 8:29 pm**

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?

Redump Forum

DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator