You are not logged in. Please login or register.
Redump Forum → Posts by velocity37
Thanks themabus.
I'll take some time later today and practice hot swapping in some of my drives, just to make sure I don't accidentally scratch the disc. If I can't get the pin eject to work to my satisfaction, I'll pop the top off of one of my drives.
Last month I acquired quite a "treasure" of the CD-i library. Link: The Faces of Evil. The disc and case are in beautiful condition, having only a hairline scratch or two. The jewel case clip is even tight, as if the disc was played only once or twice (not surprised 
).
I'm having strange problems dumping this disc, though.
I've dumped it in two of my drives, each came up with four read errors. The dumps match. I thought I'd try to dump this disc with my handy Plextor in D8 with cdtoimg. All sectors match except the four sectors. The Plextor gets some random gibberish in these sectors. I can't even determine the offset of said sectors with px_d8. These sectors are completely unreadable.
So at this point I'm fairly certain that something is wrong with the disc. Again, it is in stunning condition for what it is. I do my usual research and try to acquire an image from the Internet.
The image from the Internet matches, except for the four sectors. Does this mean the image from the Internet is good? I do a little bit of digging around in the image.
The sectors before the "problem sectors" are all pretty identical. 24-bytes of data followed by 2,328 bytes of null, like so:
A single byte difference between sectors that increments by 1, which is what would be expected for sequential empty sectors.
Those 4 error sectors, though, is also where the Internet-sourced image starts to get strange:
The "00 00 20 00 00 00 20 00" sequence changes. The normal header sequence resumes after these problem sectors. The sectors after the problem sectors, however, now have 4 bytes at the end of the sector (my dumps, cdtoimg d8 dump, and internet dump match from here on).
The problem sectors handled by ISOBuster have the normal "00 00 20 00 00 00 20 00" at the beginning, but also have the 4 bytes at the end (which match the non-error sectors at the end). The Internet-sourced problem sectors do not have this four byte sequence at the end.
Because these images are identical except for these four sectors and because the Internet-sourced image has suspicious data in the same sectors, I have reason to believe that these problems are not unique to my disc.
So the question I have is: What now? I have a feeling I'll have to wait for someone else to try to dump their disc for a proper answer. Suppose that there is a problem with these games and the sectors are truly unreadable, how should they be handled? Should I submit this with "Errors: 4" in the meantime with ISOBuster handling the errors?
If anyone is interested, here are copies of the blank sectors at the end of the disc from three sources (matching ISOBuster dumps with errors handled, D8 dump with unhandled error sectors and 120 bytes missing due to offset, and the internet sourced). The blank sectors start at sector 250,647 and continue to the end of the disc at sector 255,924.
I figured as much. Just thought I'd ask before setting it aside. I suppose it's more or less a VCD, but I can't really bring myself to think of the CD-i as a VCD player.
Interestingly, the catalog that it comes with doesn't discern films from interactive titles for DVC-required discs.
I've been out of town for a bit, but had a box of goodies greet me at home. (Two CD-i 450s and a 3DO FZ-10).
One of the things I got was Top Gun for the CD-i. It's a film. Would this be classified as "Multimedia", or is this something that does not belong?
Where do we post dumps / confirm? We start a new topic?
I will use rev 19 with CFG USB Loader and Wii Backup Manager. I have a d2pro installed.
Start a new topic in the "Dumps" forum. Read the "PLEASE READ BEFORE POSTING" sticky first, and name your topic like other posts.
The guide is here.
Since it doesn't have audio tracks, there isn't really that many possibilities.
1. You have an alternate version. Since the size matches perfectly, it might not have EDC (db does). Check for this by using psxt001z.
Use it by going to the command line, navigating to your folder, and typing:
psxt001z.exe "file.bin"
Where file.bin is your image's filename. If you're unfamiliar with using the command line, put the following in a .bat file:
psxt001z.exe "file.bin" > log.txt
You can see the output in the resulting log file. What you're interested in is "EDC in Form 2 sectors". It's also very handy to know how to do this, since this tool will save you time by automatically checking the EXE date, ID, and EDC for you.
If your disc doesn't have EDC, that means it's a new dump! 
2. Your drive introduced "minor errors" that don't halt the dumping process.
To check for this, scan your dump with CDMage (run as admin if you have UAC enabled). Open your image file and select image type "M2/2352". Once it's loaded, go to action>scan for corruption and hit enter. Make sure "error log" is checked under view.
If you do have errors, try dumping it again or in another drive.
3. The dump in the db is bad
This doesn't seem too likely, since the db dump has 0 errors. My GH20NS15 has given bad dumps with "0 errors", though. That's why I always dump in multiple drives.
Ack, I just thought of something that destroys my idea. If an entry is deleted, everything will be shifted. You can still work with the idea of creating your own indexes, though, it just won't be perfect.
One that I can think of off of the top of my head that definitely won't have any collisions is "(sum of track filesizes)_(sum of track CRC32s)". This will survive name changes (so long as you exclude the CUE) but not hash changes. It'll still be a lot better than using track 1 hashes, though.
Come to think of it, that would be an incredibly efficient way to detect dupes in the db.
As far as I can tell, the entries in each DAT are sorted chronologically. The topmost game in each DAT is the first dumped, with the latest dumps being at the bottom. Presumably the DATs are generated by the server going through an ascending autonumber field in the database.
It would be trivial to add an index to each entry based on its position in the DAT. All you'd have to do is go through the file line by line and enumerate an integer for each <game> entry, inserting an additional field like <index> to your liking.
Load up Imgburn and look for the number of sectors in layer 0:
The layer break here is 1779328
If there are no gaps on all tracks, then just dump without detecting gaps in EAC. Offset correction will still be in effect.
EAC is kind of like that. It'll work perfect most of the time, but screw up at other times. I've had a longstanding issue with EAC where on ~2% of mixed-mode discs I dump, it'll have a sync error on one of the later tracks in an identical position on two of my drives. It dumps perfectly fine on a third drive with EAC, and rips fine using other tools on the two other drives.
Here's a subcode example from an audio CD.
We can see the first three frames in the picture belong to track 2 (the Q-TNO), and that they are at the end of the song (see the time increasing 3:44.35, 36, 37.)
At frame 31434, we jump to Track 3's pregap. The Q-Index is 0, indicating we are in the pregap, and the time starts counting down from 1.28.
Frame 31536 is the last in the pregap, as we go to Q-Index 1 afterwards. In this instance, the pregap has counted down to Frame 1, but it can also count down to 0, like this:
(Basically, don't assume the pregap length based on the countdown start)
Now we know that the pregap starts at 31434 and ends at 31536. Subtracting 31433 from 31536 gives us a pregap of 103 frames, or 1.28. This coincides with the cuesheet generated by Subcode Analyzer and EAC's gap detection.
TRACK 03 AUDIO
ISRC GBJG00500048
INDEX 00 06:59:08
INDEX 01 07:00:36
P normally indicates the track start, but in this case it started 47 frames early. The subcode dictates that those frames belong to the end of track 2 though, not track 3.
@F1ReB4LL
Thanks, good to know. I didn't mean to spread misinformation, I just wanted him to know there's no disc offset hunting involved in audio CDs.
The first frame with Q-INDEX of 0 is well into the 'frames with mostly fs' instead of the first having a 'P of 0s'. Should I just ignore this and trust EAC's/SubAn's gap analysis?
Sorry about that. This was the case in the all of discs I had looked at, but I dumped more subs and found exceptions. The Q-INDEX and Q-Frame sequence is what matters.
So a CD's offset is basically a data shift distance that occurs between the data track and audio tracks, but not on data-only or audio-only CDs?
Any disc with a data track will have one, including data-only. Data tracks have their offset handled automatically out of necessity.
EAC shows irregular gaps (1.45, 2.43 etc) on the CD tracks; is that normal?
Discs can have crazy gaps, but you can check them yourself.
Dump the disc with CloneCD and check the sub in Subcode analyzer. Gap frames are going to have a Q-INDEX of 0. The first in a set will have a P of 0s, followed by followed by frames with mostly/all fs. The Q-Frame sequence will also be linear across the frames. Subcode analyzer can make a cuesheet for you, which will show you the gaps. There are 75 sectors per second (4500/min), which enumerates like 0.73 0.74 1.00. Remember that when you're trying to translate sectors to seconds and vice versa.
Except for the last track (which gets a sync error) , I get no errors and identical CRCs on all the tracks from both dumps. Is there a way to manually dump the last track in ISO buster?
If one of your drives can over-read, then sure. Pop up the sector viewer and try to view a sector past the last, if you get data instead of an error code, you're good to go.
Assuming the drive's offset is >0 and <+588: Extract from-to the track, set a fixed end address, subtract the pregap length in sectors from the start address, and set the end address to +1. Hex edit the resulting file, deleting the first (drive offset*4) bytes from the beginning and (2352-(drive offset*4)) bytes from the end.
Now if you want to verify that track on a drive that can't over-read, do the same without adding +1 to the end address. Delete (drive offset*4) bytes from the beginning, but add that many bytes of 00 to the end. So if your drive had an offset of +12, you'd delete the first 48 bytes, and add 48 bytes of 00 to the end. Since the drive can't over-read, you'll want to first verify that the truncated bytes are indeed 00, otherwise you risk losing data.
For audio CDs, just use your drive's offset. Audio CDs don't have a disc offset, so only your drive's offset matters.
Seriously, what were they (UbiSoft, to be exact) thinking? Using a cracked .exe in an official release of their own game?
You might want to consider using Mediafire for PAR2 hosting instead of Megaupload.
Mediafire will keep all your files up as long as you login once every couple of months, while Megaupload will delete individual files if they aren't downloaded in 21 (anonymous) or 90 (free acct.) days. That way, you can ensure all files stay up, regardless of how often they are downloaded.
You have a full sector (2352) and 06E0 (1760), or a total of +4112 bytes/+1028 samples.
So you'd set your correction as -1028 in PerfectRip.
Well, with the Plextor, finding the disc's offset is easy. Just insert the disc and use px_d8 (usage: px_d8 plextor_driveletter 0) and it'll tell you the combined offset. The offset of the disc is that result -12 for your drive.
So, once you know the disc's offset, you can dump in your other drives without counting garbage data. Let's say that px_d8 gave you +14. You subtract the drive's +12, telling you that the disc is a common +2. So, if you wanted to dump it in your DVR-112D, you'd use +48 + +2 = +50 in EAC's offset correction, or -24 + +2 = -22 in your LG drive. EAC will give a bad result for Track 2 when the combined offset is negative, so you'd best use another drive with a positive combined offset or PerfectRip in that case.
What the offset does is shift the position of the audio data. If you have +14 combined and you sector view the 2nd track, you'll see that there are 56 bytes of 00 (4 bytes per sample) preceding the audio data. In the case of a negative offset, the track will actually be pulled into the earlier sector.
Why don't you run hexcmp on the two dumps and see what differs.
I don't think I'd readily trust PerfectRip's results. If you look in the Mega CD sticky, you can see that it sometimes adds garbage data to the pregap.
What do I do to get the tracklength?
The track length is derived from the filesize (contained in the clrmame dat).
A second is made up of 75 sectors, and a minute of 4,500 sectors (75*60). Thus a track with a filesize of 696,438,960 bytes is made up of 296,105 sectors, each 2,352 bytes long. So, we divide by 4,500 and get 65 minutes, the remainder (3,605) by 75 to get 48 seconds, and a remainder of 5 sectors, or .05 seconds.
You don't have to calculate this yourself though, because it will all be done for you.
Once you've got a few dumps under your belt, you'll get dumper status, which will allow you to use the "new disc" menu. In the meantime, you post your dumps in the dumps forum and a moderator will do this for you. To better understand what information you should give about your dumps, I've attached a screenshot of the new disc menu.
There's only a couple fields that the guide doesn't mention, like whether the disc has EDC (psxt001z.exe tells you this), how many errors the image has, and to post the barcode and the ring code. psxt001z will also tell you the EXE date, saving you the time of actually having to find it yourself.
Looking forward to the dumps 
So when EAC 'detects gaps' on (for example) a standard three-track disk, the 'gap' listed for track 2 and 3 end up attached to the beginning of those tracks, right?
Track 2's gap will be appended to the end of track 1, and track 3's gap to the end of track 2. Each track ends with the next track's gap, except for the last. As for track 1's gap, it's discarded.
When we choose "Append To Next Track", we're telling EAC to instead place these gaps at the beginning of their respective tracks, as you described.
What is the psxtoo1z command to project image filesize?
If you run: psxt001z.exe "Track01.file"
You'll get two different sizes like:
Size (bytes): 181503840
From image: 576155328
The second line should match the total filesize of all of your tracks.
Is the following method correct for dumping track2? Disk is -12 and drive is +6 (with overread support)
That would be the correct procedure, however, I don't think this method will be reliable in this instance, since the first 24 bytes are pulled into the end of the data track instead of a pregap.
What I would do is verify the first 24 bytes in a drive that had a positive combined offset. Then you can dump the track normally (right-click extract), delete the last 24 bytes, and insert the first 24 bytes that you verified in another drive into the beginning. This would be the first 24 bytes after the garbage data.
There's just a few info tags that aren't explained in the guide. First one is "Anti-modchip", how do i get this piece of info?
You can see if your game is on the psx copy protection list linked in the guide (archive.org is pretty slow, so bear with it). iR0b0t has suggested loading the game in pSX with a firmware of the wrong region, so that's worth a shot. As you'll see on that list though, some games have their protection trickily hidden, so realistically you might not find the copy protection on a game unless you complete it.
Really though, if it's not on that list and you can start the game on the wrong region's firmware, it's fine. The only copy protection that really matters is libcrypt, as it's dependent on data in the subcode which isn't submitted to the database. Anti-modchip is more or less for informational purposes only, since it's outside of the scope of redump, so don't worry about it too much.
How do i get the write offset for a single track game?
You need a Plextor drive. There's a utility (px_d8) that can automatically detect combined offsets, including single track discs.
Also for libcrypt output, shall i just post the sectors.log file or should i include the entire output from psxt001z --libcryptdrvfast?
Unless libcrypt is detected, you don't need to. The sectors.log contains all the relevant information, so it should be fine on its own.
I'm also guessing that I get "Track Length" from EAC? I've only got single track games to put up.
Hmm? Track length is determined by the filesize automatically when your clrmame dat is parsed.
"Ring" I'm guessing is the characters written on the inner circle underneath the CD.
Yep.
I've had an issue with a couple discs where for no apparent reason, there'd be a sync error on one of the later audio tracks (where the disc is in immaculate condition). I mainly use three drives for dumping, a Mitsumi FX54++M, a Plextor PX-760A, and a LG GH20NS15. On these few discs (out of a couple hundred) both give a sync error in the Mitsumi and Plextor, but come through 100% on the LG. I can get both to match to the LG by using ISOBuster and a hex editor, and by using PerfectRip with the Plextor.
Maybe these issues are related, and some drives don't throw up that sync error when cutting off data?
EAC detects the gap on track1 as '2' and on track2 as '0'.
This always happens on two track data+audio discs. It's an EAC bug, which is rather annoying. You can use PerfectRip if your drive supports it. You can read about its usage in the Saturn / Mega CD sticky.
Your case is a special exception, though, because...
When I go to 'sector view' for track 2 in ISOBuster, it opens to the exact end of track1 (IE to the beginning of the 'garbage data' generated by my +667 drive) instead of opening to the end of track2's gap like I'm used to.
Then track 2 has no gap. I've run into this with San Francisco Rush.
Does the 'gap' listed by EAC for track1 end up attached to track2's as it's 'pre-gap'.
Nope. The CD layout is append to previous, like this:
If track 2 had a pregap, it'd be added to the end of track 1 (which is why you have to trim that track normally)
In your case, you should find that you won't need to trim track 1. When you extract the track and fix it with psxt001z.exe, you should have no warnings about additional errors. When you scan with CDMage, you shouldn't find any errors at the end. If the track had a pregap appended to it, there'd usually be 151 (last sector + 150 sector [2s] gap) errors before trim+fix.
Psxt001z's projected image filesize should match up to your final fixed data track+gapless track 2.
You've definitely got a good dump then.
If you run psxt001z.exe --fix on PerfectRip's Track 1, that will probably match too. PerfectRip won't correct the last sector for you, so that still has to be done.
Redump Forum → Posts by velocity37
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.