Using /i and /c2 option at the same time crashes the app

377 (edited by pablogm123 2014-05-07 01:44:44)

You shouldn't use the /i option to dump normal discs, this option is ONLY to dump certain PCE CD discs with non-standard yet valid ISRCs. By doing so will get lots of fictitious ISRCs and therefore an invalid cue.

Example:
http://redump.org/disc/28248/

The use of that option doesn't make sense at all for you because anyway you are double-checking the possible CATALOG/ISRC/DCP... flags with PR.

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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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?

PR can rip either to CD+G bin/cue (raw image with interleaved subcode data in non-deinterleaved form, like Alcohol 120% images or created by the 2352to2448 themabus' program and CDG instead of AUDIO in the cuesheet) or to ccd/img/sub.

When only ccd/img/sub is selected PR will append an artificial lead-out in the image and in the the subcode. This is avoided by ripping simultaneously to normal bin/cue or to CD+G.

I mean to extract that way the subcode data to have at least clean R-W data. Format would be the classic ccd/img/sub.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

380 (edited by MrX_Cuci 2014-05-07 16:42:39)

Get this error with the CDI disc Pinball:

D:\DiscImageCreator\x64\Release>DiscImageCreatorWIP2.exe cd y: PinballCDI 8
OS
        Windows 7 Ultimate Service Pack 1 64bit
AppVersion
        x86, AnsiBuild, May  7 2014 13:42:15
CurrentDir
        D:\DiscImageCreator\x64\Release
InputPath
         path: PinballCDI
        drive:
          dir:
        fname: PinballCDI
          ext:
Start: 2014-05-07(Wed) 17:33:23
Checking reading lead-out
Creating bin from 37650 to 37652 (LBA)  37652
Reading lead-out: OK
Operation Code: 0xd8, SubCode: Pack
Creating img(LBA)  37651/ 37649
Internal error. Failed to analyze the subchannel. Track[01]/[02]

App crashes then.

Logs: https://dl.dropboxusercontent.com/u/355 … rorlog.zip

381 (edited by pablogm123 2014-05-07 18:01:25)

MrX_Cuci, upload the created .sub file as well. Without that, sarami won't be able to see what is wrong exactly and generated that Failed to analyze the subchannel. error.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

SUB: https://dl.dropboxusercontent.com/u/355 … allCDI.sub

Something weird which perhaps confuses DIC, the xxx68 frames (as seen in Subcode Analyzer) contain non-standard Q-frames. F2:17:01 instead of the minute:second:frame of the given track.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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.

TOC of CD-i discs is something "special".

MrX_Cuci:
discimagecreator.exe audio y: TOC -5000 -75

And post the created .sub file to analyze that weird TOC.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

386 (edited by MrX_Cuci 2014-05-08 21:47:43)

Is it normal pause sector is nog logged in CCD file? CUE has pause sector in it when using CDMage

TOC Pinball CDI: https://dl.dropboxusercontent.com/u/355 … allCDI.zip

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
On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

388 (edited by pablogm123 2014-05-09 04:26:03)

This is the best way I have found so far to dump the R-W data of my CD+G disc Rock Paintings: CD+G Sampler, as example. Dumping fully error free the subcode of this disc was the main reason of adquiring my first real Plextor drive, the PX-W4824TU, because I read that Carlos Hernández (IpseDixit) said many times that the proper way of dumping the R-W data of a CD+G disc is a real Plextor drive and the special mode for CD+G which applies error detection and correction, the packed mode. And to clean the P-Q subcodes unaffected by the packed mode the CDGTool program by Truong Hy.

http://redump.org/disc/23529/
http://club.myce.com/showthread.php?p=2128678

The test I ran yesterday, extracting 20 times the subcode of that CD+G to clean after the P-Q subcodes using CDGTool.

PerfectRip and both cdr and ccd rips have to be selected simultaneously.

http://i.imgur.com/njcEqjf.png

8x read speed, C2 pointers and the packed mode for subcodes.

http://i.imgur.com/Tm1OoH1.png

Standard offset correction (anyway this disc has no data pushed either to the first pregap or the lead-out) and single sector read commands, not bursts of 2x sectors. With bursts reads, according to the tests I did two years ago, R-W is always somewhat different.

http://i.imgur.com/d2dPun2.png

Repeat this 20 times, giving to the drive (and me) some time to rest and cool down.

Results after cleaning the P-Q subcodes of the extracted subcodes using CDGTool:

http://i.imgur.com/kdbGNzW.png

15/20 identical ones. And these ones match the one I extracted two years ago and archived in the rar archive posted below, when I purchased this drive. Then I remember that I performanced the same method and more or less there were 8-9 matches of 10 reads. And for the rawdump project in the 2012's Summer I redid this obtaining newly more or less constant results and this subcode dump was included in the rawdump of this disc.

http://i.imgur.com/FZ5vfZY.png

The 20 extractions including logs, the uncleaned subcodes and the cleaned subcodes. Only P-Q subcodes were cleaned by software, R-W were cleaned 100% by hardware, the special packed mode for CD+G.

https://www.mediafire.com/?8bdanad3dv6qpyj

===

Said this, I will try the new /cdg option of discimagecreator, to check if can provide the same accurate results than this method described. If actually uses 0xBE read command, packed mode, C2 pointers and single sector read commands should offer the same results, being more confortable (no need to enter offset correction, no annoying naming schemes...).

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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

Subcode extracted by the new function looks too different than the constant one I have as reference; it seems that the R-W subcodes are affected by a skew or something similar.

If you compare the reference against "Non-Plextor (NEC based) (Subdump).sub" and "Non-Plextor (Mediatek based) (Subdump).sub" you will notice that they seem to contain at first sight the same data. At least R-W data is not shifted and it's only affected by many random errors (perhaps ~2000 different bytes, as far I remember), because drives used support only the normal raw mode. In fact, except "Plextor (Subdump).sub" (this is under investigation) 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.

Results by the new option:

http://www.mediafire.com/?gm11zdccdu6t9i0

Different subs extracted by different methods and drives to compare:

http://www.mediafire.com/?7ejg94376g41j53
On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

sarami wrote:
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

/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.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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

Detected a bug when dumping a PCE CD game and reproduced by two different users who own the same disc, axisleon and F1ReB4LL:

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

Version used, the latest, that one with these hashes:

CRC32: 90bdbe17
MD5: e0b49e8aedb8e099d8f9a09c3f939e3c
SHA-1: b82c57d7fa02318e22d22a96c5a88eeeb74c3a72

Description of the issue: track 12 is completely in scrambled form. After removing the first 77 (audio) sectors, descrambling the data track and restoring the 77 audio sectors hashes are the expected ones:

CRC32: 01098cf1
MD5: aa9f2c8f79a2462911560b7275b1bcee
SHA-1: b246986e66b0f6c3561a5e7ea1f918f68f4c0437

Subcode dump of that disc got by subdump:

http://www.mediafire.com/?s1v9d5fmaqtta

Logs:

https://www.mediafire.com/?e8jejtucj7h8uon

This looks weird and likely is the problem:

    Data Sector, LBA   3365- 38271 (0x00d25-0x0957f)
    Data Sector, LBA  72512-    -1 (0x11b40-0xffffffff)

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

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.

No one will use nowadays CDRWin to burn a bin/cue image with the CDG directives, but a ccd/img/sub image and CloneCD. Or simply mounting that image which double as the original CD, but including fully error free subcodes.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

396 (edited by MrX_Cuci 2014-05-17 13:48:10)

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/

Speaking of cuesheets...

http://www.mediafire.com/?9h9cb8k4ic4512n

http://redump.org/disc/24412/

http://redump.org/disc/24412/cue/

Multiple indexes aren't added. Could you see this and fix it?

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

Thank you a report.
btw, post 398 and 399 is same problem?

399 (edited by pablogm123 2014-05-17 15:52:25)

No, they aren't different.

MrX_Cuci's problem is a fictitious index created, likely by random errors in the Q subcodes not properly ignored and therefore a fictitious index is created. MrX_Cuci, you don't use the /i option anymore, right?

CATALOG 0000000000000
FILE "Track 01.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 14:57:08

Should be simply:

CATALOG 0000000000000
FILE "Track 01.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00


Regarding that Neo·Geo CD game, problem is the reverse: multiple and real indexes encoded in the subcode not added to the cuesheet. For burning/mounting the ccd image this shouldn't be a problem, subcode is here and will double as the original disc, but for mounting/burning/using this via the cue file is a problem, because the game expects multiple indexes not present and game won't work.

Anyway, a fully error free subcode dump to analyze it, just in case that you need a clean subcode to analyze this disc:

http://www.mediafire.com/?32h85e2x65v11bl
On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

Nope, /i option abondened. I have just dumped another data track only disc. Also a wrong CUE sheet was generated.