Removing Anti-modchip protection status from Europe region and removing LibCrypt status from USA: Could this be done plz (also in New disc menu)?.. they are useless for these specific regions anyway, and it will make the database better organized. There are just too many libcrypt unknown entries for no reason.

And I also believe it's safe to just put all games with unknown libcrypt and anti-modchip protection to 'No', and get rid of the 'Unknown' flag completely because it's just a useless flag and it won't be changed anyway unless somebody redumps (they are expected to check anyway!, at least for libcrypt) so if a redump shows that the current entry is wrong we can always change it again!!.

And even though I noticed that all Europe dumps have been set to No anti-modchip, I still think it would be better to just remove this status for this region.

It has always annoyed me how new dumps always get added with anti-modchip 'unknown' for all regions if the list of anti-modchip games is well-documented (and we are not asking dumpers to check for anti-modchip so only the widely known games are set to 'Yes' anyway!!.. the rest (almost 500 dumps and only growing) will always remain in the db as 'unknown' as nobody checks them anyway.. and for what? the anti-modchip data is not subchannel like libcrypt so there's really no point in forcing someone to check every single game to see if it has anti-modchip protection)..

as for for libcrypt, there are >350 'not checked' dumps and they aren't on any list of known libcrypt games.. it would be better to just set them to 'No' until proven otherwise like in court where you're not guily until proven otherwise tongue..

please support this thread if you agree with me!

There are some USA dumps that have normal UK English listed as language instead of English (USA) in USA:

Could anyone check if these are correct? or should they be using the English (USA) language?

This makes me question if there's really any use in having 3 separate 'English' languages, when they are all using most likely completely the same ingame text in different regions. Perhaps it would be better to just have one 'English' language and give it the world icon (after all it's a global language). It would be easier and it would make more sense I think.


(39 replies, posted in General discussion)

pnkiller, I noticed that for Soul Calibur the track02 audio checksum isn't the same as the other 2 dumps, could you check plz? edit: sega rally 2 has the same issue.. maybe it's normal after all..

Anyway, it's nice to see that you're dumping dreamcast using our method (if you want to be completely sure about the data track integrity you could compare against dumpcast/tosec's dat (which dumping method are you using?).. so far Star Wars Ep1 Racer data matches: tongue).. It's strange to see that all NTSC discs have a different write offset, because my PAL discs all had the same write offset.. (calculated using track02 pregap).

ps. how many dc discs do you have?


(2 replies, posted in General discussion)

To answer your questions: DVD's don't have an offset, so no need to correct anything.. all the relevant data is copied in 2048 bytes/sector user mode(except for DNAS data, which is left out.. you can use a homebrew tool and load your disc on your ps2 to get the DNAS data.. you can put it in comments).. and there won't be any errors or corrupted sectors if the dvd drive doesn't give you any read errors on the disc, so no need to scan anything.. you can also check on emule if there are any sources that match your ed2k checksum, so you can be absolutely sure that you have a proper image (though this isn't really needed)..

Yeah that Gex dump shouldn't be fixed..

we're gonna have to update the guide, but I think it's best to have a new psxt001z version that only fixes the last data track sector (and after that reports the remaining errors for reference.. and maybe move the current fix command for foreign image fixing to --fixall for instance)..


(10 replies, posted in General discussion)

That's the thing.. the data isn't like that on the disc (at least not the last data sector, before entering audio).. it's a drive error.. once you repair it with cdmage it will be like on the cd..


(10 replies, posted in General discussion)

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


(7 replies, posted in General discussion)

if some saturn games have maybe 5 versions with only the first sector different, maybe it's possible to somehow preserve these differences without creating 'dupe' dump entries.. and I agree that there's no real point in listing the header as either a comment or a separate info field.. maybe it's possible to take 1 version as a base and make the other clones (similar to MAME).

Maybe there's any sense in stripping out the first sector so that all versions will have the same checksum.. and list the different headers separately in the same dump entry? I think it's similar to SafeDisc / DNAS in a sense that one or more sectors are skipped that differ on each disc so the resulting checksum can be replicated and all the relevant data is still preserved..


(7 replies, posted in General discussion)

Hi, I noticed that a lot of dumps get added with useless info, for example:

- IFPI codes + inner ring serials.. I think these are just useless.. correct me if I'm wrong
- Disc number + disc title for discs that are only 1 disc and don't have a unique title on the disc.. @asapy, this isn't needed smile
- Dumping info in the comments fields that isn't removed by moderators when added

I also think the way Saturn headers are added now isn't good.. maybe Dremora can make a seperate info box for it at the bottom of the page.

And I hope Dremora can check the db if there's any junk left in the comments fields or serial fields that needs cleaning tongue thx

I also think it's pointless, but for the reason that a good dump can be verified anyway, regardless of mastering errors.. if a dumpers doesn't succeed in getting the same checksum, he can just write a post in the forums.


(10 replies, posted in General discussion)

Dremora wrote:
Vigi wrote:

Hi, I think 3 is the logical option, because the last sector got corrupted and should be repaired..

This error occurs only in PSX images without EDC in form 2 sectors. My opinion is that 2nd track pregap is 2:00 (so 150 sectors should be cut off from the data track and 1 extra sector should be added to the beginning of track 2 (other 149 have already been detected by EAC).

I think I also had this error with IBM discs.. it just depends on which drive you're using.. maybe Eidolon can post the contents of the last sector (unfixed) so we can see if it's the scrambled data that indicates the write offset.. (if it is then the pregap is indeed 2:00)


(10 replies, posted in General discussion)

Hi, I think 3 is the logical option, because the last sector got corrupted and should be repaired..


(39 replies, posted in General discussion)

Yuki wrote:

Are not you permitted excluding IsoBuster?
I am preserving everything with MODE1/2048.ISO.
And, most 3DO has been resold.
3DO that remains at hand is about 50.

Sorry, we only dump in RAW 2352.. MODE1/2048 is used by TOSEC already so there's no point in doing the same.


(39 replies, posted in General discussion)

Yuki wrote:

It is another one question.

I am personally collecting 3DO.
How does 3DO do Dump?
3DO is single DATA TRACK CD.

You just 'Right mouse button on Track 01 -> Extract Track 01 -> Extract RAW Data (2352 bytes/block) (*.bin, *.iso);' in IsoBuster..

gigadeath wrote:

Actually it is

(139 * 4) - (588 * 2) = -617

you forgot the 3 samples on the last row big_smile

There's 12 bytes in the last row, so that makes it -647 write offset.

or: 588 - ((7*16)+4)/4=  559 - 2*588 = -617

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


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


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


(43 replies, posted in General discussion)

ssjkakaroto wrote:

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


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.


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


(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


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