Redump Forum

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.

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.

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:

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.

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.

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



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



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.



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:



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.



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

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

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:

Different subs extracted by different methods and drives to compare: