cyanreg
commented
2 years ago Encoding is done on another thread as well here, and it's done simultaneously with ripping, so it can't really cause slowdowns. It's not responsible for the pauses. In fact, cyanrip is by far the fastest ripper I've benchmarked when used on a virtual drive.
The pauses are due to the way cdparanoia works - it has to re-read multiple sectors multiple times to produce a single sector of output, so it asks the drive to seek back many times. Since it's a mechanical process, this takes time, but the real killer is defeating the cache. Drives are smart, so if you ask it to seek back and read, it'll serve you what's in the cache. And caches can be on the order of 16-odd megabytes. So cdparanoia keeps track of sectors it has read, and when it asks the drive to seek back, it first seeks to another sector that definitely isn't in the cache and reads to fill the cache with garbage. Then it seeks to where it actually wants to read, and performs a fresh read.
Could you post the problematic hard drive model, and the speed at which it rips? Some of my discs with my main drive take 45 minutes to rip, so times of that order are to be expected at the maximum paranoia checking level.
If it takes too long to rip, you can speed it up by reducing the paranoia level. -P 3 is equivalent to -P 2 for discs that aren't completely trashed. -P 1 should give some speedup, but it doesn't really help much with the pauses, while -P 0 is the fastest and considerably shortens the pauses.
Although -P 0 disables all cdparanoia checking and verification, on all discs I have, I've never found that it causes AccuRip mismatches. After all, the keyword of cdparanoia is paranoia - modern drives already have some error recovery built-in, on top of Red Book's specified error correction.
WildPenquin
Hi!
On some drives cyanrip is very slow in ripping. I'm observing this behavior on two computers: cyanrip rips a little, then encodes the little bit it has ripped, reads another bit from the CD etc...; please let me know if this is not intended behavior. I haven't looked at the source code to see if this is actually the case, but I'm judging this by looking at iotop and the percentage reported by cyanrip. Cyanrip is not causing continuous I/O activity, desptite it certainly could (encoding is much faster on recent, modern CPUs than reading off the CD).
While this is not optimal, as these operations could be done in parallel (many rippers do this: rip an entire track, move onto the next one while starting another thread for encoding & tagging), there is another problem: another one of my optical drives has a small (but significant) delay at the start of every separate read operation. This causes ripping to be very slow on this drive! I haven't taken a time comparison, but it is around 4x to 10x as slow compared to some (any) other ripper (using cdparanoia).
On another computer (despite cyanrip behaving exactly in the same way) the CD drive does not have this delay for every read, and ripping is much faster.
Using some other ripping tools this difference goes away between these computers / drives.
Cheers!