Tweet
Hi all,
First of all, I want to send my congrats to Spoon for this very nice set of programs. I wonder what development environment you use? I come from software development myself.
I must say that I was happy with EAC but bothered by loosing time getting cover-art. Also, other squeezebox users referred to dbpoweramp to often for me to resist ;-)
I see nothing that I don't like which doesn't normally happen when I start using a new program, so that's very good. There's things that I don't see but would like to see so here they are:
1. I'm ex-EAC so I knew about the mechanism to initialize accuraterip (AR). I also knew that my Talk Talk CD would do it in 1 go so I was quickly on track. But for new users, this isn't obvious. What they see is that their AR fails every time and looking at the man-page, there's no hint that AR might not yet be initialized. A mention about this in the log (status-window after rip) would help but even better would be a pointer/reminder in the main window in the Rip Status column.
2. So, with an accurate rip I see how many other rip's in the DB agree with mine. I would love to see how many do NOT agree as well, or the total number of records for that disc-id!
3. I'm strange so I'm running this on a slow computer (but high tech, it's a Pico-ITX miniature / embedded thing). CPU is VIA and dual-core and the ripper is utilizing that very well. I'm ripping to FLAC using an external Sony DRU-810. The encoding normally (when rip speed > 8x) takes longer than the ripping. I see that the rip+encode process could be optimized to run faster. I simply determined that by looking simultaniously at the CPU utilization + rip-status. There's basically 2 threads working which are either ripping or encoding. However, sometimes 1 thread is waiting for the other one to finish a rip. During that time CPU is having some free time. Without knowing internals, the following would take care of most of these situations: thread finishes ripping: checks how many ripped but not yet encoded tracks there are: when less than 2 (so only the one it just ripped) -> rip next track (if there's 1 more available on CD) instead of encoding the 1 that's just ripped. Thread finishes encoding: see if CD drive is available and more tracks to rip: if so, rip; if not, encode.
I probably miss some details but the idea is that there's always at least 1 thread encoding after the first track is ripped.
That's it!
I still need to study that cover-art mechanism... can I upload missing cover-art? I think I managed but I'm not sure who are the providers as I didn't read man-page on that yet.
cheers,
Nick.
First of all, I want to send my congrats to Spoon for this very nice set of programs. I wonder what development environment you use? I come from software development myself.
I must say that I was happy with EAC but bothered by loosing time getting cover-art. Also, other squeezebox users referred to dbpoweramp to often for me to resist ;-)
I see nothing that I don't like which doesn't normally happen when I start using a new program, so that's very good. There's things that I don't see but would like to see so here they are:
1. I'm ex-EAC so I knew about the mechanism to initialize accuraterip (AR). I also knew that my Talk Talk CD would do it in 1 go so I was quickly on track. But for new users, this isn't obvious. What they see is that their AR fails every time and looking at the man-page, there's no hint that AR might not yet be initialized. A mention about this in the log (status-window after rip) would help but even better would be a pointer/reminder in the main window in the Rip Status column.
2. So, with an accurate rip I see how many other rip's in the DB agree with mine. I would love to see how many do NOT agree as well, or the total number of records for that disc-id!
3. I'm strange so I'm running this on a slow computer (but high tech, it's a Pico-ITX miniature / embedded thing). CPU is VIA and dual-core and the ripper is utilizing that very well. I'm ripping to FLAC using an external Sony DRU-810. The encoding normally (when rip speed > 8x) takes longer than the ripping. I see that the rip+encode process could be optimized to run faster. I simply determined that by looking simultaniously at the CPU utilization + rip-status. There's basically 2 threads working which are either ripping or encoding. However, sometimes 1 thread is waiting for the other one to finish a rip. During that time CPU is having some free time. Without knowing internals, the following would take care of most of these situations: thread finishes ripping: checks how many ripped but not yet encoded tracks there are: when less than 2 (so only the one it just ripped) -> rip next track (if there's 1 more available on CD) instead of encoding the 1 that's just ripped. Thread finishes encoding: see if CD drive is available and more tracks to rip: if so, rip; if not, encode.
I probably miss some details but the idea is that there's always at least 1 thread encoding after the first track is ripped.
That's it!
I still need to study that cover-art mechanism... can I upload missing cover-art? I think I managed but I'm not sure who are the providers as I didn't read man-page on that yet.
cheers,
Nick.
Comment