FAST audiophile ripping

[Bigear]

As a fairly new NOS1 owner, I still struggle to get my CD collection on the PC.  EAC seems to be the most recommended audiophile ripper, however it is terrible slow. Ripping a CD takes often half an hour or more. So with a reasonable cd collection it will take weeks to rip it.
Any ideas if there would be a quicker solution or improved setting for EAC to improve the speed (with still audiophile results)?

[manisandher]

Hi Bigear.

The only fast way that I know of to rip CDs is to use a 'real' Plextor drive with 'Forced Unit Access'.

You can use FUA with EAC by adding '-usefua' in the command line. With dBpoweramp, there is an option to test the drive for its FUA capabilities and then set it to use this. But in my opinion, this test is not 100% accurate. The strong recommendation given by the dBpoweramp developer is to only use FUA with Plextor drives, even if the test proves +ve with a different drive.

The affect of FUA is to bypass the drive's cache and re-read directly from the CD (google FUA to learn more). With my Plextor Premiun-U drive I can rip a CD in totally secure mode' in about 2 minutes flat. If there are scratches on the CD (never any on mine, but my wife's CDs have plenty!), the re-reads kick in exactly as expected. Of course, the rip then takes longer, but really not by much. With FUA engaged (and a Plextor drive), the re-reads are done really very quickly.

This is very topical for me because I've just installed a 3TB spinning HDD in my computer... mainly because I wanted to test Peter's findings on HDD vs. SSD, and also because it'll make my life easier when using 'Minimise OS'.

BUT... the thing that I found over the weekend was that a CD ripped directly to the new HDD sounds better than a previous rip transferred from my NAS to the new HDD!!! It may well be that I will be re-ripping my CD collection. I really don't want to, but will if I have to. In which case, this FUA command helps a lot.

I'd love to hear other people's thoughts on this subject though.

Mani.

[PeterSt]

If only nobody makes the mistake to *use* the cache from the CD Rom drive. This is just *not* allowed with ripping audio ...

[crisnee]

Hi Bigear,

If you don't have access to a Plextor it still needn't take a half hour per cd. For instance I use dbpoweramp without a Plextor. My cds are in good shape and just take a few minutes on average to rip to flac.

You're probably using the ultra secure mode or some such, I am not. But Dbpoweramp has Accurip (or something like that) which checks your rip against others rips online of the same cd, so I've had no trouble with any of my rips, at least that I know of--it will let you know if a track needs to be ripped securely, at which point you can do so. So, as long as you keep your cds, in case you do find some problems later on, or you're a total perfectionist,  the time savings (3 minutes vs. 30 minutes per) is worth the slight chance of a problem, IMO.

-Chris

[PeterSt]

When I use EAC - and I rip at 4x speed, a slightest single problem in a CD makes that it will take 20 minutes. Do the math.

When I rip at whatever high speed, the rips won't be good ... (I forgot why and how, but this is what I determined ever back; maybe I'm old fashioned by now )

Peter

[christoffe]

If only nobody makes the mistake to *use* the cache from the CD Rom drive. This is just *not* allowed with ripping audio ...

Hi Peter,

This statement is new for me.
I will test it, and I hope to hear no difference. If yes, oh boy ........... .

Joachim

[christoffe]

If only nobody makes the mistake to *use* the cache from the CD Rom drive. This is just *not* allowed with ripping audio ...

I will test it, and I hope to hear no difference. If yes, oh boy ........... .

Sh....t !!!   A ripping with the cache deactivated reveals a soundstage with more detail, more air, more darkness, less "dirt" and more silence in background.

[PeterSt]

Imagination, placebo's, hallucination, beer. This early in the morning ??

Ok, there are still more things going on than we know, and by itself this won't be anything new. But don't dedicated it too much to that cache. With the cache being activated, the "ripper" can't read something different a next time, because then it comes from the cache (memory). So it won't correct a single error, because it won't find any. Thus, finding errors is based on reading a couple of times, and then one of these times the result should be different (meaning : that implies errorneous reading). Next what happens is read many times, and pick the most occurring same data as the good one.

Now you will also understand why the speed itself is important; At reading at blazing speeds the data read may always be the same errorneous. It is not without reason that something like EAC offers the option to slow down the reading at detecting errors ...

Peter

[christoffe]

Imagination, placebo's, hallucination, beer. This early in the morning ??

Finnland is one hour ahead of you folks down in the Netherlands!

[christoffe]

Now you will also understand why the speed itself is important;

I read somewhere it is recommended to use the lowest speed for ripping with the CD drive possible.

Joachim

[manisandher]

I'll be doing some testing on ripping speeds this weekend (time permitting). Will let you know what I find...

But meanwhile, I'm more than a little perturbed that the files ripped directly to a NAS drive and then transferred to my the HDD sound different to those ripped directly to the local HDD. The former sound brighter and more edgy. The latter darker and more liquid. And yet I'm 100% sure the checksums would be identical - the same HW/SW was used for ripping after all.

I agree, "there's a lot more going on than we know", but this just seems crazy to me. The only (totally crazy) explanation I have is that somehow noise is associated with the files on my NAS drive. Such noise might not affect the checksums at all, but may influence the PC/DAC hardware in some way.

Still, totally crazy IMO...

Mani.

[PeterSt]

Merely focus on the location where things are played from first; this matters.

When you are done with that, reinterpret the ripping-to location (meaning, suddenly that may not matter, because it isn't exactly about that - maybe/logically).

Peter

[manisandher]

Merely focus on the location where things are played from first; this matters.

Yes, I can see how this might matter. BUT...

I'm more than a little perturbed that the files ripped directly to a NAS drive and then transferred to my the HDD sound different to those ripped directly to the local HDD.

(highlight added)

... both files were played back from the same location (the local HDD). So, files with identical checksums (I assume) played back from the identical location... sounding different!

I really, really hope that I'm just doing something 'wrong' and that I can simply transfer my current ripped files from my NAS to my local HDD without any affect on SQ. All logical reasoning suggests to me that there simply cannot be a difference.

Mani.

[Bigear]

Mani,

thanks for the advice.
the only 'real' Plextor optical drive available seems now to be a DVD R/W  PX L890SA. Not sure if this one supports FUA though. Can't find it on the web.

Interesting observation on the 'freshly' ripped files on the HD.
In the past I experienced that changing to another router influenced the sound, but that was while playing directly from the NAS.  RF influences over the network causing more marginal bit images on the magnetic HD??? Just speculating here, might be difficult to measure.

As Chris suggests, dbpoweramp might be an option. Would be interesting to compare rips from dbpoweramp to EAC (using both the 'highend' settings)

[PeterSt]

Mani, I already had in mind you said something like that, but I didn't read back. Sorry for that.

Your next attempt could be to REPLACE the one folder with the other. So, it won't be on the same location on the hdd anyway (that is how it works), but at least it implies the same folder structure, which also matters.

Not that this would be anything that is under our control, but if you could proove that indeed this is what causes it, your off of something not understandable.
... But creates another (for you) ...

Peter

PS: ... which difference officially would be taken out by setting "Copy to XX drive" if this isn't about FLAC (which always incurs for "Copy to XX Drive"). Still, this kind of tweaking didn't work when the XX drive is a RAMDrive; when people would copy themselves to there the sound was different again. Just saying ...