Redump Forum

Sorry. Reuploaded.

Well good news, I did what Fireball suggested, and disconnected the drives, and power cycled twice to let the chipset and windows reset everything about the IDE bus. Now my 5224A works again, ALSO my 760A can read DVD's again... so it's some stupid bug with either windows, or this j-micron controller on my motherboard.

I apologize for flying off the handle at you sarami, it wasn't your fault at all.

btw, someone reported that DIC is no longer working with PX-W2410A and old version worked.

Nexy wrote:btw, someone reported that DIC is no longer working with PX-W2410A and old version worked.

That was me.

PX-W2410TA (PX-W2410A 1.04) has never worked properly with DIC, but the support got completely broken somewhere between version 20140110 and 20140306
Before that, I could use the device to dump either the audio tracks and getting a data track with the wrong hashes, or I could dump the data track and got audio tracks with the wrong hashes.
I always get the same error message like the one that is described in the first post about the PX-W4824TU/TA.
I could only dump at 16x speed.

sarami, could I be of any assistance to get the device supported in DIC?

In the past, I confirmed that there was some probrem about PX-W2410TA (fw 1.04), PX-320A(fw 1.06), PX-W8432T(fw 1.09), PX-W1210A(fw 1.10)

[PX-W2410TA, PX-320A]
. If it doesn't read a subchannel using 0xd8 command, an offset of drive is +99, but if it read a subchannel using 0xd8 command, an offset of drive is +686.

[PX-W2410TA, PX-320A, PX-W8432T, PX-W1210A]
. If a data track exists in track 1 and read it using 0xd8 command, it becomes the read error (ILLEGAL_REQUEST. ILLEGAL MODE FOR THIS TRACK)

So, I can't support these drive at this time.

olofolleola4 reported that the PX-W2410TA drive can rip a mixed-mode disc using the classic cdtoimg-d8 program, so at least the basic D8 command with neither subcode nor C2 pointers works for this drive.

Does D8+C2, without raw subcode reading, work properly in these drives and the offset is the expected one (+98 and not +686)?

If so, I guess that a possible workaround would be to implement another additional reading mode, this way:

-Detect the CATALOG, ISRCs, DCPs, PRE flags... according to the TOC and analyzing the subcode (not issuing certain commands to read CATALOG, ISRCs... because there are drives which can give fictitious CATALOG and/or ISRCs), D8+raw subcode command. Additionaly, it would be cool that the program could detect TOC vs. subcode desyncs and print this as a warning. Examples of discs which suffer from this annoying issue:

https://redump.info/disc/29165/
https://redump.info/disc/27420/
https://redump.info/disc/29606/

-Once analyzed the TOC and the subcode to build the proper cue and ccd, rip the disc as usual, D8 + (optional) C2 command. Logically, no actual subcode from the disc is ripped and the dump is splitted and unscrambled according to the info previously detected.

With my 1210 and 1610, D8 worked most of the time with data tracks, and only some discs it failed with illegal mode for this track errors.

Interesting to know about the offset differences when reading subcode, something I did not know. AFAIK the older drives do not support C2 at all.

The only thing to note with these drives is that they are better at reading discs with weak sectors towards the end of the disc with some revisions of SafeDisc. Newer drives will dump erroneous sectors, where these drives can dump them fine.

Has there been a fix for the Error 121: semafoor issue?

I'm also having these with the latest version. However i tried an older version (Dated 2013-06-19) that i found on my laptop that works just fine with the exact same hardware.

The hardware used: Plextor PX-716A, Some old cheap USB cd drive enclosure, Apple rMBP running win8.1 update 1 through Boot Camp.

I'm pretty sure it's not the USB enclosure that creates the error, as i tried this exact same drive in my backup pc connected directly to the motherboard and it also works with the earlier mentioned older version, but not with the latest one.

1. reenabled PX-W2410TA, PX-320A, PX-W8432T, PX-W1210A for the present.
2. added: execute EccEdc.exe in this program. it places in same dir.
    (EccEdc.exe is tool that checks a user data(2048byte) using ecc/edc.)
     http://www.mediafire.com/?glwmoytaqo00e55/
    [EDIT] fixed help msg.
3. fixed: parsing subchannel (LBA -1 and adr flag isn't 1.  e.g. [PCE]1552 Tenka Tairan)
4. changed: ScsiPassThroughDirect.TimeOutValue (2 => 60)
I want to fix it. But I don't know in detail. And this error doesn't show in my PC. So I can't confirm this.

[EDIT]
5. added: msg that if it isn't index 0 at LBA 0 /p is ignored.

/p option doesn't work properly, Plextor drives can rip only the -75, -1 range of the first pregap directly. It's somewhat hard to explain the correct method to dump properly the first pregap when this one contains actual audio data (the miniCD Audio disc bundled with Tenbu MegaCD Special, for example), but would something like this.

-Read the -5000,-76 range, D8 command of couse. When reach more or less the -1000 LBA will report many read errors, it's normal and expected.

-A part of the lead-in, the entire first pregap and a piece of the first track, index 1, is dumped.

-Then use the first sectors of the normal dump to search them in the dumped file, find the portion which matches those first sectors and extract the previous 352800 bytes into a separated file.

-The subcode is easy, just extract into a separarated file the frames with 00:00:00 - 00:01:74 AMSF.

http://www.mediafire.com/?470d0r269wg6bce

I have uploaded a sample, the entire minidisc and the pregap extracted as I have proposed via the audio option.

Then, I have hashed the first 75 sectors of the first track and these ones are the results. Program used is parthash, much easier than cutting the dump and whatnot:
/viewtopic.php?t=8828


D:\MiniCD\Main dump>parthash "MiniCD (Track 1).bin" 176400
#        Size   CRC-32                        MD5/SHA-1
1      176400 fa5fa23f 4e9bff8a8ab29fafb6252977de6b11ea
                714a04d835419264528b0327c143de4267e3d961
2    39588864 e0c9e590 4083df206ba8ab18864aa27590ac346c
                dc47b01492f14f26b60bccd4de635d016a2b239d

Then I run the findcrcs.exe program by V. in the lead-in+first pregap+a piece of first track dump and these are the results:

D:\MiniCD\Pregap>findcrcs Pregap.bin 176400 FA5FA23F
4290048  fa5fa23f  4e9bff8a8ab29fafb6252977de6b11ea

Thus 4290048 is the starting point of the main dump, so I have to extract 3937248-4290047 range into a separated file to have the actual pregap ripped once and for all. The subcode is easy, just delete everything except the range with AMSF 00:00:00 - 00:01:74.

findcrcs.exe program is here, including source code.

/viewtopic.php?t=8348

With these suggestions, perhaps you can implement a proper routine to extract properly the first pregap of these discs.

And it would be cool to implement another routine to extract the lead-out of certain discs which contains audio data in the lead-out. My Alanis Morissette - Jagged Little Pill [UK(9362-459012)], as far you remember you purchased this one to perform certain tests related to the slowness when ripping discs with R-W filled with 0xff, contains data in the actual lead-out, so could be useful to implement an option to rip into a separated file the first 100 sectors of the lead-out, applying either the offset correction autodetected by D8 (if disc contains a data track, Heavy nova for MCD for example), the standard one of AccurateRip or the overriden by the /a parameter.

Somebody knows a drive that it can rip under -75 (=from -150 to -76) LBA?
This is unexpected for me. I don't know why these data get by a plextor drive.