1 Reply by norman

(7 replies, posted in General discussion)

Technically any processing done to get the intelligent checksum cleartext could also be done in patching tools with appropriate metadata (though you'd have to change those tools a fair bit). The tradeoff is between accuracy and convenience, on a sliding scale. Eidolon's proposed method is more convenient but less accurate, and vice versa for the redump.org method; Some people want one, others the other (personally I'm of the opinion that dumping them 100% accurately once is worth the work, instead of having it easier for more people -- the dumping really only needs to be done twice or so to get verified good dumps; others can then use that baseline data to do their dumps in any way they choose (for instance, once the offset is known and confirmed by somebody with a proper drive for it, nobody else needs to figure out that write offset again when they do backups of their own discs).

For PSX the redump.org method is, IMHO, currently the best one known and it's unlikely that a better one will come along any time soon. Same for other "regular" disc formats (such as acd32, segacd, etc.) IMHO -- even though dumping ECC data may not strictly be needed, it does not diminish the quality of the dumps -- and offset detection works just the same. The guide does not really cover more modern copy protections (such as those found on PC games) and how to properly preserve their data; most research in that sector in the past has gone into how to circumvent them, not how to preserve them (unless that circumvention is doable with a 1:1 copy of the protection scheme, but in that case it ain't much of a scheme).

Go to forum: General discussion

2 Reply by norman

(11 replies, posted in General discussion)

You cannot always detect the offset in a CDRWIN image; This is the reason some of us use multiple drives on specific discs (those that "appear" to have an offset of 0, i.e. first data sector of 2-second gap is completely filled with zeroes). You'd need a drive with a large offset to properly detect the factory write offset on these (for instance, discs such as http://redump.org/disc/1348/ will have problems unless your drive read offset is > +647); such drives generally can't read subchannel data though, and probably don't have C2 error reporting, either -- so multiple drives to dump the same disc are needed.

As for pregap-detection : Neither cdrwin nor EAC behaved too well here thus far. I've had both of them give me nonsensical results (and inconsistent with themselves, too); So far, PerfectRip had the best detection, and I suppose the cd xpert tools would probably have the same.

Go to forum: General discussion

3 Reply by norman

(7 replies, posted in General discussion)

Hi Eidolon, nice to see you're still around :-)

I disagree with the redump.org method on the following points
ripping RAW mode data for all SegaCD and Saturn games is not necessary. The Inn Method will concentrate on USER DATA only
MODE1/2048 for SegaCD games
MODE1/2048 and in some cases MODE2/2352 for Saturn games

Will the ripping contain a check that this data is superfluous ? I.e. even if data is saved in 2048 byte sectors, will a check be performed that verifies that the ECC information can be recreated in the standard way ? (I assume this will have to be done for Saturn games since you mention the possibility of them having to go RAW).

applying any audio data shift to the ripped binary files is not necessary to achieve comparability and maintain playability using virtual drives or emulators. The Inn ripping method will only take note of the drive read offset. Write offset can be calculated from that and the ripped image, but this is done solely to maintain comparability with redump.org database.

Given the case where the offset is not so far in the negative that most drives cannot detect it properly (this is an issue on PSX, no idea whether it comes up on Saturn or SegaCD). So long as this offset is known, however, the data layout on the CD can be recreated exactly as it was on the pressed version, so carrying this metadata is a good thing :-) There's also the issue of positive offsets and shifting of legitimate audio data into the leadout (which may be cut off), though you seem to opt for manual handling of these cases.

handling of separate files for data and audio tracks is unecessary. One single BIN file per CD is the right way to go

On this I'd disagree, but it's a contentious issue to debate. The single-file approach doesn't allow stuff like compressing audio tracks separately with more appropriate methods (i.e. flac vs. 7z), and checksum-verifications are harder on the entire image in some cases. But oh well smile

Go to forum: General discussion

4 Reply by norman

(1 replies, posted in General discussion)

Hi,

themabus wrote:

1. i've checked my SCED-02492 pal demo disc that you have listed in db and indeed i can get all crcs
excep 1st audio track, because it gets pushed in pregap with offset and i have +6 dvd and +400 something cd, i guess i would need ~+700
to fetch out first bytes. but it seems weird because as far as i can read it's still data, all other audio tracks have wav header
and then few k.bytes with 00s and only then data. could it be that there is no wav header in audio track or data starts right after header?

Ordinarily, CDDA tracks SHOULD NOT have RIFF headers. Those are oversights by the guy who mastered the disc. Some discs have have tracks bear RIFF headers while others do not (I don't have that particular disc, so I can't tell). The offset of your drive should not really matter too much, though the ability to read data from gap-sectors does (at least if that data is not all zeroes). Quite a couple of drives have trouble with that, unfortunately.

themabus wrote:

2.in guide you say: 'psxt001z.exe --fix "Track 01.bin"' what seems like ecc/edc repair+some structure checks
sorry if i'm wrong but doesn't this defeats the whole idea of dumping in raw? i mean if i dump original cd and ther's some mess with sectors
and then fix it and somebody else dumps and fixes we will likely get same crc but is it ok, shouldn't it have been left messed?

Usually, --fix will fix one sector only, that being the very last sector in the data track if audio tracks are following. This corruption is not necessarily deterministic across drives. If psxt001z attempts to fix or fixes more sectors, something is wrong and the --fix should not be performed. This is on a case-by-case basis, really.

...one more thing
3.i'm sorry for this but i don't mean to offend anyone. i can see why dumping from originals is so well defined and in need of extreme precision.
and when it is done people can check their stuff with .dat. but i think most don't have files seperated in that way, by tracks, and those offsets can
really mess things up

Yes, the format is not the same you see "usually" on the net (.bin/.cue).  Offsets are not taken into account when ripping with, say, isobuster or cdrwin. If all you are interested in is an imperfect copy, there are plenty of other sources that'll give THAT to you, and don't care about any errors or variations across drives. This is just not one of those places.

and i just thought that maybe you would attract more people if there would be some gui tool that could do scan on images like
your commandline program can, or something similar. like crcs and structure and offsets and probably around 1kbyte of 1st audio track (it's the main
concern, right?)

The audio tracks would all be shifted, and the last audio track will have similar issues. Furthermore, it can be hard to detect ripping errors on audio tracks when not using C2 error information or the EAC secure ripping modes. Many, many images out there have exceptionally crappy quality in this regard (often, they are dumped from copies that may or may not have been cracked, tagged, or whatever else, and even if not, no care has been taken to get a bit-accurate stream of the disc). Even single datatrack images suffer from this. It's just a sad reality that many, if not most, images out there are of shoddy quality, and limited information which would help determine which ones ARE of shoddy quality. Add to that the many folks that just don't care if the boot sector picture has been replaced or a video contains artefacts or some audio samples are broken, 'cause, after all, "it plays the first level, so it MUST be a good image".

would be reported by dumper (like is now) and defined in tool and then all could have image checked with one click or something.
but maybe i'm way off from reality. i know that images are different, as far as i can remember one had zero bytes as ascii 0 other as hex or
something and others have headers and subchannel stuff but can't it be pulled off? i mean maybe people would be so much into this if they could just
point and click at their images and get results.

What you are referring to with zero bytes would be the EDC checksums that are often zeroed on older discs' XA form 2 sectors. This is not something you can just "check" and change to whatever the database says. Some discs have been released in diffferent versions, both with and without EDC but otherwise the same data. How would the tool know that the disc you just dumped isn't a DIFFERENT version from the one in the database, i.e. a different release/edition/pressing ?
(The other way a previously zero-edc track would gain EDC would be "intelligent" burning utilities or burners that just add this information when not burning in raw mode. Dumps from copies are always dubious; few, if any, cd copy or burning programs take the drive write offset into account, for instance. Whoops.

As for a shiny GUI tool that does most of this automatically : sure it's possible. Are you volunteering a big chunk of your time and knowledge to develop and support such an application ? I'm not, sorry. Maybe somebody is, and if you find that somebody, all the power to them.

Go to forum: General discussion

5 Reply by norman

(9 replies, posted in General discussion)

Most platinum versions do not differ, some differ significantly. If possible, always note which edition of the game you have.

Was the game you tested your alcohol test with a game with just one audio track ? Could it be that that track contained only zeroes ? In that case drive offset will not really come into play in most drives (some may have some garbage in the first few samples though, but that's not the norm).
While Alcohol and some others can "handle" most copy protections, never equate that with making an exact dump of the data. Copy protections would usually not be dependant on a particular drive offset (since the protection can't really know what drive it is currently running on), so that's irrelevant for Alcohol to get right (... for now; theoretically one could add a calibration track to the disc, calculate the drive's offset from that, and then use that to check against some custom write offset for copy protection purposes, but AFAIK nobody has done that (yet).

Is this the issue of the old mastering equicment from Sony producing EDC with wrong reported values?

Well, technically it produces no EDC at all, i.e. the EDC field is left blank (or you might look at it as an EDC with 4 zero-bytes as its content, which is highly improbable).

Before dumping I check discs with VSO Inspector, an freeware disc-testing app. On every discs, there are some errors in the first sectors (0 - 16). Is this the area where the copy protection is stored? Nevertheless I got perfect dumps with the same hashed as stated in the db, so i guess that's normal?!

That is indeed the case. The EDC in those XA form 2 sectors is zeroized, which does not match the data at all; any self-respecting checksum-checker should complain about that, and that's probably what your tool is doing. It might be interesting to try that tool on a disc without EDC, or rather, the broken EDC mentioned above wink It should really only be sectors 12-15 though (sectors 162-165, if you count the lead-in).

The dumping process is indeed a little convoluted, but in so doing it tries to preserve all the elements of the original disc as best as possible (i.e. not just taking drive-read-offset into account, but also write-offset from the manufacturer. The latter can be a royal PITA to detect properly on many discs that sport large negative offsets, however (since you'd need a drive with a large positive read offset to even see the mentioned garbage data).

Go to forum: General discussion

6 Topic by norman

(0 replies, posted in General discussion)

psxt001z by Dremora, v0.20 beta 12

File: Final Fantasy IX GER Disc3of4 [SLES-22967].bin
Size (bytes):   730458288
From image:     730105488
Size (sectors): 310569
From image:     310419
EDC in Form 2 sectors: YES
ID: SLES-22967
Date: 2000-11-10
System area: Eu EDC

Go to forum: General discussion