This won't help you, but might put things in some perspective :

Sidenote : when you see EAC at each next track looking for 5-10 secs to the beginning of the track, you must calibrate your drive. Also note that the 10 secs this scanning for the track might take, is much on 20 secs the rip takes. So this is one good reason why it can take long.

Then, to my findings, all further settings you change for the better of speed, must be wrong (!!). I mean, all would incur for less accurate reading, less rechecking, or whatever it it is that may make the result worse. This IOW : don't try to change settings for better speed. You'll loose on that in the end by (my) guarantee.

Another sidenote :
I have written a couple of "glitch detection" programs, just because now *I* spent a weekend at ripping with poor result. This program tells me what's wrong and where, anticipating on what I see in the files itself (as you know Chris, I dive into the files when my ears tell me something is wrong ... which usually happens when some of you come up with great sounding tracks ... hehe). So ...
So I can measure (afterwards) what EAC was actually doing and can compare it with what it told me.

First of all, the track quality as presented by EAC says nothing. Oh, maybe it does, but what it is must be known by the author only.
DO NOT listen to whatever is shouted around this on the net, because everybody copies words from others, and nobody knows it really. I can at least tell *that* because I can see what it does or does not tell ... just nothing with logic sense.

When the quality is presented as 98% my program may see nothing. Mind you, this says nothing again, because my program looks for some specifics only.
When the quality is presented as 100%, 100% sure this does not tell that the copy was good. I can show you, or you can look for yourselves when I built the program in XX (which I will).

I have the examples, emerged by pure accident, that a track can be full of glitches without EAC knowing it, or ever trying to reread or whatever it takes normally to detect and recheck for errors read. Looking at the data, I'm talking about 1000ths of subsequent samples, containing the same data (a glitch), again, EAC never having seen that. The scary thing is : *this* is an example which is audible (these glitches last a tenth of a second or so), but I can also show you over 1000 detected separate glitches which are not audible (oh they must be, but I don't notice it).
I can show you files with waayyyy too less resolution, which is similar to glitching, but then consistently. So, repeating a sample 10 times before the "voltage" is switched to the next.

Actually ... when I look at a file for whatever reason, there is always something going on. I would even be as ignorant that EAC s*cks so much, that it's time for a better one ...
Btw, do note I'm talking about anomalies you can get rid of. So, rip'm again, and the problem has gone. Or is somewhere else now.

All together you might take this for the next coming future :
There is so unbelieveably much wrong with this digital sh*t, that at least I don't know where it all ends and will lead to. There can be so much wrong without absolute notice, that I'm sure we all don't know what we are actually listening to.

Okay, back to the topic : Chris, my good old ripping drive wasn't faster either. My poorly (!!) rippers are faster, without reason. The one I use now (a 52x reader) also reads about 2-3 x. But it reads good ! So at least I actually don't know what is achieveable together with good reading.
And for those who obtain a clearly higher speed ... better watch it closely. 

Peter

Of course ...

OF COURSE THE CACHE MUST BE OFF hence not active.

Gerner, your speeding was related to calibrating the drive, so it would know the beginning of a track instead of having to search for it. That may differ 10 seconds per track. Remember ?

That is what the PlayLists are for Gerner ...
 

Well ... let me wish you luck then !

And keep the "originals" until you're sure all is okay !!

Btw, it looks like you can process all in one go (batchprocessing).

Which is always better than cutting off your left arm (what you proposed before and which would be better than cutting off your right arm).

A better version ? there sure will be. I still did not start working on it explicitly. 

Gerner,

You must have got used to 96dB of motorcicle noise ...
But okay, I can't be sure whether you made up the 44K1/NoDoubling yourself, or you got smoke messages from outerspace, but yes, that is my setting as well since this version. So far I can't find anything disturbing in three days of playing, so I guess it is better than before ...

Btw, these last days I was explicitly looking for "digital" sound in all types of music, because just before this version it occurred to me I could hear "digital" again. Actually this occurred to me since the more refined CrazyA amplifiers. I just had to do something ... haha

Ha ! you are sure right on that one !

But indeed, that's why I tried to keep it as simple as possible, and in the mean time not messing with "your" PC ...

Hahaha, I just tried it. It does work, but not how we'd want it.

a. XX will start from the location where the WAV sits, implying that it can't find the necessary files, and therewith thinking it's a demo version;
b. When you select several tracks, Rightclick - Open, XX starts as many times as tracks were selected.

Currently I'm not sure what to do about that ...

Btw Klaus, your solution here is similar to my "ThumbsPlus" solution, but the ThumbsPlus solution would have everything organized independently from the physical structure. This is with Keywords (as many as you like), Archives and queries making use of that and further properties. However ... I see similar in Vista as possibilities (I mentioned this a few posts back, I think).

I think currently this is not possible, because XXHighEnd doesn't (on purpose) come with an official install. So Windows wouldn't know about it.
But indeed (I think) I could change the Registry for that ...

Well, indeed, as long as you all take your time to find the best way of working for *you*, it's allright. Otoh, it is often about knowing the possibilities (if you don't know them all, you will be sorry lateron).

IMHO one of the most important things is being able to select albums by means of the coverart. Not the individual WAVs (of FLACs , because that really would require some dedicated search function from XX itself. Now ...

If you go like I sugested in the beginning of this topic, you'd have that always. But, then there's no structure. A structure btw, which I opted for some longer ago, but which I find inconvenient now; it just won't show what you all have, once you have a couple of 1000 CDs in there. You'd be more explicitly looking only then, implying that you'll never run a big pile anymore. "Seeing makes hungry" ...

Then ...
For Vista (in XP it works too, but not as nice) in the right upper corner of Explorer, you can search ...
If you type ".jpg" (no quotes), you'd get all the coverart, no matter where it is in the structure. So ... this does NOT require the flat structure as I proposed in the beginning of this post (note that the main folder should be indexed by Vista, and it's not even easy to get that right). There's stuff like sorting properly (because sorting on "folder.jpg" -which it would be doing by default- gives random rubbish), and even adding columns for that ... letting Vista remember your sorting setting and some more nasty stuff ... and lastly the relative disadvantage of not being able to open the folder where the WAVs are in by means of one click (you'd have to do "go to location" -> Alt-B, Alt-S, Enter (Alt continuesly pressed). The main *advantage* of this means of searching (wrong, browsing !) is that the coverart will show normal in Vista (and not max 2 pictures when all is in subfolders and not by means of distorted 3D "maps" anyway).

Pfff ...
The advantage of having all albumtitles flatly organised, is that you can click anywhere in the Explorer area, see the (distorted) pictures, but directly go to the album name you type ...


Anyone dizzy ? I am. ... Too difficult to present this in a structured manner to you, but maybe it brings some ideas and things to try.
As said, we all should be independent of these (rather important !!) decisisons, and there should be an external means organizing it all for you.
Might you be interested in a means that will provide all (including complex queries that can be saved and recalled), look at ThumbsPlus. This is photo organizing software, and the way this works is really how I'd want it (and how I want to make it for XX). ThumbsPlus would even allow to start the player from within a "Thumbnail" after some additional programming which all can be done in there.

I can add that the blue lights would match the CrazyA perfectly ... (might you get the CrazyA ...)

On further remark : The backup feature you describe as "Raid" will be about automatically duplicating the one disk to the other. This means that if you by accident delete a couple of folders (or all), they are gone on the "backup" as well, instantly ...

Raid (whatever type) really is not for backup, but for continuous uptime (like with drive failure), which is something different.
So be careful !

Adding the Year at the right side wouldn't harm, but be careful that you always (still) know the year.
Now I think of it, personally I would really like the albums per artist sorted by Year ... This would imply Artist - Year - CD Title.

All 'n all it is rather complicated to do it really well, when it is about sorting and finding back, all combined with the pictures ...
I have in my head how I'd want it, hence how it will be, but there are other "things" to explore first. These "things" is about all the data Vista provides for already music only. Dit you see the, say, hundreds of fields for that ? So, if it is not awkward to use them (and assign them by batches) ... and we won't loose it at copying the data to another disk etc. etc., maybe that is something to hunt for (but my expectations are not too high here).

Best would be if there's no explicit means needed, but if you want to search for things like genre, explicit means are unavoidable.

In the end the most important is that you must be independent from the physical structure and storage location. Why ? because then you can today do what you want, or can even make mistakes with it.
That would need the player to provide it all ...

Now I'm not sure what you mean ...
My "accuracy" is about the SQ ... the gapless is 100% now. No doubts there !

Hi Bert,

If you weren't placebo'd by this :


... you could be right. I did not listen with much attention to this version myself (will do that tonight), but from theory it should be more accurate.

The latter would be about some means of compression (like FLAC ?), and personally I did not try it.

Per the current 0.9h version 100% decent gapless should be available;
I really don't know about "leaving the gaps in" or "removing the gaps" options of EAC, but removing them will never bring them back when they should be in.

Please note that this is rather more complicated than it seems at first sight, and that I spent several 10ts of hours improving things to 100% opposed to the "too simple" version 0.9g. This might be about missing a few to several hundreds of samples between tracks, to missing 30ms or so at the end of a track. Note that the latter is related, and is adding additional complications.

Dave, it is the same as with the "cue file theory" ... what you cut out, can never be gotten back. Thus ... removing gaps at ripping, will not get them back at playback when they should be there ...
It is really the intelligence of the playback what should cause all to be without anomalies; If not properly done in a current version (whatever player) ... just improve in a next.