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 ...

[christoffe]

The only (totally crazy) explanation I have is that somehow noise is associated with the files on my NAS drive.

Hi Mani,

the only explanation is "not proper shielded cables" against HF emissions. The HF emissions/immissions is for all highend manuf. of USB/ HDMI etc. cables a major argument for their special shielding.

Joachim

[crisnee]

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

The difference between rippers is not in the quality of sound of the ripped file. The differences are convenience, speed, and percent of time they make an accurate rip and that sort of thing. If the cds are ripped correctly, all ripped files will be identical (assuming of course that the compression settings were identical). So if you can check your files for accuracy after they've been ripped and they are, that's all that matters.

As to play back, that's another issue. Some say certain compressed lossless formats sound better than others. If that is so, that would have to do with the decoders and playback software etc., not the files themselves, which after all are bit perfect, proof being that they can all be converted back to their original form.

-Chris

[Bigear]

If the cds are ripped correctly, all ripped files will be identical (assuming of course that the compression settings were identical). So if you can check your files for accuracy after they've been ripped and they are, that's all that matters.

Yes, that's the theory.
With the test version I ripped a CD with dbpoweramp which I earlier had ripped with EAC, both secure mode and Accurip, no cache. I agree, the UI of dbpoweramp is nicer but with the checkups, it took me over 15 min to rip the CD  (Adele 21).
EAC was approx. 30 min.  Both compressed to FLAC.
However, it seemed that in the playback the dbpoweramp had a very light amount of brightness added, making it slightly more 'digital'. I know I'm at dangerous grounds here (placebo, beer etc.). It would be interesting if anyone else can affirm this (or disagree).

 

[crisnee]

However, it seemed that in the playback the dbpoweramp had a very light amount of brightness added, making it slightly more 'digital'. I know I'm at dangerous grounds here (placebo, beer etc.). It would be interesting if anyone else can affirm this (or disagree).

This makes no sense unless you ripped it to a different compression level or did something else to the file (versus the EAC file) that would cause it to be more difficult to decode.

You can't ever truly compare the sound of two files on a computer because there are always factors affecting one that don't affect the other.

If you really think there is a difference I'd first compare the files to ascertain whether that they are identical (same compression ratio--I don't think there's anything else but check it). If they are I would then listen to them individually i.e. reboot your system, play file 1, reboot your system play file 2. Repeat, this time playing file 2 first. Don't do anything to the system in between or before playing either file. Try to make sure everything else is identical as can be. Of course you'll still be listening to the files at different times and in slightly different environmental conditions, but that's life.

As to the time it takes to rip files with Dbpoweramp. Use the regular rip mode (that's what I was referring to), not the secure mode, then if Accurip comes up with errors on particular tracks re-rip those in secure mode.

-Chris

[Bigear]

Hi Chris,

thanks for your advices, I will try.

Cheers,

Quint

[PeterSt]

Chris,

I hope it is known that I am not much into voodoo stuff, but there's really more going on than "check your files". Please don't bother; it is not about that. What it *is* about though, is that some things are beyond our comprehension. Yes, also mine. Most easy is to think about the playback location and what *that* can do. I mean, at least that makes sense *to me*. Not that I worked on it to eliminate it, but it matters - I know.

When you have some time, read this : Burning audio CD while XX playing.
This is not to be denied !
It is not the same subject as we talk about here of course, but it will tell you that things are going on which are right against IT thinking. I'm in the IT business for 35 years now, and I do believe this (all). But I can't explain it (yet). So I'm strange.

Peter

[crisnee]

When you have some time, read this : Burning audio CD while XX playing.
This is not to be denied !

Peter, I just took a quick look at the thread, my eyes are too tired for more at the moment. Anyway, it doesn't seem so strange to me (if I got the gist of it in my quick overview). After all a ripper just rips what comes through as an electrical signal (right?). So if the signal is effected by something, it just records to file whatever comes it's way. But all this has nothing to do with the ripper, just the signal, which I think you implied/said in your post.

Of course I may have missed something in my quick perusal of the other thread.

-Chris

[PeterSt]

Maybe you only missed this little phrase from my last post :

It is not the same subject as we talk about here of course

... and as I said too, I am able to explain this. But let's not forget, what we by now seem to accept as known (fact), sure was not back at the time of that topic.

Give it time and we will all understand more of it.
Peter

[crisnee]

Maybe you only missed this little phrase from my last post :

It is not the same subject as we talk about here of course

Actually I didn't miss it, (I don't miss nothin') which is why I wrote the following in my post:
 Quote "which I think you implied/said in your post."

I said what I said just to make sure other readers wouldn't confuse what you said with the subject at hand.

And by the way I do think it's a good thing to compare flac files (and others) to see if they're identical. If they do measure as identical but sound different than I can see only the following scenarios as possibilities.

1. That they measure as identical but are not. How could this happen? An incomplete measuring device. For instance 3+4+3=10, 4+3+3=10 if you measure just for result they're identical, but as a whole they're not. Also, and this doesn't seem possible re measuring files of just bits, but that somehow we don't know how to measure for something that's there.

2. As mentioned in an earlier post of mine, they sound different because they're played at different times and therefore in a different environment (slightly) and the listener too has changed (slightly). One might say those changes are extremely minor. Well consider this, one minute it's raining the next it's not. Or as that grating message (because I see it way too often) says "everything matters."

3. Voodoo. Black magic. White magic. Gray area magic.

4. Bias, prejudice, your ears. That sort of thing.

5. Because of where the files are in your system, and what has happened to your system before you played one that's different from what happened before you played the other, even if it is only playing 1 before 2 as opposed to the other way around.

Any other ideas?

-Chris

[CoenP]

6. The files are written in a different ways on the hdd and it is the difference in hdd reading pattern (read noise) that you observe.

7. I have allways wondered how long startconditons or errors (even single ones) persist in the music. Not playing true nos some filtering is allways applied  (steep filters are usually FIR). These filters have a 'memory' for all samples involved in the filteralgorithm. The larger the offset or error, the more noticable this should become. I allways considered FLACs as lossless, so data in flac = data out flac. Never tested this though.

If the data  and checksum (which accounts for sequence) are equal and it still sounds different, it must be the processing (on the pc or in your brain ).

Rambling on,

Regards, Coen

[PeterSt]

7: One (anlomaly) spike is enough to change the whole track. With nice gapless ? the whole album ...

[crisnee]

I allways considered FLACs as lossless, so data in flac = data out flac. Never tested this though.

Well the test for lossless is: Can the compressed file be converted back to the original (the exact original). In the case of flac, supposedly it can. I don't assert this, but then I don't assert anything except perhaps that something = itself.

-Chris

[juanpmar]

"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."
Bigear


Hey Quint, have you found out if the PX L890SA is "real" Plextor for sure and if it supports FUA?. It can be found as cheap as 25€ in Amazon Spain.

Regards, Juan