Search options (Page 3 of 5)

Yes, it doesn't affect the dump. It's for documentation only and sometimes to label the version of the dump (early date ->v1.0 and later date ->v1.1 and so on).
Just don't forget to set the date in IB to local time stamp.
BTW, this topic is in the wrong forum 

I've been checking all my covermount games and i've skipped a lot of discs to dump. Some of them doesn't have audio tracks (when they should have), some have the filesystem modified (ex: 2004 filesystem date in a game from 1998; "NEW" as volume label, etc), some have extra content (i have this game http://redump.org/disc/2051/ but since it's so small the magazine decided to fill the disc with demos), and many more cases... I only dumped the ones that sounds to me like the original release (or the re-release).

I think those discs should be carefully analysed before dumping or else we will end up with 20+ versions of the same game.

It seems that this is a emulator issue and that's nothing to do with our naming convention.

Dumpers needed    !  but please note that systems like CDi, Jaguar, NeoGeo CD... can't be dumped properly due to dumping issues (ex: subchannel protections, multisession discs...).

You are right, i think that most people think that dumping discs with audio tracks is complicated but it's not! after a couple of dumps to see how the offset "thing" works we are ready to go 

I understand the 3DO and the Amiga stuff, but the SAT i can't understand because it was hugely popular back then (at least in here) till 97/98 and then Sony took off (if i recall well, in here, the turning point was the release of DB and FF7).

Disc redumped, everything matched 

The offset of this disc is 0 (i'm dumping it with +48) and this drive supports overreading (but only for the lead-out) and the Isobuster solution didn't work (reports errors), but this is definitily a drive issue because in my other drive the track is extracted and EAC don't even had to make error correction but as a said in other post the binaries aren't created in that computer so i only can check the crc that EAC reports.
I think i will extract the track with isobuster in the other drive and then combine with the bit that was dumped in the first drive to see if i can get a matching crc.

Anyway, thanks to all of you 

I tested that and it doesn't work. It doesn't matter the speed i choose, the drive reads always at 1900kb/s ( i tried in the dos prompt and in the frontend).

It's better to post the dump info in the "dumps" forum, that way you will be added as a dumper for that disc.

Since you are dumping all those discs, you could post that info in the Dumps section so they can be added into the database, because there are a lot of GC discs with only 1 dumper (and even if there are a lot of dumpers for the discs that you are dumping, one more doesn't hurt    )

Now i understand... and after all, the bytes that we use to count the offset are in the begging of the gap (if we use ReMove), just one more thing to clear this up: if those bytes (the rows we use to calculate the offset) are removed from the data track and if they are not present in the first audio track then what's the deal? those bytes don't exist in the real disc and are generated by the drive?

Anyway thanks for the explanations, i had this idea bugging me since i started dumping discs with audio tracks  lol