I'm not sure what to make of this either.. are you sure you executed px_d8 without the subchannel command? so 'px_d8 d 0 0'.. if not, there's a chance the sector offset is reported wrongly.. Also, you have to disable subchannel reading in cdtool when reading the sector.

So if both px_d8 and cdreader were used without subchannel reading and it still gives you the same scrambled header in sector -1, the maths of 270+588-98 (I suppose you're sure the read offset is correct?) = +760 is correct

And is 1.00 also the gap that perfectrip reports?

And you should notice the sync/header in the track02 pregap output.. it indicates the same offset of +760 (if you're sure about the +588) for all drives! So it's best to use this value for dumping.. I have no idea why the isobuster offset is this big, but it may be a mastering error.. have you tried cdtool instead to read the same sector? or try going back -73 first and then one more (I also don't think that d8 will ever give you a write offset that isn't a full number in samples, but let's wait what themabus has to say on this)

The only time d8 and the classic method don't provide identical results is when the data track doesn't have a write offset (it will only show the read offset with d8) but the audio does... this time you see a sync/header in the track02 pregap scrambled data output which normally doesn't show, so for some reason you'll also have to use the sync position this time, like in the d8 method..

I just hope there aren't any other discs with the same problems.. the write offset for those might have been calculated wrongly already (if the scrambled data output has a sync/header it's best to use its position instead of the amount of scrambled data).

Well.. usually it's just a cheaper version of the game, rereleased by another label..

The problem with these budget releases is that they usually have a data track that's remastered.. essentially it contains the same data as the original version, but usually with some small modifications (if the filedates are newer than the release date of the original I think it's better to wait for the original version dump and see if it can be verified).. I also have some budget releases and I got mixed results.. Mortal Kombat 3 had exactly the same data as the original version, so I was able to verify it.

Yeah.. it's a mess.. this is why I think it's best to avoid as much budget releases as possible - they just add to the mess.. I also hope it won't get much worse

The difference between alone in the dark 1 appears to be an offset difference of 3604 bytes (or +901 samples).. also, in my dump, because the track data is shifted forward compared to your dump, each track starts with data from the previous track in the pregap sad

Maybe our current methods just aren't able to detect the real write offset of these older IBM discs that show +0 write offset? hmm

ps. do your AITD1 tracks also start with a click?

Also, I noticed that your trilogy dump has the same audio sizes as your budget dump.. have you compared the 2? It looks like for the trilogy one they just took the complete track of the original release, including the gaps and then just mastered them without any extra gaps..

I'm wondering what the best way would be to deal with these differences.. the 'intelligent checksum' comes to mind again... the disadvantage would of course be that we wouldn't be able to identify the real reference point (the position of the data before any mastering, like in PSX), but I doubt my original edition discs are the ones providing the real reference point, because your budget discs don't have data entering into the next track's pregap.

themabus wrote:

i've uploaded a small (200kb) track here:
http://www.mediafire.com/?ungg3vtyyzx

could somebody compare it with the same track from Vigi's versin, please?

I don't think any of my AITD discs have PRE (only wipeout and some others, and I mentioned it each time in the comments).. I compared my aitd2 start to your file and they are different.. your dump has some data in the pregap and mine doesn't (also the data after the pregap starts with different bytes etc).

On another note, my alone in the dark dumps also come from a square black trilogy box (I also had a separate copy of AITD1 and it was identical).. I don't think the naming that you used is appropriate, because they should be identical to the normal versions (strangely enough your dumps don't match mine).. so my box just contained 3 jewel cases with the normal games with normal covers etc.. I'm not sure about yours.

And I don't know why these 2 http://redump.org/disc/2883/ + http://redump.org/disc/1706/ don't match.. could you upload a sample (.bin compressed in rar plz) of one of the audio tracks so I can compare?

I think we will run into this problem more often with IBM (same data track crc + different audio track crc's).. so maybe an "intelligent checksum" that only calculates the checksum of the data start and end is a better method for comparing audio tracks after all.

Also, it's possible that IBM discs have a +0 write offset on the data track but a different write offset on the audio tracks, so plz be sure to use the classic offset detection method!

656

(2 replies, posted in General discussion)

Ok, this is just a random thought, but I think it would be a nice addition to the site..

If it's possible to make an index of crc32 values of each track, the audio tracks can be marked with a green flag or a green V or something like that if the track exists in other dumps..

If you move the cursor over a track it already lights up... maybe it's possible without too much work to link to a new page that has a list of all games that include this track (or perhaps all tracks with the same size in bytes to identify possible bad dumps with cut off data)?

A lot of games share audio tracks, so this would be a nice way for us to verify that a dump is correct by comparing them to other games.

With certain drives it's possible to dump the high density area of a gd-rom disc using the escape eject button. The low density area (the first 2 tracks which are always visible) can be dumped the normal way (without hotswapping) on any drive using the cd dumping guide found here: http://redump.org/guide/cddumping/ .

Software needed:

- dctools, audio trap disc

Instructions:

The high density area (sector 45000-549150) can be dumped as follows:

- insert the audio trap disc (a disc with a hacked TOC of 99 mins audio, burn it with CloneCD or Alcohol).
- use 'startstop.exe driveletter 1' to stop the drive motor.
- use a pin to press the escape eject button, so the tray will eject (or remove the drive cover).. insert the gdrom and gently push the tray back (or put the drive cover back on).
- Now extract sector 44990 (to be sure that the offset doesn't cut off any data) - 549150 using CDRWin 'Select Sectors' with the following settings: CD Audio (2352), File Format INTEL, Error Recovery Abort, Audio Speed 1x, Read Retry Count 1.
- When it's done extracting, use 'ice.exe dumpfile.bin 44990 > ice.log.txt' to descramble, split the dump data and get the ice log file.

If everything went well, the dump is ready to be submitted.

If you get any errors during extraction or if your drive fails to read the gdrom disc after swapping, then this most likely means that your drive isn't suitable for dumping gdrom discs. Read the next post to see if your drive which drives are supported/unsupported.

658

(39 replies, posted in General discussion)

Dremora wrote:
Vigi wrote:

Which track from which game would you like?

Mortal Kombat Gold, track 53, first 150 sectors. TIA smile

I borrowed this game and I deleted the dump, so I don't have it anymore hmm

but I still have another game with audio tracks (who wants to be a millionaire) and plextor + escape eject also works fine for gdroms (just tested) yikes:O

659

(39 replies, posted in General discussion)

Dremora wrote:

but I want to compare them with gaps from Vigi's dump.

Which track from which game would you like?

@pnkiller:

When I used the lite-on to dump these gdroms I could see where the audio started because of scrambled data.. also, the data track in the high density area contains information about the track sizes.. you can view the toc of a dump with a tool called gdlister.. just get the toolkit from this page:  http://homepage.ntlworld.com/menace-59/ … oolkit.rar

Also, I noticed StateS is mentioned on this page.. http://homepage.ntlworld.com/menace-59/gd-rom_stuff/ perhaps he could tell us if it's him or just a guy with the same name? tongue

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:

http://redump.org/discs/region/U/sort/languages/

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.

662

(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: http://dumpcast.thekickback.com/ 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?

663

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

665

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

666

(10 replies, posted in General discussion)

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

667

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

668

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

670

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

671

(10 replies, posted in General discussion)

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

672

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

673

(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