51

(3,493 replies, posted in General discussion)

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

No success.

http://www.mediafire.com/?6brdaaafxn78ew8

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

http://i.imgur.com/8LqYCrQ.png

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

52

(3,493 replies, posted in General discussion)

http://www.mediafire.com/?7jiiwwp6r8qh7lb

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.

53

(3,493 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.

54

(3,493 replies, posted in General discussion)

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

Test of a PS1 disc with LibCrypt protection.

http://redump.org/disc/355/

To check what DIC does regarding the modified subcode frames, they are mentioned in the DB entry.

55

(3,493 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.

56

(27 replies, posted in General discussion)

This subforum:
http://forum.redump.org/forum/11/dumps/

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:
http://forum.redump.org/topic/13553/

Taking this as example, would be this way:

http://redump.org/disc/29391/

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

Mastering SID code:
IFPI LY33

Mould SID code:
IFPI AEW37

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

57

(3,493 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.

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

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.

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

«Normal» sector:

http://i.imgur.com/7cVE6pQ.png

«Weird» sector:

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

58

(27 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:

http://club.myce.com/showthread.php?t=51912
http://club.myce.com/showthread.php?t=89212

59

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

60

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

61

(27 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:

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

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.

62

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

63

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

64

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

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

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.

[TRACK 1]
MODE=1
ISRC=0@41=0100013
INDEX 1=0

[TRACK 1]
MODE=1
INDEX 1=0

Subdump:
https://www.dropbox.com/s/dmkd2l490mtdrm1/subdump.zip

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.

65

(3,493 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.

http://redump.org/disc/5045/
http://redump.org/disc/17022/
http://redump.org/disc/29087/
http://redump.org/disc/4206/
http://redump.org/disc/5052/
http://redump.org/disc/5270/
http://redump.org/disc/4916/
http://redump.org/disc/8726/
http://redump.org/disc/29009/
http://redump.org/disc/25221/
http://redump.org/disc/23663/
http://redump.org/disc/25254/

66

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

67

(3,493 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:

http://www.mediafire.com/?32h85e2x65v11bl

68

(3,493 replies, posted in General discussion)

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?

69

(8 replies, posted in General discussion)

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

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

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

70

(8 replies, posted in General discussion)

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

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

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

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

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

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

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.

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

Ordered by LBAs.

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

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.

http://i.imgur.com/68lGLTg.png

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.

http://i.imgur.com/0YvnoTq.png

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.

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

71

(8 replies, posted in General discussion)

Tested.

Tracks are 2352 bytes smaller than expected.

http://redump.org/disc/21535/

Every gap of this disc contain 150 sectors, so expected size of the created wav file is 352800 bytes (raw audio) + 44 bytes (RIFF header):

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

And to put an example, compared against the rip I made one year ago using EAC (I don't have this program installed anymore) and gaps excluded:

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

For example, according to the DB track size of track 5 (actually named Summer Day 1 according to the filenames of files linked to audio tracks) is 43314432. 43314432 bytes - 352800 bytes  (due to excluded pregap) + 44 bytes (due to the RIFF header) = 42961676 bytes. EAC one's has the right size.

72

(3,493 replies, posted in General discussion)

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.

73

(3,493 replies, posted in General discussion)

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)

74

(3,493 replies, posted in General discussion)

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.

75

(3,493 replies, posted in General discussion)

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