Hello..

I'm new to MPC but definitly NOT new to MP3 or OGG encoding (even did some Blade a while back). Have unpacked the MPC encoder ZIP file and extracted the encoder.exe (and even a .dll file). Was able to get Ogg Vorbis `up and running' in no more than a morning's time.. however I've found some issues with MusePack.

Please advise.. here are the items:

(1) running the encoder EXE from a W2K machine window.. it cannot seem to handle input filenames with spaces or dashes or apostrophies ( ' ). Is this correct?? and what can be done??

(2) is there a .dll or can the EXE file be used from the AudioGrabber `External' shell?? Perhaps this is failing because of the filename issues mentioned in item 1 above.


Thanks for assistance.. usage is for encoding `audiophile class' music from 44kHz WAV files.. also comment on compiled EXE that uses `-q' parameters instead of the `- insane' type switches .. etc.


Cheers..!!!

Are you using Audiograbber? ehem.... ' .
Switch to EAC.

You've got to put the path/filename in quotes if it contains spaces. That's no different from OggEnc or LAME though.

Take a look at Speek's MPC frontend (MPC Batch Encoder), it will make life with MPPENC and Co. a lot easier.




There is no MPC encoder DLL. The EXE does work in Audiograbber - you might have to put the "%s %d" each in quotes though (not quite sure). I haven't got AG installed at the moment, so I can't try it out.




Seriously - why would you want to use a non-secure ripper if you're encoding to a high quality format like MPC, and are seeking audiophile quality? Even the highest quality encode is worthless if it contains pops, glitches and skips (all of which Audiograbber can introduce, and it will do so without warning you that there might be audible problems).

I'd *strongly* suggest using EAC. It's a little hard to set up at first, but that's what 'we' are here for.




The current encoders do both profile names and --quality X. A quick overview:



I'd personally recommend going with 5 or 6, no higher. Everything higher than 6 is a waste of disk space as far as I'm concerned.

Don't forget to use the --xlevel switch in order to prevent internal clipping errors. (That will only be of importance on *really* badly mastered, over-compressed CDs though. I haven't had one single case where XLevel actually kicked in as of yet, but then I don't listen to the type of music which gets mastered that badly.)

CU

Dominic

Thanks for the great advise.. have not looked into EAC.. but am fairly confident that AG is creating accurate WAV files because it `pulls data' direct from the SCSI bus and not through the SBLive sound card audio output. This action has given me solid confidence in AG.. and I carefully audition the WAV files prior to encoding for content, discontinuities, pops, snaps, etc. Also determine which `quality' switch to use based on the post-rip output WAV file review.

As for streaming rate settings.. have been using -q6, -q7, -q8 with the Vorbis encoder and have been VERY happy with the results.. is this a waste of space?? Am listening to Michael Gettel piano `Winter' right now and it's SO fine at 228kbps ave. -q8 setting!!


Will check on batch-shell for MPC and EAC.

You really should use EAC. Do a "EAC" search and/or have a look at the FAQ to know why.

That's nothing special, every audio ripper copies the audio data straight off the CD-ROM drive. The thing is, although the process is digital, it does *not* always guarantee accurate results, far from it. Because Audio CDs, as opposed to data CDs, don't have an error correction layer, the data is simply read "as it is" - if there's a scratch, it can quite possibly introduce a "pop" in the resulting rip, which neither the CD-ROM drive nor the ripper software would notice (because of the lack of "real" hardware error correction).

EAC does its best to eliminate this risk, by reading every sector of the CD multiple times until it gets a constant readout. Since a scratch mostly affects (hundreds of) thousands of samples, the chance that it will return the same audio data mutliple times in a row is *very* slim, hence EAC will be able to tell in *most* cases whether a rip was faulty or not. For additional safety, there's also an option to read each track twice as well and to automatically perform a CRC comparison on those two rips. If EAC didn't report any read errors, a good track quality and matching CRCs between two rips, you can be *very* sure that you got a clean rip.

If you're still not convinced, I'll upload samples of glitches that can be introduced when ripping without a secure reading mode like EAC's, they'll scare you enough to switch to EAC.

CU

Dominic

Thanks aGaiN.. I went ahead and set-up EAC.. however it is considerably more complicated than AG. The CD-ROM tests indicated: Caching - No, Accurate Stream- YES, but it could not complete the C2 tests and I had to KILL it with Task Manager many times.

It went ahead on the first CD that I gave it.. ripping at 1.7X after pre -`spin-up'.. (I always use disc spin-up) where normally that NEC SCSI drive rips at 3.99 - 4.00X

Many of the CDAs are borrowed and can have LOTS of scratches. Luckily the kind of music that I enjoy is NOT what the kids like and scratch-all-to-hell. This is at least working in our favor.

In any case.. EAC was very slow and unresponsive to my clicks on SKIP TRACK and CANCEL and again I `Ended' it in Task Manager. Will have to revisit this app when there is more time and patience. What if one was to rip twice with an ordinary ripper and then compare CRCs??


Cheers..!!

[QUOTE,Gregory Abbey @ Jan 20 10:47]EAC was very slow and unresponsive to my clicks on SKIP TRACK and CANCEL[/QUOTE]
EAC usually takes a few seconds to react (sometimes even nearly half a minute, but more than that is not normal).

This is probably the first time that I recommend my own work *laughs*
Look at my signature: I have written a perfectionist's guide for EAC & MPC (very good audio extraction + very good quality encoder), comprehensible for ppl new to the scene. It might be what you are looking for...

If not, just bin it!!

Note - Pio is going to have his EAC guide finished one of these weeks. It will be a completly reworked version of the existing (very good) guide by Defsiam (in french tho). That is surely something to keep in mind

Great guide.. I'll have to print it out and study it. How about a AG 1.81 / MP3 guide.. because that's where I'm at.. and just getting into OGG but using `high -q switch' perhaps needlessly.

So.. maybe I'm a FLAC kind of guy.. you know.. lossless!!

That's right, audio CDs have no ECC (error correction code). Ever wondered why you can fit so many Megabytes on an audio CD?

I personally think EAC is just a hype But here at HA it found its true zealots, really. I have been using Feurio! since 1.30 version and been very, but very satisfied with it. Feurio! produces clean and accurate rips and compared with EAC it's much faster. EAC used to hang up every now and then on my Win98SE with Creative Dxr2 DVD-ROM so I had to use Task Manager to resolve. I definitelly don't like EAC

Gregory:



You don't have to use C2, you can just uncheck the "Drive is capable of retrieving C2 error information" box.




You also don't have to use the spin-up feature It actually causes trouble with my crappy CD writer - since *very few* drives actuallly need it, I'd turn it off.




As liekloo pointed out, that's not a problem.




That's quite accurate, but why the hell would you want to take on all that manual work? EAC will do it all for you.

You could also try CDex. It's not half as good as EAC, but surely better (more secure) than Audiograbber.


I agree with liekloo though, try one of the guides (* / * ) first before you ditch EAC.


budgie:

Well... Feurio is better than most ordinary burst mode rippers out there, but it's far from being as secure as EAC.

This is what happened when I ripped a badly scratched CD from the library (the type of music will tell you why the CD was in such condition ) with an ordinary burst mode ripper, when my drive totally lost the sync. EAC would have warned me instead of producing such crap. Oh, and @Gregory Abbey, that could happen to you too, if you use Audiograbber.



MOD: * no links or names to ripping group guides please.

uhm

So Reed-Solomon codes aren't error correction codes? C1 and C2 don't ring a bell?

It's not because data CDs have better error correction/detection, that audio CDs don't have any. You don't wan't to know what CD sounds like without error correction

Feurio vs EAC - a little bit off-topic, but probably not worth starting a new thread:

I don't quite understand where this idea comes from that Feurio is so much better at error-concealment than other DAE programs.

I tried Feurio to rip a scratched CD that I had previously ripped with EAC,
and the result was not any better at all.

EAC reported some tracks as perfectly intact (no error correction, also burst mode test & copy gave matching CRC), other tracks had to be error-corrected, and a few tracks had unrecoverable read/sync errors.
The tracks with read errors did also have audible glitches - clicks etc.
I tried EAC burst-rip those tracks several times - again, audible clicks.

So I tried Feurio, and re-ripped all tracks, a couple of copies each.
And the clicks were all there, most of the time, just about the same as with EAC burst rips.
Additionally, on one track that have been securely ripped by EAC without any errors, Feurio introduced an audible click.
Both with EAC and Feurio, every new attempted burst copy has the audible clicks appear or disappear at random (that is, most of the time there is a click, but sometimes there is not).

So my conclusion is that Feurio is not any better than EAC burst mode or perhaps any other DAE software (at least, ripping that particular disc on my particular drive).

kdo:

I believe it's a lot drive and bus dependent, while some of my friends swear to Feurio! and some kiss the book to EAC and there are some, who use other grabbers and everyone swears their rippings are alright. The truth is, that normally you have a very few chances to get a scratched or badly scratched CD into the hand, if you use your own or the CDs from the friends, who take care of their discs and if they let them out of their hands, it's a rare case (and in this particular case it's because they can trust you).

I personally have nothing against EAC but on my machine Win98SE with Creative Labs Dxr2 DVD-ROM it didn't work correctly and many times hung or even had frozen. So I quit using it, because with Feurio! I have never experienced any problems. I do audition to all disc which are important to me and never caught anything which could make me nervous...

P.S. I work with computers since 1981 so I hope I am experienced enough to make everything to run EAC correctly...

Audio CDs have 8 interleaved parity bytes per each block of audio data, for rudimental CIRC error correction. Along with the Eight-To-Fourteen modulation, this is a basic two-layer error protection. But there is no designated ECC on audio CDs!

You don't need to explain to me how error correction works on audio CD, I studied it very thoroughly 3 years ago for linear algebra I (Electrical Engineering, KU Leuven).

"For this reason, data formats on CD employ additional ECC data. In addition to the ECC defined at the bit level as part of the "red book" audio CD format, data CDs devote over 10% of the theoretical capacity of the disk to additional error detection and correction codes at the byte level. For each 2,048 bytes of data, 280 bytes are used for error detection and correction codes."

You need to explain to me how storing more than 16 bits of information per 16 bits of audio information does not constitute "error correcting codes" in the audio CD standard. Thus my confusion ( ) with above posts. No need to get know-it-all for that. Stating things like "audio CDs don't have an error correction layer" or "That's right, audio CDs have no ECC (error correction code)" is entirely and utterly false and misleading.

First off.. let me say that it was just yesterday when I `plunged' into MPC after being a MP3 user for years. In the last month.. have gotten into Ogg Vorbis encoding, and after a day of orientation with MPC and it's encoder / shells.. I'm ready to make MPCs complete with fully populated tags. Fortunately there is a LARGE IDE drive here with a number of WAV folder just waiting to be encoded.

Thanks for all the great tips!!

You fine chaps are suggesting the use of a `secure' error-correcting rip application such as EAC. I think this is a good idea but was too busy getting familiar with MPPENC and it's front end. On the subject of rippers.. I've been using the same app (Jackie's AG) since day-one. The machine is a VERY robust SCSI-based NT (now Win2K) workstation with three SCSI buses. The two CD drives are on their own integrated SCSI channel (bus).

Also.. I very rarely come across discs that are badly scratched and have had really no troubles with this DAE system in `buffered burst' mode. There is 512MB or RAM on this machine and each track is ripped at 4.00X and PCM'ed entirely to RAM before flushing the WAV to hard-drive. No encoding is done at this stage.. only WAV creation and I really never seen any indication of mis-syncronization. If there is a bad scratch.. then the rip will stop with a ASPI error indicated for that track and the disc is deemed `as a reject' for encoding use.

As for `spin up disc' I always use this (in unbuffered burst mode) to accelerate the platter to the target 4X speed before extracting.. and besides.. it allows 2 - 3 seconds to move the `progress dialogue box' to the lower corner (smile). There is NO screen saver during ripping and NO other activity and the process stays on top.

EAC is technically superior to the AG app that I've been using since day-One.. but it was too much for me to learn and configure whilst getting familiar with MPC all in the same day. Will be revisiting EAC when the excitement ramps down.. but for now.. will stick with AG because it works VERY well for me.

The first one didn't come from me, the second one did; admittedly, both are misleading. But (as you surely know, because you studied it very thoroughly 3 years ago) the error correction on data CDs is more sophisticated than that on audio CDs by the order of magnitudes. As you said yourself, the very basic error protection with the parity bytes is necessary to make it sound good at all! IMO, this doesn't qualify as what one expects from a real error correction. Thus, let me rephrase my sentence from above: "Audio CDs have no reliable error correction, concerning data integrity".

Gregory Abbey:

You're definitely right... the way you rip the CDs is absolutely OK and AudioGrabber is great tool. But I don't like it somehow from the days it got bundled with AudioCatalyst But this is rather a matter of emotion and there's no brain involved...

Hmm... that is somewhat doubtful, IMHO. What could be a reason for such drive/bus-dependence?
Shouldn't some more or less standard libraries (ASPI, ASAPI etc) be used to access the drive? If we exclude C2-capable drives, I would expect all normal grabbers produce similar quality rips in the burst mode.


Yes, if the disc is in perfect condition, then all grabbers should read a perfect copy, most of the time - though not always.
I have verified it with some "ordinary" grabbers.


Well, I caught a click with Feurio on the very first time I tried it. Maybe you are just lucky.
Other grabbers that I played with did show the same behaviour on un-scratched discs: most of the time the copy was perfect,
but once in a while a couple if bits were read with error. When the error occured in a most significant bit, it was a very audible click. Probability is obviously not very high, but it does happen.

Using EAC to detect and correct those tiny errors I don't have to listen to the whole cd myself.
Of course, one cannot be always 100% sure about anything in DAE, but with EAC it's pretty close to 100%.

There are other programs that can report if two burst copies are not bit-identical. I think that EAC offers the most convenient and natural way to correct it.

Gregory Abbey:



That's exactly what you CANNOT rely on with non-secure rippers. Sometimes an error will reported if there is a scratch, but most of the time, the grabber won't notice.

Anyway, I'll leave it up to you. I personally see no point in using a high quality format like MPC if you're running the risk of bad rips.

IIRC, the reason you are seeing a decrease in speed of approximately half is because EAC rereads each sector twice, to make sure it has a proper reading of the sector, hence it takes twice as long to rip and thus reports half the speed. If you think about it logically, it isnt ripping things slower, its just ripping things twice to make sure its right.