search

speed47 / dvdisaster

A tool providing additional ECC protection for optical media (unofficial version)
https://dvdisaster.jcea.es
GNU General Public License v3.0
259 stars 20 forks source link

Embedding RS03 ECC in image with memory-mapped IO fails direct verification, generates CRC errors #82

Closed marhry closed 4 months ago

marhry commented 5 months ago

OS: Windows 10 Version: v0.79.10-pl2

Settings: grafik

With these settings, dvdisaster-enhanced .iso files consistently fail the "Verify" step before burning to disk on my end. I originally noticed this after burning a full BDXL and trying to verify the re-read iso and narrowed it down a bit.

To reproduce: 1) Create a small image .iso (I had about 170 MB with various files) 2) Use above settings to embed ECC info 3) Run "Verify" on this new image immediately. The result in my case was: grafik

Workaround: Set I/O method to read/write again

michilumin commented 4 months ago

Also showing this exact issue with separate-file ecc, so it seems to be generating bad ECC data when I/O is set to memory-mapped, no matter what the method or target.

In my case this is also on BDXL media, 100 and 128gb. (Have not verified the issue yet on DVD/BD SL-DL media.)

BDXL 128GB separate-file ECC data written with memory-mapped I/O then verified: (note fingerprint match and sector count match to below R/W file.) (Also shows Data Checksum at beginning of verify, when R/W I/O does not.)

image

BDXL 128GB separate-file ECC data written with Read/Write I/O and then verified: (deep verification aborted) (No Data Checksum displayed, however all sectors verify good.)

image

Just finding it odd that we get a data checksum on the 'bad file', created with mmap-i/o, whereas we do not on the 'good file' created with r/w io.

File sizes of the "good" (R/W I/O) and "bad" (mmap I/O) .ecc files are identical.

Looking inside the .ecc files, i'm seeing an alternating pattern of "blocks" of data that are completely different but then returning to completely identical. I'm not sure if that helps much if any, but wanted to see if maybe it was something simple like an offset (it isn't.)

speed47 commented 4 months ago

Thanks for the detailed report!

I can't reproduce the problem with the Linux build, nor the Windows 32 bits build, but I confirm I can reproduce it with the 64 bits build. The number of threads doesn't change anything, so it's not a thread-synchronization problem. It seems to be a 32 vs 64 bits issue, but only applicable to Windows.

EDIT: can reproduce it with the 32 bits version actually. This might be a bug with the mmap version of Windows. If I can't fix it, I'll disable memory-mapped i/o under Windows.

speed47 commented 4 months ago

Found the problem, in fact memory-mapped i/o has never been supported in the program under other OSes than Linux, but an error in the code implies that if mmap is selected under Windows, even if the program correctly fallsback to normal i/o, a portion of code that needs to be ran under normal i/o but not mmaped-i/o is NOT executed where it should be, which corrupts the data.

This problem is also present upstream but has not been noticed because Windows support was dropped some time ago. Fix incoming.