1 Reply by Eidolon

(10 replies, posted in General discussion)

Vigi wrote:

Yeah that's error output, you should just repair it with cdmage.

But in one of the other discussions, Dremora mentioned:

Dremora wrote:

We are not forgetting anything - some discs have mastering EDC/ECC errors which shouldn't be fixed (either accidental or intentionally made by the developers). Not only PSX, but even some Sega CD discs have these errors, so by ripping data tracks in cooked mode or fixing them with CDmage you'll lose data.

So, if I used CDMage to fix the last sector (my option 3), the dump would not be like the original.

- How can I determine if the faulty EDC/ECC data is intentional, or if it happens because of a bad disc?
- How can I determine if I should rely on EAC's pregap detection or not?

Go to forum: General discussion

2 Reply by Eidolon

(10 replies, posted in General discussion)

of image version 1, here is the last sector, unfixed:

LBA :108157

0000 : 00 00 00 00 00 00 00 00  00 00 00 00 24 04 07 01   ............$...
0010 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0020 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0030 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0040 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0050 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0060 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0070 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0080 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0090 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00A0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00B0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00C0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00D0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00E0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00F0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0100 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0110 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0120 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0130 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0140 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0150 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0160 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0170 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0180 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0190 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01B0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01C0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01D0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01E0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01F0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0200 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0210 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0220 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0230 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0240 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0250 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0260 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0270 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0280 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0290 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
02A0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
02B0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
02C0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
02D0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
02E0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
02F0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0300 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0310 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0320 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0330 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0340 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0350 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0360 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0370 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0380 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0390 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03A0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03B0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03C0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03D0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03E0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0400 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0410 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0420 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0430 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0440 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0450 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0460 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0470 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0480 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0490 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
04A0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
04B0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
04C0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
04D0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
04E0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
04F0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0500 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0510 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0520 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0530 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0540 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0550 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0560 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0570 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0580 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0590 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
05A0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
05B0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
05C0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
05D0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
05E0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
05F0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0600 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0610 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0620 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0630 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0640 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0650 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0660 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0670 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0680 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0690 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
06A0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
06B0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
06C0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
06D0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
06E0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
06F0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0700 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0710 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0720 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0730 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0740 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0750 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0760 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0770 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0780 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0790 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
07A0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
07B0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
07C0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
07D0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
07E0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
07F0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0800 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0810 : 44 6C DF 17 00 00 00 00  00 00 00 00 38 F3 F1 F5   Dl..........8...
0820 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0830 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0840 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0850 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0860 : 00 00 00 00 00 00 CC B4  7C 39 00 00 00 00 00 00   ........|9......
0870 : 00 00 1C F7 F6 F4 00 00  00 00 00 00 00 00 00 00   ................
0880 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0890 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
08A0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
08B0 : 00 00 00 00 00 00 00 00  00 00 00 00 88 D8 A3 2E   ................
08C0 : 00 00 00 00 00 00 00 00  E6 82 00 00 00 00 00 00   ................
08D0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 02 6A   ...............j
08E0 : 51 6D FD BC AE BB 00 00  00 00 00 00 00 00 00 00   Qm..............
08F0 : 00 00 00 00 00 00 26 65  5C 40 9C A7 C2 86 00 00   ......&e\@......
0900 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0910 : 00 00 DD 7D 69 38 92 26  26 63 00 00 00 00 00 00   ...}i8.&&c......
0920 : 00 00 00 00 00 00 00 00  00 00 D7 90 92 47 87 51   .............G.Q

Go to forum: General discussion

3 Topic by Eidolon

(10 replies, posted in General discussion)

Ok I'm not panicking, it's about the Sega CD game "Panic!" (US version).

Ripping its data track I ran into a problem.

Analysing the disc layout with EAC, a track 2 pregap of 1:74 is reported.

So, according to the redump guide, I remove 149 raw sectors from the end of track 1 (resulting image version 1 = 108158 raw sectors)

But when I analyze the resulting image with CDmage, an error is reported in the very last raw sector (severity "low" though).

This doesn't happen if I "play dumb" and remove 150 raw sectors as if there was a pregap of 2:00 (resulting image version 2 = 108157 sectors).

What are your thoughts on this? Obviously I don't want to keep or submit a corrupted image.

Should I
1) keep and submit image version 1
2) keep and submit image version 2
3) repair image version 1 with CDmage, then keep and submit it

UPDATE
Both IsoBuster and CDRWIN report a track 1 length of 108307 raw sectors. So, assuming the 1:74 pregap as the guiding principle, the logical conclusion would be to keep image version 1 (108158 + 149 sectors attached to next audio track = 108307 sectors). However, that would mean to keep a corrupted track 1 image...

Go to forum: General discussion

4 Reply by Eidolon

(11 replies, posted in General discussion)

p_star wrote:

GoodSaturn? smile
CDRWin is not able to define correctly gap between 2 date tracks in many games SS.
Nights Into Dreams for example

Thanks for the tip. I have the EU version of that game, so I'll check it.

Anyway, Saturn dumping is an issue which I still have to get into - knowing that Saturn games, unlike Sega CD games, have copy protection, this might become more difficult and may even lead me to dropping the GoodSaturn project in favour of redump.org

Go to forum: General discussion

5 Reply by Eidolon

(7 replies, posted in General discussion)

Vigi wrote:

Good job on your post, only it would be nice if you could explain the following part, because I don't understand what you mean:

However, for any existing rip where the drive read offset is not known, it can be determined if it originally came from an original CD or not! This is a significant advantage over the redump.org database.

Yes I see I have phrased that badly. What I mean is the following: If the Inn database contains intelligent checksums for a particular game, you can test your rip against that. If the checksums are the same, you KNOW that your rip - even if it has a different audio offset - has come from an original CD (i.e. it is a "good" rip which you can keep), or e.g. from a ripped, burnt and re-ripped ISO/MP3 fileset (which is a "bad" rip you should delete immediately ;-).

Vigi wrote:

Also, I hope CDRWin is capable of detecting the correct gaps on all drives, because I don't see any mention of it in your post. Gaps can be a real pain (at least with EAC).

Therefore, we have to define "correct" detection. From my findings so far, it looked that CDRWIN and EAC detected the gaps the same way, even on my "bad" drive. This is one of the questions noone here did answer me yet sufficiently, apart from blunt "CDRWIN sucks" answers.

Vigi wrote:

Also, have you considered writing your tool in C for crossplatform compatibility?

Probably not. Why should I? All ripping is done in Windows anyway. However, I plan to make the C# source freely available so anyone can look at it and improve it.

Go to forum: General discussion

6 Topic by Eidolon

(7 replies, posted in General discussion)

See here.

I think this constitutes the best of two worlds.

When the tool is finished, it will still be possible to submit valid information (valid according to redump.org method) from my ripping method to the redump.org database. At the same time, we give the Sega community a more flexible way to compare their rips.

Go to forum: General discussion

7 Reply by Eidolon

(6 replies, posted in General discussion)

F1ReB4LL wrote:
Eidolon wrote:

Wirehead exists; if as a commercial release or as a demo I cannot say. I have the disc, but unfortunately only as a pirate copy. I need to check wether it's 32X at all.

It was released for Sega CD, but your base claims it was later rereleased as 2CD SegaCD + CD32X combo, just like Fahrenheit.

Maybe. Then I've never seen a dump of the 32X version. I just checked my (pirate) copy - it's SegaCD only.

Go to forum: General discussion

8 Reply by Eidolon

(55 replies, posted in General discussion)

Dremora wrote:

2Eidolon:
Didn't want to make any comments - I thought you would understand that your method is wrong after a couple of answers from our dumpers. Looks like I've been mistaken...
I see absolutely no point in using Cdrwin. It offers no benefits comparing to the current method. Dumping using EAC takes less time and is more accurate. And Cdrwin can't even properly dump audio - this should be quite enough to stop anyone from using it in attempt to make perfect dumps. It is just a waste of time and efforts.

I disagree. Even on a "bad drive" as I seem to have, CDRWIN dumps give you EXACTLY THE SAME RESULTS and EXACTLY THE SAME METADATA (write offset value) as the redump method. Of course, only for the unproblematic discs (the ones where the last audio track doesn't run into the lead-out).

Moreover, in your process you're forgetting to run the data tracks through CDMage to confirm correctness - something which wouldn't be necessary at all if you only dumped the MODE1/2048 user data.

Also, none of your dumpers have proven to me that EAC is "more accurate" than CDRWIN (see my Burai ripping experience - EAC was even less accurate with my bad drive).

But as a conclusion:

Apart from bad discs (as Snake said, easily identifiable through their non-zero data at the end of the resulting BIN file), there is no reason at all to use the complicated ISObuster+EAC method outlined in the redump guide!

You can simply dump the CD twice with CDRWIN, and if the resulting BIN files match you can be reasonably sure that it is a good dump.
After that, you check if the resulting dump contains an ample amount of 00's at the end. If it does, you have a good dump.

Go to forum: General discussion

9 Reply by Eidolon

(6 replies, posted in General discussion)

The correct SegaBase link should be http://www.eidolons-inn.net/tiki-index. … e=SegaBase.

Wirehead exists; if as a commercial release or as a demo I cannot say. I have the disc, but unfortunately only as a pirate copy. I need to check wether it's 32X at all.

Anyway, even 32X Sega CDs still only have MODE1/2048 bytes user data, so yeah, the ripping process can be the same as for plain Sega CD.

Go to forum: General discussion

10 Reply by Eidolon

(55 replies, posted in General discussion)

Vigi wrote:

(Your Burai disc for instance. It doesn't have 100% track quality everywhere, does it still give the same 'intelligent' audio checksum as EAC?)

That is a good question. I will check that.

Go to forum: General discussion

11 Reply by Eidolon

(55 replies, posted in General discussion)

Vigi wrote:

Of course it would be nice to have a faster and more reliable dumping method, but I don't see how an obsolete tool like cdrwin (can it even detect proper gaps?) can improve things.

I wouldn't call CDRWIN obsolete. It is an actively maintained program just as Isobuster and EAC are. And my comparison proves that in theory it is easy to convert a CDRWIN dump to the REDUMP format (and vice versa), because the offset value you get from your Isobuster-clicking-around-between-tracks-1-and-2 is easily calculable with the CDRWIN dump. From that, you can derive the write offset.
It seems noone here in this community has bothered to actually check out CDRWIN properly (maybe my statement is a little premature, let's give your other community members some time to answer...).
And hey I'm NOT working for Goldenhawk technology, before anyone asks...

Vigi wrote:

Even though I like the results of your test, I would still like to see a time comparison that includes splitting the tracks and creating a proper cuesheet etc. until the output it identical to Redump's.

How much time you save in the end depends on the availability and intelligence of the analysis tool I outlined. Of course, the redump disc submission process may have to be adapted as well in order to parse different files.

Vigi wrote:

Besides, you will always need a drive that supports certain features (overreading, C2, etc) if you want to be sure that the output is correct.

Correct.

Vigi wrote:

I'm still waiting for the PerfectRip successor myself.

Depending on how my research goes, the first step towards that that could be a one-click CDRWIN image dump, plus running it once through that "analysis tool".

Of course, one single tool would be better.

Vigi wrote:

In the meanwhile, I'll have my eyes open for the stuff that you and Snake come up with.

Yeah, let's all keep open minds on the matter.

We disagree on the importance of RAW data for systems which don't need it, and the practical importance of normalizing the audio data offset using measured/calculated read/write offset values.

But we agree on the importance of not losing data, have proper pregap detection (ensures proper start of audio tracks) and of individual track checksums to be able to make comparisons.

That's enough common ground, I say.

Go to forum: General discussion

12 Reply by Eidolon

(55 replies, posted in General discussion)

No, it's got nothing to do with community politics, and I don't think I'm going in circles.

Like in every discussion, when I get new information (like the comparison I did yesterday between Isobuster+EAC and CDRWIN methods), I have to question again the premise of the REDUMP guide.

For the new questions I have posed now (especially pregap detection), I still did not get sufficient answers, but hope to get them.

I have understood your goals now (or I think I do)
- treat all CDs equal, i.e. RAW mode dumps not caring wether its MODE1/MODE2/CDI/whatever, to have the guide as simple as possible
- normalize audio data by adjusting for the read/write offsets and shifting them in the track dump accordingly
- store data and audio tracks in seperate files and checksum them seperately to provide comparability between different game releases
- anything else I forgot?

If I find out that there is an easier way to achieve the same goals, and it can be proven that it works just as reliably, and it even provides the same results and checksums as the REDUMP method (and thus could be used to submit data to both redump, tosec and whatever else) why not pursue it?

Please understand I am not trying to "rip apart" (no pun intended, hehe) the redump.org project, I am merely joining the discussion.

It's not a matter of choice, it's a matter of how to collaborate.

Go to forum: General discussion

13 Reply by Eidolon

(17 replies, posted in General discussion)

Yes, somehow there seems to be confusion about the INDEX value for the audio track file.

It seems Kega uses the INDEX00 position rather than the INDEX01 position when loading the "REDUMP" CUE sheet.

INDEX00 points to the pregap silence
INDEX01 points to the audio track without pregap silence

Go to forum: General discussion

14 Reply by Eidolon

(55 replies, posted in General discussion)

themabus wrote:

here, i did some more math:
name|offset(bytes)|silence(b)|difference(b) -you'll miss that on 0 offset drive
nostalgia|7800|1864|~6k
sangokushi 3|3880|1344|~2.5k
jangou w c|19|lucky
cosmic fantasy|7208|676|a lot
gambler j.|1823*4|1760|4x
...i just walked up directories sorted by serial skipping winning post...

Too bad, I don't have any of these games to test them with CDRWIN. Would be nice if one of you could check and see if CDRWIN really cuts of the last audio data bytes, or simply reads a few sectors into the postgap until there are only zeros.

Go to forum: General discussion

15 Reply by Eidolon

(11 replies, posted in General discussion)

gigadeath wrote:

A method which needs exceptions correction to give proper results is not what we want. Our method don't comprehend exceptions. It works with all discs and handle them all the same way with proper results. I don't want to dump a disc first and THEN have to check if it falls in the exceptions category or not. I'll dump with IsoBuster+EAC directly and all will be fine.

Well, it hasn't been proven yet that CDRWIN definitely cuts of data from the last audio track. That could easily be checked by one of you guys, taking one of the example Sega CDs (e.g. Winning Post) where you say that they contain audio data until the very last byte.

If you do that, and compare the raw audio data from the Isobuster+EAC dump and the CDRWIN dump using the method I outlined in my Inn post, and then get a difference, then it is proven that CDRWIN behaves faulty and cuts of data. If it is still the same checksum, then it is proof that you do not lose data with CDRWIN.

Finally, with each dump you can take note of the drive read offset, detect the sample offset and from that calculate the factory write offset using one single tool analyzing the dumped CDRWIN image. Together with the cue sheet, you can also calculate checksums for all tracks, even choosing different methods (with or without offset correction, with or without pre- or postgap zeros).

Also, I'm still waiting for a sufficiently good statement about CDRWIN's and EAC's pregap detection. Is there any particularily "difficult" CD with which that can be tested and see if both tools come up with different results?

Go to forum: General discussion

16 Reply by Eidolon

(17 replies, posted in General discussion)

Nevermind. Number 2 is a non-issue, I tested it again today and it works fine.

That Kega doesn't work with REDUMP cue sheets seems to be because of the way you guys handle the addition of pregaps to the beginning of the single audio track file.

Go to forum: General discussion

17 Reply by Eidolon

(11 replies, posted in General discussion)

gigadeath wrote:
Eidolon wrote:

- Is EAC's pregap detection really that much better than CDRWIN's?

Others might answer better, I'll choose the easy one: yes. Much better. I know Themabus is a gap guru, he can give a deeper answer.

Hey Themabus, can you please comment? That would be really interesting to know! Because as I wrote in my Inn article, it seems that both EAC and CDRWIN detect the pregaps just fine.

gigadeath wrote:

I hope so, the more tools, the better (assuming they work right, of course). But we have to decide how to define "normalization". The reference for normalization should be full dumps only.

CDRWIN dump is a full dump (with one exception see last sentence)

Well, as I wrote in the Inn article - in this case, it would be very easy to shift the audio data again by 11016 bytes "left" as you do in the current redump process to come to exactly the same image.
EDIT: And that can even be done automatically by the analyzer tool, because this offset you currently detect cumbersomely, manually using ISOBuster can be easily detected in a CDRWIN image. It is the difference between the start of the first non-zero audio byte of the first audio track and the end of the data track.

Mind you, this method only workds with the prerequisite there should be an ample amount of zero's at the end of the dumped CDRWIN image.

Go to forum: General discussion

18 Reply by Eidolon

(11 replies, posted in General discussion)

gigadeath wrote:

I like your researches. But...

I like to do some research before I start such a project as GoodSegaCD or GoodSaturn, or join a project like redump or tosec. smile

gigadeath wrote:

Problem is that once you start memorizing the procedure, the IsoBuster+EAC procedure we follow now takes so little time that it makes the switch to CDRWin useless, because there's no real saving of time when you learn the passes and do them automatically.

Of course, every method is a matter of getting used to it. But I still dispute your argument that it couldn't be done faster with the method I propose above.

gigadeath wrote:

Probably today it took you much time to dump a single disc, but what you did in half an hour I can do in 7 minutes:
-1 minute finding offsets
-1 minute ripping data track and resizing it
-5 minutes ripping audio tracks
I guess someone already said it, but there's not real time saving in using CDRWin, and you risk to lose data with it.

Well, that is what I put up for discussion here, I haven't heard sufficient arguments. Look at my proposed method, if it is true then it could be something like this:
-1 minute finding offsets
-5 minute ripping complete CD (cue, data, audio)
-1 minute running the rip through the fixing tool

Well you see that the time may be the same, but the amount of manual work you have to do is significantly less.

I guess it comes down to the following questions:
- Is EAC's pregap detection really that much better than CDRWIN's?
- Can someone write the "image normalization and checksumming" tool I proposed on the Inn?

Go to forum: General discussion

19 Reply by Eidolon

(17 replies, posted in General discussion)

gigadeath wrote:

It could be CDRWin working like EAC's "append gaps to previous track" (which is wrong).

Why is that wrong?

Go to forum: General discussion

20 Reply by Eidolon

(55 replies, posted in General discussion)

chungy wrote:

redump.org doesn't "just dump the user data" for any system, so it's a null point. If they did, it will have to be looked on a case-by-case basis on weather a system and/or game needs the extra data. Dumping the raw sectors for anything and everything is simple; the rules don't change for different systems or games.

That is an acceptable answer. You should mention it in the mission statement of your website. From redump.org multi-system point of view, this makes sense. I'm just curious though; which systems have MODE1 data tracks where the game actually makes use of the additional EDC/ECC data in that MODE1 track?

chungy wrote:

I have no idea where you got the idea that it increases the chance of bad dumps, this doesn't make sense. Either the CD drive is just giving you the raw data (redump.org) for you to store, or it's just sending back the user data, but it's still reading it all to do internal checking/correction.

Oh, it does make sense. It is very simple when you look at the different layers of error correction.
- for audio tracks as well as MODE2 data tracks (user data = 2352 bytes), there is the CD drive's internal C1/C2 correction mechanisms.
- for MODE1 data tracks (user data = 2048 bytes), there is the drive's internal C1/C2 correction mechanisms PLUS the 304 bytes of EDC/ECC data contained in each RAW sector of 2352 bytes.

So, the more error correction you have available for your chunk of user data, the less chance there is that the user data is wrong.

Of course, the discussion is a bit theoretical:
- If you have a good condition CD, you get reliable RAW data.
- If a drive's internal C1/C2 error correction cannot compensate for read errors in the RAW data, the resulting dump would not be usable for the redump database anyway.

Go to forum: General discussion

21 Topic by Eidolon

(11 replies, posted in General discussion)

I would like to hear your thoughts on my following findings:

Differences between REDUMP and CDRWIN methods

If that can be consistently reproduced, and it can be determined how CDRWIN behaves when an audio track has non-zero values until the very end, that would greatly simplify the preservation process.

Go to forum: General discussion

22 Reply by Eidolon

(2 replies, posted in General discussion)

I absolutely agree. Here are a few ideas:

- The Guide has to be thoroughly rewritten. As a newbie, I had lots of questions on several steps which were not extensively covered in the guide
- Maybe it is better to split the guide per system (PSX/Sega CD/Saturn etc.) so that users don't get confused which ripping/verification steps are required for which system's images and which not
- The rationale behind redump, and the technical background and differentiation to other projects such as tosec needs to be outlined in a FAQ in a detailed way. Only after lots of discussions I understood the value of that particular ripping method (still have not fully understood it). Of course that may be because I'm a little dumb, but anyway... I guess if you want lots of people to contribute, one has to be very precise about the benefits of and the rationale behind contributing.

Go to forum: General discussion

23 Topic by Eidolon

(17 replies, posted in General discussion)

As you know I've been spending a lot of time with ripping SegaCD games lately. smile

I have run into a problem with SegaCD games dumped with the "redump method", which is relevant to the Sega emulation scene.

I would appreciate if you read my respective post on the Inn on that issue, and help me and Steve (probably just me ;-) to understand the problem.

I would like to understand the issue of pregaps, and why the redump ripping method tackles it different even to the EAC method (attaching pregap to the beginning of the next track instead of the default method of attaching it to the previous track).

Go to forum: General discussion

24 Reply by Eidolon

(55 replies, posted in General discussion)

Vigi wrote:

I really don't know why 2048 would be better than 2352 (it's smaller yes, but what else?). Maybe you could include both 2352 and 2048 checksums in your database, but this would only take you more time.

That would be a feature request to ClrMame then, wouldn't it...

Go to forum: General discussion

25 Reply by Eidolon

(55 replies, posted in General discussion)

gigadeath wrote:

-to achieve consistency between systems

You consistently dump RAW data tracks for every system, but you do not consistently dump just the user data for every system.

gigadeath wrote:

-to get full raw dumps (data+audio) and not frankenstein dumps

I would not consider calling the audio data RAW, because in case of audio data, RAW data is really the user data. In case of data tracks, RAW does not equal user data.

gigadeath wrote:

-because if you really hate raw dumps you can convert them later but you can't do the other way around with 100% reliability

I don't "really hate" them, I just question their usefulness for systems which do not require the EDC/ECC data as user data. For these systems, it just produces data overhead and increases the chance for getting bad dumps as explained in my previous post.

gigadeath wrote:

-because dumping raw takes only 10 seconds more and not 10 hours

See above, usefulness and data overhead.

Go to forum: General discussion