1 Topic by Egen (edited by Egen 2017-05-16 03:07:55)

  • Egen
  • Dumper
  • Offline
  • From: United States
  • Registered: 2015-01-29
  • Posts: 193

Hi guys, I just got some games in a package today and one of them is the Japanese version of Ridge Racer, SLPS 00001. I've checked my total image size and CRC and they match the info in the database, but NONE of my other hashes or even file sizes match. EVERYTHING is off. I'm dumping with a PX-716A with the most updated firmware using DIC, and I've completed the dump twice. Both times the dump was successful, gave me identical CRC/filesize values, and had 1 error just like I'm seeing on the database (sector 1550 or 1558, can't remember which). The date for the EXE file on my disc also matches the database, so it's very mysterious. What is perhaps the biggest part of this mystery is that this disc is PERFECT. Like, guys, this entire game is in A+ grade condition, looks like I pulled it out of the shrink wrap myself; the case, the booklet, the obi, the disc... everything.


I'd like to get this problem solved, because I never have mismatches with this database, and apparently three different people have all come up with the same values as each other in the database. There's a whole mess of log files and stuff that DIC leaves behind when it's done, so please let me know which files I can supply here so that someone might be able to troubleshoot this for me. It's so utterly bizarre that I can't even chalk it up to a version different, although I guess it could be? It's truly just... bizarre.

  • Registered: 2014-06-08
  • Posts: 470

I have also dumped this disc and the dump agrees with the other 3 dumpers. Check if the tracks are out of order in the .dat file that DIC generates. It happens occasionally for multitrack dumps. Post the .dat file contents.

3 Reply by Egen (edited by Egen 2017-05-16 04:24:16)

  • Egen
  • Dumper
  • Offline
  • From: United States
  • Registered: 2015-01-29
  • Posts: 193

Bah, I'd linked to the wrong disc XD I fixed that link.


Here's the DAT file's contents.

        <rom name="image (Track 01).bin" size="3671472" crc="ad208351" md5="e169b3d4395f17afe1b26deb2ecc4184" sha1="d493197f3a0eb8c67f1347515a675975359bd2d7"/>
        <rom name="image (Track 02).bin" size="56415072" crc="0ad1d484" md5="218bb23cbd817472983fe2ea9352e915" sha1="f84ffe2d5e57bc0e05715c50b5d1c62b0fcec5fe"/>
        <rom name="image (Track 03).bin" size="48500592" crc="a6a485d8" md5="3e3a8b5ff10f69c2685866caeccadf2e" sha1="6bb4430c2ba1fe7de512708585500a7de2b0a041"/>
        <rom name="image (Track 04).bin" size="56567952" crc="cc628c6d" md5="1f4ce7fecd51179c7519e793ad5c4b81" sha1="d11e757b26d3013e2acbde52672251f4cf82b53d"/>
        <rom name="image (Track 05).bin" size="57640464" crc="4c5b7aa3" md5="f597693a732a4ada6004a161575852c6" sha1="2f25072e85b2d6839a35ba7fc69a37c3e4cf91a9"/>
        <rom name="image (Track 06).bin" size="54481728" crc="2b23b76b" md5="3ddfbdd9e117de1299c8bf7d8f1ab9b4" sha1="11a46d904684bfbd40b79059cded05cb89ca6fc3"/>
        <rom name="image (Track 07).bin" size="53670288" crc="958ffa28" md5="615f05d45ca1037dfaf963658204def7" sha1="7a3f2753b22b4aa78f4cc8ff4fc70e22b56ff90c"/>
        <rom name="image (Track 08).bin" size="21523152" crc="2c62eb8a" md5="fc66a3124188328b8d9a7a67264f0b48" sha1="3820997047510fb8058eec50fc4e2756538d9e78"/>
        <rom name="image (Track 09).bin" size="13629840" crc="4419980f" md5="0027959a80e5d8b787543186d7c47165" sha1="903dc3864dcfee190a127d667ff09ffeea7780cb"/>
        <rom name="image (Track 10).bin" size="2065056" crc="d15f4f67" md5="b3c9862715973f5cc1a36640e608b86d" sha1="6cd853f5eab284077afa974f06eac9c2731fd931"/>
        <rom name="image (Track 11).bin" size="21878304" crc="5a12f52f" md5="ac7b42be519c7e04cf2171ad7c015a83" sha1="eb21b68fb0b4f2ccc1a53d22d964fb8328f25c47"/>
        <rom name="image (Track 12).bin" size="17449488" crc="7a141b83" md5="20569601781c24eb7a4da8d627319ae8" sha1="f56d4c39e171145a6bbb14a2e35e232f262d6e70"/>
        <rom name="image (Track 13).bin" size="26610528" crc="c7790790" md5="3f8140d05383b095cc3e78a9b1cb32d9" sha1="fe9dd4c0658044ecdeebc8b44a0ce6c88a1617c8"/>

Upon further inspection, it seems that my CRCs match up starting at track 3. This means that tracks 1 and 2 are the culprits. Furthermore, track 1 has a size of 3671472 when it should be 3666768. This is an increase of 4704 bytes, which is exactly 2 sectors. Track 2 has a size of 56415072 when it should be 56419776. This is a decrease of 4704 bytes. Combined with the fact that the filesizes and hashes match up from that point on, it makes sense that the total file is the same, since the size differences offset each other in the first two files.


So now my question is wtf DIC, I guess. I'm literally doing nothing different from ripping all of my CDs and none of them have done this to me. Why is this one behaving in such a manner?

  • Egen
  • Dumper
  • Offline
  • From: United States
  • Registered: 2015-01-29
  • Posts: 193

I actually had a good idea. I removed the last 4704 bytes from Track 1 and put them at the beginning of Track 2 (not-so-curiously, the data was all zeroes). The CRCs and sizes of the resulting files match the database. It's still weird that this is happening, though. Why would DIC have this strange behavior only for this single game after years of using it to dump all my CDs? It makes no sense. Does anyone have any guesses?

  • Registered: 2011-02-20
  • Posts: 1,747

Please  check the subchannel file.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Egen
  • Dumper
  • Offline
  • From: United States
  • Registered: 2015-01-29
  • Posts: 193

Ah, sarami, great, just the person I need to talk to... the plot TOTALLY THICKENS.


I had another decent idea and I downloaded the newest version of DIC. Ripped the Ridge Racer disc with it and bam, my results match the database, first time. What bothered me, though, is that I was using a version of DIC that dated back to 2015. The Ridge Racer entry was created on Redump in 2008, and only last modified in 2014. That's a whole year before I got DIC, so it's impossible for anybody to have been using a version that was newer than mine. If that's the case... why would I need to update to get the same results as people using versions that could have only possibly been older than mine? Why would they get better results with older versions, yet I get the same results only when I get a newer one? The impossibility of it is rather mind-boggling.

  • Registered: 2011-02-20
  • Posts: 1,747

1. 1st dumper probably used isobuster and eac, but I don't know what tools are used by 3 dumper.
2. The version 2015 you used may exist a bug about subchannel, but I don't know because I don't see the log.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

8 Reply by Egen (edited by Egen 2017-05-16 07:59:12)

  • Egen
  • Dumper
  • Offline
  • From: United States
  • Registered: 2015-01-29
  • Posts: 193

Which log do you need? The image_sub log? I looked at it, and if I looked at the correct one, it's exactly 184568 lines of repeating text that looks like

LBA[184567, 0x2d0f7], Audio, 2ch, Copy NG, Pre-emphasis No, Track[13], Idx[01], RelTime[02:28:63], AbsTime[41:02:67], RtoW[Zero, Zero, Zero, Zero]

Various things will change, but it's always [Zero, Zero, Zero, Zero]. I know because I did Replace to that, and every single line ended up with nothing left in that area. It's 26.0MB so I can't really paste it here, I don't think. Assuming I'm looking at the correct log though, do you want me to upload it as a txt file or something? I still have the one from the dumps done with the old DIC.

  • Registered: 2011-02-20
  • Posts: 1,747

No need the log. I don't support the old version.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

10 Reply by Egen (edited by Egen 2017-05-16 09:42:19)

  • Egen
  • Dumper
  • Offline
  • From: United States
  • Registered: 2015-01-29
  • Posts: 193

Uhhhh, okay... you said yourself "The version 2015 you used may exist a bug about subchannel, but I don't know because I don't see the log" so... what was that about if you don't support it? XD


And even at that rate, it's an incredibly bizarre bug because it only happened on one multi-track CD in the history of my CD dumping years, which has seen quite a few CDs, so... *shrug*


To be honest, this has kind of left me wondering if the results I got this time are more "correct" than my previous results. I mean, honestly, that version never went wrong with anything and it was a newer version than anybody who did the rips before me could have used. So, why should I believe these results over the ones I got with a version that had proven itself 100% reliable over years of usage? That version wasn't spitting out random results—I got the same exact results over two passes of ripping the same CD, so... =/ it just seems kinda weird to me.

  • Registered: 2014-10-06
  • Posts: 704

Post image_sub.txt somewhere. It compresses well, maybe it would fit in attachment.

  • Egen
  • Dumper
  • Offline
  • From: United States
  • Registered: 2015-01-29
  • Posts: 193

Okay, here's the image_sub.txt log from the old rip. I have no idea what I'm looking at when I see it. I compressed it using 7-Zip 16.04.

Post's attachments

image_sub.7z 455.37 kb, 16 downloads since 2017-05-16 

You don't have the permssions to download the attachments of this post.

13 Reply by reentrant (edited by reentrant 2017-05-16 19:41:51)

  • Registered: 2014-10-06
  • Posts: 704

LBA[001559, 0x00617],  Data,      Copy NG,                  Track[01], Idx[01], RelTime[00:20:59], AbsTime[00:22:59], RtoW[Zero, Zero, Zero, Zero]
LBA[001560, 0x00618],  Data,      Copy NG,                  Track[01], Idx[01], RelTime[00:20:60], AbsTime[00:22:60], RtoW[Zero, Zero, Zero, Zero]

Should be audio, not data. That explains shifted tracks. There must be a bug somewhere. Always use the newest build...

14 Reply by Egen (edited by Egen 2017-05-16 22:08:52)

  • Egen
  • Dumper
  • Offline
  • From: United States
  • Registered: 2015-01-29
  • Posts: 193

Why should those be audio? Also, when I ripped the disc with that program, like I explained, I was using a newer build than anybody before me could have used. So why would their build, which was older than mine, work "correctly" while mine would have to be updated much further than theirs possibly could have been? Something's not adding up here. It also doesn't add up that it only occurred with this disc out of a countless amount of discs that I used this same version to rip. Is there something mystically different about the pregap on only Ridge Racer Japan discs? This "bug somewhere" only affected this multi-track, multi-session disc and not allllllll the others I've done? It's hard to believe.


I'm not trying to be difficult or argumentative and I apologize if I am, I just really don't understand. I don't want to get results and not understand them, or else I'm just doing what I'm told and not knowing if it's a good rip or not. This. Just. Doesn't. Make. Sense.

  • Registered: 2014-10-06
  • Posts: 704

Could you post here a sub file made with another tool: CloneCD or Alcohol. I want to see what's in the subs...

  • Egen
  • Dumper
  • Offline
  • From: United States
  • Registered: 2015-01-29
  • Posts: 193

Where can I get CloneCD?

  • Registered: 2006-12-24
  • Posts: 3,847

Egen wrote:

Is there something mystically different about the pregap on only Ridge Racer Japan discs? This "bug somewhere" only affected this multi-track, multi-session disc and not allllllll the others I've done? It's hard to believe.

Yes, why not? 2 sectors could be either read worse than the rest due to some light scratch/dirt/dust or read properly, but  incorrectly "fixed" afterwards by the old subchannels-fixing algorithm.

http://forum.redump.org/topic/14725/subdump/ -- use this to dump the subs, clonecd and alcohol usually produce incorrect subs with certain sectors missing and certain sectors doubled. You can add the "-quick" parameter to make a "fast" copy without rereadings.

  • Egen
  • Dumper
  • Offline
  • From: United States
  • Registered: 2015-01-29
  • Posts: 193

F1ReB4LL wrote:

2 sectors could be either read worse than the rest due to some light scratch/dirt/dust

I've already said the entire game, every part of it, is mint condition :S Case, booklet, obi, disc; it looks like I removed it from the shrinkwrap myself.

F1ReB4LL wrote:

or read properly, but  incorrectly "fixed" afterwards by the old subchannels-fixing algorithm.

An algorithm that incorrectly "fixes" pregaps... when it wants to? If it's an algorithm, why doesn't it happen all the time? If the program is coded to behave this way with pregaps between data and audio sessions (tracks 1&2), then how do you explain that every other type of this CD I've ever dumped with this version never did that? If this algorithm is coded to work this way and the dumps for those CDs came out correctly, then the Ridge Racer CD must have also turned out correctly, because that's the way this algorithm works.


Anyway, I downloaded subdump, but have no idea how to use it. Does it want a disc, or does it want a file? And if so, which file? Do I give it a full image dump? And if so, which image? DIC creates multiple full image dumps, I believe 2 of them that are both the same size but have different file extensions.

19 Reply by reentrant (edited by reentrant 2017-05-18 23:24:46)

  • Registered: 2014-10-06
  • Posts: 704

Subchannels don't have that great error correction schemes like 2352 data. I have CDs that look like they just came from factory but data on them is barely readable. I bet your CD is an example of poor quality master that has some unstable data in subchannels area + DIC might have a bug somewhere and incorrectly repairs the subchannel.

Subdump: http://forum.rawdump.net/viewtopic.php?id=13