lordmulder
commented
9 years ago Extrapolating the remaining time for a single file is straight forward: If the first x percent of the file completed in n seconds, then we can approximate the total time as n/x and thus the remaining time can be approximated as (n/x)-n. But LameXP rarely processes a single file. That's the point!
LameXP is optimized for batch processing, i.e. it will process multiple files. And it even processes several files in parallel (multi-threading). Of course we could simply say: If completing the first x of y files took n seconds, then completing all files will take approximately n/(x/y). But this will be an extremely coarse estimate, even if all files have (roughly) the same length. And if the files do not have the same length (which is the case more often than not), the estimate will simply be wrong and misleading.
The only way to do a "proper" estimate in the LameXP scenario would be to compute the accumulated length of all files in the list, before we start the encoding process - which yields the total amount of audio to be processed. And then, for every single update of the ETA, we would need to compute the accumulated length of the files that have already been completed plus the completed fraction of all files that are currently being processed - which yields the total amount of audio processed thus far.
While this is not totally impossible to implement, it would add a whole lot of complexity to the program. For a very little gain. So I don't see this happening any time soon...
xtemp09
Could you add an indicator that shows estimated time left?
I got used to set the highest quality; therefore, it takes a long while to convert. It would be easier to manage your time if you see how much time the program needs to finish the list.