Recent drives are somewhat trash for the enthusiasts of digital audio extraction, because recent drives lack near always of overreading into the lead-out, and sometimes of overreading into the first pregap.

Without taking into account real Plextor drives, my old GCE-8526B LG-Hitachi CD writer is just fine for PSX: reads finely without workarounds no longer allowed the last sector of data tracks of no EDC discs with audio tracks and can overread into the first pregap AND lead-out using EAC, so for any +2 PSX disc is just fine. A -647 disc which would lose potentially audio samples due to negative combined (-641 samples for a +2 discs)? Just rip the first audio audio track in a +667 drive and solved.

Tha main problem with current conventional drives is the lack of overreading into the lead-out (however, audio trap disc method acts as workaround to rescue the lost audio samples when supported). Tipically, conventional drives won't read into the lead-out at all, so the risk of losing audio samples (especially for +2 discs and +667 drives) does exist and you cannot match certain DB entries due to that.

Examples of entries you cannot match with a +667 drive: And the discs which share the same last dummy track:

For discs without audio tracks... near every modern drive is fine.


(1,166 replies, posted in General discussion)

Dummy images to test:

To be burned only using CloneCD, in RAW DAO 96 mode and with that option not to repair subcode data enabled.

For MegaCD/Saturn/TurboGrafx-CD/Neo Geo CD... dumping a drive which supports D8 command is needed yes or yes. Additionally with these drives truncated audio tracks due to the lack of overreading is a thing of the past and make possible the use of PerfectRip, DiscImageCreator and so on which ease so much the dumping of discs with audio tracks, without truncated audio tracks, ruined last sector of data tracks of no EDC PS1 discs with audio tracks...

Plextor PX-712SA, PX-716SA, PX-755SA and PX-760SA. Or any +30/+98 real Plextor drive converted into an external drive via an PATA/SATA to USB 2.0 adapter.

As very last resource, a drive which supports properly the audio trap disc method via the emergency hole to dump into scrambled form the discs, like an Optiarc AD-7240S.


(1,166 replies, posted in General discussion)

Much better. Expected intentional errors (32) + 9/10 false ones due to either corrupted RMSF/AMSF or CRC-16. I am wondering if would be possible to create an algorithm to smartly detect these sectors and leave them untouched, as XOR every frame of this range with 0x0080 and 0x8001 (I mean try both possibilities, not literally XOR with 0x0080 and the got data XOR with 0x8001) to undo the initial XOR operation, if the new CRC-16 matches now the rest of the Q-Frame, is a Libcrypt frame and shouldn't be altered.

Main page gives the tips, posted below.

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.


(1,166 replies, posted in General discussion)

discimagecreator.exe cd g: Wip3out 8 /c2 1000 4096 8 /l

No success.

These modified frames. And once modified the new CRC-16 is XORed with 0080.

43012    09:33:37    41 01 01 09 31 33 00 09 13 37 63 09    8f60
43017    09:33:42    41 01 01 09 11 42 00 0d 33 42 15 c2    e948


(1,166 replies, posted in General discussion)

Fully clean subcode of Wip3out (Europe) (En,Fr,De,Es,It) without random errors and with the expected modified frames (curiosly, being a disc produced by Sony DADC pregaps are Philips style), so that you can examinate it. As far I know, actual contents of the modified frames isn't actually important for this protection in a real console as long as the calculated CRC-16 doesn't match the stored Q-CRC16.

Any chance of smartly detecting these frames and do not repair them? 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.


(1,166 replies, posted in General discussion)

For LibCrypt protected discs, of course that absolutely not. At least the modified frames (only que Q subframes). Later I will post a sample of a subcode from that disc fully cleaned and with the expected modified Q subframes.


(1,166 replies, posted in General discussion)

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.


(1,166 replies, posted in General discussion)

I asking how handles EccEdc.exe those sectors where copies of subheader differ. No error (because EDC/ECC match the expected), only warning (due to mismatching copies of subheader) or false error (what CDmage does)? Ideally, should be reported as warning.


(26 replies, posted in General discussion)

This subforum:

As template, but specifying more clearly what is mastering ring code, mastering SID code, toolstamp, mould SID code and additional mould text, layer from that code and we put <TAB> for any ammount of multiple spaces:

Taking this as example, would be this way:

Mastering ring code:
Sony DADC<TAB>5057288DVD 01

Mastering SID code:

Mould SID code:

And because it's a single layer DVD, only there is codes in that layer, as general rule (certain DVD-5 discs can contain a dummy second layer with codes more or less readable depending on how the artwork cover these codes).


(1,166 replies, posted in General discussion)

Speaking of EccEdc.exe... what does regarding the situation I am going to describe?

This is an old bug of CDmage. If the two copies of the subheader of a mode 2 form 1/form 2 sector vary, CDmage will report falsely this as error. Wrong (as maximum can be reported as warning or whatever, not as error itself), because user data matches the stored EDC/ECC, so there is no corruption.

Screenshots of an affected data track.

10 errors reported by CDmage, the last one (actual and expected, disc contains no EDC in form 2 sectors and audio tracks) and the first nine ones, errors as real as Mickey Mouse is.

Same data track checked by a much modern program based on the code of ECM. Much more detailed and real error reporting, no errors real as Donald Duck.

«Normal» sector:

«Weird» sector:


(26 replies, posted in General discussion)

CD Manipulator does support RAW DAO 96 burning, subcodes generated by the software (when no sub is available) or read from the sub file. ImgBurn is simply RAW SAO, subcodes generated by burner according to the cuesheet sent.

Regarding dumping of Tagès:


(26 replies, posted in General discussion)

It's a lossless process, converting from MDF to img+sub (2448to2352) and reconverting img+sub to 2448 (2352to2448) and then renaming to MDF gives the original MDF file. And that .sub file can be replaced with the extracted by subdump and the MDS will be still valid of course.

Subcode data is mainly useful for multitrack discs, to detect accurately the gaps of tracks and imperative for these EUR PS1 discs protected by LibCrypt. For normal PC discs with just a data track even bin/cue is just fine, so perhaps ccd/img/sub (accepted by CDManipulator in RAW DAO 96 mode, by ImgBurn as well, but will ignore the sub and subcode will be generated by the burner) is the optimal solution.


(26 replies, posted in General discussion)

Separated compatibility is better, can be used as bin/cue, ccd/img/sub image and opened by programs as IsoBuster and CDmage. The major thing is understand that MDFs of CD discs won't match due to random errors in the subcode, nothing more. Once separated, main channel should match if the dumps are good (and should match IsoBuster, CDManipulator's... imgs if disc doesn't contain audio tracks).

Erroneous sector of CDs discs protected by SecuROM is in the postgap, the 4th sector from the end. This sector reminds the last sector of data tracks of PS1 discs without EDC in form 2 sectors and with audio tracks, looks very similar, a mode 2 sector with erroneous ECC data.

A read error doesn't sound good, even if sectors 0-15 are don't contain normally useful data in PC games, it's normally used only for console discs (header and whatnot of Saturn games, logo and license of PS1 discs...).


(26 replies, posted in General discussion)

It's extremely unlikely that you rip to mds/mdf once CD several times and you get the same hashes, or directly impossible due to random errors in the subcode:

2448to2352 can split the MDF file into main channel and subchannel. Main channel should be always identical and uniform for these these discs. Subcode is always affected by random errors.

2352to2448 to do the reversed process: convert a clean subcode and the raw dump into a MDF file reusing the MDS previously created.


(26 replies, posted in General discussion)

Only MDS format can capture data of physical measurements (due to that it's suggested in the guide to create one MDS file for personal use), needed for SecuROM and StarForce. ccd cannot capture that, it's a simple .txt file similar to a .ini file which describes the TOC, but nothing related to physical measurements. I doubt that a personal backup will work without doing anything special due to the physical measurements performed by the protections.

RPMS needed to burn and Alcohol to emulate DPM data. Perhaps Daemon Tools with SPTD installed, to enable advanced emulation options can mount the image (or even create it in certain advanced editions) and get this image acting as the original disc in order not to wear the precious original disc.

For Safedisc, a decent burner capable of burning weak sectors (decent EFM encoder) and done, as far I remember.

Exact meaning of outter and inner ring? Could you describe them using the terms read side (L0) and label side (L1)?

By the way, very likely you are missing the mastering SID code of The Elder Scrolls dumps, these discs contains reallly ultramegasmall mastering SID codes, likely IFPI L030 or similar.

And these dumps lack of PVD data and properly barcode spaces, if you provide/fix these ones, better yet.


(26 replies, posted in General discussion)

bin/cue should be good enough for every common disc layout. ccd/img/sub is needed actually in certain discs which contains mixed type pregaps (75 sectors of data + 150 of audio, being the first ones marked as data in the subs). bin/cue cannot handle this layout, ccd/img/sub can because actual .subcode is present. mds/msf for this protections which measures physical disc positions.

Anyway, converting bin/cue to ccd/img/sub if you prefer this format in the future is trivial: just mount the image, create a CloneCD/CDManipulator dump (.img file created should match the original .bin) and replace the .sub created with the one dumped by subdump.

Even if the disc is in near mint condition and not affected by discrot, subdump takes some time to dump the subcode (not protected by CIRC, so no error correction is offered and a high ammount of rereads is needed to get uniform and constant data). For a disc in good condition with more or less 70 minutes (740,880,000 bytes of data extracted into raw mode), without any class of deep scratch, expect easily 45-60 minutes.


(26 replies, posted in General discussion)

That page contains updated and accurate data, was written by MrTikki after asking me and others lots of questions to write the best possible guides yet easy of understand.

Guide basically says that you should extract the data track as usual using IsoBuster, raw mode. You should dump the disc at least twice and make sure that dumps are identical, better yet if using different drives when possible.

Nothing more is needed for the DB, except obviously the errors count (1 expected error in the postgap zone) and perhaps a quick and dirty subcode dump got by CloneCD/CDManipulator (subdump only if are really interested in getting the cleanest subcodes possible, but it's very time consuming and for detecting CATALOGs and so on even a quick and dirty subcode dump by CloneCD is good enough) to determinate properly if the disc contains CATALOG and other possible flags. One good strategy and efficient would be dumping the disc as usual using IsoBuster, and then a CloneCD/CDManipulator (see the screenshot posted below) dump with the proper profile to kill two birds with one stone: to verify the IsoBuster dump and to get the quick and dirty subcode dump that you can upload (subcodes compressed are very small files).

For you personal backup and archive perhaps you could desire to create a mds file for that disc. Create it and archive it. If the dump by Alcohol lacks of subcodes mdf file must match the dump got by IsoBuster and/or CloneCD/CDManipulator.

P.S.: CDManipulator can create .ccd files if you choose that in the file output options once selected the multi-session mode. Just use any plain text editor to delete the ficticious ISRCs which uses to add due to random errors in the subcode not properly ignored.




Reference of command line for a non-real Plextor drive:

subdump.exe -i g: -f test.sub -mode 1 -rereadnum 25 -speed 8 -flushspeed 8 -fix 2

Optimal speed depends on the drive used. Certain drives read better at lower speeds (4x/8x), others one at higher speed (24x and higher).

If there is a  real Plextor drive which supports D8 command:

subdump.exe -i g: -f test.sub -mode 2 -rereadnum 25 -speed 8 -flushspeed 8 -fix 2

And if you are just interested in getting a quick and dirty subcode dump, somewhat cleaner than the one got by CloneCD/CDManipulator and verifying the linearity of subcodes frames add the -quick parameter.


(1,166 replies, posted in General discussion)

sarami wrote:

Oh, I see. To test, I think that I want to buy some disc before long big_smile .

Many Saturn games contain multiple indexes as well, if you are interested.


(26 replies, posted in General discussion)

As long as the program and platform you run use the standard 0xBE read command, the dump is raw (2352 bytes per sector) and you have a minimally decent drive everything is OK and extension doesn't matter actually. Anyway, for CD discs we don't add cooked dumps, 2048 bytes per sector.

To put this simple taking as example a conventional, without Safedisc, SecuROM and these things, PC CD game with just a data track extracted by Isobuster in raw mode, CloneCD (when using this one TURN OFF regeneration of data in the read profile, we don't want that CloneCD fixes in the fly user data of damaged sectors using the stored ECC because this is as dumping a disc into raw mode to fix later bad sectors using CDmage, dumps shouldn't be modified in this sense) and Alcohol 120%.

bin of bin/cue = img of ccd/img/sub = mdf of mds/mdf (only if subcodes weren't read, if so mdf will contain interleaved subcode data and you need the 2448to2352 program by themabus to split the mdf file into main channel and subcode). Simple as that.

Problem are discs with audio tracks, you have to find a program for Linux which can:
-Perform a secure ripping, either by multiple reads or C2 pointers.
-Correct the offset, any value you desire once detected the proper one.
-Detect properly gaps and append them to the next track.
*-Detect possible CATALOG/DCP/ISRC flags (this ideally for discs with only a data track as well).
-Extract to headerless files, or at least run sox to remove RIFF headers.

*Answer to the "Is cue good enough for detailing all the intricacies of the disc or is there some more information" question. To detect them PR is good and for discs without copy protections and with just a single data should work even without a real Plextor drive.


(1,166 replies, posted in General discussion)

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:


(1,166 replies, posted in General discussion)

Speaking of cuesheets...

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


(5 replies, posted in General discussion)

Same results than PR appending gaps to none and ripping to wav.


(5 replies, posted in General discussion)

Never was so easy to split properly into individual tracks and indexes a bin/cue image.

To test my favourite PS1 soundtrack, Racingroovy/ レーシングルーヴィー。Variety of styles in the racing themes and likely one of the best menu themes I have ever listened. Composed/produced by Satoru Wono, just in case that someone is interested in tagging properly these tracks (names of tracks 06-13 [racing themes], including these ones, are official, they are in the booklet and in the juke box of the game).

.DA files, which are actually linked to audio tracks. Windows adds automatically the RIFF header (and due to this are actually .wav files once renamed to *.wav) when you copy these ones as normal files from the physical CD/virtual drive once mounted the image via the file manager of Windows. Of course, the best option is from a virtual drive mounting the redump image, because copied files will be offset corrected, it's impossible that there are C2 errors and it's much faster.

Ordered by LBAs.

Splitted .wav files compared against the ones which were extracted a time ago via mounting the image into a virtual drive and copying these .DA files as normal files. Then renamed, tagged and whatnot. Fully success! DA files don't include pregap (length of audio is dictated by the ISO9660 file linked to the audio track, without including pregap) and therefore match the .wav files created.

To test this deeply, I have converted the .wav files to headerless files by removing the first 44 bytes and renaming to .raw.

All pregaps of this disc include only digital silence and hashes are the expected ones for a file filled with 352800 bytes of zeroes.

Last test: prepend 352800 bytes of zeroes to the indexes 1 of tracks, to restore the missing pregaps. As expected, now they match the original .bins, thus .wav files have the right size, they are properly aligned and no audio data was lost.