When using Grip to rip/encode entire disks, it appears
that the process could be sped up by reading the tracks
in the reverse order. Two factors contribute to this:
First, ripping happens more slowly for the lower track
numbers due to the fact that most drives are constant
angle velocity (CAV) devices. Second, when Grip is
both ripping and encoding, the encoding process speed
is limited by and inversely proportional to ripping
speed (as ripping gets faster due to the increasing
linear velocity of the outer tracks, encoding gets slower).
Using the current approach to ripping, the first track
takes the longest time to rip, thus causing encoding to
be idle for quite a while before it can even begin its
task. Also, since the first few tracks tend to encode
faster than they rip, the encode engine tends to idle
after it completes each of the first few tracks.
By offering the option to rip/encode in the reverse
track order, the encoding process would begin more
quickly and would tend to get behind early in the
process, thus keeping the encoder busy and causing it
to be more nearly done when the ripping process completes.
Ticket moved from /p/grip/bugs/215/