Well I've been trying to come up with a system for ripping CDs to FLAC files in a perfect fashion but I now realize that because of many factors it isn't going to happen on any system with any configuration. Too bad, sometimes digital technology doesn't seem so digital.

At this point, I'd like to figure out the "best" way to do this, as opposed to the "perfect" way to do this. My Lite-On SHM-165H6S has an EAC offset of +6, which should be adjusted by -30 according to the corrected offset discovery. I've read that this drive does not over-read. I use Linux and I don't want to set up wine so I'll be using rubyripper.

What do you think about ripping undamaged discs with this quality drive and pretty-secure software, choosing to re-read 5 times. Should be pretty reliable right?

I wonder what offset to use. +6, -24, 0? Should the fact that my drive can't over-read affect this decision? It obviously makes very, very nearly no difference, but if I'm going to rip all of my discs this way, I may as well make the best choice.

Mainly due to the ancient red book format. File-based storage does not have the drawbacks of Audio CDs.

Don't do that! The rest of the world uses the "wrong" offsets, and so should you. Because when it comes to comparing your rip to the rip someone else did of the same pressing, you cannot compare your results, unless one of you adjusts their audio data by 30 samples.

I would do a simple burst read and compare the results to the AccurateRip database, if there's a mismatch then re-read with a secure method.

Use +6 for obvious reasons. Good luck finding a CD where there's actually anything but digital silence at the start and the end of it, because that's the only case where omitting over-reading and wrong offsets actually do real damage (as in not recoverable).

Apart from that making use of AccurateRip is one of those "best choices" you should make.

Fandango,

Yeah but I don't want to set up wine, I've got to use rubyripper. Which offset would you use in this case? With which offset would I lose the least amount of (insignificant) data? Again, it doesn't actually matter, but I may as well set it up as close to "right" as possible.

As I said most CDs have digital silence at the start and the end. So whether the offset is incorrect by 30 samples, 6 or none, is irrelevant most of the time. The CRCs may be wrong with a incosistent offsets, sure, but the tracks can easily be corrected later on, when you decide to check them against a reference CRC, i.e. AR in case a *nix tool becomes available. And also note that this correction will become superfluous once AR2 has been established. The only problem you'd have to worry is to get ahold a tool that you can use on your system (without using Wine).

And in case of CDs that do have audio at the start and the end... well in that case your drive cannot trufully copy the whole audio data. But be aware that these samples are not even taken into account for AccurateRip CRC calculation anyway. If they did, it would produce too many incosistent results with all the drives around not being able and being able to over-read.

So you gonna ask yourself how much hassle are these few samples really worth? It's not necessary to rip them in order to compare your rip with the rips of other people, and they are sure not noticable when you listen to the CD.

a less bad thread title would "ripping is lossy" or better yet "ripping offsets are arbitrary" since "lossy" does not usually mean what you are using it for.

At least it was posted to the correct forum.

I guess this is a downside to having the most popular lossless codec. I'll change the title.

EDIT: Just for reference, the title of the thread was originally "CD -> FLAC is lossy".

Really? How would that be done? I thought an incorrect offset would add or subtract data from the beginning and end of each track.



Sounds good. How will AR2 work with regards to this?



True, since you used the word "usually". Lossy means having loss. Most people mean lossy compression when they say lossy.

If I use rubyripper and the EAC/AR offset for my drive which is +6, should I be able to compare my separate FLAC files to the AR database if a tool to make that possible were written? Would the data match? I'm not sure if AR checks other parts of the CD than the tracks, such as the pre-gap or attributes which won't be included in the FLAC files.

I realize now that data will be lost from any CD rip, and audio data will be lost even with the correct offset if the CD itself has an offset. May as well resign myself to lost data and at least rip in a manner that could be compared to AR in the future (since I'm using rubyripper). Hopefully if Musicbrainz implements a similar system, they will include a method for verifying with the EAC/AR offset. I think they would.

flac allows you to decode a range. It also has the ability to write raw pcm data, so this can be done quite easily with just a simple script. I have written one for Windows, though most Win users will probably use Moitah's CUE tools which was mentioned in the link I gave you in your other thread. Writing one in Linux should be just as easy.

On this forum, the term "lossy" has a specific meaning which does not apply to offsets or accurate ripping.

What do you mean by "attributes"? AR requires that gaps be appended to the previous track, so with the exception of HTOA, yes, they are included.

Only if the samples not being ripped are non-null. Maybe it would be helpful to look at the data from a few of your discs so that you can see for yourself how significant of an issue this is for you if it even exists.

I have no idea why you would think that.

Right, like I said.


That's what I needed to know. It looks like rubyripper only handles the pre-gap if it's doing "cuesheet_singlefile":

http://code.google.com/p/rubyripper/source...ib.rb&r=163



http://www.nabble.com/Verify-data-integrit...72778s2885.html