Feature Request for CD Ripper

[Ambrose Mensch]

First off, great work. I've found the latest alpha to be a great alternative to EAC. It is easy to configure and has a very clean interface. And of course, produces highly reliable and secure results.

One thing that I would love would be a batch encode mode. This way CDs could be ripped in a batch, and then encoded all at once (presumably at night, in my case). This would offer two advantages. One, the cpu-intensive act of encoding can be done at a time when the computer is not being used (I tend to use my computer while encoding, forcing me to set the encoder to run at a sub-standard priority). Second, it allows the user to make the most of the time he's in the room. If I have 5 CDs to rip, I can do it faster if I don't have to wait for each one to encode.

Thanks for all the hard work!

Amby

[Spoon]

Re: Feature Request for CD Ripper

Encode to one folder (fast lossless like monkeys, so it tags) then use dBpowerAMP Music Converter to convert over night.

[Ambrose Mensch]

Re: Feature Request for CD Ripper

Encode to one folder (fast lossless like monkeys, so it tags) then use dBpowerAMP Music Converter to convert over night.

Hmm, I've never used Monkey's; I didn't realize that it had a significant speed advantage. I'll give it a try.

Long-term though, is there a reason why my aforementioned idea would not be implemented (aside from lack of necessity, if you believe that to be the case)? I think that for people ripping an entire CD collection it would offer your product a significant advantage over the others available (EAC, namely).

Perhaps a better intermediate step would be to save the tags in .TAG format (like Foobar2000 does for formats that do not support tagging). That way you could just rip to wave, and the dbPowerAmp converter could read the .TAG files later when you encode to FLAC.

At any rate, I don't mean to persist if this is a no-go; I just want to offer my $0.02 and let you know what I'd find useful. Thanks very much for making this available; it has made my life a lot easier

Amby

[Spoon]

Re: Feature Request for CD Ripper

In some of my tests in fast mode, Monkeys can encode and write faster than writing an uncompressed wave file! (because it is half size and the speed limiter was the hard disk).

I dnt see the need for the ripper to store temporary files, for example encode to monkeys and then use 'File Selector' (select the root folder) to convert all monkey files to something else over night and delete the source if sucessfull (note file selector has not been written for r12 yet). The converted files would go inthe same folder as the monkeys (ie artist\album\ etc).

[bhoar]

Re: Feature Request for CD Ripper

In some of my tests in fast mode, Monkeys can encode and write faster than writing an uncompressed wave file! (because it is half size and the speed limiter was the hard disk).

Just a comment: that's the sort of thing I was hoping to hear!

-brendan

[Ambrose Mensch]

Re: Feature Request for CD Ripper

In some of my tests in fast mode, Monkeys can encode and write faster than writing an uncompressed wave file! (because it is half size and the speed limiter was the hard disk).

Wow! I guess I didn't quite realize how fast we were talking :D

I'll definitely try that when I get home.

My only other suggestion in this case might be to make it so that the "File Selector" can append the written log file from the ripper and write what it does for the file conversion (this may be planned; I don't know). This way there's no confusion between the Monkey's Audio in the log file, and the FLAC files that are left in the directory.

Thanks again, I very much look forward to trying this out

[Spoon]

Re: Feature Request for CD Ripper

There should not be a requirement for a log between Monkeys to Flac, either it works or it does not (perhaps disk is full) in which case the error would be shown on screen with the option to reconvert failed files.

[Ambrose Mensch]

Re: Feature Request for CD Ripper

There should not be a requirement for a log between Monkeys to Flac, either it works or it does not (perhaps disk is full) in which case the error would be shown on screen with the option to reconvert failed files.

Is it possible for the batch converter to write a (separate) log file detailing what it does? This way one would have a record of how it was converted, the settings used (i.e. Flac level 1 vs flac level 5), etc.

[Spoon]

Re: Feature Request for CD Ripper

These settings are in the FLAC files themselves, upto now no one has ever requested a conversion log.

[Ambrose Mensch]

Re: Feature Request for CD Ripper

These settings are in the FLAC files themselves, upto now no one has ever requested a conversion log.

Do all lossless codecs include tags (or metadata in other ways) regarding the full set of encoding settings?

Aside from that, I still say that for achivists it's a great feature. If a format is ever found to be flawed, you have a record if your file comes from that such format.

[LtData]

Re: Feature Request for CD Ripper

No, Shorten and WAV do not have tags. However, dMC r12 has apparently added tagging for WAV files. Also, currently the dMC TTA codec does not write tags.

[Ambrose Mensch]

Re: Feature Request for CD Ripper

No, Shorten and WAV do not have tags. However, dMC r12 has apparently added tagging for WAV files. Also, currently the dMC TTA codec does not write tags.

Sorry, what I mean is do those codecs (i.e. TTA and Shorten) have embedded information that contains all of the encoding settings? IT doesn't seem to be relevant for shorten as there isn't much flexibility, but perhaps for TTA?

I don't mean to come off as greedy (I love this ripper/converter and have been using it quite extensively lately!), I just think that maintaining an up-to-date log file is very much preferable. Another reason why is that I occasionally have to transcode lossy codecs (i.e. m4a > mp3) so that I can play the files on my portable. It would be great to have a log file so that I know the history of those such transcodes. If I delete one, I certainly don't want it to be the original!


edit: on more of an FYI note, batch converter loses ReplayGain tags when going from FLAC to WavPack.

[Spoon]

Re: Feature Request for CD Ripper

ReplayGain is intentionally dropped, you need to add the DSP Effect ReplayGain to calculate it on the fly.

[Ambrose Mensch]

Re: Feature Request for CD Ripper

ReplayGain is intentionally dropped, you need to add the DSP Effect ReplayGain to calculate it on the fly.

When you use the DSP Effect, however, is it copied over or is it re-calculated? If the latter, may I ask why?

[Spoon]

Re: Feature Request for CD Ripper

There might be other effects, which affect the overall gain, it takes relatively small cpu power to recalculate so is always best done when converting.