Non optimal rip/encode pattern

[perzquixle]

This is what I see happening while I rip a cd.

1) Rip track 1 / (CPU Idle)
2) Rip track 2 / encoding track 1
3) encoding track 1 / encoding track 2 (Drive Idle)
(track 1 finishes)
4) rip track 3 / encoding track 2
(track 2 finishes)
5) Finish ripping track 3 / (CPU idle)
...

The problem with this is that the most limited resource (CPU) is being wasted. A better pattern would be this:

1) Rip track 1 / (CPU Idle)
2) Rip track 2 / Encode track 1
3) (drive idle) / Finish track 1
4) Rip track 3 / Encode track 2
...

Basically just limit the # of tracks encoding at the same time to the # of CPUs. Also, is there any reason why it dosen't rip ahead more then 1 track? In EAC I can have a few CD's worth of encoding queued up while I'm ripping at full speed.

[Spoon]

Re: Non optimal rip/encode pattern

How is the first (current) way of doing it wasing the CPU resource? the if encoding to Ogg Vorbis (ie a slow format) then the CPU will be pretty much 100% all throughout the ripping, no wastage.

[perzquixle]

Re: Non optimal rip/encode pattern

In the first pattern line 5, the cpu is (mostly)idle because the encoder has caught up to the ripper. If I was using a fast encoder, there's no way around this bottleneck. However, I'm using flac -8 and yet the encoder manages to catch up.

The reason it's catching up is because of line 2: the program works on only two tracks at a time, and for some reason it will encode 2 tracks at the same time (both making progress), while the ripper sits idle. Then when the tracks finish encoding, the ripper has lost its lead and the encoder has to wait for the ripper to rip the next track.

[Spoon]

Re: Non optimal rip/encode pattern

I see what you are saying, but if the encoder is slower than the ripper (which will get faster as teh last track are ripped) then the limiting factor of the rip is not that it pauses ripping whilst 2 tracks are encoded (as soon as one or both finish the ripper restarts, the encoder will be instantly slower than the ripper as soon as data flows), rather that the encoder will take x amount of time regardless.

[perzquixle]

Re: Non optimal rip/encode pattern

Because the encoding is the slowest part, total time = encode time + encoder idle time. The encoder is slower then the ripper, and therefore it should never catch up with the ripper, and sit idle. However it is catching up and idling, and thats the problem. (actually its the symptom)

This happens because for some reason 2 tracks will be encoding at the same time, instead of 1 encoding, and one waiting.

This never happens on cds where all the tracks are the same length. Find a disc with a long/short/long/short/... track pattern

Here's a pic:
Encoder is stuck

[Spoon]

Re: Non optimal rip/encode pattern

Try this test - start ripping a cd (all different lengths) to a slow encoder - then have a stop watch, open up task manager and switch to the CPU usage page. For the rip start the stop watch when CPU usage goes less than 75% and stop when above that. I am sure that it will be only for a few seconds at the end of a rip (unless using the secure ripper, but that is totally different).