Search options (Page 47 of 66)

Meh, no, it's a bad mastering afterall, very similar to http://redump.org/disc/34036/
First 88706 sectors are correct, the next sector has 1104 bytes of data, then 7508 bytes of zeroes, then it goes data again, but, of course, shifted by 7508 bytes. The first 7508 bytes of the audio track also belong to the data track.

So the DIC dump is as correct as possible, though, the image is non-functional in this form

If to cut that 7508-bytes sequence of zeroes and glue them to the end of the 2nd track, then split the image and descramble the data track - the image doesn't have any errors and the audio track doesn't have any incorrect data.

Disagree. IMO, we should include any imperfections into the total errors count. Otherwise, there should be a "Warnings" count field as well.
I'm not talking about NoEDC sectors in NoEDC images, of course, I don't understand the reason to warn there.

"Number of sector(s) where while user data does match the expected ECC/EDC there is no EDC" -- most likely these numbers just show the number of Mode 2 Form 1 sectors in the NoEDC image, these are not errors.

I think it's better to report the number of errors from CDMage, because edcchhk treats many cases as "warnings", that's confusing.

Well, my own idea was to list all the "main" titles first, each title would have "releases" (distinguishable by serial or barcode, 1 serial = 1 release, even if different packages exist) and each release would have subreleases with possible alt rings/revisions/scan variations.

CD scans would differ due to different ringcodes. One of the main ideas was to make the ringcode scans/photos mandatory.

And after adding all the scans we could make CAPS/SPS-style xml dats (gameinfo.xml with all the scans and binaries and their checksums). That would be the real preservation. We even had D4ve guy who was going to make us a perfect scanning convention and guide, but disappeared.

DIC and PerfectRip (for confirmation) for Saturn, yes.

Yes, gone. http://forum.redump.org/user/2/ -- no visits since 2010 and no db engine modifications from him since, dunno, 2007 or 2008. iR0b0t is only capable of doing little corrections, AFAIK. I only remember small form/field fixes from him for certain systems, adding some additional CUE fields handling and adding the total image CRC (with the V's help).

Wii dump was overlooked or something, dunno, it's added now. I don't know how to verify DC, GC/Wii and XBOX/360 dumps, anyway, they are in their own tricky format requiring specific drives and specific tools.

PC is a different story. Since all my ideas were totally ignored even by Dremora (while he was still an active coder), the PC section is a total and barely maintainable mess now. What should be done from the very beginning is to split the PC section to Win16, Win32, Win64, MS-DOS, OS/2, *nix, BeOS sections, etc. Only then it would be more or less possible to maintain the dumped/undumped lists and all these sections separatedly as well as properly adding all the stuff instead of putting everyting into a single bottomless bin. And then we have another problem - inability to assign more than 1 system per entry, that's a fundamental database issue, Dremora was going to code so-called "Redump 2" engine able to handle that (as well as subchannels, cover scans, bonus materials and all the other possible stuff), but abandoned the project. So, at the moment, only Jackal and Nexy are adding PC dumps from time to time picking the ones to add by their own logic. And yes, many PC titles are heavily protected with gazillions of different protections (compared to the consoles, where all the discs have the same format), so you can't just add these blindly.

EAC doesn't read post-data pregaps, always ignores them and replaces with zeroes. EAC author says that's intentional and refuses to do the proper reading, also, bans everyone who tries to argue with him on the forum.

The important part for verifications isn't the data submitted by the dumper, but the provided logs, so the mod could see, if the game was dumped properly to avoid the case when the first dump was taken incorrectly and the "confirmation" was done the similar way.

If you read these sectors with IsoBuster - do you get proper descrambled data or some kind of read error? I believe, that proper sync is mandatory for descrambling.

Redirects to http://www.ggmania.com/

I've seen many cases when DIC simply replaced the sub sector, so I don't trust its subs.

According to the P channel the EAN sector belongs to the previous track. The first sector of pregap should have zeroes in the P-channel, the next sector should have FFs. The first non-pregap sector after the gap should also have P-channel padded with FFs. This is described in rainbow books.

DIC doesn't make good subs, too many fixes/replacements.

http://forum.redump.org/topic/14725/subdump/

subdump -i D: -f test.sub -mode 6 -rereadnum 25 -fix 2 -- precise dump, slow (for subchannel archival purposes)
subdump -i D: -f test.sub -mode 6 -rereadnum 25 -fix 2 -quick -- fast dump (not suitable for archival, but good enough for gap detection).

D: should be PX-760 used for DIC.