You are not logged in. Please login or register.
Redump Forum → Posts by Rocknroms
Welcome.
PCE CDs dumping is quite complicated at first sight as said by Fireball. You have to check subcodes (clonecd ones are the best) and probably dumping it with a audio trap cd. By the way someone has already to write down a guide, all infos are here and there.
If you really want to contribute it's better you take contact with Fireball on irc or via private msg
Ok finally I found some time to test CleanRip, update is approching even if the readme inside explain quite everything.
By the way it generates BCA data also for disc that should have not had it.
Ex. Super Mario Galaxy (Japan)
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 4D 42 55 54 0B 0B 74 00 06 00 4B C8 ....MBUT..t...KÈSomeone can confirm that this is simply void or if we have to take care of this data also for old games that didn't have any BCA?
Rocknroms :
Drive= Samsung TSSTCorp SH-D162D
MB = Asus P5K
OS= XP Pro w/SP3
If needed Sound Card = Creative SB X-Fi
Lite-On SOHD-167T doesn't work on y system.
Faq will be updated soon, sorry for delay.
ssjkakaroto wrote:If any pro dumpers could test this and report. I would gladly help expand the database.
I tested it yesterday but I cannot report anything because I'm not able to dump in chunks (a bug?), I've set it to 3gb and it continued dumping anyway until it stopped with an error because card is full (4gb, moreover it's fat32 formatted so how can it accept it, another bug?). I can say that maybe it's a bit faster than superdump.
I will try again as soon as I have some time.
I will update the guide with Specialt1212 icons and patched Superdump as soon as possible.
Simply go back to rev 13b or 17 (about 17 I'm still waiting more confirmations that it always works) when you have to dump a disc.
The guide was not updated yet nor with rev.19 neither with rev.17 as both are not confirmed to work properly at all, a pair of feedbacks cannot confirm anything. By the way your comment is the first one about bad results with rev19, probably you could be right but it seems nobody is really interested to check and leave feedbacks.
Rev.19 seems to be the best one avaible (with previous versions you'll got some problem with dumps, gmaes, etc. but this one is the more stable). If you got problems you can always uninstal with the tool in the mai package and instal old one.
@21 ---> it doesn't say anything to me. By the way why don't you install last revision as it's the less baggy?
@22 ---> great, I'll add it as soon as I can test on my wii
PR and d8 command don't work with LG 
You have to dump it with EAC with offset correction +1028
I doubt the last track will be good with such drive... He should use PerfectRip - if it is really able to overread, PR should work.
I don't understand if offset is positive or negative (he reported positive) but it should be wrong ("Going forward 1 sector...").
By the way if I remember well those Wii/GC LG can overread
0. There's no way to know it unless you simply reinstal new version rev19 so you know which version you have.
1. It's a command line: open prompt and digit "dolmd5 "filename.iso"
2. There's no need to report image sectors, simply report image size and check if it's right. By the way you can get sectors size with "image size / 2048"
High positive/negative offsets are normal in sega media.
Simply remember that one sector = 588 samples, so you need to add/subtract 588 for every sector you have to shift. It's better to post sector viewer sheet to verify you have done it right.
Specialist, yours are DVD video so they are to by unlocked simply loading them with meadiaplayer or another video player, then close the program and dump it as always.
About those other PS2 CDs: first TOC and filled image size has nothing in common, by the way if CD is protected with a wrong TOC it could be dumped with the swap method you can find in many posts around. I cannot say anything more, I hope someone will give a better reply.
http://forum.redump.org/topic/2201/dump … edisc-cds/ use this method
Yes it's implicit is cIOS / IOS249.
Someone have tested WODE? I see it dumps directly from drive so it's not wifi, by the way I'd like to know how many cables you'll have to change because they got cut or broken (you have a tiny drive cable that come out from wii and connect to slave board, it was so difficult to make some round cable or connector or use one of the usb ports instead? ).
Thanks for the infos, I will try to check it as soon as posible (I have to change chip or disable it). By the way if we'll have more feedbacks I could update the faq with rev19 only.
TOC
Track Mode Flags Start Length
-----------------------------------------------------------------
01 DATA 4 00:00:00 ( 0) 17:06:66 ( 77016)
02 AUDIO 0 17:06:66 ( 77016) 00:33:51 ( 2526)
03 AUDIO 0 17:40:42 ( 79542) 01:28:38 ( 6638)
04 AUDIO 0 19:09:05 ( 86180) 03:00:62 ( 13562)
05 AUDIO 0 22:09:67 ( 99742) 00:43:00 ( 3225)
06 AUDIO 0 22:52:67 (102967) 01:06:03 ( 4953)
07 AUDIO 0 23:58:70 (107920) 01:00:71 ( 4571)
08 AUDIO 0 24:59:66 (112491) 02:32:06 ( 11406)
09 AUDIO 0 27:31:72 (123897) 00:07:71 ( 596)
Leadout 27:39:68 (124493)Pregap is 2.00 for all tracks and track5 doesn't seem to have any issue.
The file you uploaded is corrupt, if it's a sub it's better to upload it to mediafire than here. I'll check once uploaded.
By the way it's not the same situation I'm talking about. This disc probaly has some sectors EAC+plextor don't like (probably due to drive speed).
ISOBuster says the pregaps are all 00s
You don't have to follow IB sector viewer because sectors will be moved by offset correction.
I've also had a couple situations where EAC would give a sync error on a flawless disc (My GH20NS15 fares fine, but my PX-760A and FX54++M don't like these weird discs). PerfectRip does well here, but for those where this is not an option, you might also have the need to manually extract a track on a disc with a positive combined offset.
When you find a situation like this it's always better to submit subcode and check it. When a sync error happens at 99% you have data sectors in audio pregap (due to sync error, one of the situation I talk about above) and pregap lenght could be different from what you see both in EAC and PR. It has been discussed in the past and those bytes have to be saved as they are on disc, so if you use IsoBuster you can get a bad dump.
In the future I'll probably dump any new discs using Perfect Rip and compare them using ISOBuster + EAC. If I find any discrepancies I'll dump the track 2 manually using ISOBuster.
If you find discrepancies, submit a subcode taken with CloneCD and with the right options.
That's why I had him dump a sector range starting 150 sectors early
Sorry I should be blind, by the way this is always risky if you have data in pregap as ISObuster scrambles those sectors to match audio.
If I'm not mistaken, the CD layout in ISOBuster looks like this
Yes layout is right. As above: within data and audio you can lose data (let's say that you can recover it if it's simply empty) with this method (probably not with psx, but with SS/CD32 it can happen).
But I thought that was what the copy /b pregap.bin+track02.bin track02good.bin command is for, isn't this adding the pregap to track 2?
yes it's adding. If you get bad result after adding pregap you simply got a bad dump.
resize => deletes bytes
remove => moves bytes from file to file
You have to use resize to cut pregap from the end of data track (but you can use remove too and than delete the temp file created). Resize is better when you have to move bytes from a track to another.
The command you use is exactly what you have to do, but about DC2 you are lucky because there's no byte lost due to negative offset.
EAC result on single audio track discs is always bad because it doesn't dump pregap and may cut of data if you have a negative offset (moreover if there's data in pregap this will be lost at all).
EAC shows error only if it finds error on disc or if cannot overread. The "no-pregap" issue is a bug.
Simply use PerfectRip (you have a plextor and dumps are also speeder) to dump all tracks, then check data track with Isobuster and audio with EAC. If track02 doesn't match is because of cutoff data, data in pregap, etc. so forget EAC for those tracks.
If you got strange gaps, and if EAC gaps don't match PR ones, you have to submit a subcode.
-2468 are the bytes in offset -617 => 617 x 4. IsoBuster dumps a track with no offset correction, so you do it manually.
You have to dump track with IB, not with normal method.
Now that I read better Velocity method there's a mistake because IB does like CDRwin and attaches gap to previous track. So to get the right track (for a single audio track CD) you have to add also pregap manually.
I suggest to use "remove" to work on those bytes (you can find it in some themabus threads or in the SS faq)
By the way this method can return bad results for tracks with strange sectors like some SS/CD32 disks.
PerfectRip and EAC have their pro and cons this is why it's better to use both (if you have a plextor) along with a subcode analisys when required.
Not if you use "Extract RAW", which is what "Extract From-To" uses by default.
You are right, sorry I was "out of business" for some times
Redump Forum → Posts by Rocknroms
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.