I know the official name. 

Is it always post the name shows on the cover here?

77

(29 replies, posted in General discussion)

Thanks for yours answer, RetroGamer.

Best regard.

If the SLPS-00451~2 have the same case, shall I post "Error = 1"?

1. 戦艦 = Battleship(meaning) = Senkan(pronounce)

2. 忍 = <kanji> = Shinobi(pronounce)

3. しのび = <hiragana> = Shinobi(pronounce)

79

(29 replies, posted in General discussion)

I try to borrow one drive that support PR, today, and dump it via PR.

...
Info    | 3:36:58 | Trk 01: 00:00.00 to 07:11.49 (000000 to 032374), duration: 07:11.50 (032375)
Info    | 3:36:59 | Trk 01 format type is CD-ROM mode 2
Error   | 3:38:32 | Error while burst reading sectors: 032208 to 032230 (07:09.33 to 07:09.55)
Info    | 3:38:32 | Retrying with 1 sector reads from: 032208 (07:09.33)
Info    | 3:38:32 | Found new subchannel offset correction (sectors): 2 (LBA: 32225)
Info    | 3:38:32 | Pause found: 0102000001740007115068DA
Info    | 3:38:32 | 1 sector reads were ok, setting back to burst reading from: 032231 (07:09.56)
Info    | 3:38:32 | Index found: 01020100000000071350984B
Info    | 3:38:32 | FLAGS DATA
...

So the PR fixed it automatically.

And the 01.- cd.track.img match the newest DB, CRC32 = dab05773

http://redump.org/disc/9568/

The cdmage check result is "Image has 1 corrupted sector(s)."

Need fix or no ?  Confused...

SIMPLE 2000 Series Vol.51: The Senkan(=Battleship)
シンプル 2000 シリーズ VOL51 THE 戦艦

Shinobi
忍 (しのび)

81

(2 replies, posted in General discussion)

Some information here...

http://forum.redump.org/topic/4862/pc-e … questions/

For [KMCD3005]Akumajō Dracula X: Chi no Rondo, you can try the write offset: +6125

82

(29 replies, posted in General discussion)

Hmm, I'll try it again after getting  the other devices.

Thank you, Administrator


Sorry, the last question:

Fill-up QSF on the last sector of Track01 will match the DB but still have 1 error.

Then clear the User Data will match the old history and no error occured.

If the situation happened again, should I fixed it? (Ex: SLPS-00451)

83

(29 replies, posted in General discussion)

No, the 2nd question didn't, yet.

84

(29 replies, posted in General discussion)

Sorry everyone, the 1st question solved.

I use the write offset to read offset correction.

Maybe I should go to the bed and sleep more.

85

(29 replies, posted in General discussion)

2nd question:

Another Game with one-Data and one-Audio, but it's PSX game.

http://redump.org/disc/9568/

Use the same way, and the Audio is match the DB.  (Wow!!)

but get a one-sector-error Track01.bin.

MD5:    140b9c3be7a43273e7042e328b91ff6d
SHA1:   5d4a7e09f131b5ebad31dce6e97b1efa077eb6e1
CRC32:  1ec78ed9

Did I miss something?  (I notice some fixed issue in the DB edit history.)

86

(29 replies, posted in General discussion)

Hello, everyone. Sorry for many question.

I always get wrong hash audio-data when dump one-Data and one-Audio CD.

But no problem for multi-audio track CD via EAC using the same way.

This time I choose a [SS]Shining-Wisdom that have been verified by 4 dumpers.

I found there are two datas in DB, so I dump Track01.bin first and match that one. (lucky)

http://redump.org/disc/3235/  (The other one have different Track01.bin)

After calculate the exact offset manually, it's +684 ok. (And the ringcode is P2K, too.)

EAC Log:

Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 1. December 2011, 7:10

Unknown Artist / Unknown Title

Used drive  : PIONEER DVD-RW  DVR-111   Adapter: 0  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 684
Overread into Lead-In and Lead-Out          : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to next track

Used output format : Microsoft PCM Converter
Sample format      : 44.100 kHz, 16 ビット, ステレオ


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 |  8:50.70 |         0    |    39819   
        2  |  8:50.70 |  0:08.23 |     39820    |    40442   


Track  2

     Filename C:\new\TEST\Track02.bin

     Peak level 45.9 %
     Track quality 98.7 %
     Test CRC FACEB85C
     Copy CRC FACEB85C
     Copy OK

No errors occurred

End of status report

Get a Track02.bin without gap because of EAC bug. (1465296 byte)

MD5:    fad8a46bc73e11908f1ff6f9d246f68d
SHA1:   25eec6ee539794eb7ef3be84e4f0effbdf6db296
CRC32:  faceb85c

After fixing the gap by ss_fixing. The hash is    (1818096 byte)

MD5:    f5cddc51455b85a83ec645a55cdbc251
SHA1:   8c2e9b3ff004d850153ce9f0eed262010cbac570
CRC32:  3b4c493e

Not match the DB.

I did that 3 times.

DJoneK wrote:

Maybe your drive doesn't read into lead-in/lead-out.  Or maybe the pregap contains some data.

Try this.  Dump track 02 using isobuster "Extract from-to"  you'd need to calculate the exact sectors so it includes the pregap too.  Then manually fix the offset.  If your combined offset is +48, then remove 192 bytes from the beginning of the track, and add 192 bytes of 00s at the very end.  See if that way it matches at least.  I doubt it would serve as a verification since it's such a roundabout method, but at least you can see if you can match the track.

The answer is NO MATCH, anyway thank you again.

After verified the [SS] Layer Section, I find out there is [3M] and [6M] version in DB.

I guess that's the answer because my GS-9082 is [3M] version. Maybe....

The data in DB is [1M] version.

Different Ring-Code.

I think the「三国志」,  「Romance of the Three Kingdoms」, and「Sangokushi」,  even 「San Guo Zhi」,  「三國志」is a interesting  topic, too.

And the related games are more than the other Specific series.

DJoneK wrote:

Maybe your drive doesn't read into lead-in/lead-out.  Or maybe the pregap contains some data.

Try this.  Dump track 02 using isobuster "Extract from-to"  you'd need to calculate the exact sectors so it includes the pregap too.  Then manually fix the offset.  If your combined offset is +48, then remove 192 bytes from the beginning of the track, and add 192 bytes of 00s at the very end.  See if that way it matches at least.  I doubt it would serve as a verification since it's such a roundabout method, but at least you can see if you can match the track.

According the guide, the Track02 seems be converted by the  PCM converter...

But I'll try your way, thanks.

It's interesting, another game with one data and one audio track.

http://redump.org/disc/9568/

The Track01.bin(data) not match (and have one error), but Track02.bin is OK.

Someone can explain that?

I use the EAC099b5 with the same setting....

Hello, I think I can handle the PSX with single data track, and learn to dump the disc with audio tracks.

I read the guide carefully and do it step by step.

First, I pick a game with one data and one audio track, and it's not huge for saving error-testing time.

The Track01.bin is OK, but it always get the wrong Track02.bin against  DB.  (I've fixed it via ss_fixing)

http://redump.org/disc/5262/

I've read EAC bug topics about two track CD, and pick another game with multi-track.

http://redump.org/disc/1691/

Everything is OK and match DB, thus my setting seems fine.

So I post the [SS] World Advanced Daisenryaku: Sakusen File log for help, thanks.

Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 29. November 2011, 4:39

Unknown Artist / Unknown Title

Used drive  : PIONEER DVD-RW  DVR-111   Adapter: 0  ID: 0

Read mode               : Secure
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 29. November 2011, 4:45

Unknown Artist / Unknown Title

Used drive  : PIONEER DVD-RW  DVR-111   Adapter: 0  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 48
Overread into Lead-In and Lead-Out          : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to next track

Used output format : Microsoft PCM Converter
Sample format      : 44.100 kHz, 16 ビット, ステレオ


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 | 24:07.55 |         0    |   108579   
        2  | 24:07.55 |  0:20.02 |    108580    |   110081   


Track  2

     Filename C:\new\TEST\Track02.bin

     Peak level 97.0 %
     Track quality 100.0 %
     Test CRC FF5C1341
     Copy CRC FF5C1341
     Copy OK

No errors occurred

End of status report

After fix the 2 second gap problem, the hash of Track02.bin is...

MD5:    14f40ec2e532f9e835aab10a5c516423
SHA1:   456ddcb7b6fe4d3d8e5cd4559e67b7315837395e
CRC32:  cc93f8cf

The Track 02 start on sector 108580, and scramble data begin from sector 108430 and  48 samples long.

I've dump it 6 times, and thanks everyone for reading my post.