mirror of
https://github.com/aaru-dps/Aaru.git
synced 2026-07-08 17:56:18 +00:00
Problems dumping a specific CD-XA disc #220
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TheRogueArchivist on GitHub (Jun 24, 2018).
This appears to be another problem disc, as whenever I dump it using DiscImageChef, it reports a bad sector towards the very end that no other program finds. It does this in all the formats I've tried (CUE, MDS, DICF), and they are all consistent. Another thing I noted is that both sets of the MDS files (produced by Alcohol 120% and DiscImageChef) don't have as many sectors as the original disc according to ImgBurn. Dumping the disc also states that the output format "needs" to support CD_ATIP and CD_PMA. When converting the two MDS file pairs to ISO, the one originally dumped using DiscImageChef ends up about a MB larger than the one from Alcohol 120%, and 7-zip refuses to open it up. The image file is hosted at https://archive.org/details/Fortres101Version4.12000, but the version of DiscImageChef I used to dump/convert those there was older. Newer dumps and logs are included below.
DICF.zip
CUE.zip
MDS (DiscImageChef).zip
MDS (Alcohol 120%).zip
@claunia commented on GitHub (Jun 24, 2018):
It's a CD-R with a XA track meaning:
It has an ATIP and PMA, not all formats support those two disc tags, that's why DIC tells you so.
DIC is designed to store as much information as it can get from a disc with the drive you're using. If you try to read this disc on a CD-ROM drive it will probably not complain, because those two tags can only be read on recorders.
Alcohol is designed to create an image of copy protected games, so when it finds errors it usually does not complain, just writes fake data that will return an error (usually not the same) in a CD emulator so the copy protection still passes.
Because of how a CD recording happens, when dumping CD-R and CD-RW you'll see the following:
1.- The image from a recordable is always bigger than the image sent to the recorder.
2.- Depending on recorder and mode (DAO/TAO) used to record the disc the Lead-out may start a few sectors earlier than where the TOC says it should, giving those errors at the end of the disc. Just check with analysis and image-info after dumping it, and you'll see the filesystem size is 150 sectors less than the end of the dump before the error.
Volume has 4082 blocks of 2048 bytes eachSo the recorder got an image of 4802 blocks, and after it wrote 150 sectors of pause (as the specifications says), so that would bring us up to 4232 sectors (exactly what's dumped). The TOC says Lead-out starts at 00:58:34 (sector 4234), but it is indeed starting at 4233 (the first failed sector, as your drive cannot read lead-outs).
This behaviour of recorders is a recurring thing. If you record a 4000 blocks ISO, then dump it, you get a 4150 blocks ISO, record it dump it, 4300 blocks iso, and so on.
But well in a nutshell, up to 150 errors (never seen more than 5 myself) at the end of a disc in a CD-R or CD-RW can be ignored by you, but won't be ignored by DIC (because it's feature is, try to read as much as possible). I may add an option to ignore them in these specific case but that will be after the release I'm preparing, and I don't see it's really useful, sorry :/
About 7-Zip and an iso. This disc is a Mode 2 XA, an ISO file is, by definition, Mode 1. Converting a M2 track to ISO is undefined, something you shouldn't do, and something afaik 7-Zip does not support.
Anyway the MDS file generated by DIC is incorrect, I'll solve it soon.
@claunia commented on GitHub (Jun 24, 2018):
@SilasLaspada by itself, this is not an issue, yet the image you created is incorrect because of bugs #184 and #185 so check those two.
@TheRogueArchivist commented on GitHub (Jun 24, 2018):
Ok, the two disc images are much more consistent now. The iso generated from converting them don't have matching hashes, but they are the same size at least. Since it's undefined anyway, I guess that's not important. Thank you also for all that information, I didn't know any of that about CD-R! One last weird thing, I tried dumping the disc as DICF again, and this time it still detected sector 4233 as bad, but it was able to successfully retry it. Since nothing about my set up changed, I don't know what to make of that.
@claunia commented on GitHub (Jun 24, 2018):
It means that your drive was able to read that sector. Nothing more and nothing less all said above still stands.