StateS wrote:

But would psxt001z fix these types of errors or leave them alone?

psxt001z no longer fixes any errors (except for the last sector iirc)

Ready 2 Rumble: Round 2 is another example

678

(43 replies, posted in General discussion)

ssjkakaroto wrote:

ah ok
BTW, why did you remove the Original flag from some of my discs?

it's useless also.. IBM PC discs are expected to be original releases and not budget.. if it's some special non-budget release the field can be used.

679

(43 replies, posted in General discussion)

ssjkakaroto wrote:

Vigi: The pregap on Track 02 is 1.73 and the game's serial is 723F-B302

The serial isn't needed because there are no other versions from that region.

680

(43 replies, posted in General discussion)

ssjkakaroto wrote:

Can someone update my dump with the info I posted earlier?

Thanks

Done.. so pnkiller's last track has cut off data? yikes I still think this is kind of odd.. pnkiller, have you tried checking the last sector in cdtool instead of isobuster?

fuzzball wrote:

Determining the (factory) write offset
If the Track02 pregap was 2 seconds, or 150 sectors, go back 149 sectors (substract 149 from from the number in the white box);

Is the part of an underline right? Or is 'go back 150 sectors'?

What we meant is 'go back 149 sectors, then one more' (so 150 in total) because sometimes if you go back 150 at once it won't show any garbage.

682

(43 replies, posted in General discussion)

pnkiller78 wrote:
Vigi wrote:

@pnkiller, what's the offset difference between the 2 Hexen II dumps? are you sure there isn't a sector offset caused by the bug?

Vigi, could you repost track samples for your Hexen II dump, this thing is taking to long sad
I tried to download the ones you posted earlier, but they are not available on the server anymore

sure, here it is: http://vigi.dremora.com/hexen2.rar

683

(43 replies, posted in General discussion)

I'm not sure how many sectors need to be removed.. I hope someone else knows this.. And I hope you can compare the last track to pnkiller's.. maybe one of them is cut off.

edit: pnkiller, can't you install the plextor into your pc? tongue

684

(43 replies, posted in General discussion)

So what are you saying ssjkakaroto, does the checksum match if you invert in perfectrip or not? or is there anyway you can trigger a 1.73 gap in EAC?

685

(43 replies, posted in General discussion)

ssjkakaroto wrote:

Using the offset +1176 I was able to get the same hashes for tracks 2 and 3 as pnkiller78 (probably all the other tracks will match too now).
I'll redump this game tomorrow.
Does this change affect track 1 too? If so, how much do I need to remove?

Just dump it in perfectrip with the plextor.. if that will give you matching checksums with +1176 and 1.73 gap then it should be ok.. smile

@pnkiller, what's the offset difference between the 2 Hexen II dumps? are you sure there isn't a sector offset caused by the bug?

686

(43 replies, posted in General discussion)

Ok, after adding track1+2 sizes of both dumps there is a difference, so I guess it's a different region version anyway, but I still think the pnkiller's 2352 offset and gap length are strange and I think all audio tracks should match on both versions..

687

(43 replies, posted in General discussion)

@pnkiller78, I noticed that your Quake II dump with 2352 offset is identical to this dump - http://redump.org/disc/2511/ only your dump has a smaller Track02 gap and 2352 offset.. One of the 2 dumps has to be wrong, I think they should both match.

A 2352 write offset is very unlikely.. I think that the gap should be 1 sector bigger and the offset 1 sector smaller, but I'm not sure why your drives are detecting it wrongly (did you dump this disc using PerfectRip, have you verified the gaps on multiple drives?)

I hope you can recheck the offset using px_d8 and cdtool, and be sure to disable subchannel reading in both tools so that the sector offset will be correct (I hope you read the post last week where I explained that older plextor drives have a bug when, if reading sectors with subchannels enabled, the data that you see is moved to another sector.)

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

691

(4 replies, posted in General discussion)

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

692

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

694

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