MrX_Cuci wrote:
I still get the invalid request error aswell. Different disc (dumps 100% btw)
added log to console. Please retest and show me a console log.
1,252 2014-07-20 11:25:35
Re: DiscImageCreator (3,488 replies, posted in General discussion)
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.
I'll confirm later too.
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).
About r to w without cd-g disc, it replace at all zero at the present.
And C2 file is 588 bytes bigger than expected.
Fixed.
About MotorMash
LBA[147329, 0x23f81], Track[03]: PrevTrackNum[03] -> [02]
There is wrong Subdata of tracknum of LBA 147328.
Fixed probably.
1,253 2014-06-28 14:23:11
Re: DiscImageCreator (3,488 replies, posted in General discussion)
20140628
- improved: fix Adr 2 of SubQ(Sub[19] & 0x0f => 0 and Sub[20] => 0)
20140630
- improved: Adr fix logic
1,254 2014-06-26 21:03:05
Re: DiscImageCreator (3,488 replies, posted in General discussion)
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.)
1,255 2014-06-22 14:25:13
Re: DiscImageCreator (3,488 replies, posted in General discussion)
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...
1,256 2014-06-22 08:32:19
Re: DiscImageCreator (3,488 replies, posted in General discussion)
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.
1,257 2014-06-21 11:01:07
Re: DiscImageCreator (3,488 replies, posted in General discussion)
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
1,258 2014-06-11 19:11:17
Re: DiscImageCreator (3,488 replies, posted in General discussion)
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.
1,259 2014-06-03 15:53:03
Re: DiscImageCreator (3,488 replies, posted in General discussion)
- improved: SubQ of adr 3(=ISRC sector)(if adr is correct but ISRC data is wrong, fixed it.)
pablogm123 wrote:
2 bits from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.
2 bits from both MSFs are modified, original CRC-16 is XORed with 0x8001.
Either 2 bits or none from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.
Wip3out is the third case, because certains frames have no MFSs altered and CRC-16s are recalculated and XORed with 0x0080.
I don't have a LibCrypt disc. So, it would help me if someone could test the 1st/2nd case.
1,260 2014-06-02 16:44:44
Re: DiscImageCreator (3,488 replies, posted in General discussion)
sorry, I didn't write the subcode for LibCrypt...
re-fixed. But data is incorrect probably. Please test...
1,261 2014-06-01 13:54:53
Re: DiscImageCreator (3,488 replies, posted in General discussion)
pablogm123 wrote:
Or at least the already implemented option but affecting only RMSFs 03:xx:xx and 09:xx:xx, the known positions of these modified frames.
Improved at above. (change option /n -> /l)
added: xxx_infolog.txt (for no error log)
1,262 2014-05-30 07:09:35
Re: DiscImageCreator (3,488 replies, posted in General discussion)
added: /n option (for PlayStation LibCrypt disc)
added: disclog for PCE disc (1st, 2nd sector of the 1st data track)
1,263 2014-05-29 13:49:41
Re: DiscImageCreator (3,488 replies, posted in General discussion)
pablogm123 wrote:
http://www.mediafire.com/?zyggub7owugg48q
Test of a PS1 disc with LibCrypt protection.
To check what DIC does regarding the modified subcode frames, they are mentioned in the DB entry.
Shouldn't I fix the subcode automatically?
1,264 2014-05-26 17:25:35
Re: DiscImageCreator (3,488 replies, posted in General discussion)
fixed: check CD+G per track (for WonderMega Collection)
added: /m option (for WonderMega Collection)
1,265 2014-05-24 18:28:43
Re: DiscImageCreator (3,488 replies, posted in General discussion)
source code
////////////////////////////////////////////////////////////////////////////////
//
// Check if this is a sector we can compress
//
// Sector types:
// 0: Literal bytes (not a sector)
// 1: 2352 mode 1 predict sync, mode, reserved, edc, ecc
// 2: 2336 mode 2 form 1 predict redundant flags, edc, ecc
// 3: 2336 mode 2 form 2 predict redundant flags, edc
//
static int8_t detect_sector(const uint8_t* sector, size_t size_available) {
if (
size_available >= 2352 &&
sector[0x000] == 0x00 && // sync (12 bytes)
sector[0x001] == 0xFF &&
sector[0x002] == 0xFF &&
sector[0x003] == 0xFF &&
sector[0x004] == 0xFF &&
sector[0x005] == 0xFF &&
sector[0x006] == 0xFF &&
sector[0x007] == 0xFF &&
sector[0x008] == 0xFF &&
sector[0x009] == 0xFF &&
sector[0x00A] == 0xFF &&
sector[0x00B] == 0x00 &&
sector[0x00F] == 0x01 && // mode (1 byte)
sector[0x814] == 0x00 && // reserved (8 bytes)
sector[0x815] == 0x00 &&
sector[0x816] == 0x00 &&
sector[0x817] == 0x00 &&
sector[0x818] == 0x00 &&
sector[0x819] == 0x00 &&
sector[0x81A] == 0x00 &&
sector[0x81B] == 0x00
) {
//
// Might be Mode 1
//
if (
ecc_checksector(
sector + 0xC,
sector + 0x10,
sector + 0x81C
) &&
edc_compute(0, sector, 0x810) == get32lsb(sector + 0x810)
) {
return 1; // Mode 1
}
}
else if (
size_available >= 2336 &&
sector[0x10] == sector[0x14] && // flags (4 bytes)
sector[0x11] == sector[0x15] && // versus redundant copy
sector[0x12] == sector[0x16] &&
sector[0x13] == sector[0x17]
) {
//
// Might be Mode 2, Form 1 or 2
//
if (
ecc_checksector(
zeroaddress,
sector + 0x10,
sector + 0x10 + 0x80C
) &&
edc_compute(0, sector + 0x10, 0x808) == get32lsb(sector + 0x10 + 0x808)
) {
return 2; // Mode 2, Form 1
}
//
// Might be Mode 2, Form 2
//
if (
edc_compute(0, sector + 0x10, 0x91C) == get32lsb(sector + 0x10 + 0x91C)
) {
return 3; // Mode 2, Form 2
}
else {
return 4; // Mode 2, No EDC (for PlayStation)
}
}
//
// Nothing
//
return 0;
}In case of mode2 disc, if a subheader and edc matches, no error. Otherwise error.
Ideally, should be reported as warning.
I think so, too.
1,266 2014-05-24 05:37:16
Re: DiscImageCreator (3,488 replies, posted in General discussion)
axisleon wrote:
DIC v.20140518 read HDA slowly and easy to fail, back to old v.20120707
fixed: transfer length
fixed: c2 error fix logic
about edccchk
oh.. I didn't know this tool. it is recommended than my tool in the error report.
1,267 2014-05-20 23:59:06
Re: DiscImageCreator (3,488 replies, posted in General discussion)
pablogm123 wrote:
These CD-i discs confuse many drives...
At first sight... actually no starting position of track 1 is defined by the TOC. Only is defined that the first track is 2 (A0), second track is 2 (A1) and lead-out starts at AMSF 08:24:00 (A2), but no actual entry for track 1.
So I guess that to rip these CD-i discs is needed to rip everything from AMSF 00:02:00 until the last pre-lead-out sector, ignoring what TOC (except the lead-out position of course) and subcode say. But even so subcode has to be analyzed just to detect possible CATALOG fields and other flags encoded and add them in the written cue.
And when ripping these discs the written cue has to contain the CDI directive instead of MODE2/2352 .
Should be trivial to analyze the filesystem contained and rip these discs properly, only rip everything from AMSF until the last pre-lead-sector, determinate if the disc contains CATALOG and so on and write the cue with CDI instead of MODE2/2352. Sample of the first 17 sectors of two CD-i discs, which contain the CD-i signature.
http://www.mediafire.com/?3yenqq3mewqchx0
added: CDI directive
F1ReB4LL wrote:
Many Neo Geo CD games have multiple indexes for track 1, it's a protection scheme.
I bought a disc (kof97, that is including index 99 in track 1) and I confirmed it that dic wrote mutiple indexes for track 1 in cue.
other
added: output a list of file in 3DO disc. (using the code of http://kaele.com/~kashima/games/3do_dir.html)
improved: SubQ of adr 2(=EAN sector)(if adr is correct but EAN data is wrong, fixed it.)
fixed: log (hash of .img)
Updated EccEdc.exe
added: analyze header from [16] to [19]
1,268 2014-05-18 05:19:38
Re: DiscImageCreator (3,488 replies, posted in General discussion)
pablogm123 wrote:
Many Saturn games contain multiple indexes as well, if you are interested.
Thanks. But I have already multiple indexes in track 2, 3, 4... (Nanatsu no Hikan, pc-fx disc etc.)
If your introduced disc is cheap, maybe I'll buy. 
MrX_Cuci wrote:
The CUE sheet probleem seems to be affected by data only tracks
This is a big hint. Fixed.
1,269 2014-05-17 20:28:03
Re: DiscImageCreator (3,488 replies, posted in General discussion)
F1ReB4LL wrote:
Many Neo Geo CD games have multiple indexes for track 1, it's a protection scheme.
Oh, I see. To test, I think that I want to buy some disc before long .
1,270 2014-05-17 20:08:28
Re: DiscImageCreator (3,488 replies, posted in General discussion)
MrX_Cuci wrote:
App crash with latest WIP. I tried it three times. Perfect rip dumps the disc fine. Logs: https://www.dropbox.com/s/w8mh60gald22x9v/logs.7z There also seems to be a CUE sheet problem in latest build. See here: http://forum.redump.org/topic/13887/mis … ide-rally/
Does two problems happen in the same disc? Ｉn either case, please upload all created file except bin, img.
pablogm123 wrote:
Multiple indexes aren't added. Could you see this and fix it?
I hadn't supported at multiple indexes in track 1 until now.
Fixed probably. (Because I don't have a disc that is multiple indexes in track 1.)
1,271 2014-05-17 14:56:40
Re: DiscImageCreator (3,488 replies, posted in General discussion)
Thank you a report.
btw, post 398 and 399 is same problem?
1,272 2014-05-16 06:39:52
Re: bin2wav (8 replies, posted in General discussion)
Thanks. Fixed reading size.
1,273 2014-05-15 09:11:49
Topic: bin2wav (8 replies, posted in General discussion)
To pablogm123
I created the tool that it created a wav file from multiple bin (redump.org format).
Please test.
Repository
https://github.com/saramibreak/bin2wav
20170401
https://github.com/saramibreak/bin2wav/releases
20140516
http://www.mediafire.com/download/h89m2ut0b7x3am6/
1,274 2014-05-11 21:41:33
Re: DiscImageCreator (3,488 replies, posted in General discussion)
pablogm123 wrote:
they seem to contain the same data minus for the random errors and CD+G graphics are playable once mounted as ccd/img/sub in the Kega emulator.
I had ever thought that CD+G hadn't playable at ccd/img/sub...
Fixed: If disc is audio only, use 0xbe command and subcode is raw mode. (omitted /cdg and CDG directive in cue)
pablogm123 wrote:
Detected a bug when dumping a PCE CD game and reproduced by two different users who own the same disc, axisleon and F1ReB4LL:
Thank you. Fixed.
1,275 2014-05-09 19:04:51
Re: DiscImageCreator (3,488 replies, posted in General discussion)
pablogm123 wrote:
/p option should rip the pregap always, no matter if first track is audio, data or AMSF 00:02:00 is/isn't marked as index 00 by the subs. Currently it refuses to extract the pregap of that miniCD bundled with Tenbu Mega CD Special because AMSF 00:02:00 isn't marked as index 00.
remove index 00 checking