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

Read/Verify cycle is inefficient and should be improved #579

Open
eharris opened this issue Sep 26, 2022 · 2 comments
Open

Read/Verify cycle is inefficient and should be improved #579

eharris opened this issue Sep 26, 2022 · 2 comments

Comments

@eharris
Copy link

eharris commented Sep 26, 2022

The read/verify cycle of whipper is pretty inefficient and I think it could be dramatically improved.
Instead of re-reading and re-verifying the track if there is a mismatch, it should instead just reuse the previous verify pass as the source of the read pass on the next try instead of starting from scratch with a fresh read. The chances of a verification match success would be just as likely, but the number of extraction reads would be only half as much, and would allow for more retries without increasing the extraction time.

@Azlinon
Copy link

Azlinon commented Mar 22, 2024

The existing validation logic could definitely use some optimizations. The proposed change seems like a good stop-gap measure to improve things a little bit, but maybe not the end goal.

I wrote out a whole response, but then realized #266 had this one nailed.

@MerlijnWajer
Copy link
Collaborator

MerlijnWajer commented Mar 22, 2024

Yes, this is indeed something that whipper would benefit from. I've made changes to the old morituri at the time to do exactly this, and you could even consider not running in full paranoia mode first, but rather just in the fast mode (flag is -Y iirc). This will drastically speed up rips if you're doing many of them.

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