You are not logged in. Please login or register.
Redump Forum → General discussion → DiscImageCreator
I don't want CloneCD even if given for free...
PerfectRip subcode:
http://www.mediafire.com/?73w2wb7ri70w7om
It's fixed probably (I don't test because I don't have this)
EDIT:
re-fix
sarami can you add the option to disable C2 entirely.
Do you have any SafeDisc/Laserlock protected discs? or ones with Cactus Data Shield or something else with intentional C2 errors?
disable C2 entirely
What do you mean? If you don't need C2, you don't need to set /c2 option.
Do you have any SafeDisc/Laserlock protected discs?
I don't have yet.
or ones with Cactus Data Shield
I have some disc (CDS-200, CDS-300).
or something else with intentional C2 errors?
I have 2 disc.
Ahh yeah the /c2 switch... sorry I'm on pain meds and I'm a bit derpy.
Need to be able to dump discs with intentional errors scrambled and check later, didn't you add some ecc/edc checking too?
Forgot to ask, can we specify a range to dump now, and if so can we dump that range also backwards?
http://www.mediafire.com/?8z2x18co8bdiqmvLogs and whatnot included in that archive, plus the problematic mixed pregap.
Issue: 41 sectors in that mixed pregap in scrambled form. Those sectors should be unscrambled. In the same disc there is another data track with the same kind of mixed pregap (because the previous track is audio, so should contains 75 audio sectors + 150 mode 1 sectors) unaffected.
===
http://www.mediafire.com/?dgx51e49mog8tmyThe new version can rip finally the problematic William Shatner's Tekwar (authentic release by Intracorp) disc I have. Unfortunately, the new EccEdc.exe program returns unexpected results, likely because it analyzes the data track without taking into account the pregap defined by the subcode and then audio sectors (and this disc has scrambled data sectors in the pregap of track 2) which belongs actually to track 2 are reported as false errors.
Do you have any PCE CD to test? These discs contains mixed pregaps in the data tracks and therefore a routine to detect smartly the audio sectors and ignore them is needed.
Issue: 41 sectors in that mixed pregap in scrambled form. Those sectors should be unscrambled. In the same disc there is another data track with the same kind of mixed pregap (because the previous track is audio, so should contains 75 audio sectors + 150 mode 1 sectors) unaffected.
from log
LBA 232097, Track[27]: data track, but this sector is audioLBA[232096, 0x38AA0], Data, Copy NG, TOC[TrackNum-27, Index-00, RelativeTime-00:01:33, AbsoluteTime-51:36:46] RtoW:ZERO, RtoW:ZERO, RtoW:ZERO, RtoW:ZERO
LBA[232097, 0x38AA1], Audio, 2ch, Copy NG, Pre-emphasis No, TOC[TrackNum-27, Index-00, RelativeTime-00:01:32, AbsoluteTime-51:36:47] RtoW:ZERO, RtoW:ZERO, RtoW:ZERO, RtoW:ZERO
LBA[232098, 0x38AA2], Data, Copy NG, TOC[TrackNum-27, Index-00, RelativeTime-00:01:31, AbsoluteTime-51:36:48] RtoW:ZERO, RtoW:ZERO, RtoW:ZERO, RtoW:ZEROUploaded latest WIP. Please re-test.
Do you have any PCE CD to test?
Yes. I have 134 PCE CD now.
the new EccEdc.exe program returns unexpected results
EccEdc_20140429
fixed: skip scrambled sector
http://www.mediafire.com/?j87e0amayhc2q7h/
Yes. I have 134 PCE CD now.
Your dumps are welcome 
sarami wrote:Yes. I have 134 PCE CD now.
Your dumps are welcome
I don't have a recommended ripping tool for PCE.
Have you considered the possibility of implementing some way of detecting possible subcode vs. TOC desyncs, and print this data in the log files?
Once dumped the disc, you compare the indexes 01 and flags (DCP, PRE...) according to the TOC against the ones defined by the dumped subcode. If differ, print as warning.
coded.
added: /s option (if toc vs. sub isn't sync, sub indexes in priority)
if not /s option, toc indexes in priority.
added: cue file for img
TOC indexes in priority should be the default option.
TOC indexes in priority should be the default option.
fixed option
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.
-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.
I confirmed PX-755SA, but didn't confirmed PX-W4824TA. Do you know which a plextor drive is supported?
PX-W4824TA (+98) doesn't support that at all, the range extracted this way is fully messed and the drive produces strange mechanical noises and halts frequently for a moment the dumping process.
Any +30 drive is fine, tested in my PX-W5224TA, PX-716AL and PX-755SA.
Tested the new function:
http://www.mediafire.com/?f18qzrrxlw3m298
While works OK to be actually useful should work this way, without needing that the user specifies any special parameter:
-When ripped the subcode and the main channel, determinate if exist any TOC vs. subcode desyncs. If not so, proceed as usual and create the normal dump.
If exist these desyncs, then create automatically two versions and dats of the dump:
-With subcodes indexes in priority
-With TOC indexes in priority.
Any idea why it took like six hours to dump the disc from attached logs? https://dl.dropboxusercontent.com/u/355 … l_logs.zip I tried an older version aswell. Same result. ISObuster did it like in 3 minutes or so, with the same result. I have soem more of these disc with the same problem.
Sub Channel LBA 0
P ff ff ff ff ff ff ff ff ff ff ff ff
Q 61 01 01 00 00 00 00 00 02 00 11 3f
R ff ff ff ff ff ff ff ff ff ff ff ff
S ff ff ff ff ff ff ff ff ff ff ff ff
T ff ff ff ff ff ff ff ff ff ff ff ff
U ff ff ff ff ff ff ff ff ff ff ff ff
V ff ff ff ff ff ff ff ff ff ff ff ff
W ff ff ff ff ff ff ff ff ff ff ff ff
I thought that the supermegaslow reading process due to packed mode for subcodes which doesn't like at all R-W filled with neither zeroes nor CD+G data was solved by changing to the raw mode (unaffected by this).
Any idea why it took like six hours to dump the disc from attached logs?
Thank you. please wait until fix.
-When ripped the subcode and the main channel, determinate if exist any TOC vs. subcode desyncs. If not so, proceed as usual and create the normal dump.
If exist these desyncs, then create automatically two versions and dats of the dump:
-With subcodes indexes in priority
-With TOC indexes in priority.
Coded it (and del /s option). Please test.
Off-topic: why the last pre-lead-out sector of certain MCD discs manufactured by JVC, marked as first sector of the lead-out in the subs, is replaced with a normal subcode frame?
refixed.
Tested this disc:
http://redump.org/disc/27420/
Complete list of known discs which feature this mastering error:
http://redump.org/discs/quicksearch/indexes/
Logs:
http://www.mediafire.com/?dyxp9o7ajtd0dei
Just (Subs indexes) instead of _SubSync .
The last frame of subcode isn't altered anymore, see the posted subcode.
get an appcrash with some of the newer versions... http://www7.pic-upload.de/04.05.14/f3ttx8wtrpbc.jpg
Just (Subs indexes) instead of _SubSync .
Changed
get an appcrash with some of the newer versions... http://www7.pic-upload.de/04.05.14/f3ttx8wtrpbc.jpg
Fixed
The last frame of subcode isn't altered anymore, see the posted subcode.
Is there a error log of the last frame?
As expected, the last frame of program area of these discs manufactured by Victor is marked as the first sector of Lead-out.
LBA[325975, 0x4f957], Audio, 2ch, Copy NG, Pre-emphasis No, Track[43], Idx[01], RelTime[01:02:07], AbsTime[72:28:25], RtoW[Zero, Zero, Zero, Zero]
LBA[325976, 0x4f958], Audio, 2ch, Copy NG, Pre-emphasis No, Track[43], Idx[01], RelTime[01:02:08], AbsTime[72:28:26], RtoW[Zero, Zero, Zero, Zero]
LBA[325977, 0x4f959], Audio, 2ch, Copy NG, Pre-emphasis No, Track[43], Idx[01], RelTime[01:02:09], AbsTime[72:28:27], RtoW[Zero, Zero, Zero, Zero]
LBA[325978, 0x4f95a], Audio, 2ch, Copy NG, Pre-emphasis No, LeadOut , Idx[01], RelTime[00:00:00], AbsTime[72:28:28], RtoW[Zero, Zero, Zero, Zero]xTMODx wrote:get an appcrash with some of the newer versions... http://www7.pic-upload.de/04.05.14/f3ttx8wtrpbc.jpg
Fixed
thanks! works again
Any idea why it took like six hours to dump the disc from attached logs? https://dl.dropboxusercontent.com/u/355 … l_logs.zip I tried an older version aswell. Same result. ISObuster did it like in 3 minutes or so, with the same result. I have soem more of these disc with the same problem.
I maybe realized.
In case of the plextor with d8, there is four ways to get sub channel.
1. main + Qsub (=2352+16byte)
2. main + P-Wsub(Pack) (=2352+96byte)
3. P-Wsub (=96byte)
4. main + C2 + P-Wsub(Raw) (=2352+294+96byte)
This app is using 2(no option) and 4(/c2 option).
To sum up, in case of R-W sub filled disc, to rip sub channel at raw mode, you need to use a /c2 option.
Any chance of 0xBE + packed mode + single sector reads for CD+G discs?
According to my tests, PR (which uses 0xBE read command) configured with packed mode and single sector reads offers the cleanest subs files for my CD+G disc Rock Paintings. Once I extracted 8 times (yes, 8 times) the subcode of that disc this way and R-W data was always identical. Drive used was the PX-W4824TU, the best drive I have for CD+G and GD-ROM discs.
To sum up, in case of R-W sub filled disc, to rip sub channel at raw mode, you need to use a /c2 option.
Thanks, will try that option and let you know how it behaves.
You always should use the /c2 option anyway, to discard that your dumps are affected by those errors.
/c2 1000 8192 8 for example.
Redump Forum → General discussion → DiscImageCreator
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.