serious bug regarding files produced in the iso not being valid

[drixoman]

Hi, I'm completely new to this program; usually I would just use things like ImgBurn to save iso, but considering I have a lot of pretty old disc (not CD-R mind you, CD-ROM purchased ages ago--already into the "cross-finger it's still readable" territory admittedly) I found this program along with CDCheck so I thought to use this to check them out and get them into iso before they rot completely.

But it seems there is a severe bug I encountered with the last "stable" version for Windows (0.72.3pl3 that's accessible from the dead official website on the Wayback Machine archive) that seems to still be present in your latest 0.79.6pl7: a typical 700MB CD-ROM was read using the Linear strategy with all sector reported readable (all green) and the curve looking smooth and no C2 error reported, yet there are many files in the resulting ISO image that have the correct size but are unreadable; you can't open them when you mount the iso nor can you even copy them to the hard drive--Windows report them with a "Invalid MS-DOS function" error. A lot of those files don't seem to be corrupt as you can open/copy them from the disc still fine. So essentially the image made is useless. (now maybe there's thing regarding copy protection? on some disc I think, but I don't think that's the issue here as these are not some commonly bootlegged movies and big-named softwares)

Now I think some of my disc are not that dead yet so I can reimage them, but CDCheck don't make the iso while reading the disc so I'd basically be flying blind if I make a image now with Imgburn and the like (or plain copying out the files).

Personally I think this should be given the highest priority for investigation (so perhaps drop all other issues for the time being) as I think this may even affect the reputation of this program (not sure if the ecc are based on the image but it does seem like there is a connection on first thought); honestly I think if this were a commercial program there's likelihood ground for legal action even if it's a bug and not just me the user not setting the program correctly--it's this serious as data integrity seems to be compromised here, for who know how long and how many users as the last "stable" version was released ages ago.

If you need any log or such I might be able to help, but I can't use Linux and have no software development knowledge whatsoever so request have to be made with how-to-guidance if you want any settings changes for testing.

[speed47]

Hello @drixoman,

I think there is a misunderstanding about what dvdisaster can do for you: its goal is to protect an iso image you've just built, adding correction data to it, BEFORE you burn it to a CD-R/DVD-R/BD-R.

If you have a bunch of old CDs and would like to salvage data from it, if those CDs were not augmented with dvdisaster-produced correction data before being burnt back in the days, dvdisaster won't help you in any way.

Side note : you might want to try with a different drive, when reading back data from damaged discs, you can get very different results, and having an iso file resulting from a drive reading the full CD, with no error, but with corrupt data, this seems strange and might come from you drive.

[drixoman]

Hi @speed47,

As I said I think there's some bug with the program, at least with the recommended setting on my drive, as for some reason it builds corrupt iso from what seems to be good disc that it had just read with NO UNREADABLE SECTOR reported (so the curve was smooth and no C2 error reported also). Sure the disc is a bit dated but it can be considered healthy, not even weak and certainly not damaged, by the disc scan results vis-a-vis the program's own documentation, yet corrupted iso is what's produced, however if you copied the files with Windows Explorer the files seemed intact; heck if you run what was on the disc (it's a program installation disc) the program install (since the the disc is still going strong apparently) but if you load the iso the necessary files are basically invalid file reference to data that's not there (probably not even corrupted data) but still had the correct file size (so don't be misled by the file sizes). FYI I found this out using WinMerge as it hangs when encountering these so-called "files" when I copied out the iso and did a folders comparison.

So again, the program seems to have bug in how it create iso, which I'm assuming likely affect the ecc data it creates thereafter--basically you're probably getting compounding error with the ecc data made from faulty iso made from a error-free CD.

Now I realized I was using the last available Windows version and that doesn't seem to be the the "stable production" version (0.72 of 04-07-2009), so I'm going to try again with that version. I don't have other drive to try with unfortunately, but the problem seems to be with the program and/or the settings as I can read the disc fine just thru Explorer.

[drixoman]

okay even with 0.72 the issue is still there. all sectors read, ecc file made, mount iso and some file still invalid.

[speed47]

Do you have the same behaviour on an iso produced by another software (e.g. imgburn) from the same optical disc?

[drixoman]

Hi,

This bug is at least present with that one disc I've been mentioning above which I am using as the test for this issue.; so yes, for that disc if I make the iso with that same disc using imgburn there seems to be no invalid files.

Granted, I do have some other CD-ROM that seem to have some kind of perhaps ecc data in them, as the iso imgburn yield are quite larger for these disc than the disc size as reported by Explorer, ie some extra invisible data were detected by Imgburn (unfortunately the setting in imgburn of "Disc Capacity" between File System vs Disc seems not function so I always get a iso with a larger size than what all of its file adds up to.)

So I will use 0.72 in another Image Size setting and see if that solves it. Then it's probably a issue of the program can't figuring out it should switch size mode to account for those extra data somehow as the setting was on the recommended ISO/UDF size mode which resulted in some file corruption.

FYI: It seems a faster check for this problem is to extract the iso with 7Zip and it will complain about data error on specific files.

[drixoman]

Okay I think I sort of figured it out the problem.

So here is the Imgburn disc info on the disc I've been mentioning:

` HL-DT-ST DVDRAM GUE0N LC20 (SATA) Current Profile: CD-ROM

Disc Information: Status: Complete State of Last Session: Complete Erasable: No Sessions: 1 Sectors: 321,250 Size: 657,920,000 bytes Time: 71:25:25 (MM:SS:FF) Supported Read Speeds: 10x, 16x, 20x, 24x

File System Information: Sectors: 321,016 Size: 657,440,768 bytes Time: 71:22:16 (MM:SS:FF)

TOC Information: Session 1... (LBA: 0 / 00:02:00) -> Track 01 (Mode 2, Form 1, LBA: 0 / 00:02:00) -> LeadOut (LBA: 321250 / 71:25:25)

Track Information: Session 1... -> Track 01 (LTSA: 0, LTS: 321250, LRA: 0) `

Turns out the ISO mode was not capturing all of sector as it only read the File System's 321016 sectors but actually 1 file and part of 1 other file were in the difference between Disc and File System. So I used Drive mode to read it and no invalid files this time; the difference were too small so I didn't think I should use ECC mode as the difference don't seem to be ecc data, but some of my other disc have significantly larger difference so perhaps (more head shaking is that some are in Mode 1 but other's in this Mode 2 Form 1--I haven't done the tracking on which have the huge sector/bytes difference so it's hard to tell if I should use ECC reading mode for some of them!)

Now turning to this "bug", I managed to perhaps figured it out using 0.72 but your latest revision is quite different in the setting and unfortunately the default setting there also didn't figure this difference out and still went with the File System size. I see some setting that seem to change the next disc reading, but I'm not willing to bet an "average" user's ability to tell/remember how big the disc truly is and what setting should they choose really; so perhaps for future stable release try to make the program "smarter" in detecting what setting to use so the user don't need to do what I needed to do with these tedious post-verification AND re-read the disc in trial-and-error settings changing, since I think the ecc file created after any disc read is probably based on the image produced.

Anyway, I am not sure if this is even a "bug" now that I think about it, but please consider checking your files similar to what I did--perhaps you need to re-read the disc also (or maybe it's just me not knowing what I'm doing and all the other user of this program are disc/image-mastering expert lol)

[speed47]

In that case, for those kind of discs, you might have more luck enabling this option:

It replaces the old option you're talking about in 0.72 ("drive", "iso/udf", "ecc/rs02"). This change has been made by the original dvdisaster author in the more recent 0.76 series, and is intrinsincally better as enabling "ecc/rs02" for discs without dvdisaster ECC data makes no sense, so for those discs the behaviour of 0.72 couldn't be specified by the user.

Now the order of preference is always: ECC reported size when present, otherwise ISO/UDF then drive. Unless you tick this option, in which case ISO/UDF and drive are reversed.

It usually should not be enabled, as explained in the help, but for some discs it has to. There's no "smart" way to automatically guess which is the proper one for a specific disc, unfortunately, as we're dealing with a while range of discs prepared by a wild range of softwares ranging from the last 20 years, and each has its own quirks and oddities in the images they produce.

[drixoman]

Yeah I was referring to that option I saw in your latest revision. Unfortunately, pretty much all of my CD-ROM (ie not CD-Rs I burned myself but OEM ?pressed? data disc) all seems to have extra data outside the file system that suggest using the ISO/UDF option is not good enough, and I don't know if they qualify as ECC data by the program. Does the new revisions make the ECC data search more efficient so it won't take as long as what seems to be indicated in the document for 0.72? the new revision seem to suggest a split relative to 0.72 in getting image size from the ECC--ie the old version seem like it does exhaustive search for the ECC until found if using that size option while the new version seem to have split that search into 2 option, a light and a deep search.

[speed47]

Yeah I was referring to that option I saw in your latest revision. Unfortunately, pretty much all of my CD-ROM (ie not CD-Rs I burned myself but OEM ?pressed? data disc) all seems to have extra data outside the file system that suggest using the ISO/UDF option is not good enough, and I don't know if they qualify as ECC data by the program.

What dvdisaster calls "ECC data" is not the builtin error correction codes all optical media have (C1/C2 for CD, PI/PO for DVD, BIS/LBC for BR), it's the supplementary recovery data dvdisaster added to an iso before burning it.

If the disc was not augmented by dvdisaster when burned (and 0% of CD-ROMs are), there is no ECC data to look for.

Does the new revisions make the ECC data search more efficient so it won't take as long as what seems to be indicated in the document for 0.72? the new revision seem to suggest a split relative to 0.72 in getting image size from the ECC--ie the old version seem like it does exhaustive search for the ECC until found if using that size option while the new version seem to have split that search into 2 option, a light and a deep search.

For discs that were augmented with dvdisaster error correction data, once you scan them, yes dvdisaster has two ways of finding back the data it added. In all cases I've seen, even with the deep search, it doesn't take more than a few seconds. But again none of this applies to CD-ROM or CD-R without dvdisaster-specific added error correction.