Redump Forum

sarami wrote:I tested Read(12)[0xA8] command for CD.
Audio Sector => SenseData Key:Asc:Ascq 05:64:00, ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
Data Sector => get only user data (2048 byte). couldn't get sync header, ecc/edc, c2, sub etc...

When I set a transfer Length to 0, an error didn't appear.

20140627
- added: /f option of cd command (But I don't know whether or not a cache is clear.)
- added: Output log of mode sense (page code: 0x2a)
- added: fix AFrame of Adr 2, 3 of SubQ(=MCN, ISRC)
- improved: Adr 2 of SubQ(=MCN)(check whether or not adr is correct.)

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.

20140628
- improved: fix Adr 2 of SubQ(Sub[19] & 0x0f => 0 and Sub[20] => 0)
20140630
- improved: Adr fix logic

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

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

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.

pablogm123 wrote:This pattern dissapears when packed mode for subcodes is selected, -mode 2 for subdump.exe.

Mode 2 isn't exactly in "packed" mode, it's for 0xD8 and 0xD8 doesn't have any "RAW' or "Packed" modes.

0xBE wrote:TABLE 2-22D READ CD, SUB CHANNEL DATA SELECTION FIELD DEFINITION
Sub-channel Definition Description
000b No Sub channel Data No Sub-channel data will be transferred
001b RAW Raw Sub-channel data will be transferred
010b Q Not Supported
011b Reserved
100b R - W R-W data will be transferred
101b-111b Reserved

0xD8 wrote:Sub Code Field CD-DA block length Description
00h 2352 bytes CD-DA data with no Sub Code
01h 2368 bytes CD-DA data with Sub Q Code
02h 2448 bytes CD-DA data with all Sub Code
03h 96 bytes All Sub Code only
04 ~ FFh Reserved

Mode 0 and Mode 1 use 0xBE with 0x01 subs, Mode 2 uses 0xD8 with 0x02 subs, Mode 3 uses 0xD8 with 0x03 subs.

What does "invalid filed in CDB" mean? I used this command to rip a PC CD disc: DiscImageCreatorTEST.exe cd y: D:\Redump.org\TFX 4 (using latest test version)

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

Seems DIC does something my Plextor does not support PX-708A
No clue what you want me to do with the C2 paramater. I only get a large c2 file as output.

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.