Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[NickM]

I was most impressed with the concept of threads that MC now uses for library changes.  I can now make huge numbers of updates and MC will chug along in the background gradually applying them.

Then I thought of the ripping and encoding process.  I am not sure if this is a particular setup issue with my PC, but the ripping end encoding process seems to grind the rest of the system to a halt occasionally.  This happens at the end of a track rip and again during the encoding process.  At the moment, if you require normalizing, you rip then encode each track. 

So, what about ripping the entire CD and then allocating a priority for the encoding so as not to interrupt the rest of the system?  If you have plenty of system resources and a powerful PC, you could always have multiple instances of the encoder and process together ( barking? ).

nick

[NickM]

Oh, and whilst we're on the subject of threads; if an external destination drive ( e.g. SAN ) goes off-line for a short time during the encoding process, MC11.216 hangs even when the external drive is re-connected.  Is this too much to expect a thread to pause and re-connect?
nick

[GHammer]

Oh, and whilst we're on the subject of threads; if an external destination drive ( e.g. SAN ) goes off-line for a short time during the encoding process, MC11.216 hangs even when the external drive is re-connected.  Is this too much to expect a thread to pause and re-connect?
nick

Do you have any example of rippers that will pause and wait for a missing drive?
Just curious.

Myself, I would find why the SAN was taking the drive offline and correct it.
Coding for rare/uncommon things takes time that may be better used on commonly used items that are broken.

But I am curious if there are other rippers that will wait for a missing drive.

[NickM]

The reason my SAN goes off line is a hardware problem with my switch - it will be fixed - eventually.  I also tried making tagging changes and the same MC crash happens if the SAN goes of line whilst the changes are being written.

It appears that the library thread adjusts its priority depending what else is happening on the client end.  It shouldn't be too hard to have a re-try built in to the process, but yes I agree, more important bugs to fix first...

More importantly, what about ripping all the WAV's first to a local temporary folder then encoding in batches later?  Given LAME's inability to operate at a low thread priority, I am sure that would make a difference for many users.

nick

[JimH]

More importantly, what about ripping all the WAV's first to a local temporary folder then encoding in batches later?  Given LAME's inability to operate at a low thread priority, I am sure that would make a difference for many users.

Other people find this a good method.  Encoding to APE would also work.  It's fast and smaller.  Then start a conversion and let it run overnight.