Dumping tools and games (Page 1 of 2)

As long as the program and platform you run use the standard 0xBE read command, the dump is raw (2352 bytes per sector) and you have a minimally decent drive everything is OK and extension doesn't matter actually. Anyway, for CD discs we don't add cooked dumps, 2048 bytes per sector.

To put this simple taking as example a conventional, without Safedisc, SecuROM and these things, PC CD game with just a data track extracted by Isobuster in raw mode, CloneCD (when using this one TURN OFF regeneration of data in the read profile, we don't want that CloneCD fixes in the fly user data of damaged sectors using the stored ECC because this is as dumping a disc into raw mode to fix later bad sectors using CDmage, dumps shouldn't be modified in this sense) and Alcohol 120%.

bin of bin/cue = img of ccd/img/sub = mdf of mds/mdf (only if subcodes weren't read, if so mdf will contain interleaved subcode data and you need the 2448to2352 program by themabus to split the mdf file into main channel and subcode). Simple as that.

Problem are discs with audio tracks, you have to find a program for Linux which can:
-Perform a secure ripping, either by multiple reads or C2 pointers.
-Correct the offset, any value you desire once detected the proper one.
-Detect properly gaps and append them to the next track.
*-Detect possible CATALOG/DCP/ISRC flags (this ideally for discs with only a data track as well).
-Extract to headerless files, or at least run sox to remove RIFF headers.

*Answer to the "Is cue good enough for detailing all the intricacies of the disc or is there some more information" question. To detect them PR is good and for discs without copy protections and with just a single data should work even without a real Plextor drive.

That page contains updated and accurate data, was written by MrTikki after asking me and others lots of questions to write the best possible guides yet easy of understand.

Guide basically says that you should extract the data track as usual using IsoBuster, raw mode. You should dump the disc at least twice and make sure that dumps are identical, better yet if using different drives when possible.

Nothing more is needed for the DB, except obviously the errors count (1 expected error in the postgap zone) and perhaps a quick and dirty subcode dump got by CloneCD/CDManipulator (subdump only if are really interested in getting the cleanest subcodes possible, but it's very time consuming and for detecting CATALOGs and so on even a quick and dirty subcode dump by CloneCD is good enough) to determinate properly if the disc contains CATALOG and other possible flags. One good strategy and efficient would be dumping the disc as usual using IsoBuster, and then a CloneCD/CDManipulator (see the screenshot posted below) dump with the proper profile to kill two birds with one stone: to verify the IsoBuster dump and to get the quick and dirty subcode dump that you can upload (subcodes compressed are very small files).

For you personal backup and archive perhaps you could desire to create a mds file for that disc. Create it and archive it. If the dump by Alcohol lacks of subcodes mdf file must match the dump got by IsoBuster and/or CloneCD/CDManipulator.

P.S.: CDManipulator can create .ccd files if you choose that in the file output options once selected the multi-session mode. Just use any plain text editor to delete the ficticious ISRCs which uses to add due to random errors in the subcode not properly ignored.

[TRACK 1]
MODE=1
ISRC=0@41=0100013
INDEX 1=0

[TRACK 1]
MODE=1
INDEX 1=0

Subdump:
https://www.dropbox.com/s/dmkd2l490mtdrm1/subdump.zip

Reference of command line for a non-real Plextor drive:

subdump.exe -i g: -f test.sub -mode 1 -rereadnum 25 -speed 8 -flushspeed 8 -fix 2

Optimal speed depends on the drive used. Certain drives read better at lower speeds (4x/8x), others one at higher speed (24x and higher).

If there is a  real Plextor drive which supports D8 command:

subdump.exe -i g: -f test.sub -mode 2 -rereadnum 25 -speed 8 -flushspeed 8 -fix 2

And if you are just interested in getting a quick and dirty subcode dump, somewhat cleaner than the one got by CloneCD/CDManipulator and verifying the linearity of subcodes frames add the -quick parameter.

bin/cue should be good enough for every common disc layout. ccd/img/sub is needed actually in certain discs which contains mixed type pregaps (75 sectors of data + 150 of audio, being the first ones marked as data in the subs). bin/cue cannot handle this layout, ccd/img/sub can because actual .subcode is present. mds/msf for this protections which measures physical disc positions.

Anyway, converting bin/cue to ccd/img/sub if you prefer this format in the future is trivial: just mount the image, create a CloneCD/CDManipulator dump (.img file created should match the original .bin) and replace the .sub created with the one dumped by subdump.

Even if the disc is in near mint condition and not affected by discrot, subdump takes some time to dump the subcode (not protected by CIRC, so no error correction is offered and a high ammount of rereads is needed to get uniform and constant data). For a disc in good condition with more or less 70 minutes (740,880,000 bytes of data extracted into raw mode), without any class of deep scratch, expect easily 45-60 minutes.

Only MDS format can capture data of physical measurements (due to that it's suggested in the guide to create one MDS file for personal use), needed for SecuROM and StarForce. ccd cannot capture that, it's a simple .txt file similar to a .ini file which describes the TOC, but nothing related to physical measurements. I doubt that a personal backup will work without doing anything special due to the physical measurements performed by the protections.

RPMS needed to burn and Alcohol to emulate DPM data. Perhaps Daemon Tools with SPTD installed, to enable advanced emulation options can mount the image (or even create it in certain advanced editions) and get this image acting as the original disc in order not to wear the precious original disc.

For Safedisc, a decent burner capable of burning weak sectors (decent EFM encoder) and done, as far I remember.

It's extremely unlikely that you rip to mds/mdf once CD several times and you get the same hashes, or directly impossible due to random errors in the subcode:

http://www.mediafire.com/?p8on996xtmrb8

2448to2352 can split the MDF file into main channel and subchannel. Main channel should be always identical and uniform for these these discs. Subcode is always affected by random errors.

2352to2448 to do the reversed process: convert a clean subcode and the raw dump into a MDF file reusing the MDS previously created.

Separated compatibility is better, can be used as bin/cue, ccd/img/sub image and opened by programs as IsoBuster and CDmage. The major thing is understand that MDFs of CD discs won't match due to random errors in the subcode, nothing more. Once separated, main channel should match if the dumps are good (and should match IsoBuster, CDManipulator's... imgs if disc doesn't contain audio tracks).

Erroneous sector of CDs discs protected by SecuROM is in the postgap, the 4th sector from the end. This sector reminds the last sector of data tracks of PS1 discs without EDC in form 2 sectors and with audio tracks, looks very similar, a mode 2 sector with erroneous ECC data.

A read error doesn't sound good, even if sectors 0-15 are don't contain normally useful data in PC games, it's normally used only for console discs (header and whatnot of Saturn games, logo and license of PS1 discs...).

It's a lossless process, converting from MDF to img+sub (2448to2352) and reconverting img+sub to 2448 (2352to2448) and then renaming to MDF gives the original MDF file. And that .sub file can be replaced with the extracted by subdump and the MDS will be still valid of course.

Subcode data is mainly useful for multitrack discs, to detect accurately the gaps of tracks and imperative for these EUR PS1 discs protected by LibCrypt. For normal PC discs with just a data track even bin/cue is just fine, so perhaps ccd/img/sub (accepted by CDManipulator in RAW DAO 96 mode, by ImgBurn as well, but will ignore the sub and subcode will be generated by the burner) is the optimal solution.

CD Manipulator does support RAW DAO 96 burning, subcodes generated by the software (when no sub is available) or read from the sub file. ImgBurn is simply RAW SAO, subcodes generated by burner according to the cuesheet sent.

Regarding dumping of Tagès:

http://club.myce.com/showthread.php?t=51912
http://club.myce.com/showthread.php?t=89212

This subforum:
http://forum.redump.org/forum/11/dumps/

As template, but specifying more clearly what is mastering ring code, mastering SID code, toolstamp, mould SID code and additional mould text, layer from that code and we put <TAB> for any ammount of multiple spaces:
http://forum.redump.org/topic/13553/

Taking this as example, would be this way:

http://redump.org/disc/29391/

Mastering ring code:
Sony DADC<TAB>5057288DVD 01

Mastering SID code:
IFPI LY33

Mould SID code:
IFPI AEW37

And because it's a single layer DVD, only there is codes in that layer, as general rule (certain DVD-5 discs can contain a dummy second layer with codes more or less readable depending on how the artwork cover these codes).

For ripping PC discs with audio tracks, ideally a real Plextor drive should be used, or at least a drive which supports the audio trap disc method to dump the entire disc into scrambled form, and process it manually. My Pioneer DVR-107D, 110D and Optiarc AD-7240S supports audio trap disc method via ejecting the tray by the emergency hole just fine. And my Lite-On LH-20A1P and LTR-48246S support audio trap disc too, but for that these drives have to be dissablembled and used externally to hotswap manually (for that I have many spare magnetic disc holders ripped from the top cover of dead drives) inserted disc without resetting the TOC, so drive thinks disc inserted is a CDDA and can be dumped into scrambled form without modifications.

For more or less *standard PC discs with audio tracks, the classic IsoBuster+EAC method once detected the combined offset should be fine, anyway.

There are currently 5 Half-Life discs of that region in the DB:

http://redump.org/disc/10506/
http://redump.org/disc/26040/
http://redump.org/disc/16573/
http://redump.org/disc/26001/
http://redump.org/disc/25966/

You cannot dump properly track 2 of /disc/26001/ with neither a real Plextor or a swappable drive. Anothers ones yes, assuming that last track isn't truncated by the offset when drive used lacks of overreading into lead-out hability (my Pioneer DVR-107D/110D and my Hitachi-LG GCE-8526B are conventional drives and they can read into the lead-out).

*: no mastering errors, no scrambled data sectors in the first audio track's pregap, no audio sectors in the data track and a generous amount of digital silence in the ending of last track.

This is not explained in the official guide, because majority of "hardcore" dumpers started to use real Plextor drives and therefore manual method was considered obsolete...

When in the pregap there is at least one entire scrambled data sector (=2352 bytes/588 samples) or more scrambled data with a visible header, first visible header should be observed very carefully.

Requested sector is 22:19:25, and because that sector is marked as audio by the subs drive won't correct the offset. Neither unscramble data.

Drive provides a part of 22:19:20 and the beggining of 22:19:21, that header you can see. Drive is reading 4 sectors before than expected, plus 2324 bytes (because sector 22:19:21 [23:99:21 in scrambled form] starts at 0x914 offset in that screenshot).

2352*4 bytes +2324 bytes = 11732 bytes. Read offset of drive used: +6 samples, +24 bytes.

(11732 bytes - 24 bytes)/4 bytes per sample = 2927 samples, the expected one and verified via a real Plextor drive:

http://redump.org/disc/29165/

With the classic way, user will see that there are 16436 bytes of scrambled data, so that will think that offset once subtracted the read offset of the drive is 4103 samples. Very wrong, because in that pregap there are two scrambled data sectors which belong to the audio track.

Sample of pregap used, untouched and the valid sectors unscrambled, being 22:19:21 the first one.

https://www.dropbox.com/s/t0h467nl9y84v … 0offset.7z

==========

Once properly detected and configured the offset, any drive should dump the very same audio tracks, if there are mismatches (without taking into account read errors themselves):

-First audio track with data in the pregap. In the posted example, if you delete the first 11732 bytes matches the pregap extracted via a Plextor drive and cdtoimg-d8. Sometimes pregaps with scrambled data sectors can be recovered by extracting the pregap range via IsoBuster, adding a few of extra sectors to correct the offset. In this case, extracting 100300-100460 (10 extra sectors to overdump a little) sectors, deleting the first 11732 bytes and resizing the bin so that size is 352800 bytes (deleting now useless data from the ending, not from the beggining). That would be the pregap with data, which could be pasted into the track dumped by EAC to restore it.

-Gaps badly detected, use another drive or another method of detecting gaps in the drive's properties, until getting gaps which make sense. And always configure EAC to analyze EAN aka MCN aka CATALOG and ISRCs, another thing not mentioned in the guide, to get more complete cues, because many discs have the typical CATALOG 0000000000000.

-Last track truncated. With a +667 drive it is somewhat likely that certain last tracks are truncated. Hot swap method (any useless [or not useless if you treat it well and carefully in the process] CDDA disc bigger (speaking of size in sectors) than the disc to dump is fine for that) and then you can run to recover the lost audio samples. Extract the first sectors of lead-out (previously known that sector, for Fury^3 is 191780) and replace the xyz bytes of the track dumped by EAC with the xyz bytes of the lead-out, where xyz is the combined offset for that disc/drive combination. An easier alternative would be another drive where combined offset for that disc is negative (for example, +6 drive for -22 and -12 discs, at least to dump the last track, never the first one unless you restore the possible missing data) or a drive which can overread into the lead-out.

For that drive:
C2 error reporting enabled.
Cache defeating disabled, because caches audio data under 64 KB of audio. 37/39 KB as far I remember.
And of course, makes use of Accurate Stream, because any decent drive since 1998~2000 offer Accurate Stream = constant and predictable offset, not something like +113 in a read, +115 in other, +116 in other... an 8x CD-ROM drive by Panasonic which jitters.

And try +667-12 for that disc, -16 samples isn't a common offset. -12 is.

To mount the image, don't forget to replace MODEx/2xxx with the proper one (MODE1/2352 or MODE2/2352, pretty obvious seeing the byte 15 of the dumped data track, 01=MODE1 and 02=MODE2) and replace every .wav" WAVE with .bin" BINARY, because audio tracks dumped following the guide lack of header.

==========

CCD question: make a CloneCD dump and replace the img created with bins concatenated:

copy /b "Track 01.bin"+"Track 02.bin"+"Track 03.bin"+"Track 04.bin"+... "Name of the IMG.img"

Done, CCD image with the audio ripped securely and with corrected offset. And additionally sub could be replaced with the dumped by subdump if you care.

I am writing this reply to personally thank you pablogm123. You have helped so much in dumping these games, and I wanted to make sure I got them dumped as best as possible. Thank you very much and I very much appreciated what you have done for me.