51

(8 replies, posted in General discussion)

Thanks for your help!

52

(8 replies, posted in General discussion)

Now all my PCE rips are from PerfectRip (except track 58, 66 and 70 of Valis IV, which I could read only with IsoBuster - not C2 errors, only "unknown sense key code combination" errors probably caused by bad mastering, so they should be good).


Is there a way to check all the data tracks and make them consistent between the PerfectRip way and your way? I don't like manually adding EDCs, especially with discs like Valis IV which have 30 data tracks (it took 2 days to dump it correctly); moreover writing down LBAs and generating EDCs one by one is prone to errors...

53

(8 replies, posted in General discussion)

I mailed you the file.

54

(8 replies, posted in General discussion)

Themabus, dumping with PerfectRip gets me different data tracks than yours (sizes are correct but CRC is different). And that's after I correct everything, 2.74->3.00, track02 resized and track03 added silence (all audio tracks match, even track03). LBAs are correct too, they perfectly match the original disc ones.

PerfectRip dumps even data tracks pregap, without using IsoBuster + manual EDC adding. Are you sure your method of adding silence+EDC to the start of a data track is correct? I tried other discs too, and with Isobuster+GenEDCECC I always get a different result than PerfectRip (which returns no error at all).

Can you compare your data tracks with mine? I uploaded them here:  http://www.megaupload.com/it/?d=795FZ2AM

Isn't the drive offset subtraction only necessary to get the absolute write offset of the disc? He should dump with +702 in EAC / -702 PerfectRip

56

(43 replies, posted in General discussion)

I'll try to redump my budget disc to see if it matches anything

57

(43 replies, posted in General discussion)

Yes. There's some option you have to adjust, did you read the guide?

For example combined read/write offset has to be inserted with +/- inverted

So if you dump with +56 in EAC you have to put -56 in PerfectRip

58

(43 replies, posted in General discussion)

ssjkakaroto wrote:

Here's the gap detection on EAC

http://img2.freeimagehosting.net/upload … fd8b96.png
http://img2.freeimagehosting.net/upload … edcebb.png
http://img2.freeimagehosting.net/upload … e59b43.png

With a Pioneer DVR-107D the result was the same as the NEC and LG.

Can you try dumping it with the Plextor and PerfectRip? Out of them all, I'd trust the Plextor gap the most... maybe PerfectRip can confirm results

59

(43 replies, posted in General discussion)

ssjkakaroto wrote:

Hey Vigi, I checked the offset with px_d8 using all 3 options and the result was the same with all 3.

Another thing, the 1st track of pnkiller78's dump should be different from mine, as my version can't be installed in a english system.

Since when PC have region protection? I run on mine Cds from all over the world... if it's only a writing on the box or manual, it doesn't mean anything, it's like "don't play this game outside of Japan blah blah" on arcade PCBs boot

xenogears wrote:

I really don't know. There are not corrupt C2 pointers but in the end perfectrip sends out a message similar to "sorry, the dump was not perfect"
On the other hand the data track is the same I got with the traditional method. Soon we'll see for the audio track.

Vigi, the dump is not good, PerfectRip itself says it. And the log says clearly that some sectors were replaced because they couldn't be read. I don't think having 0 corrupt C2 pointers is the only indication of a good dump.

Vigi wrote:

Hi.. all I can say is that the errors that you got are normal and don't affect the dump.. as long as there are 0 Total corrupt symbols (C2 pointers), everything is alright.

Actually I don't think it's always true...

The replaced sectors warning in the log is a sure sign of something wasn't right.

Try EAC. It's very possible that PerfectRip has issues with some discs.

Dump track 2 with "Leave out gaps" option enabled (instead of "Append gap to next track"), then use psxt001z to create a 2:00 sec pregap, then attach it to gapless track 2.

CD 2 seems fine...

CD-Text error I think simply means there's no CD-Text on CD, I get that error too.

And I get burst reading error too, if you note then the log says than 1-sector read is fine. It's just that the program has to read sectors between data and audio tracks one-by-one, not in burst mode, it switches modes automatically.


On the other hand I never got unknown sense key code combination errors, I guess that's something more complicated.

Are you sure your disc has write offset 0 too? Did you try with EAC?

64

(6 replies, posted in General discussion)

I had no problem with the 4824 with either PerfectRip or D8 command, it supports 100b.

The only thing I can't judge about is the great buffer size, I don't know if it makes a difference.

Another thing you should look after for these out of production drives is state of conservation. When I bought mine it was 5 years old (it still had firmware 1.00!), and it was idle since years in the wild, I had to do a partial cleaning.

So if features are the same, choose the better conserved drive, and if both are boxed brand new, either is good.

65

(6 replies, posted in General discussion)

Yes they should be the same apart speed. Even the last firmware is the same (I upgraded it instantly).

This site list them both as having the same features (even if firmwares weren't updated)

http://www.daefeatures.co.uk/search.php

66

(55 replies, posted in General discussion)

Eidolon wrote:

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.

Concluding:
-you can dump the way you like smile
-we care about offsets and having full audio
-we won't change our dumping method
-we think our dumping method is better
-everybody is happy

Basically, we're at the same point we were 3 days and 60 posts ago. Good luck with your work smile

Now the thread can be closed. It should be linked to whomever comes here in the future and asks why we don't want CDRWin big_smile

67

(55 replies, posted in General discussion)

I think you went back 149 sectors only, instead of 150 when searching for data track end.

68

(55 replies, posted in General discussion)

Eidolon, the discussion seems to me a bit like a dog trying to bite his own tail now.

We gave you PLENTY of reasons why Redump.org method is preferable to others, in IRC, Redump forums and your own forums. Now that you know these reasons, you only have to decide. You're in the dumpers category now, if you want to submit dumps here I'll be the first being happy, if you choose another way fine, I wish you good luck, but we won't support what we consider an inferior method. If settling to an inferior method was fine to us, we would have settled to dumping for TOSEC ages ago. At the time I didn't consider TOSEC to be a good way and I waited 'till Redump.org gave me the opportunity to do thing the better way. I had to choose too.

As I told you in IRC, for the love of God I only hope all of this isn't an emu politics issue. Maybe you want your own project to attract people to your community, I'm cool with that, but even if you decide to keep the dump info on your site only, I think it would be better to follow Redump.org method. We won't "steal" anything. Using CDRWin only to have it "your own way" sure isn't beneficial to the community.

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.

70

(17 replies, posted in General discussion)

Eidolon wrote:

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.

Again, they work perfectly when loaded with a proper CD emulation tool like Daemon Tools. I think it's very clear where the fault resides.

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.


Eidolon wrote:

- Can someone write the "image normalization and checksumming" tool I proposed on the Inn?

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.

72

(55 replies, posted in General discussion)

Snake wrote:
chungy wrote:

You've never had to re-insert a cartridge before a game system recognised it? I'd find that hard to believe tongue (this message was to Snake...)

Not 15% of the time, no tongue

You're good at keeping your carts clean then. 10 years of foggy basement have wrecked mine. Not to the point they're unreadable toe tongue

73

(55 replies, posted in General discussion)

Snake wrote:

Really, the only thing we don't agree on is whether the audio offset is important. *Provided all the data is there*, I don't think it is - because the time between issuing the 'read' command and the drive actually playing the audio is going to vary WAY more than any audio offset anyway. Plus, if all the data is there, it can be corrected any way you like afterwards.

If I'm not mistaken, the issue is that the method we dislike returns 1/75 of second wrong. You say this data is so little it doesn't matter, we say that this data matters, and that a proper dump should include it.

If it all reduces to that I can safely says that Redump.org will continue the dumping the way it does now.

we want full proper dump -> we care about offsets -> we use EAC... it's pretty simple, really

I understand what you say, but there's A DIFFERENCE IN MENTALITY AT THE START OF THE DISCUSSION. That can't be worked out. Redump.org cares about things you don't care about. It's fine but it doesn't change what we think of our method of dumping.


And BTW, in cart dumping you have to take into account dirty contacts. Rust is a bitch wink

74

(55 replies, posted in General discussion)

Vigi wrote:

It appears that some drives do this and some don't. I know that my Plextor drive does it.

Which return us to the point that a good CD-rom drive is needed. A good drive is a prerequisite of proper dumping. A good drive has (and not "should have") no problem reading data in raw mode. No problem at all. If not your drive is not good for the task.

75

(17 replies, posted in General discussion)

Snake wrote:

I don't know that I'd call it 'wrong'. Pretty much everything does it that way. Is everyone wrong?

If wrong is a word too hard, call it "less suitable" then.

It's true that old programs behave like CDRWin. In fact EAC guys has always made clear that the ability to select where gaps go is a strong point of their program.

From a theoretical point of view, gaps should be attached at the beginning of a track, because they act as support to the full reading of the following track; the previous track could care less that there's a gap coming after itself.