Tweet
This is close to a wishlist post and also concerns the new Batch Ripper feature, but I still post it here because I might just have overlooked something.
I've recently bought the dBpowerAMP reference version. I'm happy with it so far, so thank you Spoon. I did tell you I'd buy it when I was beta testing
Recently, I've also bought a new CD/DVD drive, which is able to rip at 48x. Now when ripping a CD, the audio codecs usually can't keep up with the ripping, and the ripping is delayed until one of my two CPU cores is "free" again. During these pauses, the drive sometimes spins down, and up again when ripping continues, causing some unnecessary noise. Also, it leads to the fact that most of the time, only one CPU core is actually encoding.
Wouldn't it be possible not to interrupt ripping, but rather create some more temporary files (or store more audio tracks in RAM, I don't know how exactly you handle this currently) and work them off when the CPUs get to them? Storing one more track for "delayed encoding" would already at least keep all CPU cores busy most of the time and thus reduce the time needed, but never interrupting ripping at all and continuing to encode in the background while you swap CDs and fill in the metadata for the next one could help a lot with big ripping sessions.
Thanks for your attention.
I've recently bought the dBpowerAMP reference version. I'm happy with it so far, so thank you Spoon. I did tell you I'd buy it when I was beta testing
Recently, I've also bought a new CD/DVD drive, which is able to rip at 48x. Now when ripping a CD, the audio codecs usually can't keep up with the ripping, and the ripping is delayed until one of my two CPU cores is "free" again. During these pauses, the drive sometimes spins down, and up again when ripping continues, causing some unnecessary noise. Also, it leads to the fact that most of the time, only one CPU core is actually encoding.
Wouldn't it be possible not to interrupt ripping, but rather create some more temporary files (or store more audio tracks in RAM, I don't know how exactly you handle this currently) and work them off when the CPUs get to them? Storing one more track for "delayed encoding" would already at least keep all CPU cores busy most of the time and thus reduce the time needed, but never interrupting ripping at all and continuing to encode in the background while you swap CDs and fill in the metadata for the next one could help a lot with big ripping sessions.
Thanks for your attention.
Comment