Dynasty Warriors 2 problem

[Egen]

I'm doing a dump of Dynasty Warriors 2 right now and it is a CD PS2 game with 2 tracks, the first being the game and the second being audio. When I detect gaps in EAC, I only ever get a pregap of 00:00:00 for track 2, even testing with 3 different drives (PLEXTOR DVDR PX-716A 1.11, IDE-DVD DROM6216 HD08, and HL-DT-ST BDDVDRW UH12NS29 1.00). However, the dump in the database has a pregap of 00:02:00 for track 2. I understand track 1 has the standard 00:02:00 pregap, but that pregap will never come into play; if we're prepending gaps, it goes at the beginning of that track. If we're appending gaps, it goes at the end of the previous track, and there is no previous track. A pregap never goes to the next track, only to that one or the previous one.

I'm just verifying that the entry in the database was done incorrectly (or perhaps the disc was just different?) and that I understand how this works, because this is the only multi-track CD dump I have to do and I'd like to know I'm doing it correctly. Here is the log file from my extraction.

Code: Select all

Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 1. February 2015, 1:43

Unknown Artist / Unknown Title

Used drive  : PLEXTOR DVDR   PX-716A   Adapter: 1  ID: 0

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

Read offset correction                      : -647
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 previous track

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 | 61:34.14 |         0    |   277063   
        2  | 61:34.14 |  3:32.26 |    277064    |   292989   


Track  2

     Filename C:\Track02.wav

     Peak level 0.0 %
     Extraction speed 17.7 X
     Track quality 100.0 %
     Test CRC C80C8C94
     Copy CRC C80C8C94
     Copy OK

No errors occurred

End of status report

==== Log checksum 310D77214A3953DF82FC2295A21D1F8259ADB76AAEA162DB6E401E8EAC75DBA4 ====

Also, just to make sure, I remove the 44 bytes of WAV header data before hash checking, correct?

[GreyFox]

Incorrect. From our guide. https://redump.info/guide/cddumping/ It shall be appended to the next track.

And two throw EAC in the garbage bin when you have a plextor and use DIC. EAC cannot handle 1 data 1 audio track discs properly.

[Egen]

Ah, I see now. Using DIC, I receive the following information from a log:

Code: Select all

    Session 1,      Leadout, MSF 65:08:40 (LBA[293140, 0x47914])
    Session 1,     Track  1, MSF 00:02:00 (LBA[000150, 0x00096])
    Session 1,     Track  2, MSF 61:36:14 (LBA[277214, 0x43ade])

Knowing that the data track's length is 61:32:14 and taking the starting position of 00:02:00 that DIC reports (the standard 2-second pregap before track 1), that would mean track 2 should start on 61:34:14, but DIC reports 61:36:14. That means another 00:02:00 exists in between these 2 tracks, and indeed, when DIC ripped the disc, it created a CUE sheet with a 2-second pregap for track 2.

I just want to say: that's much different than "appending" the track 1 pregap to track 2. You can't do that because the pregap of track 1 physically does not exist between track 1 and track 2, so it's not possible to just "move" it there, what you would be doing is creating an entirely new one there that doesn't really exist. Just saying but that's not the case here since there is a pregap between tracks 1 and 2 according to DIC.

Anyway, there's still a problem with this: I get different hash results for track 2. I have
CRC: 40e86050
MD5: 61239a3dc22088a08f2d320918ac11a1
SHA-1: 7c8508996d34d2a39fd75a8fab58e2c9b766b09b
SHA-1 for Redump's entry is 9130927bd36791313187616cce1ffc42c51fe892, so something is still afoot either with the way DIC ripped it, or the existing Redump entry. Please let me know if I can include some information to help figure it out. DIC has its proper offsets file and it looks like everything went as it should. From the "disclog.txt" file:

Code: Select all

Offset(Drive offset data referes to http://www.accuraterip.com)
     Combined Offset(Byte)  -2468, (Samples)  -617
    -   Drive Offset(Byte)    120, (Samples)    30
    ----------------------------------------------
           CD Offset(Byte)  -2588, (Samples)  -647
    Overread sector: -2

So it knows my proper read offset and the disc's write offset.

[GreyFox]

Track 1 matches DB now though? It is just Track 2 which has a mismatch?

Also just a Q. Not related to this but to your DVD of Evergrace and more to come I guess. You are dumping these on two drives right? And 1 not being the Plextor if possible. And then comparing the hashes you get against each other right?

[Egen]

The 3 drives I named in my first post are used for every dump I do.
PLEXTOR DVDR PX-716A 1.11
IDE-DVD DROM6216 HD08
HL-DT-ST BDDVDRW UH12NS29 1.00
Every CD I own is in very good condition so naturally I've always had matching hashes.


As for DW2, Track 1 always matched the DB because it was easy to do manually as it didn't involve the mystery pregap and stuff. Yes, now it's just track 2 which doesn't match. I did the rip again with DIC using a different drive speed, but I got the same results so unless there's a setting I'm not doing correctly, maybe the previous rip on Redump was done incorrectly (possibly, DIC was not available at the time or just not used, and the rip was done using EAC).

[GreyFox]

Good. That is what I wanted to hear!

I will order a copy of the game myself. Just to get it verified. But since the hash you get now matches a lot of other entries in the DB while the hash given for Track 2 by Nexy only matches that entry it is very likely it is a bad dump.

Nexy would have used other tools to get his dump done. But no one is perfect and mistakes do happen. That is why the goal is to have 2 dumpers submit data from 2 different discs so that one knows for certain that the dump is good.

[Egen]

That is why the goal is to have 2 dumpers submit data from 2 different discs so that one knows for certain that the dump is good.

Yes, this certainly sums up the essence of Redump Hey, everybody starts somewhere and uses some tool in the beginning before a better one comes their way. I'm still learning the best tools and methods through these discussions. I appreciate your help a lot because I want to contribute to the maximum accuracy!

If you order Dynasty Warriors 2, I have to share my opinion that it's one of my more enjoyed games in the series despite being the first. I notice you have many Warriors games dumped so you may or may not be into them, but I think it's a good game in its simplicity, even though other people may think it's no good XD

[iR0b0t]

Egen: why are you bothering dumping it with EAC anyways? Isn't DIC working for you? It does everything automatically, use it.

[Egen]

Well, I was using EAC to dump for a number of reasons.
1. It's the only method explained in the only guide on the site.
2. It's the the most obvious program to rip audio from a CD (at least, for an outsider).
3. It's the program I'm personally most familiar with.
Please keep in mind, I've been here for only 4 days. In a post made not even 24 hours ago two more programs I had never heard of were mentioned.

Obviously now having learned from this experience, I am going to use DIC. However, if it's the clearly obvious choice, perhaps consider writing an updated guide detailing how to use newer, more superior programs, it will avoid these situations and help newcomers be efficient and accurate much more quickly. Had I known about these programs coming into this site, I could have been much more effective early on.

I'm not trying to blame anybody, just saying that updated guides would certainly be good

[iR0b0t]

Well, the only reason i was suggesting DIC to you is because i saw a real plextor in your own.
EAC + Isobuster can be difficult in usage in some cases, i would not recomend it over DIC if you can have it much easier this way. You don't have to learn offset calculation and moving byte samples. There are some time consuming things to do which you better skip. Just set up DIC quickly and enjoy dumping )))

DIC is still in development, although its way better than old dumping methods.