You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 52 of 56)
Topics by sarami User defined search
Posts found: 1,276 to 1,300 of 1,390
- 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.
sorry, I didn't write the subcode for LibCrypt...
re-fixed. But data is incorrect probably. Please test...
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)
added: /n option (for PlayStation LibCrypt disc)
added: disclog for PCE disc (1st, 2nd sector of the 1st data track)
Shouldn't I fix the subcode automatically?
fixed: check CD+G per track (for WonderMega Collection)
added: /m option (for WonderMega Collection)
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.
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.
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]
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.
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 .
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.)
Thank you a report.
btw, post 398 and 399 is same problem?
Thanks. Fixed reading size.
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/
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.
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
pablogm123 wrote: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.
improved /p option
pablogm123 wrote:Any chance of 0xBE + packed mode + single sector reads for CD+G discs?
added: /cdg option
MrX_Cuci wrote:Get this error with the CDI disc Pinball:
FULL TOC on SCSIOP_READ_TOC
FirstCompleteSession: 1
LastCompleteSession: 1
Session 1, FirstTrack 2, Format: CD-I
Session 1, LastTrack 2
Session 1, Leadout, MSF 08:24:00 (LBA[037800, 0x093a8])
Session 1, Track 1, MSF 00:02:00 (LBA[000150, 0x00096])
LBA[000066, 0x00042], Track[01]: Adr[6] -> [1]
LBA[000066, 0x00042], Track[01]: TrackNum[135] -> [01]
LBA[000066, 0x00042], Track[01]: Idx[42] -> [01]
LBA[000166, 0x000a6], Track[01]: Adr[6] -> [1]
LBA[000166, 0x000a6], Track[01]: TrackNum[135] -> [01]
LBA[000166, 0x000a6], Track[01]: Idx[42] -> [01]
:
:
umm.. I don't understand why first track and last track is 2, why adr and tracknum and idx is these values.
I want to test. But I don't have CD-I disc.
pablogm123 wrote:Edit: minor bug detected in the x86, AnsiBuild, May 5 2014 00:11:05 version. When the disc has TOC vs. subcode desync, the normal cue (TOC in priority) has filenames with the '(Subs indexes)' string.
sorry, fixed.
pablogm123 wrote:Any chance of 0xBE + packed mode + single sector reads for CD+G discs?
single sector? it's not cdg format (2448byte) but bin format (2352byte), isn't it?
MrX_Cuci wrote: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.
pablogm123 wrote:Just (Subs indexes) instead of _SubSync .
Changed
Fixed
pablogm123 wrote:The last frame of subcode isn't altered anymore, see the posted subcode.
Is there a error log of the last frame?
MrX_Cuci wrote:Any idea why it took like six hours to dump the disc from attached logs?
Thank you. please wait until fix.
pablogm123 wrote:-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.
pablogm123 wrote: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.
pablogm123 wrote:TOC indexes in priority should be the default option.
fixed option
pablogm123 wrote: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?
F1ReB4LL wrote:sarami wrote:Yes. I have 134 PCE CD now.
Your dumps are welcome 
I don't have a recommended ripping tool for PCE.
pablogm123 wrote: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
Posts found: 1,276 to 1,300 of 1,390
