I use EAC + Lame for ripping & encoding.

But I am searching for something easier and faster for a friend.
This is: a ripper with integrated mp3 encoder (Lame or Franhoufer for example) that rips at about 6x-8x, and is easy to use.
My friend is using Xing, it is fast (12x) and easy to use but all we know that the Xing quality is very bad.

Does anybody know a ripper with all that?

CDex

CDex 1.51 fails on my system. It tries to write in my boot sector.
Do you know other?, please.

For Windows 98
Not EAC, not Xing, not CDex
Easy to use
Fast: about 6x-8x
Mp3 integrated

Take some time and investigate the underlying reasons of your problems instead of jumping from solution to solution. Take some time figuring instead of expectancy of not having to actually learn anything to use a certain solution.

You could use EAC almost as simply as CDex, read the HA knowledgebase. There are also heaps of userfriendly guides floating around the web that should help you throught setting everything up.

The problem with Windows 9x (only) and CDex 1.51 has actually been reported several times but since it hasn't been fixed and no new version has been released, one solution is to use the previous version 1.50.

Another solution is to save a copy of the old CDRip.dll (from a previous version) and copy it over the new CDRip.dll file that CDex 1.51 installs...

What about foobar's audio grabbing and component ?

If a plextor drive is present, Plextools are an option as well.

Audiograbber has lame support, too.

Feurio! can do DAE as well ...

Poikosoft Easy CD-DA Extractor is what you're looking for.

EAC!

For multiple reasons:
1. When running the Config Wizard it gives the option of having Accurate Rips, or Fast Rips.
2. EAC gives the option to not turn on the advanced features, therefore all the extra settings could be avoided.
3. If at some point your friend decides that the pops, clicks, and other abnormalities from in-secure ripping are becoming annoying it would be easy to reconfig EAC to use secure mode.
4. EAC automatically configures LAME.EXE, however it could quickly be reconfigured to what is mentioned here on Hydrogenaudio.
5. The CD database .dat files are quick and easy to backup, easy to restore, and don't use single CDDB type files for storing the CD information.

Thanks to all the people that answered to me.
I have the solution. It is CDex older version (I use 1.40).
It is perfect for my friend. Without jitter correction it goes at 7x, but uses integrated Lame compressor and not Xing.

For Andavari:
In EAC configure lame isn't easy. You must have the file lame.exe and you can't choose the compression bitrate from a droplist as in CDex. CDex also supports a local cddb dat file.

For JeanLuc:
Foobar isn't pretty for my nonPCknower friend.

Yurop.

Have you tried FreeRip?

http://www.mgshareware.com/frmmain.shtml

Put the CD in, the cddb gives you you cd info, set to the bitrate you want, and it wil rip and convert in no time.

Hey what did you expect? I don't use it. This is strictly for some who's really not computer savvy.

i would try dbpoweramp music converter (here) ... freeware and very fast ... it uses LAME also, and you can choose -aps

I don't think you are going to find anything that rips and encodes to lame that fast, at least not with -aps, if it encodes Xing as 12x. My machine encodes Xing at about 60x, but only 5x with lame aps. That's just the encode, not counting the rip.

For DonP:
My friend only needs encode to 128 kbps CBR: it is enough for him if he uses lame instead of xing. (Constant BitRate is very faster than Variable BitRate like --alt-preset standard)

I repeat that I already have the solution:
CDex 1.40 with no "Jitter correction" and no "On the fly encode" at 128 kbps goes at 6x-7x all included (rip + encode) in my athlon AMD 2000+.
My friend has a Pentium at 466 MHz. I supose that it should go at 5x-6x: Rip & encode a cd-audio of 60 minutes in 10-12 minutes: good.

If I set Jitter correction on, the speed slows to 2x, so I prefer No jitter correction: if you don't use the PC while ripping it is rare that appear errors.

You know what "jitter correction" actually does, do you ?

If you have 6x on your XP2000+, how do you expect to reach 5x on a PII 466? It's more likely to be around 1.5x

For JeanLuc:
I think that jitter correction is that CDex reads several sectors overlap to the left and to the right. This is to avoid to lose or to repeat some sector.

But I think that jitter problems are easy to appear if you are using other programs (Word, Internet Explorer, Kazaa) at the same time. If you don't use the pc while you rip, there wouldn't must be jitter problems (that is clics in the resultant wav).
Correct me if you don't think than me.

For Gabriel:
I am going to rip & encode with CDex in PII 466MHz and I'll say you the speed.

Sorry for my poor english.

Yurop, that start this post.

www.musicmatch.com or www.dbpoweramp.com

i would recommend dbpoweramp with mpeg suite as mp3 encoder. fast as hell.

RipTrax is probably worth looking at as well:
http://www.riptrax.com/

Jitter problems appear if the ripping drive is too bad (and lacks hardware jitter correction or is badly implemented), and the drive has to stop and continue for any reason (like doing things while ripping).



but you'll be using all your CPU power for compressing to MP3.
The drive will have to wait a lot of times for the CPU.
Make sure you use a good drive.

well, I've just read that you won't compress at the same time that you rip...


!!!!
That's horrible.
I think I would prefer Gogo compressor at 160kbps... and it's much faster and supported by CDEx.

You can try using EAC combined which Frahunhofer mp3 filter, from CoolEdit.
This combo can rip and encode on the fly, and easily reach speeds of 5 or 6x, depending of the hardware, of course.
In a test machine, (celeron900, cheap Benq 56x cdrom, 256 RAM) I got that benchmark.
And, the best of all, EAC is highly reliable and the Fhg codec is fast and not that bad.
Worth of testing.
I hope it helps.

Yeah I know it's a bit OT but I can't resist...

I just love Riptrax's first page with these comments:

"The reason for this release is the new analyzer function on the Files tab. The analyzer can be used during playback to view the spectral components of the file. This gives you a visual indicator of the file's quality. When CD tracks are encoded using low bitrate encoders the spectral quality is low and there are few high frequency components. Or, if the rip process was plagued with C2 errors, there will likely be many unwanted high frequency components. In these and many other cases, viewing spectral content is very useful in determining when problems are present."

Btw...if your friend just can't deal with Lame (I'm talking about having poor speed results) I would also suggest GoGo. It's obvious that he isn't after the best available quality after all.

That what is often falsely being referred to as "jitter correction" ...

In fact, this is nothing more than buffered burst mode with overlapped reading (you can adjust the amount of sectors being overlapped) and resync to avoid losing data ...

A sync error will then be reported if the overlapped area does not match (or cannot be aligned properly) for some reason. This option is valid (and thus should be used) with drives that are not capable of delivering an "accurate stream" of audio ... a normal ripper will not benefit that much from using sector-synchronization except for the overlapped area.

"non-accurate" in this sense means that the drive shows inconsistant read offsets over the disc area (which modern drives don't do anymore - with the exception that they get worn out and become non-accurate - my old and now replaced PX-40 showed that kind of behaviour at the end of its "life").

Higher system load during DAE does not cause jitter problems (as stated on the Feurio! homepage which is not entirely correct) since high system load cannot influence hardware specifications ... these problems should be better referred to as "timing problems" since they occur on the IDE/PCI bus and not within the drive ... and timing problems can occur with sector resync as well.

So, summing up you can

1. deactivate sector resync (aka jitter correction) if you own a modern drive
2. use higher rip speeds and keep your system load low
3. rip twice with any given DAE tool (there is a multitude out there)
4. compare the two rips afterwards (aka "Test & Copy" in EAC)
5. be very sure that your rip is free of random & burst errors if both rips match.