I didn't realize the process was as complicated as it appears to be, but it would explain a few things.

Regarding EAC, does anyone know what the "technology" is, or addresses?

EAC wrote:

It works with a technology, which reads audio CDs almost perfectly. If there are any errors that can’t be corrected, it will tell you on which time position the (possible) distortion occurred, so you could easily control it with e.g. the media player

It seems like something similar can be achieved with "Secure Mode" and cdparanoia. Any idea if this is limitation more with the drive, cdparanoia, or cdparanoia's "compatibility" with the drive? Or something else? Some of the flaws I've had with skipping in some of the results seem like this could be the issue.

I haven't searched offsets much yet, but what I'm unclear on is whether or not this is something easily compensated for. If I read correctly, it sounds like some drives have variable offsets. Doesn't seem like that would be easy to address?_________________lolgov. 'cause where we're going, you don't have civil liberties.

Trying to figure out the best way to rip CDs has always been incredibly frustrating. I use cdparanoia or EAC, and I am probably using them both sub-optimally, but I get tired even thinking about trying to figure out the right way to do it. Offsets? Lead in? Secure mode? Somebody shoot me._________________Your argument is invalid.

I get tired even thinking about trying to figure out the right way to do it. Offsets? Lead in? Secure mode? Somebody shoot me.

That's what I was thinking. I haven't had a chance to look more, but from what I can tell, secure mode is supposed to achieve most of what EAC is able to do. Offsets are drive dependent (good ones are apparently more consistent in a given model) and are used to properly read track lead in and lead out. It's what properly has the gap between songs. Or at least that is my memory from many years ago.

I'm most likely going to just set up the CD/DVD drives I have with whatever media setup I come up with and see what happens. Hopefully it is compatible._________________lolgov. 'cause where we're going, you don't have civil liberties.

To answer some of the half-stated questions rolling around in this thread: What's the deal with offsets, retries, and all this complication? Why can't you just read the data and be done with it, like one does on any *ROM device, or any hard disk?

Audio CDs were not designed for random access. They were designed for real-time streaming into a digital->analog converter. But computer disk interfaces operate on the principle of reading "sectors" of some fixed size. Getting the audio stream into sector-sized chunks is imprecise because of a lack of fine-grained addressing marks that tell the drive where it's at. Once the drive cuts off a block of audio, it is not trivial to seek and pick up where it left off.

Also, audio CDs have much less error checking and correction. A standard Audio-CD holds 74 minutes of music. Two channels, 16 bits each, sampled at 44100Hz. 2 channel * 2 bytes/sample * 44100 sample/second * 60 second / minute * 74 minute ~= 783MB total audio data. The same disk, written as a CDROM, holds only 650MB of data. The difference is the extra error-correction and sector marks present on the CDROM, that's absent from a audio disk.

So, it's not easy. Drive firmwares vary in their ability to cope with this. That's why the complications. And that's why I recommend to anyone embarking on a ripping project, to always rip to flac (or other lossless encoding). Conversion to mp3 or anything else can happen later, automatically, by script. The ripping part needs babysitting and it's not something you'll want to have to repeat. Good luck with yours!_________________"Full sentences are harder to write. They have verbs." -- Jeff Bezos, in a Fortune profile

So, it's not easy. Drive firmwares vary in their ability to cope with this. That's why the complications. And that's why I recommend to anyone embarking on a ripping project, to always rip to flac (or other lossless encoding). Conversion to mp3 or anything else can happen later, automatically, by script. The ripping part needs babysitting and it's not something you'll want to have to repeat. Good luck with yours!

Thanks. FLAC is the way I'm going this time.

I too would be curious to know what you mean by "babysitting." In my experience, it isn't playing while ripping, so it doesn't seem like I'd be able to do much* until I've listened to it afterwards?

* I've read of using some comparison against a site to ensure the process completely successfully, which even confirms correct lead-in/out, etc. Comparing a checksum of some kind against a database.

So it mainly seems like I need to verify that secure mode works on my drive and the offset can be determined. The only other significant item I've read is that most front-ends for cdparanoia don't allow offset configuration. So I guess I'm that much farther ahead than when I ripped everything to .ogg._________________lolgov. 'cause where we're going, you don't have civil liberties.

I too would be curious to know what you mean by "babysitting." In my experience, it isn't playing while ripping, so it doesn't seem like I'd be able to do much* until I've listened to it afterwards?

* I've read of using some comparison against a site to ensure the process completely successfully, which even confirms correct lead-in/out, etc. Comparing a checksum of some kind against a database.

I mean several things by "babysitting":

There's the process of cycling thru the CDs as they finish - put one in, start it, take it out, put another in and so on. Not particularly hard but I find it distracting enough it's harder to concentrate on stuff like coding, so doing it while I'm otherwise at the computer isn't a freebie. And doing it while doing regular mindless chores, I'm not always near the computer to replace it when one pops out, so that one goes slow too.

There's also the process of checksum verification. Using EAC running on wine, it'll report whether there was a match, and whether there are any errors. Best case you got a match on all tracks and you can put that CD away and go on to the next. But sometimes you'll get a "no match found, perhaps you have a different pressing?" This case is indistinguishable from a every-track-read-wrong situation, except for the number of errors reported. I'll try re-ripping those on a different computer using a different drive. If both match, I'll call it good. If not, I'll treat it as a error-disc even if no errors were reported (rarely happens).

If there are errors, it goes in the "retry" pile, using a different drive (sometimes one brand has better luck than another). If there's still errors, it goes into yet another pile for deeper investigation and recovery attempt. Maybe it's a scratched disc (try a plastic polish).

Maybe it's a older disc that's starting to come apart. There's been a few that seems to be de-laminating (a tiny bit of cyanoacrylate glue carefully applied to the edge while holding the CD together sometimes works).

And there's some that don't seem recoverable at all: puncture in the data layer, manufacturing defect, etc. I've had brand new ones throw up errors. (Those I'll take back and exchange). The rest I'll mark the tracks that contain errors with comment tags. Then I'll listen to the bad tracks. If it is noticeably bad, I'll attempt to patch that part over. Usually that involves running a linear predictive coding model a few seconds before the errors and using it to interpolate forward thru the error; and also running another linear predictive coding model in reverse starting a few seconds after the error and interpolating that one backwards thru the error; then cross-fading between the two. That's a lot of work. So more commonly those tracks go into a "for later fixup" directory.

And, finally, there's checking the tags are correct and fetching the artwork. The bigger the better (much like using flac for audio, better to start large and scale down as needed, than to wish you had it N years down the road). So I'll usually look at a place like albumartexchange first. But that site uses capthas so it's not readily scriptable (and even if it were there's often several different versions of a cover, and I'd want to pick the best anyhow).

So... there's a lot of babysitting _________________"Full sentences are harder to write. They have verbs." -- Jeff Bezos, in a Fortune profile

I didn't bother with album art last time. I may or may not this time. Well, I won't, but if it is automated, then I'll go that route.

The main thing will be the checksums. I'm pretty sure that is automated, other than the physical handling. My intent would be to go through the collection once, then fix known failures, prioritized based on how much I like the disc. Of course, listening to it all will be the biggest time consumption, but that's the point of doing it in the first place! I've actually not listened to much of my music in a long time. Need to remedy that._________________lolgov. 'cause where we're going, you don't have civil liberties.

Mr. IP lover is creating illegal copies of 1's and 0's. Quick, get me an attorney of the statist variety!_________________At the heart of the durability of mass schooling is a brilliantly designed power fragmentation system which distributes decision-making so widely among so many different warring interests that large-scale change is impossible to those without a codebook.

The MAFIAA told me that I licensed the CDs. Those assholes are now trying hard to prevent me from selling or buying used CDs. And because of some copy-protection scheme, fair use went down the shitter with the advent of DNA-sucking wikileaks-loving Hilarious Clitoris' DRM-enforcement squadron. Worldwide, thank you, USA. Don't be confused, we love you.

Oh, and the CDs are perfect, because they are digital. The MAFIAA said so, too. I also love that Digital Copy which comes with some blu-rays.

Most of the CDs I've bought over the last several years (since DRM) have been used. The market is mostly limited due to people buying fewer discs. Fair use, at least with video, hasn't been prosecuted. And since I don't share it with the world, I'm not at all worried._________________lolgov. 'cause where we're going, you don't have civil liberties.

I think your referring to AccurateRip. It's available in EAC. Turn it on, when your rip matches those of others you know it was successful.

Sounds right. I didn't realize it was only EAC. That alone might be worth trying to configure WINE.

Is AccurateRip the only important part or are there other reasons that EAC is all the rage for audio ripping?
Im asking because I just stumbeled over morituri (which apparently does support AccurateRip) and was wondering if that would be a viable alternative on linux.

I think your referring to AccurateRip. It's available in EAC. Turn it on, when your rip matches those of others you know it was successful.

Sounds right. I didn't realize it was only EAC. That alone might be worth trying to configure WINE.

Is AccurateRip the only important part or are there other reasons that EAC is all the rage for audio ripping?
Im asking because I just stumbeled over morituri (which apparently does support AccurateRip) and was wondering if that would be a viable alternative on linux.

EAC does secure ripping, it rips each song multiple times. If the hash matches, it marks it as secure and moves to the next file. With AccurateRip, if the first rip matches what's in the AccurateRip database it moves on.

I hadn't heard of morituri before, I'd always used Rubyripper in linux, which also does secure rips but without AccurateRip.

Is AccurateRip the only important part or are there other reasons that EAC is all the rage for audio ripping?
Im asking because I just stumbeled over morituri (which apparently does support AccurateRip) and was wondering if that would be a viable alternative on linux.

EAC does secure ripping, it rips each song multiple times. If the hash matches, it marks it as secure and moves to the next file. With AccurateRip, if the first rip matches what's in the AccurateRip database it moves on.

I hadn't heard of morituri before, I'd always used Rubyripper in linux, which also does secure rips but without AccurateRip.

Pretty much what Spent wrote. From what little I've read, it seems like EAC is "reliable" in that a linux solution may or may not work. The drive has to use secure mode, make sure it configures offsets, etc. As is common, a much more manual procedure. And, apparently, f you don't know what you are doing, error prone (due to misconfiguration, not necessarily jitter, etc.). The AccurateRip piece is very compelling._________________lolgov. 'cause where we're going, you don't have civil liberties.