hi all!

what is the best compressor for my audio cds if i just want to listen to them on my computer? mpc, ogg, or lame with the alt.presets? another important aspect should be the encoding time on my p3 900.

greetings

I'm very happy with the sound quality of mpc, and the encoding is fast - usually about 13x on my Athlon XP 1600.

qualitywise mpc is best.
speedwise mpc is best.

mp3 (lame) has best compability.

ogg is in the middle of every aspect I just mentioned.

btw.: You should look around this forum for semilar threads.
There are many and members get anoid when newcomers don't take the time to search a little for the answers.
It gets very time-consuming when we have to answer the same questions 20 times and it's generally a lag of respect and rude that newbies waste peoples time to save them selves from doing a little research.

ok, sorry,
but i have one question left
i just downloaded the newest mpc encoder and the newest cdex
how do i encode my cds with cdex to mpc with -xtreme? if i do it with external encoder and this parameters: -xtreme -v %1 %2 i get an error message after ripping/before encoding "File Not Found" (German: Die Angegebene Datei wurde nicht gefunden), I don't know why but the error message is in German so i just translated it

i got it (with Eac it works) but i got only 5x-real-time-encoding on my p3 900 :-(

complaining?

I get 0.9x on my 266...

I say be happy about your 5x... why is the speed so important?
just do something else while you encode.

ok
thx to the both of you

sometimes i get internal errors with mppenc it says reencode with -scale xxxxxx
but if i rip the track a second time it works
what the hell does that mean?

Umm, sometimes there are so called internal clipping with MPC encoder and it suggests to encode using --scale which you should do. But if the same track encodes without this message after re-ripping, then it has been a problem in your ripping.

but if a rip a whole cd i can't sit the whole time in front of my pc and look if there are internal errors?!
anyway, how do i recognize these internal errors?

If you use Frank's latest encoder mppenc 1.01j ,use --xtream %1 %2
Notice the --.

no, i downloaded the original from Andree

Well, firstable this internal clipping error doesn't happen very often (it really shouldn't happen at all, and hopefully will not happen with SV8). Anyway, you can use the new switch in Frank's 1.01j encoder --stderr

Just use --xtreme --stderr messages.txt %1 %2

Then you can after encoding check the messages.txt file. It shows all the console messages from mppenc.

Andree's encoder is very old. You really should use the latest encoder from Frank's site. mppenc 1.01j.
Also my above messages are valid only for Frank's latest 1.01j.

whats the difference between frank's and andree's?

Frank continued Andree's work. Andree is too busy with his work at the moment. Basically the latest encoder from Frank's site is in everyway more developed version. Better quality and functionality.

must i download the winamp plug-in from frank too?

YES.
http://www.saunalahti.fi/~cse/in_mpc_0.92m.zip
or
http://www.uni-jena.de/~pfk/mpp/bin/in_mpc_0.92m_en.zip

The above is Case's compile, which is supposed to have better working dithering (not a big deal). Otherwise the same.

with eac i have to use this?

--xtreme --stderr messages.txt %s %d

yeah.

sv8? it is still stream version 7!!

and, does it say that an internal error occured in the log file?

it doesn't show encoding statistics (like cpu speed, etc.) while encoding!

As a counterbalance to the MPC fans, I thought I'd reply saying that I think the best option is Ogg, particularly if your main platform is a UNIX. Purely personal choice, of course.

LOL, I'm not a "MPC-fan". I advocate and support also Vorbis very much (and help Monty with various issues), but the question was "best compressor for pc-only use". And quality wise the best is MPC at higher bitrates at the moment.

Anyway, yes, there's not yet SV8, but hopefully Frank will finish it sometime in not so distant future. And yes, --stderr should show console messages, like internal errors.

Unless you specify --forcewrite the encoder won't overwrite an existing file, so I suspect the reason it doesn't give an error the second time is that the file already exists, so no work is being done...

Yeah, but then there's "ERROR: Output file already exists", which is pretty obvious.

i guess the problem here is Andree's old encoder - using Frank's most recent encoder, i get 5.7x realtime on a mere Athlon 600..

what means --xlevel
it says that this fixes these internal errors, is that right? and is there any contra about --xlevel?

i can't see how fast it is if i'm using frank's

I wouldn't compain too much..

Putting things in another perspective.. using Lame 3.92 (MP3), --alt-standard, I usually get 1.7-2.0x on my old Athlon 1Ghz.

Sounds like there's a pretty big speed benifit, using MPC!

Jon

--xlevel tries to be somekind of solution, but at least a while ago it was problematic quality wise, so --scale is preferred when this happens.

Better not to use --xlevel.

Now I also have a quick question. (didn't wanna open a whole new thread about this)
Is internal clipping really hearable??

I've listened over and over again to tracks but the only thing I can hear is the clipping that is already on the original track .

I really have been wondering about this.

Use the "--verbose" switch, that will bring up a speed display (in addition to other information).


Until APE tags (the new tagging system in MPC, instead of the old ID3v1.1 tags) are supported natively by EAC or CDex, you can use the MPCEncT utility to create them automatically on encoding. Get it at Roberto's site. There's a nice readme included, describing how to integrate the utility into EAC/CDex.

I loooooooooove MPC and would strongly recommend using it if you don't have a portable player.

CU

Dominic

I have asked the same thing and no one has answered whether they can hear the difference or not. My experiences are similar to yours, that's why I don't bother with --scale.

I don't bother with scaling either. The tracks that I have that cause internal clippings produce a very low number of them (never more than 10). With such a low number of clipped samples, I doubt anyone would be able to hear them. I could be wrong.

Seems kind of pointless to scale to 0.83 for 1 sample...

damm I'm glad now, that I've never bothered scaling everything for those few samples.

Thank you guys for giving some answers on this question, I never found an answer fot that question on this forum.

It seems nobody knows "excactly" what to do

The original comment was in reference to the suggestion that --stderr be used. The --stderr switch disables the realtime display in the command prompt window. You'll need to check the log file you specify to see what kind of speed you're getting.

My 1.3Ghz Thunderbird runs about 11.8X on average with PC133 SDRAM. Using EAC with the option to launch the encoder while ripping occurs slows both down slightly, but overall seems to run faster. If quality really is a critical issue I'd strongly recommend reading through the EAC tutorials and using that over any other ripping program. After getting over the plethora of options and figuring out how things worked I 've just left things as is. The file naming in EAC is quite powerful and answers complaints I've had with other ripping programs.