OK I've been thinking about it, I have a few ideas how to make the app recoverable from crashes. This all came about from me today when my Max crashed. At the time I had 7 CDs being ripped 11 GB of already encoded music, and 448 songs/25GB of music in the encoder queued up to be encoded.
When ripping audio tracks, store in memory, and only write to disk when its done. Same for encoding, write output file to memory and only write it to disk when its done. Or, if that would use too much RAM, maybe have a secondary scratch folder for true temp files, in addition to the main scratch folder that is essentially the queue folder for the encoder. [the more i think about this, secondary scratch is a much better idea. If I happen to be ripping 8 CDs at once and all 8 are on really long tracks, thats 8 huge AIFFs all being stored in RAM. Thats just asking for trouble]
Now, my queue scratch folder is filled with 25 GB of music even right now. Max could just pick up encoding that folder is I relaunch it. I assume it stores the audio tag information elsewhere. So it could just automatically add everything in the queue folder to the encoder and start encoding again. And as for ripping. Max has the option to only rip CDs it hasn't ripped before. As far as I can tell, it just checks to see if the CD itself has been inserted. What would make this work is if instead, Max marked each track as complete after ripping it and writing the ripped track to the queue folder. The mark as ripped would be another attribute of wherever all the tag info is stored for CDs. Then, when a CD is inserted, it would just rip all tracks that haven't been ripped yet.
With the features above implemented, you could theoretically be able to crash max, and just double click to relaunch it, and have it pick right up where it left off, without loosing a bit of data.
Discuss the current and future development of Max.
1 post • Page 1 of 1