Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow descrambling with certain cd-rom #167

Open
dutchcow opened this issue Dec 6, 2022 · 4 comments
Open

Slow descrambling with certain cd-rom #167

dutchcow opened this issue Dec 6, 2022 · 4 comments

Comments

@dutchcow
Copy link

dutchcow commented Dec 6, 2022

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
Copy link
Owner

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
Copy link
Author

dutchcow commented Dec 8, 2022

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
Copy link

seritools commented Dec 27, 2023

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
Copy link

seritools commented Dec 27, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants