The items that I've noticed that may be useful features are:
- Separate naming formats for image and per-track rips. It's likely that most users will pick one style to stick with, but setting a format for image rips and then ripping tracks results in ambiguously named files.
- Log, Cue, etc. should use the same naming convention as set out in the custom naming field. And should probably be based on the image format, even if the current is a track rip.
- Are the temporary WAVE files necessary? I see that currently Rip writes out per-track WAVEs and then converts as necessary. It should be possible to convert the PCM data to the destination format without going through an intermediary, saving time and space.
- If temp WAVEs are created, they should be deleted when the rip is finished, currently they persist even after quitting. For multiple rips this can add up fairly quickly.
- Is checking of previous rips on the feature list? I can understand that the current focus may be on ripping, but with the way Rip can check multiple offsets it would be useful to check rips from other sources for alternate offsets. XLD currently supports this, but from the description I've read on the forums, Rip can check many more offsets. Saving with a new offset would be required if this were to be implemented. For discs with multiple sessions (audio/data hybrid discs), this would necessitate being able to read a Log or TOC file in addition to cue reading. Possibly out of scope for this project.
- Command line or scripting would also be useful, especially if file checking is available. I have many Cue/Image rips which were performed before I knew of AccurateRip. I've written a basic command line AR checker and have identified those which are accurate. I suspect that many others have a bad offset (some I've corrected with XLD). Others may be missing some initial frames from the track 1 pregap (typically 32 or 33). Being able to script the checking of multiple rips in sequence, possibly correcting those that can be, would be a wonderful capability for repairing accurately ripped files. At this point I can almost guarantee I'm out of the scope of Rip's focus, but I'll list these here in case they might find a home in Rip.