DiscImageCreator (Page 13 of 141)

Happened with me with subdump and PX-716A once. Also 100% usage and was unable to kill the process, after reboot the drive locked and refused to eject the tray (the led was blinking for a few secs after pressing the eject button, nothing more). I've disconnected IDE and molex cables and reconnected after a hour or so - was working fine after that. So, I believe it's not a VS2013 issue (though, in your case, it lets you to eject the tray, but the drive is also different).

I really don't know what caused it... and I don't feel like risking my last working plextor to test.

I think you need to have some kind of time out check, and some way to abort the process (crtl+q) or something...

Possible bug discovered by Hustle, the first sector of certain PC game (CD, one single data track) is in scrambled form. Checking the logs and the sub the only unusual thing I see (besides of R-W filled with a non-standard data pattern) is the Q frame of the subcode at AMSF 00:02:00 replaced with a MCN frame.

Logs, sub and 0-16 sectors:

http://www.mediafire.com/?4qm5id2m57f5hhl

I'm getting the following error message when using the latest version,

Sorry. Reuploaded.

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?

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:

http://redump.org/disc/29165/
http://redump.org/disc/27420/
http://redump.org/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.

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.

/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:
http://forum.redump.org/topic/13085/

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.

http://forum.redump.org/topic/12450/

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.

Plextors rip from -75 for Audio CDs and from -142 for Data CDs.

It's a known trick. You can also try to dump not "-5000 to -76" range, but "$FF000000 to -1". Exactly "$FF000000" as a starting sector.

>pablogm123
Thank you testing.
EccEdc_20140416.7z
http://www.mediafire.com/?74xxfl46ozbt1tz
fixed: detect  mode 2

>F1ReB4LL

"$FF000000 to -1"

sorry, I don't understand "$FF000000".