651

(11 replies, posted in General discussion)

The descramble_cdda tool to descramble the data track (if you just select the complete d8 dump file and start descrambling it will stop extracting once it reached the proper data track size): http://vigi.dremora.com/dctools.zip

I tried comparing the amount of bytes in the pregap of my alone in the dark dump but it's different on each track, so there's no way to detect a reference.. sad

652

(11 replies, posted in General discussion)

You mean reading the entire disc in d8, then cut off the bytes in the first sector before the sync starts, then cut off the data track (it has to be descrambled anyway)?.. this should give the exact same results as our current method (and this is also how I dumped the dreamcast discs). Perhaps I'm just looking for a way to avoid the offset differences from mastering and finding the true reference.

Here's a tool that can extract all sectors in d8 mode: http://vigi.dremora.com/cdtoimg.rar

653

(11 replies, posted in General discussion)

ps. of course it's possible that the detected offset of this disc is just wrong: http://redump.org/disc/1460/ maybe d8 gives a -306 offset.. I'm not at all comfortable with all the +0 write offsets .. Maybe the correct write offset just isn't showing.. I also have some IBM discs where the data track with d8 only shows the read offset and not the write offset (yet the old detection method gives me a write offset different than +0 on the audio tracks).. maybe these +0 discs just don't show the write offset using any method. How can we fix this?

Same for these discs: http://redump.org/disc/2883/ http://redump.org/disc/1706/ .. same gaps, same track sizes, +901 offset difference.. both discs show a +0 write offset.. I will see if there's another way to determine the correct write offset value (for instance the amount of data that is moved outside of the tracks).

In other words: how to find a reference that isn't there? tongue

654

(11 replies, posted in General discussion)

I noticed this earlier.. the only systems where the visible write offset really makes sense are PSX and Dreamcast.. in all the other systems, after correction,  the audio doesn't start exactly at the pregap, data gets moved into the next track's pregap, etc..

It would be nice to know if the d8 method gives the same offset correction on these discs, but I suppose it does.. there are propably multiple offset corrections needed, but we can only detect 2 of them (read+write)..

An 'intelligent checksum' would make more sense for these systems imho.. as Eidolon explained back then, you'll be ignoring the offset completely instead of assuming that our method of offset correction is the right one (I have no doubt that it is for PSX and Dreamcast, but I can't be sure about the other systems as a lot of dupe games don't have matching audio).. at least we could verify the integrity of the audio data then WITH matching checksums..

Maybe it would be possible to write an app that can determine the most likely original offset by comparing several dumps, for instance saturn ones? based on the following assumptions:

- No data gets moved outside of the track, unless the data starts exactly at pregap.
- If data gets moved outside of the track with the default offset correction, the amount of bytes outside of the track could indicate the additional offset correction needed (there are several psx discs where the last audio track has audio data up until the last byte.. if these bytes are also the last bytes on the cd, this means no data is cut off and it's a hint on what the proper offset correction should be).
- All tracks on a disc need the same offset correction (is the offset difference on saturn discs the same for all tracks? I remember that with IBM PC this usually isn't the case due to different mastering, different gap sizes etc)... this means that if we want matching audio offsets for all audio tracks, the pregaps should be ignored because the same games (but different system, version, region, etc) sometimes have different gaps?
- It is likely that one or more tracks start exactly at the pregap.

It's clear that offsets DO exist.. and that for PSX and DC they can be used as values to put the audio data back into the original position (usually exactly @ byte 352800 for one or more tracks on the discs).. I'm not sure if our method makes sense on the other systems though.

Are there any discs in the database that were released with multiple write offsets and where correcting both gives identical checksums for both discs (excluding dummy tracks)? Example: Doom for PSX.

The -30 is only to get the factory write offset, not the dumping value.. and we can't be sure about the -588.. just make sure you read it in d8 and the normal way without any subchannel reading. It should be ok then.

Sorry dude, the "018200" and "018174" aren't related to the pregap size.. you should browse the first couple of sectors in normal mode and look for the same number (for instance "018200") as the px_d8 gives in sector 0..

The best way to figure out the sector correction is by using Truong's cdreader tool: http://www.cdtool.pwp.blueyonder.co.uk/ … 1_2b20.zip.

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.

If it's the same as in the db then it must be correct smile

658

(9 replies, posted in General discussion)

Bleh.. he posted the same thread on no-intro.. Prototypes aren't released on original media so they're about as useful for our project as pirates

659

(3 replies, posted in General discussion)

They also never have any errors afaik, so no need to check I think

660

(1 replies, posted in General discussion)

Unfortunately for you this is not a download site.. we only list checksums (so people can make correct dumps of their discs).. if you want the download images, try snesorama or extreme-games.

Topic closed

661

(25 replies, posted in General discussion)

I also think it's a good idea to split Games and Demo discs into separate dats..

662

(6 replies, posted in General discussion)

Well, you could just check and compare the first and the last audio sectors (including the first couple lead-out sectors) to the IsoBuster sector browser output if you wanna be sure no data is cut off.

663

(6 replies, posted in General discussion)

I don't understand the question..

Does every audio track have to end in silence?

I don't think so..

and overreading only applies to the first and last audio sectors.. if the read offset is larger than the write offset I don't think you'll run into any problems where data is cut off etc.

Dremora has to give you dumper status so you can use the New Disc menu.. if you're verifying existing entries you can just post them in the forums in a single thread.

themabus wrote:

but if Vigi says it's ok, should be ok smile

No, no.. I also have no idea what's going on.. I'm just saying that the +760 offset makes more sense than the other one.

themabus wrote:

Vigi, can you help, please?, i'm totally lost on this, how can this happen? is it like tracks are physicaly on variable distance, wouldn't audio collide with datatrack when offset is negative, and what's between them, when offset is positive?

I don't know what causes it.. I only know that I have some IBM discs that show +30 in D8 on the data track and a different offset with the old method.. so I felt it was safe to conclude that the data track didn't show the write offset, but only the read offset.

ghostgecko wrote:

Detection method B gives a gap of 5:42 for track 2, and method C stalls and fails to complete. Result is the same on two separate drives. I will try a different disc later and see if I have any luck.

Ok.. then it's best to stick with method A.. I guess EAC isn't having any luck detecting the gap because it's a dummy track.. If you want to verify the existing dump you can just dump it with the 0.00 gap and add 352800 bytes at the start using a hex editor (if you need any help let us know).

Welcome..

yes, it should say 02.00 for the second track as well.. have you tried selecting a different gap detection method?.. also, there's a chance you first have to enter the correct offset correction before pressing the 'detect gaps' button..

if none of this works, you could either try a different drive if you have one OR you could try some other discs with audio tracks and hope that EAC detects the correct gaps on those..

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!

673

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

675

(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