Rage Racer is affected by this too, Die Hard Trilogy as well. Likely hundreds of PS1 JAP games (and who knows whether game discs for another platforms manufactured by Sony DADC Japan are affected, because just to mention one example, certain version of Lethal Enforcer (USA) for Sega CD is manufactured by Sony DADC Japan) contain this special pattern in the R-W frames. Externally, I see certain correlation: affected discs contain the IFPI 45xx code in the hub itself, whereas non-affected discs (Racingroovy for example) have the IFPI 45xx code in the read side of the outter ring of the hub, where the mastering ring code and the mastering SID code are located.
That sub file has the expected size,
Session 1, Leadout, MSF 53:17:64 (LBA[239839, 0x3a8df])
Last frame of the subcode has 53:17:63 AMSF, so at least the .scm should be complete and app fails when post-processing the scrambled dump, not before.
I would say this is the problem, or at least a part of the problem.
LBA[147352, 0x23f98], Track: Subchannel & TOC isn't sync. LBA on TOC[148449, 0x243e1], prevIndex
Completely wrong, because MotorMash_disclog.txt says:
Audio Track 2, LBA 147352- 148448, Length 1097
Audio Track 3, LBA 148449- 161236, Length 12788
And seeing the dumped subcode, track 2 - index 01 starts at 32:46:52 AMSF = 147352, track 3 at 33:01:24 AMSF = 148449, as expected according to the TOC analyzed in the very beggining of ripping process.
Re: Question about dumping games with lybcript protection (1 replies, posted in General discussion)
Sent a PM in Spanish explaining the question.
Update the firmware ASAP.
Fully zeroed C2 file (if you have installed WinHex, just press Control+Alt+X and search for !00) = dump without E32 errors. Dumping process should be done ALWAYS with this parameter, to discard E32 errors in the dump.
Invalid field in CDB means basically that either an unsupported read command or an invalid parameter for that read command have been issued. Add always the C2 parameter, to make sure that your dump isn't affected by E32 errors. As reference, this is the command line I always run, launched via psexec.exe by SysInternals with higher CPU priority.
psexec.exe -high discimagecreator.exe cd g: discimagecreator 08 /c2 2000 8192 08
Backing to the R-W question:
Dummy image of a disc I have created with pattern on the R-W subcodes similar to the ones present in certain discs manufactured by Sony DADC Japan. It includes a proper lead-out, with proper P flags. To be burned only with CloneCD in RAW DAO 96 mode.
Tests of extracting that burned CD, discimagecreator vs. PerfectRip (raw and packed mode). Definitely, discimagecreator erases that pattern, like packed mode of PR does (here is the drive itself misscorrecting that pattern). And C2 file is 588 bytes bigger than expected.
Main channel: 310381680 bytes / 2352 bytes per sector = 131965 sectors.
Subcode: 12668640 bytes /96 bytes per frame = 131965 frames.
C2 pointers: 310386384 bits / 2352 bits per sector = 131967 sectors.
Testing your program to dump certain PS1 discs for my personal archive and new PC Engine CD discs, standing the fucking heat of the Baetic Depression in the summer, I have noticed this:
It's the very same issue noticed by gorelord4e two years ago: certain discs manufactured by Sony DADC in Japan (IFPI 45xx) have a weird pattern in the R-W subcodes, last byte of R-W frames are filled with 0x1, 0x2 or 0x3 values. This pattern dissapears when packed mode for subcodes is selected, -mode 2 for subdump.exe.
The selected subcode reading mode of your app is the raw one and this pattern is present and replaced with zeroes in the auto-cleaning process. Unfortunately, «_errorlog.txt» file gets so big due to this pattern and discimagecreator complaining about R-W subcodes with unexpected values.
In the detection process for CD+G data this pattern is observed for every track, seems feasible to implement a routine to detect it and switch to packed mode for these discs, in order to avoid these logs files with an insane size.
Two samples of discs with this pattern, SLPS 00504 and SLPS 00667:
─ Logs, cues, sub and whatnot created by discimagecreator.
─ Raw subcode extracted by CDTool without any cleaning. AMSF 00:02:26 is corrupted because drive used (a cheapo Hitachi-LG CD burner based on Mediatek chipset) accelerates crazily when reading a mode 2 data track, even overriding the selected read speed.
Can you post the future WIP releases of discimagecreator stored in a zip/7z/whatever archive? Mainly to preserve the original timestamp and whatnot.
Now can clean successfully even the subcode of that awfully damaged disc without C2 errors.
An option to dump the raw subcode as provided by the drive is still welcome, sometimes user maybe want the subcode without any class of modification.
Subcode of that PCE CD game is right now, this looks very promising in order to dump my collection of discs for my personal archive...
However, isn't fully perfect yet:
Subcode dumped from my disc with the label side somewhat damaged, but fortunately no E32 errors because C1 and C2 error correction levels can cope with the error rate, as dumped and cleaned by discimagecreator, as provided by the drive via CDTool (trap disc method used, and both packed and raw methods) and the subcode from a copy in pristine shape provided by F1ReB4LL.
Cleaning of mode 2 Q subcode frames, aka MCN frames, isn't fully polished.
Compare offsets 8693589~8693591 and 14789973~14789975 offsets of subcode dumped by DIC and subdump. Absolute frame and CRC-16 are wrong:
Initially, I prefered single file bin/cue dumps rather than splitted ones, until I realized that splitted ones are more confortable. For example, if the hash of the dump (DB can compute the CRC-32 of the entire image, deduced from the sizes and CRC-32 of the individual tracks) isn't the expected one you can detect easily the corrupted track and replace only this one, or even borrow it from another games which share the same audio tracks.
I have to add several new dumps from another dumper, so 1-2 days. When added, bookmark carefully your dumps, to add you properly as dumper (clickable nick, in other words) when you reach that range.
Delete the REM, TITLE and PERFORMER lines. REM are comments/remarks, unneeded because these ones don't say anything useful. TITLE and PERFORMER only should contain data, in my opinion, data extracted from the actual CD-Text info encoded in the disc when available, not data provided by an online database.
To concatenate the dump, CDmage and Save as. Will create the proper cue (possible CATALOG, ISRCs and another possible flags are lost) for a single file dump, and the bin created by CDmage must match the created by copy /b. Once mounted that image, you can create a CCD/IMG/SUB (can coexist with the cue once edited the cue so that references the proper IMG file) or MDS/MDF dump from the virtual drive.
Regarding CDmage and scanning the image, seems that only can determinate the pause for images opened via a cue, not for ccd files.
PX-716AL works fine, have ALWAYS the firmware updated and try another PATA to USB converter if you are using one of these ones.
Regarding 0xA8, both EAC and dBpoweramp support FUA for extracting audio just fine, and the supposed code for supporting FUA is the posted by Spoon.
What does exactly swap?
Just spinning up disc? If so, should be named «start».
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:
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.
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.
Yes, I understand... no FUA for D8 command (the one you have to use yes or yes to read in scrambled form data tracks), only for certain commands like A8h, in fact the link posted above mention this one. In short, for audio tracks and pure audio discs could exist some chance of implementing this way of defeating cache, but for data tracks ripped via the D8 command absolutely no.
Things I miss.
An option to eject the tray, could be used to more or less automatize the ripping process of several consecutive discs, combined with the sleep progam for Win32, to pause execution for a prudential time.
«discimagecreator.exe eject g:» for example.
An option to spin up the disc after hot swapping (at the lowest speed possible always [trying to set 1x read speed, for example, actual read speed will be 4x/8x/10x depending on the drive used], because my Optiarc AD-7240S only supports disc swap if read speed used just after swapping is the lowest possible, if not so TOC is reanalyzed. Once read certain portion, can support the usual normal read speeds). And read certain portion as audio using the basic BE command with neither C2 pointers nor subcode, like the first 4000 sectors. This would be enough to defeat any drive cache after swapping.
«discimagecreator.exe swap g:» for example.
«discimagecreator.exe reset g:» works OK, my PX-755SA gets resetted and reanalyzes the inserted disc with neither resetting the entire system nor power cycling the drive.
«- added: writing multiple indexes for track 1 to cue file»
Sometimes another track can contain multiple indexes, just observe the Saturn games I posted as examples.
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:
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.
Use code boxes. Anyway, for me both copying and pasting the selected range and exporting as RTF file to delete the unneeded data and save as plain .txt file work OK.
0320 : 20 20 20 20 20 20 20 20 20 20 20 20 20 31 39 39 199 0330 : 34 31 31 33 30 31 32 30 30 30 30 30 30 24 30 30 4113012000000$00 0340 : 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 30 00000000000000.0 0350 : 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 000000000000000. 0360 : 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0370 : 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
The sample used stored as RTF document, as created by IsoBuster without any modification.
Aah! I mean the PVD copies and pasted as normal text in the IsoBuster's sector viewer. Or if you want, extract sector 16 as is (extracting that one using IsoBuster, from the dumped image extracting offsets 37632-39983 for CD dumps and 32768-34815 for DVD dumps as a binary file via a hex editor...) and upload it somewhere.
Write down manually those values to match what's represented in the screenshots would be somewhat frightening.
And barcodes should have the original spaces.
More or less, like CloneCD, but data of the transition between sessions 1-2 isn't read actually (can be read with the trap disc method, not always because sometimes there are unreadable zones, likely no EFM data encoded).
A little issue, regarding the driveOffset.txt file and jokers submitting false read offsets for certain drives.
@Sarami: additional info about the FUA command:
PVD is simply offsets 0x320-0x37f as seen on the IsoBuster's sector viewer, go to sector 16, copied into the clipboard. For CD discs, raw checkbox always unchecked. If discs lacks of an ISO9660 filesytem (only UDF, for example) no PVD to submit.
For the layerbreak, ImgBurn and read mode (Layer 0 Sectors: bla bla bla line):
For CD dumps, errors count is always convenient. Just drag and drop the data track into the binay and report errors and warnings, for standard discs should be 0, for SecuROM discs 1 error and for SafeDisc discs, hundreds of them. And every dump (especially SecuROM and SafeDisc CDs) should be dumped at least two times in the same drive to make sure that they are constant, better yet in different drives based on different brand of chipsets.
Ring codes/matrix codes are completely missing. Get a decent lamp, a glass magnifier for the trickiest ones and read them. Or provide decent scans/photos of them if possible.
For that Dead Space (already dumped: http://redump.org/disc/16528/) should be something like, as general rule replace any multiple amount of spaces with a tabulation or three/four spaces to indicate tabulation:
Mastering ring code: (367688) 1904307 01 0102
Mastering SID code: IFPI L779
Mastering ring code: (367697) 1904307 01 0104
Mastering SID code: IFPI L780
Another suggestion: could you develop an complementary app which would do this?
-Analyze the data track passed as argument: [name of app].exe [name of data track].bin and determinate if according to the stored EDC/ECC sectors are OK.
-For those corrupted sectors, replace everything except the sync and header fields with 0x55 bytes.
That way discimagecreator would offer support for SafeDisc CDs and should match CloneCD and CD Manipulator, but much faster.
Those corrupted sectors (DIC will dump them as they are interpolated by the drive, because contain intentional and constant C2 errors) should look this way once processed.
Why don't release a complete package once fixed several bugs and add new functions, including the Unicode release, driveOffset.txt, scramble.bin and EccEdc.exe files? Releasing the loose WIP app is somewhat confusing for the novice users, because they don't realize that driveOffset.txt and scramble.bin are required.
Possible suggestion, because this app is obviously used by users who own a PX-4824 drive or a +30 Plextor drive:
Download this source code:
And see the source code of pxfw. It includes a function which maybe you can implement to reset via software (I run many times the Win32 version of pxfw.exe for that) a real Plextor drive without resetting the entire system, useful to reanalyze TOC of inserted disc after hot swapping without ejecting+closing the tray and to recover a drive which has got silly. Possible name of argument: «reset».
Finally I attached a secondary bootable HDD to install Daemon Tools and do the final tests, because in my main OS I don't want Daemon Tools, CloneCD and another programs which install filter drivers even if given for free an authentic license for the full version...
DA files in the file system linked to the audio tracks copied via the OS file manager, except the last one (dummy audio track with digital silence):
DA files too:
Extracted via PR and appending gaps to none:
Same method than the used for Heavy Nova.
So it seems to work very properly, no more exotic methods to get rid of the damn gaps I don't want in my redbook rips.
improved /c2 ripping ver.20140607
It sounds good. In what sense?
By the way, I can dump properly discs using my PX-716AL drive connected via a JMicron based PATA/SATA to USB 2.0 adapter, finally.
Logos are written as normal text in the rings submitted, and according to F1ReB4LL logos should be in the very end of the mastering ring code, preceded by a tabulation. Generally speaking, any ammount of multiple spaces in the ring codes is replaced with a tabulation.
You can start to submit these dumps via the new disc form, just make sure that you aren't missing the possible CATALOG 0000000000000 and another flags. Due to that, it's always a good idea double-check dumps via either PR or DIC. For SafeDisc CDs only DIC, won't match these dumps because gargabe sectors aren't replaced with 0x55 pattern, but at least should detect the possible flags in order to get a more complete cue.