(1 replies, posted in New Dumps)

Offset reported by ice.exe is absurd. I have seen the same in gorski's submissions recently, no idea what is causing this. Maybe it's a problem with specific drive? At least I know with a significant degree of confidence that it's not affecting the dump negatively.
Also mastering code is likely starting with 0I0... and not OIO... This is the same pattern as in the retail version and zero-letter-zero is a known pattern for DC discs mastering codes generally. I entered it as zeroes, but could you please recheck this?

F1ReB4LL wrote:
MajorPBX wrote:

Category: Games

Still Games?

MajorPBX wrote:

DPSC-976 2MM1 C 9X

All 3 are [TAB]s?

Dumper supplied several ringcode images to me, one of them was for this. It's definitely all tabs, see attachment.
I doubt that category is Games, I think current category of Demos is more appropriate for this disc.

While we are at it, I added the IFPI mastering and mould codes. For some reason, these were not added even though dumper provided them.

Tidegear wrote:

Hello! I'm trying to confirm that this...
https://www.amazon.com/dp/B0050SX97I/re … 1Eb188TZVM
(MGS HD Collection, PS3, Standard)

Is the exact same disc that came with this...
https://www.amazon.com/dp/B005PSTTJA/re … 1EbD4BXFPA
(MGS HD Collection, PS3, Limited)

Basically, I have the Limited Edition, and I'm looking to replace the disc with a brand new copy of the same thing from the Standard Edition release. I want to make sure it's the same disc in every way possible (including the data on the disc).

If the disc labels look exactly the same, and I dump (using the PS3 dumping guide) both my original disc (from my Limited Edition) and the replacement disc (from a standard edition release), and the SHA1s match... Is there any point in verifying that the metadata and ring information are same? Do the metadata and ring info ever differ between discs if the SHA1s match?

Please help ease my collector OCD! Thanks so much!

If SHA1 matches between the 2 dumps, then disc contents are identical.
For the EU version this is already proven: http://redump.org/disc/25025/ but not for the US.
I am not very familiar with ringcodes for Sony discs, so can't answer that part with any big certainty. As a general principle, ringcodes usually are the same or similar if contents are the same.

ClevelandDynamics wrote:

I'm in the process of dumping all six discs for the Chinese retail release of Metal Gear Solid 2: Substance.

This release has Chinese SID, Mould, and the data on the disc is also Chinese.  The game setup file is in Chinese, as well as preliminary setup text.  However, once installed, the game itself is in English.  How do I tag this when submitting the dump?

My suggestion would be that the in-game language takes precedence. But it should be noted in the comments section that the installer/setup text is in Chinese, so include this information too.

Plextors are not good for dumping GD-ROM HD area.
There are very few drives that can do that in a reliable way.
In short, you have to dump the LD area with the Plextor and the HD area with the other drive.
Please read guide linked in post above yours, it has some recommended drives (section "Dumping the HD area")

Keep in mind that even with the recommended drives process can be quite difficult, especially in discs with scratches and will take some more patience than dumping a normal CD ROM.

Qubits wrote:

Finally, to speed up the process of submitting verifications (~50 verifcations to come) Is it ok to leave some info unfilled, that is identical, like name, foreign name, region, lanuage etc?
I'm thinking about putting in the serial number and the new/missing data.
This would save me a lot of time.

Either copy/paste the identical data from the existing entry in the DB (this is what I do personally if it's too time consuming to write it down, eg for Japanese names or other stuff that can't be typed in seconds) OR omit them but clearly mention what has been omitted due to being identical. Even putting something like "all other info as seen on the current entry is identical" should be clear enough IMHO.


(5 replies, posted in Guests & account requests)

pdcfounder_sketch wrote:

It's been awhile but I still have all of these demos that I would like to donate somewhere for preservation purposes. I no longer have the ability to maintain a site to keep them readily available to all both present and future. All demo's are in EBOOT format and work on official firmware 6.61. Any ideas?

Redump uses .ISO format, so it can't put these in its' dats.
I would suggest making an account on archive.org and upload all there.
In most cases, Archive is a good home for things like this and anyone with an interest in them can locate and download.

user7 wrote:

This doesn't answer your question but many of us are using internal drives but with a USB adapter. Here are recommended brands/models. Check your localized Amazon for a cheaper price:

Avoid other brands / models.

Second link is not the correct product. I think this is the one user7 intended to link:
https://www.amazon.com/UGREEN-Adapter-C … 01AW40QZW/
I have successfully used this specific adapter with several different internal Plextor models and I also do my dumping using a laptop running Windows 10.

For the faulty drive, there are basically 3 things to check, IMHO the only things in a drive that an average user can fix without much knowledge of electronics. If none of these fix the fault, drive is probably for the bin.
1) clean laser lens carefully and thoroughly with pure alcohol.
2) see that drive belt is not broken (ie that disc is actually rotating in the tray), in case it's broken try to source a replacement (this will be hard)
3) adjust the pot of the laser with a multimeter (need to see initial resistance, note it, then adjust slowly and with tiny turns of the screw, checking if discs become readable inbetween adjustments.

Hope this info helps you somewhat.

Yes, this is abnormally many non-matches.
It *is* hard to match sections (with 1 and 40 being the worst), but normally at the second pass you should be getting at least 10-15 sessions matching with any good quality disc, potentially even more. And the entire disc matched within about 10 passes in most cases with disc in good condition.
We have seen cases with erratic behavior like that, where it proved better to stop and start the dumping from scratch. Ie eject disc, redo the trap disc and start again). As a rule of thumb, any dump that is going on for more than 1.30-2 hours, will never complete properly or will turn out bad even if matches found.
If your drive still behaves like that after some tries, adjusting the pot with help of a multimeter should be a last resort measure before declaring the drive bad.

user7 wrote:

if that doesn't work, then just use the tosec method for the hd area. if there's one track in the hd area hashes will be the same as redump method (when redump method works)

I believe it will work on a repeat dump, I had this scenario with ice.exe throwing an error after dcdumper had difficulties dumping a specific segment several times while dumping my stuff. Trying again later generally resolved the problem.
Majorpbx already said the disc is in good condition, so my expectation is that it will be fine after a redump.

F1ReB4LL wrote:

Also, is it a bad dump?

03  Mode1   45000  549149  504150 ok (1)

Yes, that (1) there is a definite problem. Also, track 03.bin does not match the verified TOSEC dump. IMHO a definite bad dump.

        <description>Dreamcast Middleware Conference Demo Disc Part.2 v1.000 (1999)(Sega)(NTSC-PAL)[!]</description>
        <rom name="Dreamcast Middleware Conference Demo Disc Part.2 v1.000 (1999)(Sega)(NTSC-PAL)[!].gdi" size="87" crc="d7ab4c6b" sha1="9d50b816d3f69ad192f5986ab487769965c2e082" md5="b3ecdf113fd42344dd84142679e4cb36"/>
        <rom name="track01.bin" size="705600" crc="ad7554e1" sha1="89ae513774b409b7bf0b91ae3d08794dd026bb8b" md5="360bf1a74ea1e1fc3a72558a54e8d4d7"/>
        <rom name="track02.raw" size="1735776" crc="c73e4eb1" sha1="7be6cba55f0cec2617890652b6917a5339be5f0b" md5="665aa3c2c521301f45eb3aa7d8a128cd"/>
        <rom name="track03.bin" size="1185760800" crc="81dfe0b4" sha1="7324dd046a52f4cb93e9f9cd07603b7300eef189" md5="68c439c597509d32f008f43325c0d2e3"/>

@MajorPBX: I am fairly sure the offender is the 1st section, which took a while to match. I have seen this on some of my dumps too, dcdumper getting a match after struggling with a segment, only for ice.exe to spit out an error afterwards.
If you have kept the partial dumps, delete section 1 044990-055278 and let dcdumper try again. This will save the hassle of reading the entire disc again. Worked for me several times.


(6 replies, posted in General discussion)

reentrant wrote:

Any of CRC32, MD5 and SHA-1 is not secure. But all combined?

All combined and with a specific file size as per current dats should be an astronomically small chance of a hash collision, even if someone tried to do this intentionally. I don't think our roms can be faked with current level of knowledge.


(3 replies, posted in General discussion)

It's not the same disc and IMHO it would be wrong to just hack it to compliance, however convenient that may seem in reducing data volume and amount of dumps in DB. Applying additional offset correction apart from what the dumping method already does is totally equivalent to hacking stuff to compliance.

Again IMHO, it's significant to indicate different print runs/different ringcodes, at least when they result in different dumps when using the same standard dumping method.

Also had a similar case with one of my dumps recently that was accepted as separate discs, which of course they are.


Same with the Vampire example, discs are different and it was correct that all of them were included.


(1 replies, posted in General discussion)

A Murder of Crows wrote:

the biggest things i'm seeing are Categories (clrmame doesn't have/use them) and the fact that my dat says "Machine Name" instead of "Game name"


The Machine vs Game issue is easily fixable.
Open cmpro.ini, in Notepad, find the line

Adv_SetElementXML = machine

and change machine to game so it looks like this:

Adv_SetElementXML = game

For the categories question, I am not sure what you mean.
Headers for Redump dats look like this:

        <name>Sega - Dreamcast</name>
        <description>Sega - Dreamcast - Discs (1277) (2019-11-14 22-30-10)</description>
        <version>2019-11-14 22-30-10</version>
        <date>2019-11-14 22-30-10</date>

What are the categories you are referring to?


(2,818 replies, posted in General discussion)

I am sure a good explanation exists, but thought to ask about it.
I just dumped a PS2 CD ROM: http://forum.redump.org/topic/25130/ps2 … to-no-ken/
At first pass, the dump came back with some C2 errors. However, final checksums of the dump with the errors were the same as the existing verified dump. I gave this disc a thorough wash with soap and it fixed the errors, resulting in same checksums again but this time with 0 C2 errors as expected.

I was wondering how a disc with C2 errors can still come back with the correct checksums? Theory says that C2 is uncorrectable error which *should* break the dump and cause wrong checksums, but probably I understand something wrongly here and would love to hear explanation from the experts. smile

Logs of the dump with C2 errors: https://mega.nz/#!30hAyAyB!eRiljbOBIBnf … pwpe5hgZ1Q
Logs of dump of same disc without C2 errors: https://mega.nz/#!v95wWYhJ!Pp7cAIze9SnG … hERx9f-gF4

I have to agree with F1ReB4LL on this.
When you are dumping/doing preservation work, you should not be hacking things to compliance or to "intended" values, even if that feels convenient and/or reduces number of dumps. You are supposed to be documenting the disc itself (not just the data that is on a disc). Nothing more, no less. If the disc is crap, you have to document a crap disc, not make it look nice and proper.

In my opinion, any other approaches would be exactly the same big NO-NO like an archaeologist discarding a fragment of bone or pottery because he has already thousands of very very similar fragments. Or to correct a grammatical error in an ancient script because what was actually written and what was intended to be written were not the same.

I agree that this approach may feel counter intuitive to the layman and that it is even pointless from a gamer's or rom collector's point of view. However, preservation is just coincidentally useful to these categories and should not be going out of its' way to cater for such needs. Documenting discs is the point here. At least that's how I understand the project.


(2,818 replies, posted in General discussion)

sarami wrote:

http://www.mediafire.com/file/q5b8c94jv … st.7z/file
- fixed: TimeOutValue was not set

Good news on my side. smile
With this release, there's no longer any error message in the console window (I am tempted to say DOS to make F1ReB4LL correct me again, xD) and the output seems to contain title keys normally.
Attaching 3 consecutive runs for each of the 2 discs, results are identical in all 3 runs.


(2,818 replies, posted in General discussion)

sarami wrote:

Uploaded test version. http://www.mediafire.com/file/q5b8c94jv … st.7z/file

F1ReB4LL wrote:

GetLastError: 2147681032 Copy Protection Error - DVD session key not established

- fixed: establishment of session is needed per title key for some drive

sarami wrote:

It seems [001] to [081] are all same every time, but the remains are all different every time.

- fixed: mpc-hc original code

Tried using this new test version.
I have an LG USB DVD (GP65NB60 model)
When I run it I get this message:

D:\Downloads\CSS\Release>css s out.txt
[F:ExecReadDisc][L:150] GetLastError: 87, The parameter is incorrect.

lpCmd: a8, 00, 00, 00, 00, 10, 00, 00, 00, 01, 00, 00
dwBufSize: 2048

This message was the same in 20190531.

It produces output with matching keys after 81, unlike the 20090531 version I tried earlier.
But, output files end without the expected list of files (none of the LBA, file, key is output) :

[406]: 7B 8A DB 7A 9E [407]: 89 9C 3B E4 ED [408]: C7 D3 CA 2E B6 [409]: 7E 9E 1C 8B EF
PlayerKey[1]: 01 AF E3 12 80
DecryptedDiscKey[020]: 2E 90 FE F6 E8

This behavior is the same in this version and 20090531.
Attaching results of 3 consecutive css.exe runs for the 2 discs I have here, DICUI output logs for the same discs can be found on the relevant dumps thread.

My drive is region 2. Historical Disc is also region 2. Dramatic DVD is region free (1-8).


(1 replies, posted in Guests & account requests)

Full marks for honesty, but there are exactly ZERO game downloads in this website. Just FYI.

Thanks for the kind words and for accepting me. Submitted some dumps already as promised.