Topic: [MIL-CD] Himitsu - Original Sound Track

Logs
http://www.mediafire.com/file/4ymu85w7b … 29.7z/file

Re: [MIL-CD] Himitsu - Original Sound Track

Does this mean Mil-CDs are possible to dump with DIC now? I have a bunch of them

Re: [MIL-CD] Himitsu - Original Sound Track

I don't see the REM SESSION 01, REM LEAD-OUT and REM SESSION 02 in the cue. And the lead-in area/1st pregap of the 2nd tracks should be saved into some file as well, I think.

Re: [MIL-CD] Himitsu - Original Sound Track

F1ReB4LL wrote:

I don't see the REM SESSION 01, REM LEAD-OUT and REM SESSION 02 in the cue.

Yes, I know. Did redump db support this? If it's already supported, DIC supports this too.

F1ReB4LL wrote:

the lead-in area/1st pregap of the 2nd tracks should be saved into some file as well, I think.

pregap of the 1st track of the 2nd session, not 2nd tracks? If so, Why redump db doesn't save these of the single session disc? (Of course, I know you save these of single session personally.)

Re: [MIL-CD] Himitsu - Original Sound Track

sarami wrote:
F1ReB4LL wrote:

I don't see the REM SESSION 01, REM LEAD-OUT and REM SESSION 02 in the cue.

Yes, I know. Did redump db support this? If it's already supported, DIC supports this too.

Not yet, I think, but it's not correct not to show the sessions at all.

sarami wrote:
F1ReB4LL wrote:

the lead-in area/1st pregap of the 2nd tracks should be saved into some file as well, I think.

pregap of the 1st track of the 2nd session, not 2nd tracks? If so, Why redump db doesn't save these of the single session disc? (Of course, I know you save these of single session personally.)

gorelord4e was collecting them for his rawdump project, not me smile And I've asked to add an automatic 1st pregap and TOC reading into DIC already, but you haven't added that yet smile

Btw, according to Green Book, the first pregap + 16 sectors of the main area (166 sectors in total) contain an audio warning encoded in CDDA format and placed into the MODE2 sectors. I don't know, if all the CDI discs have the same message there or different discs have different messages, but if they are different, we need to preserve them somehow.

Re: [MIL-CD] Himitsu - Original Sound Track

You should continue to work on your sub error correction algorithm hmm

LBA[037483, 0x0926b]: Track[03]: SubQ Reread this sector because Crc16 doesn't match
LBA[037483, 0x0926b]: Track[03]: SubP[03]:[0x04] -> [0x00]
LBA[037483, 0x0926b]: Track[03]: SubQ[12]:Adr[1] -> [0x02]
LBA[037483, 0x0926b]: Track[03]: SubQ[13-19]:MCN[0301053728000], Sub[19]Lo:[8], Sub[20]:[0x21] -> [4943674011599], [19]Lo:[0], [20]:[0x00]
LBA[037483, 0x0926b]: Track[03]: SubQ[22]:CrcHigh[0xe8] -> [0xc9]
LBA[037483, 0x0926b]: Track[03]: SubQ[23]:CrcLow[0x93] -> [0x18]
LBA[037483, 0x0926b]: Track[03]: SubQ Reread NG

You should leave such sectors "as is", fixing them only makes the things worse. In this case, the sub mode was read as 0x02 instead of 0x01 and you've changed almost all the bytes, that's very wrong and sometimes affects the indexes producing wrong cues.

LBA[107819, 0x1a52b]: Track[08]: SubQ Reread this sector because Crc16 doesn't match
LBA[107819, 0x1a52b]: Track[08]: SubP[08]:[0x10] -> [0x00]
LBA[107819, 0x1a52b]: Track[08]: SubQ[12]:Adr[3] -> No ISRC frame
LBA[107819, 0x1a52b]: Track[08]: SubQ[13]:TrackNum[70] L:[511] -> [08], L:[1316]
LBA[107819, 0x1a52b]: Track[08]: SubQ[14]:Idx[09] -> [01], L:[431]
LBA[107819, 0x1a52b]: Track[08]: SubQ[15-17]:PrevRel[8208, 01:49:33], Rel[630099, 140:00:99] -> [8209, 01:49:34], L:[431]
LBA[107819, 0x1a52b]: Track[08]: SubQ[18]:[0x06] -> [0x00]
LBA[107819, 0x1a52b]: Track[08]: SubQ[19-21]:PrevAbs[107968, 23:59:43], Abs[36794, 08:10:44] -> [107969, 23:59:44]
LBA[107819, 0x1a52b]: Track[08]: SubQ[22]:CrcHigh[0x10] -> [0x82]
LBA[107819, 0x1a52b]: Track[08]: SubQ[23]:CrcLow[0xe9] -> [0x1c]
LBA[107819, 0x1a52b]: Track[08]: SubQ Reread NG

I think it has ruined an ISRC sector here, but not sure.

Re: [MIL-CD] Himitsu - Original Sound Track

F1ReB4LL wrote:

Not yet, I think, but it's not correct not to show the sessions at all.

DIC could support gc/wii and xbox(ss.bin only) recently, so I support multi-session before long.

F1ReB4LL wrote:

I've asked to add an automatic 1st pregap and TOC reading into DIC already, but you haven't added that yet

Sorry, I don't remember it.
The problem is that even plextor can't read lead-in perfectly. When we read lead-in, starts reading from -5000 traditionally. But see below (Caesars World of Boxing),

LBA[-01151, 0xfffffb81]: P[00], Q[4100a2021974005605005e71]{ Data,      Copy NG,                  Point[a2], AMSF[02:19:74], StartTimeOfLead-out[56:05:00]}, RtoW[0, 0, 0, 0]

The AMSF of last lead-in sector is 02:19:74. If AMSF starts from 00:00:00, the lead-in exists 10350 sectors. But plextor can only read about 1900 - 2000 sectors.
How many sectors does gorelord4e preserve?

F1ReB4LL wrote:

according to Green Book, the first pregap + 16 sectors of the main area (166 sectors in total) contain an audio warning encoded in CDDA format and placed into the MODE2 sectors.

Surely, it seems these sectors are encoded in CDDA format.
_disc.txt

========== OpCode[0xd8]: SubCode[0]: Check Drive + CD offset ==========
========== LBA[000000, 0000000]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0010 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0020 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0030 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0040 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0050 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0060 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0070 : 00 00 00 00 72 DD E5 99  00 FF FF FF FF FF FF FF   ....r...........
0080 : FF FF FF 00 01 82 00 62  00 28 20 1E 80 08 40 06   .......b.( ...@.
0090 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00A0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00B0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00C0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00D0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00E0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00F0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
 :

It looks like the scrambled sector is normal data sector.

F1ReB4LL wrote:

You should continue to work on your sub error correction algorithm

This is fixed.

Re: [MIL-CD] Himitsu - Original Sound Track

A bit of a tangent, but does anyone know whether or not this is the absolute fullset for Mil-CD? http://wiki.redump.org/index.php?title=Sega_Mil-CD

Re: [MIL-CD] Himitsu - Original Sound Track

It is if you don't count unlicensed stuff like bleemcast.

Re: [MIL-CD] Himitsu - Original Sound Track

sarami wrote:

The problem is that even plextor can't read lead-in perfectly. When we read lead-in, starts reading from -5000 traditionally. But see below (Caesars World of Boxing),

LBA[-01151, 0xfffffb81]: P[00], Q[4100a2021974005605005e71]{ Data,      Copy NG,                  Point[a2], AMSF[02:19:74], StartTimeOfLead-out[56:05:00]}, RtoW[0, 0, 0, 0]

The AMSF of last lead-in sector is 02:19:74. If AMSF starts from 00:00:00, the lead-in exists 10350 sectors. But plextor can only read about 1900 - 2000 sectors.

It reads the sectors randomly. Also, you can start with -10000, for example. Or you can even start to read from the sector "$FF000000" (this value should be entered as a sector number) and read sector by sector until you get all the needed ones.

sarami wrote:

How many sectors does gorelord4e preserve?

He preserves the last TOC iteration only (around 10-20 sectors) and the pregap.

sarami wrote:

Surely, it seems these sectors are encoded in CDDA format.
...
It looks like the scrambled sector is normal data sector.

Yeah, I've checked a few Justin Bailey's dumps and they have empty mode2 sectors there. While the Green Book claims these should have some CDDA warning message encoded in Mode2 sectors to be played on the old CDDA players.

sarami wrote:
F1ReB4LL wrote:

You should continue to work on your sub error correction algorithm

This is fixed.

I think it should work another way, I'll try to describe it in the DIC thread.

Re: [MIL-CD] Himitsu - Original Sound Track

added SESSION, LEAD-OUT syntax
added lead-out of 1st session, lead-in of 2nd session (padded by zero because almost all sectors are unreadable), pregap of 1st track of 2nd session (read by 0xbe because some sectors are unreadable).
http://www.mediafire.com/file/ffltan057 … su.7z/file