You are not logged in. Please login or register.
Redump Forum → Posts by F1ReB4LL
I'm noticing that the hashes for the data tracks (both those in the low-density area and high-density area) properly match, but the audio tracks do not.
You need to fix the offset using the write offset value info in the corresponding entries and compare the hashes against the db again. IIRC, there are tools to automate the process.
One of the already registered members uses the same IP as you and it's not from a dynamic pool. Any ideas why could that happen?
Welcome, obtain your password here.
(check the spam folder in case there will be no message in your inbox)
Please make sure you read and understand the dumping process and the way you have to submit the dumping logs before posting your dump info.
Dumping_Guides
Feel free to ask question on the forum, or via Discord about how to get started preserving games with Redump:
Discord
Welcome, obtain your password here.
(check the spam folder in case there will be no message in your inbox)
Please make sure you read and understand the dumping process and the way you have to submit the dumping logs before posting your dump info.
Dumping_Guides
Feel free to ask question on the forum, or via Discord about how to get started preserving games with Redump:
Discord
Welcome, obtain your password here.
(check the spam folder in case there will be no message in your inbox)
Please make sure you read and understand the dumping process and the way you have to submit the dumping logs before posting your dump info.
Dumping_Guides
Feel free to ask question on the forum, or via Discord about how to get started preserving games with Redump:
Discord
Welcome, obtain your password here.
(check the spam folder in case there will be no message in your inbox)
Please make sure you read and understand the dumping process and the way you have to submit the dumping logs before posting your dump info.
Dumping_Guides
Feel free to ask question on the forum, or via Discord about how to get started preserving games with Redump:
Discord
Welcome, obtain your password here.
(check the spam folder in case there will be no message in your inbox)
Please make sure you read and understand the dumping process and the way you have to submit the dumping logs before posting your dump info.
Dumping_Guides
Feel free to ask question on the forum, or via Discord about how to get started preserving games with Redump:
Discord
Welcome, obtain your password here.
(check the spam folder in case there will be no message in your inbox)
Please make sure you read and understand the dumping process and the way you have to submit the dumping logs before posting your dump info.
Dumping_Guides
Feel free to ask question on the forum, or via Discord about how to get started preserving games with Redump:
Discord
Welcome, obtain your password here.
(check the spam folder in case there will be no message in your inbox)
Please make sure you read and understand the dumping process and the way you have to submit the dumping logs before posting your dump info.
Dumping_Guides
Feel free to ask question on the forum, or via Discord about how to get started preserving games with Redump:
Discord
Welcome, obtain your password here.
(check the spam folder in case there will be no message in your inbox)
Please make sure you read and understand the dumping process and the way you have to submit the dumping logs before posting your dump info.
Dumping_Guides
Feel free to ask question on the forum, or via Discord about how to get started preserving games with Redump:
Discord
Ide like to possibly help with dumping some games that I have and learning more about the whole dumping scene in general
Any examples of those undumped games, maybe? And do you have a proper drive to dump them?
FMT Arquelphos, Eikan wa Kimi ni 3 and Rejection are also affected. Also, there are non-PX drives that give additional track hashes (not matching the ones from the drives mentioned above) without C2 errors, I don't know how to choose the correct hashes.
While it is true that most discs with 2 layers of ringcodes are DVD-9, it isn't always the case. I know it is uncommon in US discs, but in European PS2 discs, it is pretty common for there to be two layers of codes, but only a DVD-5.
I've thought all the PS2 discs have 2 layers of ringcodes, but one of them is usually hidden under the label for DVD-5 discs? And there were experiments by scratching off the paint from the label side proving that?
PX-810SA is a rebadged Pioneer 212/212D/212L, IIRC, it doesn't even support a C2 errors reporting.
LBA[009128, 0x023a8]: Track[03]: Subchannel & TOC doesn't sync. LBA on TOC[9168, 0x23d0], index[01]
But "New Horizon.dat" and "New Horizon (Subs indexes).dat" hashes/sizes are the same, "New Horizon.cue" and "New Horizon (Subs indexes).cue" gaps/indexes are also the same? Misdetect?
It is "normal" for Sega discs to have revisions mixed up. Probably there are Brazil releases with all 4 discs RE or non-RE.
Welcome, obtain your password here.
(check the spam folder in case there will be no message in your inbox)
Please make sure you read and understand the dumping process and the way you have to submit the dumping logs before posting your dump info.
Dumping_Guides
Feel free to ask question on the forum, or via Discord about how to get started preserving games with Redump:
Discord
Is there anyone actually making discs with ARM Mac software? Because ARM Macs were released last year and they don't have a disc drive.
No idea, just named all the known CPU variants.
I feel relieved people won't have to buy 3 copies of The Horde which cost $210 each just to make an entry in PC98, then FM Towns, and then DOS/V.
Boxes are different for these, so they need to be bought separately in any case (we've already dumped FMT and PC98 releases, though).
I don't know how I feel about them appearing in all dats, this will seriously bloat the Macintosh datfile in particular.
Mac needs to be split to 68k Mac, PPC Mac, x86 Mac, x64 Mac, ARM Mac. After that dats should look fine even with hybrids.
user7 clearly was refering to his PC, not a build of DIC, and if you were unsure, you should have asked him what he meant first
Then he has nothing to worry about, what's the problem? Just warned people not to use untested/hacky builds, we have lots of problems with specific official & test versions of DIC, we don't need additional problems with hacky ones.
Even if he didn't, you could have talked things over in a much less hostile manner.
No hostility at all, I haven't said anything about his dumps, the warning was neutral.
F1ReB4LL wrote:but some dumps are a mess of descrambled and scrambled data
I'm not clear on the benefit of the .scm hash. What's the process for discs with a mess of descrambled and scrambled data? Is the .scm hash used, or is the .bin hash used?
What do you mean by "used"? In db? Db only uses cue-bin images, ofc. SCM hash is needed when/if you decide to verify some descrambled image by scrambling it back. Messy discs may give a different result, depends on the case. Also, there are known mastering errors when the scrambled CD image contains unscrambled sectors and the descrambled data contains scrambled sectors - again, if you don't have .scm checksums and don't have the scm image anymore, you can't really confirm the image is correct.
If the descrambling isn't reversible for discs with mastering errors or unusual scrambling, won't it have to be redumped regardless of what the log shows?
It is reversible for normal cases, but some dumps are a mess of descrambled and scrambled data. Also some scrambling/descrambling tools handle the data differently (the themabus'es descrambler adds weird headers to zeroed sectors, for example).
If the .scm hash is the One True Hash, why not store it in the database?
Ask iR0b0t. scm contains what was read from the disc, img and bins are conversions.
The hashing phase is slow at least in part due to it only reading 2K at a time from the file. There's even a comment to that effect.
Probably also worth not to hash img and bin separately for the single-track dumps.
Come on guys. It's as simple as implementing some command line switch to perform extra hash caclulations...
I've already explained those hashes are important and shouldn't be disabled. DIC dumps every disc upto 15-20 minutes on 4x, while the hash calculating takes maybe a minute (when reading data from HDD, from ramdisk it should be faster). If "the years of your work" don't deserve that minute - better not to do any dumping at all.
Says the guy who has undumped discs marked on the wiki for years...
Huh? I've dumped the "stacked" saturn discs years ago. And what's the connection between "stacking" the discs and importance of having the scrambled checksums? We have lots of discs descrambled in unusual ways, lots of discs with mastering errors, if they don't have logs with .scm checksums - they will be nuked sooner or later.
I've got a good build bro, thanks.
I will personally nuke all the dumps made with unofficial/hacked tools, we don't need them. We don't accept the dumps from non-plextor drives, why should we accept dumps from some shady builds?
What's the problem to make a 4GB RAMdisk and do all the dumping stuff there? All the calculations will be instant.
Is there anyway to prevent dic from hashing .scm and .img to save time? is it necessary?
Thanks <3<3
Absolutely necessary. Get a new PC if yours can't do fast calculations. Since we're using the descrambled images for redump checksums, the .scm checksum is the only evidence of the original data. And the .img checksum is important to compare with the calculated-by-the-site one + needed for the quick db-vs-log verifications.
Redump Forum → Posts by F1ReB4LL
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.