You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: