426 (edited by pablogm123 2014-06-03 17:29:36)

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

pablogm123 wrote:

improved /c2 ripping ver.20140607

It sounds good. In what sense?

- improved: /c2 option (support PX-4824)

pablogm123 wrote:

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.

ok, thanks.

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

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

431 (edited by pablogm123 2014-06-20 11:58:56)

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
On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

Is DIC mutisession support ?

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

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

434 (edited by sarami 2014-06-21 11:02:43)

uploaded 20140621
- include WIP fixes
- added: plextor unique command
- updated: driveOffset.txt (and sent a mail to AccurateRip about PX-716)

about protected disc(or corrupted sectors): I pushed to Todo.txt

about FUA: See KnownIssue.txt

435 (edited by pablogm123 2014-06-22 15:47:06)

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

Does the software support the Plextor 716-AL drive? It keeps exiting on me with:

OS
        Windows 8 Pro  64bit
AppVersion
        x86, AnsiBuild, Jun  7 2014 12:37:35
CurrentDir
        E:\Dumps\psx\plextor\dic
InputPath
         path: dump.bin
        drive:
          dir:
        fname: dump
          ext: .bin
Start: 2014-06-21(Sat) 21:20:16
[F:GetDriveOffset][L:64] GetLastError: 2, The system cannot find the file specified.

This drive doesn't define in driveOffset.txt
Please input Drive offset(Samples): 128
Checking reading lead-out
Creating bin from 298065 to 298066 (LBA) 298066
Reading lead-out: OK
[F:ReadCDAll][L:780] GetLastError: 2, The system cannot find the file specified.


End: 2014-06-21(Sat) 21:20:25

Thanks for any help with this.

pablogm123 wrote:

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.

Oh, I see. I'll try it.

An option to eject the tray

added.

An option to spin up the disc

added. But couldn't change a reading speed.

ack2121 wrote:

Does the software support the Plextor 716-AL drive? It keeps exiting on me with:

Edited the 1st post. Please show the 1st post again.

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

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

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

441 (edited by sarami 2014-06-26 21:08:46)

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

442 (edited by pablogm123 2014-06-27 15:27:48)

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

443 (edited by sarami 2014-06-29 17:52:11)

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

449 (edited by MrX_Cuci 2014-07-17 22:21:29)

Seems DIC does something my Plextor does not support PX-708A

ScsiStatus: 02-CHECK_CONDITION
SenseData Key:Asc:Ascq 05:24:00, ILLEGAL_REQUEST - INVALID FIELD IN CDB

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.

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot