WHy doesn't MPC has have a dll version so other ripper could implement it
instead of having to do a long process of converting to wav then to convert to MPC.
Would Sv8 allow something like direct encode from CD?? would this features be implenment??
since it will be easier to use.

EAC can be configured to use the mppenc.exe so there is no need for external programs.

In EAC go to compression options, external decoder, user defined encoder, point it to mppenc.exe, change the file extension to mpc and in the additional command line options put in the file info you need such as the profile etc.

Sorry i can't be more specific but i haven't used it for about a year and have no machine to run and test it on. Perhaps someone else can be more specific.

Cheers,
Kristian

Most cd rippers can use commandline encoders without any problem. The only drawback I can see would be that it looks a bit ugly when the dos window pops up. Is this the problem, or you just don't know how to set it up?

I guess he meant on the fly encoding (no intermediate .wav file). Like CDex using Lame_enc.dll

Regards;

Roberto.

While we are on the subject,is there any real difference between .exe and .dll of various encoders,i.e does the quality vary?

I don't believe there will be dll version available. But it would be simple for rippers to send audio data to stdout so it could be encoded on the fly.

No. Only differences are caused by different settings and compilers.

Aha. Strange that not so many rippers can do that. I couldn't find it in EAC for example... Only one I know about is CDex. Are there any other?

Yeah, sending data to stdout works fine, i've written perlscripts under Linux in the past and simple command lines that do just that using cda2wav? and mppenc for very quick encodes that i needed, ie. no paranoia and it worked just fine ever since Frank implemented encoding from stdin, a very long awaited feature for me a while ago

Kristian

Yeah, missing of this feature is strange as it is a lot easier to implement than support for dll. I didn't know any ripper supporting it, thanks for pointing CDex out. Maybe I'll use it on clean disks...

Hehe.. I think you can use it on some dirty cd:s as well. It uses the cdparanoia lib for ripping (not by default), and from what i heard it is not bad at all.

I have tried CDex 1.40 and it's ripping capability with scratched CDs was big disappointment. Even with maximum paranoia it ripped my scratched test CD with full speed and the quality was really bad. I think it can't bypass my Plextor's cache.

easy cd-da extractor for example...
www.poikosoft.com (??? i'm not sure about the URL)
not freeware

I've been working on a front end for Media Jukebox that uses the encoder's stdin support. I've had a few problems with it, but if I get it working I'll see what I can do about DLLs for other applications.

I will release the code for certain. Some one want to lend a hand?

well yes it is quite urgly , but the main reason is speed and ease of use.

If it could be direct rip, than it would be faster. Audiograbber can do that with mp3...

and it would be easier if the bitrate and commands could be set via a GUI, (i.e using .dll would allow you to set bitrate and tags inside the ripper ) easier to use and therefore more people will use it..

Why not just tell EAC to supress the encoder windows? Open EAC, choose EAC Options, go to the Tools tab, and check "Do not open external compressor window". No more ugly DOS window. I've never tried it myself, but I imagine that it works.
If you have EAC open a simultaneous encoding window, then I don't think direct ripping would be faster at all (see here for how to do this). EAC will rip constantly at full speed, and the encoder will run at full speed on the track that was just ripped. Direct ripping would only be faster on CD's with just a couple of tracks, since on these CD's there wouldn't be much time for EAC's operations to overlap with the encoder's (EAC would be done by the time the encoder is just starting to do its job).