gigadeath wrote:

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.

Those messages only meant that 5 sectors in the pregap, which were empty to begin with, were replaced with empty contents..

I've had this error plenty of times before and my dumps always matched EAC's checksums and other dump's checksums.. the log says 'completed succesfully' and there are no C2 errors, so everything should be ok. And I agree with xenogear's latest post.. the disc is clearly different and there are no dumping issues.

gigadeath wrote:

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.

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.

The dump is good.. it should be added.. It's just strange that it's supposedly the same version, but with different data+audio tracks.. maybe p_star can supply some more info about his dump (disc scans, whatever)

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.

Either you have a different version than the current dumps or the offset isn't correct. It's possible that the factory write offset isn't detected on the data track using d8 (then you will only see the read offset = +30 for plextor)! The old offset detection method will give different results then, so be sure to try! (I've also had this problem with several IBM PC discs, and this is also why for a while again we believe that the EAC reference is correct and ipsedixit's offset conclusion isn't)..

You can try if the old offset detection method gives you the same write offset. And be sure to check if EAC gives you the same results. I'm not sure how a version on saturn discs can be checked (maybe it's in the first sector in text format if you browse it using isobuster/hex editor).

654

(4 replies, posted in General discussion)

Themabus, does this version fix any of the issues that you reported to him in the forums?

655

(5 replies, posted in Fixes & additions)

ssjkakaroto wrote:

oh cool, you can add Discs 1 (Install) & 3 (Cinematics) though, they are not protected with Securom

oh.. could you readd them plz? I erased these dumps in WIP neutral (and are you sure they don't match the existing entries?)

Vigi wrote:
pnkiller78 wrote:

The sector in CDReader with the same sync/header that in px_d8 is sector 2.. look at this screenshoot, what that means, did I my calculations wrong?

edit: I just remember something.. older plextor drives have a bug where the normal read mode outputs a different sector offset than d8 mode.. I'm pretty sure that +222 is the correct write offset after all.. but if possible try confirming the offset using the old method..

I hope this doesn't affect any other users and any current dumps in the database..

Ok I found out the issue again.. it happens when you read with subchannels enabled.. so when you use px_d8 or cdreader to compare syncs, make sure you disable subchannel reading! the output that you get then should be reliable.. if it still gives you a large negative then it should be correct..

One other thing you can try is reading the last audio sector in d8, so the sector before the track02 pregap.. you should see a certain amount of zeroes at the end of the data track (if you count the amount you get the offset), which also indicates a negative offset.

657

(5 replies, posted in Fixes & additions)

attn: ssjkakaroto, I'm not adding any other Diablo II dumps until we can dump securom games properly

Today, with the help of Truong Hi, the coder of PerfectRip, we've come up with a better way of detecting the combined read+write offset of a disc. This new method expands upon our previous discovery, and also proves that our current methods of correcting both offsets are correct.

The principle is that, by using the D8 vendor read command on compatible drives, data sectors are read in audio mode and thus become scrambled. The sync remains unscrambled, and its position can be used to determine the combined read+write offset.

Advantages over old method:

- Works on all discs with data tracks
- All data track sectors can be used to detect

Disadvantage:

- It requires a drive that supports the D8 read command. Most Plextor drives (original ones, not rebadged) are confirmed to support this command (755A, 760A, etc).

Software needed:

Px_D8 v1.01A by Truong Hi and Dremora - http://soft.dremora.com/px_d8_1.01A.7z

Usage: px_d8 <drive letter> <LBA sector>

For LBA sector you can just put '0' or any number. If your drive supports the command, it will give you the Combined offset (the offset that is used in EAC for dumping audio tracks).

Precautions:
- If you have a Plextor drive, be sure to update to the latest firmware available for your drive!

pepsidrinker wrote:

Damn, so Atari Jaguar games will never be properly dumped and verified? sad

I wonder if Atari will give up the offsets for it's games? They released the encryption program so people can make homebrew run on actual machines.

Atari Jaguar games have no data track? yikes

pepsidrinker wrote:
Vigi wrote:
pepsidrinker wrote:

Hey Vigi, does this work with just audio cds? When I get my plextors I want to retry dumping the Jaguar games and it would also be nice to dump properly video game sound tracks and such.

- Works on all discs with data tracks (no audio tracks needed)
- All data track sectors can be used to detect (in the old method it was only possible to use the first track02 pregap sector for this)

So you can't use it soundtracks if they don't have a data track. There has to be a data track for it to work.

Is not being able to find the correct offset for audio only a technical limitation or a software tool limitation? I mean if there is no possible way to find the offset so it can be corrected I won't worry about it but if it's just because we don't have a tool capable to do it, I wouldn't mind taking the time to research and that to find a way.

it's a technical limitation.. it will never be possible sad

pnkiller78 wrote:

The sector in CDReader with the same sync/header that in px_d8 is sector 2.. look at this screenshoot, what that means, did I my calculations wrong?

edit: I just remember something.. older plextor drives have a bug where the normal read mode outputs a different sector offset than d8 mode.. I'm pretty sure that +222 is the correct write offset after all.. but if possible try confirming the offset using the old method..

I hope this doesn't affect any other users and any current dumps in the database..

Wrong.. you have to get cdreader: http://www.cdtool.pwp.blueyonder.co.uk/ … 1_2b20.zip and compare the complete sync/header:

Use 'View Sectors' to go to the first sector of the data track, then enable the 'Apply YB scrambling' box. This will scramble the header (the sync/header is now the same as the px_d8 output). Then you can determine the offset in sectors by looking for the sector with the same sync/header in cdreader.

I think the write offset is just +222 (and it's a common IBM PC offset)

themabus wrote:

i wish it would be true smile ...since there was no lc on jpn psx and all, it would be something. i actually dump subchannel twice but so far besides Q-ADDRESS=2 and messed up layout i haven't noticed anything unusual. i guess that would mean non zero RSTUVW channels. in that case it should be easy to scan throug. i'll write a program and give it a try.
about 1st and last track it's true they are very alike but since we read in raw and last track hasn't got those empty secotrs at the end it would not show in db, only sizes are close.
gaps - well, what can we do? EAC does not pick them up. and since those last 4 or 5 cds i've added yesterday i'm actually now 99% sure this is the right thing to do. along with everything i posted before ther's one more case when EAC would fail - it's when absolute time frame at the end of gap repeats twice - EAC would decrease it by a frame. and about those 02:74 gaps when Audio changes into Data - ther's always  75 empty audio sectors and 150 empty data (75 empty audio and something, some bytes to fill last sector with audio data). only difference with 3:00 second cds is that 1st empy audio sector is not set as a gap in subchannel. so it's like those cds were prepared for standart 3 second transition area but somewhere late in process it just didn't happen smile . only cds with ring imprint * R1? V have this, so i think it was a bug. this pretty much rules every oddity out i have seen so far to 3s audio-data; 2s data-audio; 0s audio-audio. with sole exception where audio-data gaps were 2s, but that's ok, i guess. so if i wasn't sure about this before, because 2:74 gaps seemed perfectly valid, now i think it's better to just go with 3:00.

I'm sure you will do what's right.. anyway, maybe existing rip tools like turborip can also be used to rip the subchannels, but they will have to be cleaned so there will be no random errors. I'm looking forward to seeing what kind of scan tool you will come up with.

pepsidrinker wrote:

Hey Vigi, does this work with just audio cds? When I get my plextors I want to retry dumping the Jaguar games and it would also be nice to dump properly video game sound tracks and such.

- Works on all discs with data tracks (no audio tracks needed)
- All data track sectors can be used to detect (in the old method it was only possible to use the first track02 pregap sector for this)

So you can't use it soundtracks if they don't have a data track. There has to be a data track for it to work.

[00:32] <Tolvatar> too bad, pce games has data in subchannels
[00:32] <Tolvatar> this dumps are not correct
[00:32] <Tolvatar> i think
[00:33] <Tolvatar> on super cd-rom games, the second track and the last one are similar, only a few bytes differ
[00:33] <Tolvatar> this bytes can be found on subchannels
[00:33] <Tolvatar> and manually change the gaps seems awful
[00:34] <Tolvatar> thanks anyway for the link

any thoughts on this?

Hi.. I'm not sure.. I don't think there's any difference between them except the speed.. just get the one that's the cheapest of the two.. have you tried looking on the plextor site to see if there are any firmware updates for these drives?

If you check this topic: http://forum.redump.org/viewtopic.php?pid=4207#p4207 you will see that gigadeath has a PX-W4824A that does support everything. I'm not sure how it is different from the Plextor PX-W4824TA and what the T stands for.

667

(3 replies, posted in General discussion)

weren't they red or grey dumps?

Eidolon wrote:

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

You'd be surprised to see how many cd rips out there have 1 or 2 audio tracks with errors on them. You'd have to be extremely lucky to find an image somewhere that has a matching intelligent checksum. Still, you're right that the 'intelligent' checksum makes it easier because the offsets are ignored.

Anyway, I'm looking forward to your tool, and it's much appreciated that you also choose to add Redump.org support to the tool instead of just going your own direction. I'm sure that if all the issues are ironed out it can become an easy alternative to the current method.

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.

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

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

670

(55 replies, posted in General discussion)

gigadeath wrote:

Now the thread can be closed.

You read my thoughts. This discussion is getting out of hand.

I respect Eidolon's/Snake's input to this matter. We should all wait until they come with a tool to postprocess the cdrwin output data before we can do any real comparisons between both methods. I hope they can also let this tool check if the last audio sectors indicate if the data is cut off.

Because there is no such tool yet, my current conclusion is that our method is still the most reliable one, because EAC will warn you when there is a problem and data is cut off. CDRWin doesn't do this, and there is no supplementary tool yet that does. And this has to be automated, because you can't expect people to manually check each disc to see if there's any data cut off. Also, keep in mind that if a drive doesn't support overreading, the dump should at least be verified using 2 drives. I'm not sure if at the end the CDRWin method will be any faster. I'm looking forward to the results.

Topic closed.

671

(55 replies, posted in General discussion)

I do like CDRWin, I've first used it maybe 6 or 7 years ago (if not longer) and I also used it to dump the gdrom discs that are in the database. However, I don't see how CDRWin is any better than other cue/bin tools like IsoBuster, Fireburner, etc., because they all seem to create the same output.. they're all pretty basic and don't have the features that EAC has when it comes to dealing with errors. (Your Burai disc for instance. It doesn't have 100% track quality everywhere, does it still give the same 'intelligent' audio checksum as EAC?)

672

(55 replies, posted in General discussion)

Eidolon wrote:

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?

TOSEC won't change their dumping method. Why would you care about submitting data to them if almost all of their dumps are flawed? (isn't that what we agreed about?)

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. 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. Besides, you will always need a drive that supports certain features (overreading, etc) if you want to be sure that the output is correct. I'm still waiting for the PerfectRip successor myself. In the meanwhile, I'll keep my eyes open for an improved method from you and Snake.

673

(55 replies, posted in General discussion)

In the end it all seems to come down to keeping the first and last audio samples, which is what CDRWin appears to fail at (because there's no offset correction).

@Snake.. I understand from your posts on Eidolon's Inn how offsets aren't really important for your projects, but you have to understand why they are important to us.

First of all it's for documentation. We like the idea of having the audio tracks put back into the position they were before mastering. Even though in the end it only comes down to a few shifted bytes, if you split dumps into separate tracks and store them this way, there can be great benefits to it. For instance for 600mb games with 550mb of identical audio tracks, you can just get the data track and import the audio from another file, without even having to touch a patch tool.

If we would be using TOSEC's method we wouldn't be able to know if a 600 mb game has 550 mb of identical audio in the PAL version compared to the NTSC version (example: http://redump.org/disc/469/ + http://redump.org/disc/475/). Of course you could try to make a patch, but you loose some insight on how these dumps actually differ.

You could just assume that all dumps are different if the disc isn't exactly the same, but at the end that won't help you (at least not if you want to store the cd-images of the dumps somewhere), and here's why: There are plenty of games that only have one difference: the offset. If you would dump these games using TOSEC's method, you would have 2 separate dumps and need 2 dump entries. Using our method there's just 1 dump and 1 entry: http://redump.org/disc/447/ http://redump.org/disc/1777/

If you're planning to include 'intelligent checksums' for both data and audio in your database then I guess you will have the same advantages as our method for games where all audio tracks are identical, but there are also a lot of games where 1 or 2 audio don't match and all the others do. This is why we prefer offset correction and separate tracks. If you don't care about seeing the similarities between two dumps, you can just go ahead with your proposed method, but if you're planning on keeping the cd-images or spreading them around OR if you decide to care about showing people the similarities between dumps, you now know the advantages of our method.

It's not about good or bad. If you actually pay attention to the offsets instead of ignoring them, you are able to remove all the irrelevant differences between a dump and get an ideal dump. Let the offsets help you by separating them from the dump and by storing them as values, not by ignoring that they are there! tongue (the factory write offset is a relevant piece of information about the CD that should be stored in the db).

All tracks have a factory write offset. The only difference is that you don't see them on data tracks, because data isn't read in audio mode (you can still do that and detect the write offset for information purposes using this method: http://forum.redump.org/viewtopic.php?id=2057). The point I'm trying to make here is that what we are really doing here is treating audio the same way the drives are treating data (by removing the offsets that aren't affecting the data track).

Yeah, I don't see any talks about gaps. CDRWIN doesn't split tracks, but can it detect all gaps correctly?

Anyway, nice job on comparing the methods. If you can come up with an easier/faster way of getting identical results as our current method, this would be really nice I guess.

675

(55 replies, posted in General discussion)

chungy wrote:

Does IsoBuster not already re-read problem sectors? I haven't used it on discs with problem sectors yet, but I know that cdrdao in raw-reading mode (btw it can read the subchannel data, if it's of any interest) *will* re-read problem sectors multiple times until it gets a good copy (or correctable, either way...).

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