26

(3,493 replies, posted in General discussion)

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.

27

(3,493 replies, posted in General discussion)

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.

File MotorMash_infolog.txt:
LBA[147352, 0x23f98], Track[02]: Subchannel & TOC isn't sync. LBA on TOC[148449, 0x243e1], prevIndex[00]

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.

Sent a PM in Spanish explaining the question.

29

(3,493 replies, posted in General discussion)

Update the firmware ASAP.

http://www.skcj.co.jp/discon/download/firmware/px708_112.zip

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.

30

(3,493 replies, posted in General discussion)

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.

http://www.mediafire.com/?1qbjcboj3c7udjd

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.

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

31

(3,493 replies, posted in General discussion)

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.

http://www.mediafire.com/?1256gaea45s62fc

==========

Can you post the future WIP releases of discimagecreator stored in a zip/7z/whatever archive? Mainly to preserve the original timestamp and whatnot.

32

(3,493 replies, posted in General discussion)

http://www.mediafire.com/?25801h9syjq4sht

Now can clean successfully even the subcode of that awfully damaged disc without C2 errors.

33

(3,493 replies, posted in General discussion)

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...
https://www.mediafire.com/?q0v0dht84owhayn

However, isn't fully perfect yet:
http://www.mediafire.com/?s1v9d5fmaqtta

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.

34

(3,493 replies, posted in General discussion)

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:

http://www.mediafire.com/?1kmlml5dhk46ooy

35

(27 replies, posted in General discussion)

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.

36

(27 replies, posted in General discussion)

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.

37

(3,493 replies, posted in General discussion)

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

38

(27 replies, posted in General discussion)

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.

http://i.imgur.com/2cmh2uy.png

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.

39

(3,493 replies, posted in General discussion)

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.

Regarding:
«- 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.

40

(27 replies, posted in General discussion)

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.

41

(3,493 replies, posted in General discussion)

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

42

(3,493 replies, posted in General discussion)

A little issue, regarding the driveOffset.txt file and jokers submitting false read offsets for certain drives.

http://forum.redump.org/post/47923/#p47923

@Sarami: additional info about the FUA command:

http://forum.dbpoweramp.com/showthread.php?33676

43

(3,493 replies, posted in General discussion)

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.

http://i.imgur.com/V1bvdvN.png

http://i.imgur.com/65b1uSp.png

44

(3,493 replies, posted in General discussion)

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:

http://sourceforge.net/projects/qpxtool/files/qpxtool/0.7.x/0.7.2/qpxtool-0.7.2.tar.bz2/download

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

45

(8 replies, posted in General discussion)

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

=====

http://redump.org/disc/20028/
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):

http://i.imgur.com/0HUKEhp.png

=====

http://redump.org/disc/29920/
DA files too:

http://i.imgur.com/oHSF1n6.png

=====

http://redump.org/disc/1741/
Extracted via PR and appending gaps to none:

http://i.imgur.com/NdXHre8.png

=====

http://redump.org/disc/25923/
Same method than the used for Heavy Nova.

http://i.imgur.com/FDyIkOp.png

=====

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.

46

(3,493 replies, posted in General discussion)

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.

Recent drives are somewhat trash for the enthusiasts of digital audio extraction, because recent drives lack near always of overreading into the lead-out, and sometimes of overreading into the first pregap.

Without taking into account real Plextor drives, my old GCE-8526B LG-Hitachi CD writer is just fine for PSX: reads finely without workarounds no longer allowed the last sector of data tracks of no EDC discs with audio tracks and can overread into the first pregap AND lead-out using EAC, so for any +2 PSX disc is just fine. A -647 disc which would lose potentially audio samples due to negative combined (-641 samples for a +2 discs)? Just rip the first audio audio track in a +667 drive and solved.

Tha main problem with current conventional drives is the lack of overreading into the lead-out (however, audio trap disc method acts as workaround to rescue the lost audio samples when supported). Tipically, conventional drives won't read into the lead-out at all, so the risk of losing audio samples (especially for +2 discs and +667 drives) does exist and you cannot match certain DB entries due to that.

Examples of entries you cannot match with a +667 drive:

http://redump.org/disc/6563/
http://redump.org/disc/30018/
http://redump.org/disc/18462/

http://redump.org/disc/3210/ And the discs which share the same last dummy track: http://redump.org/discs/quicksearch/9eb22530/

For discs without audio tracks... near every modern drive is fine.

48

(3,493 replies, posted in General discussion)

Dummy images to test:

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

To be burned only using CloneCD, in RAW DAO 96 mode and with that option not to repair subcode data enabled.

For MegaCD/Saturn/TurboGrafx-CD/Neo Geo CD... dumping a drive which supports D8 command is needed yes or yes. Additionally with these drives truncated audio tracks due to the lack of overreading is a thing of the past and make possible the use of PerfectRip, DiscImageCreator and so on which ease so much the dumping of discs with audio tracks, without truncated audio tracks, ruined last sector of data tracks of no EDC PS1 discs with audio tracks...

Plextor PX-712SA, PX-716SA, PX-755SA and PX-760SA. Or any +30/+98 real Plextor drive converted into an external drive via an PATA/SATA to USB 2.0 adapter.

As very last resource, a drive which supports properly the audio trap disc method via the emergency hole to dump into scrambled form the discs, like an Optiarc AD-7240S.

50

(3,493 replies, posted in General discussion)

Much better. Expected intentional errors (32) + 9/10 false ones due to either corrupted RMSF/AMSF or CRC-16. I am wondering if would be possible to create an algorithm to smartly detect these sectors and leave them untouched, as XOR every frame of this range with 0x0080 and 0x8001 (I mean try both possibilities, not literally XOR with 0x0080 and the got data XOR with 0x8001) to undo the initial XOR operation, if the new CRC-16 matches now the rest of the Q-Frame, is a Libcrypt frame and shouldn't be altered.

Main page gives the tips, posted below.

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

2 bits from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.
2 bits from both MSFs are modified, original CRC-16 is XORed with 0x8001.
Either 2 bits or none from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.

Wip3out is the third case, because certains frames have no MFSs altered and CRC-16s are recalculated and XORed with 0x0080.