Resurfacing can't fix all errors. Particularly, hold your discs against a strong light source and look carefully at the data surface for any tiny holes that allow light to shine through. If you get any, the disc is permanently damaged and can't be fixed. Any such disc is not worth attempting to resurface as it has label side damage and data is lost for good.
If none found, resurfacing one more time with a good professional machine may be worth your time.

2

(3,497 replies, posted in General discussion)

sarami wrote:

DVDAuth also crashes for the same reason. Fixed it.

https://www.mediafire.com/file/eq80y20l … st.7z/file

Apologies for late reply, I was very busy this week. This version fixed the problem and the disc is now dumpable. Thank you!

3

(3,497 replies, posted in General discussion)

sarami wrote:

DVDAuth returns no error.
If other DVD-Video discs are no problem, I have no idea about this now.

Everything else dumps fine.
I ran DVDAuth on its' own.
With command dvdauth F css out1.txt  > I get a blank out1.txt  (same behavior as the CSSKey.txt
With command dvdauth F cppm out2.txt and dvdauth F cprm out3.txt I get identical files that contain only:

AlbumIdentifier: 8d 24 d8 32 77 85 df 45

If any of these mean anything...

4

(3,497 replies, posted in General discussion)

sarami wrote:
Maddog wrote:

I believe the problem now is extracting CSS keys correctly, since the CSSkey.txt is blank.

It needs a screenshot of the command prompt.

Attached.

5

(3,497 replies, posted in General discussion)

sarami wrote:
Maddog wrote:

Unchanged behavior.

Uploaded. Link is the same.

Definitely on the right track, it now started dumping and created a small .iso.
This time it fails because of "Read of scrambled sector without authentication".
I believe the problem now is extracting CSS keys correctly, since the CSSkey.txt is blank.

Tried also with command prompt with admin privileges, just in case. No change.

6

(3,497 replies, posted in General discussion)

sarami wrote:
Maddog wrote:

The Shooting Love is still behaving the same, exits with no messages.

- added: check if the directory record length is really correct
URL link is the same.

Unchanged behavior.

7

(3,497 replies, posted in General discussion)

sarami wrote:

- fixed: the buffer size when analyzing the IFO files

Test version fixed the problem with Kingdom II-Shadoan, which dumped with same CRC as the Isobuster dump.
The Shooting Love is still behaving the same, exits with no messages. This is the one that creates a 0 byte .iso before crashing, so probably I was right they are not crashing for the same reason.

After looking at it a little more, I suspect a possible reason: this DVD according to Isobuster has an illegal LBA in its' filesystem and also has files with Japanese names. Please refer to attached screenshots. Maybe this is the reason? Attaching also the logs that were created this time.

8

(3,497 replies, posted in General discussion)

Got 2 DVDs that simply refuse to dump.
When you execute DIC, it just exits without any message and without completing the dump. Maybe the cause is not even the same, because in one case a 0-byte .iso is created while on the other, no .iso gets created.
The problem DVDs are the older version of Kingdom II-Shadoan USA (the one that doesn't show "PS2 compatible" on the cover) and the Japanese Insanity DVD: The Shooting Love: XII Stag & Trizeal.
Tried with a Plextor 755A DVD and an LG WH14NS40 BluRay.
Tried with DIC directly and through MPF. And of course using latest DIC version.
Both discs dump fine in Isobuster.
Whatever logs get created are attached.

9

(3,497 replies, posted in General discussion)

sarami wrote:
Maddog wrote:

DIC somehow lost its' ability to dump CD Text.

Because CRC of the last entry is bad.

Entry 138 crc[0000] is Bad

But 0x8f does not affect the cue sheet, so CD-TEXT output is permitted.
https://www.mediafire.com/file/eq80y20l … st.7z/file

Confirming that the disc dumped correctly with this test build, including CD Text.

10

(8 replies, posted in General discussion)

fuzzball wrote:

Does this mean that all FM Towns applications will be allowed?

AFAIK, anything related to FM Towns CDs is allowed.

11

(8 replies, posted in General discussion)

Microsoft Plus! 98: Companion for Windows 98 contains some games, so it's within scope for Redump.
I don't know if Microsoft Windows 95 Companion: With USB Support is similar, since contents are not listed and a quick Google didn't return too much specific information. Most likely it was allowed for the same reason, I believe.

All the others are either games or stuff related to Dreamcast (this PC disc is a devkit for Dreamcast) and FM Towns, which is allowed.

12

(3,497 replies, posted in General discussion)

DIC somehow lost its' ability to dump CD Text.
Discovered it while trying to redump http://redump.org/disc/70938/

Logs from latest test version downloaded from previous post (I also had same no CD Text results from monthly 01/04/2021 version)
https://mega.nz/file/K4IkkTjA#E03w979hQ … FwJllxc5K8
Logs from 02/02/2021 version (which appears to be working properly).
https://mega.nz/file/71ZAVLoa#RDS-LdElH … xOSrVrWZlc

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.

17

(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:
https://www.amazon.com/gp/product/B0019HLE7Q
https://www.amazon.com/gp/product/B00P0C4M5M

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.

20

(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.

21

(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.

http://redump.org/disc/39867/
http://redump.org/disc/65686/

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

22

(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"

thanks!

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:

     <header>
        <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>
        <author>redump.org</author>
        <homepage>redump.org</homepage>
        <url>http://redump.org/</url>
    </header>

What are the categories you are referring to?

23

(3,497 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.

25

(3,497 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.