Cyanrip is very slow in ripping on some drives (caused by non-continuous read operations)

[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!

[cyanreg]

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,

Thanks cyanreg!

Your reply clears a few things up.

I believe the problematic drive (note: optical, not HDD, I believe your reply has a typo ;-) ) indeed has poor behavior with it's cache while the "good" one is better in that regard (at least to whipper drive analyze; another ripper using cdparanoia).

I believe the "problem" is that other rippers I've tried (abcde, whipper, ripright) use cdparanoia with a lower Paranoia level. Maybe that's why the caching behavior doesn't get "in the way" when using them.

The problematic drive is this one (a SATA Bluray DVDRW drive):
[2:0:0:0] cd/dvd HL-DT-ST BD-RE BH10LS30 1.00 /dev/sr0
And the good one is this one (on an Macbook Pro 5,5):
[1:0:0:0] cd/dvd MATSHITA DVD-R UJ-868 KB19 /dev/sr0

The Matshita is a lot faster consistently (even with same CDs) with cyanrip. I'm paranoid enough to use it for ripping for the time being!

I think you can close this issue, unless you believe there is an actual issue which still needs some work =)