search

saramibreak / DiscImageCreator

This is the disc (CD, GD, DVD, HD-DVD, BD, GC/Wii, XBOX, XBOX 360) and disk (Floppy, MO, USB etc) image creation tool
http://forum.redump.org/topic/10483/discimagecreator/
Apache License 2.0
530 stars 45 forks source link

Slow descrambling with certain cd-rom #167

Open dutchcow opened 1 year ago

dutchcow commented 1 year ago

Version Latest, 20220909

Describe the bug Cd-rom gets dumped succesfully and normally but then the descrambling process always takes a lot of time, about a hour or two. It does descramble succesfully, it's just very slow. It does have some filedate issues in the bin/cue, not sure if related. Restarted pc, tried it several times but the descrambling stays slow with only this cd-rom. My computer is a highend pc, with other cd-roms it goes much faster.

The 71041TWAV01_mainError.txt file is very big, more than 1gb.

I'm not sure if this is a bug or not, but maybe the process can become quicker.

Screenshots https://user-images.githubusercontent.com/96270929/206045509-0aefa962-69ce-4121-8975-1a1c625ad9c3.mp4

Disc title NTI Skill Builder Microsoft PowerPoint 97

Disc ringcode Dawidisc/ 22000 / NTI/ MS PP 97 / 06-01

URL https://archive.org/details/nti-pp97 (.scm file is there too)

Log file Too big, see url above

saramibreak commented 1 year ago

Unfortunately, this is not bug.

Scrambled image of this disc is not normal (some bytes are scrambled but some bytes are not scrambled). For this reason, _mainError.txt is very big size.

dutchcow commented 1 year ago

Thanks.

Would it be possible to speed up the process?

I have no technical knowledge but someone told me it's just some XOR-ing and using a highend pc with quick ssd/cpu I somewhat expected a quicker process. Any chance there is a little bottleneck in the code that can be fixed?

seritools commented 8 months ago

This can definitely be fixed - the problem is that there is absolutely no output buffering in OutputLog, and OutputMainChannel generates the hex dump view mostly one char/byte at a time, meaning one WriteFile call per byte. It seems like 99.99% of the time is wasted in WriteFile calls.

image

seritools commented 8 months ago

Just did a quick test:

Before:

StartTime: 2023-12-27T17:09:54+0100
EndTime: 2023-12-27T18:29:37+0100

(3.2GB mainError.txt)

Commented out the OutputLogs in OutputMainChannel:

StartTime: 2023-12-27T18:40:32+0100
(.scm capture from drive was done at 18:52:16)
EndTime: 2023-12-27T18:52:39+0100

So all the steps after the scm capture went from 68 minutes to about 23 seconds.