Guide to Proper Lossless Rips
 

Copied from one place and then to another, and now it returns to its origin.

Ripping Guide

How to use Exact Audio Copy

Download EAC from here: exactaudiocopy.org

Before installing EAC you will probably want to install an ASPI layer for your computer.

If your machine has SCSI hardware, and/or built in CD burner, get the one from Adaptec here.

(Note: Although there are newer versions; I do not recommend them. They screwed up my computer; and some other people's; they might do the same to yours. The older version is more reliable.)

If you have Firewire or a USB/USB2 external burner you will want to use the ASPI from Nero (copy this file to the system32 folder on your computer or put it in the directory where you install EAC and reboot). (See attachment: winaspi32.rar)

Required EAC Settings:

Menu Action:

• Select: append gaps to previous track (default)

http://img288.imageshack.us/img288/4...caction6lc.jpg

Required EAC Options:

Extraction tab:

• Check: Fill up missing offset samples with silence
• Check: Synchronize between tracks
• Select: Error recovery quality - High
• Rest: leave unchecked

http://img288.imageshack.us/img288/6...raction2sh.jpg

General tab:

• Check: on unknown CDs, select automatically access freedb database
• Select: use English language

http://img288.imageshack.us/img288/6...general6lf.jpg

Tools tab:

• UN-Check: retrieve UPC/ISRC codes in CUE sheet generation
• Check: Use CD-Text information in CUE sheet generation
• Check: Create '.m3u' playlist on extraction
• Check: Automatically write status report after extraction
• UN-Check: Activate beginner mode, disable all advanced features

http://img288.imageshack.us/img288/7750/eactools5ux.jpg

Normalize tab:

• Do NOT use Normalize

Filename tab:

• Naming Scheme = %N - %T
• Various Artists Naming Scheme = %N - %A - %T

http://img288.imageshack.us/img288/2...ilename7go.jpg

Required Drive Options:

Extraction Method tab:

• Secure mode - NOT Paranoid, Synchronized or Burst mode!
• Check: Drive has 'Accurate Stream' feature
• Check: Drive caches audio data
• Do Not Check: Drive is capable of retrieving C2 error information

http://img288.imageshack.us/img288/3...raction5nm.jpg

Offset/Speed tab:

• Select: Use read sample offset correction or test and check your offset with this tutorial
• Do Not Check: Overread into Lead-In and Lead-Out (check only if retail CD is over 80:00 min.)
• Check: Allow speed reduction during extraction New
• Check: CD-Text Read capable drive New

http://img288.imageshack.us/img288/6...eoffset0qc.jpg

Ripping and creation of CUE sheet:

• put in CD
• ctrl-a (select all tracks)
• F4 (detect gaps)
  Important: If the first track has a gap of more than 2.00 seconds and a start time of more than 0.00 seconds, see the FAQ for how to rip this track!
• EAC, menu action, create CUE, multiple WAVs with gaps (noncompliant)
• F6 (test and copy tracks) or shift-F6 (see later, when EAC is setup to encode to FLAC)
• then click "okay" and explicitly save/create logfile

Don't forget to check the CRCs after each rip, because unlike other errors they do not generate a There were errors message (the log doesn't warn you). The Test CRC and the Read CRC should be the same.

- Encoding with FLAC [/b]
FLAC is a great lossless encoder, arguably the best. Generally what we go for when it comes to encoding wavs into lossless files is how small we can get the files, but then again how quickly they will decode when we want to play them in our favorite audio players. FLAC does both well.


Download FLAC 1.1.2 for Windows (tools only)

EAC options (F9), tab "tools" (example settings):

• Check: on extraction start external compressors queued in the background
• set number of threads to 1 (you can set it higher, but it makes no sense)
• Check: do not open external compressor window (recommended, you can leave it unchecked for debugging purposes)

http://img306.imageshack.us/img306/5...eneralc4do.jpg

EAC compression options (F11), tab "External Compression" (example settings):

• Uncheck everything on Waveform tab
• Uncheck "use offset" on Offset tab
• Uncheck everything on ID3 Tag tab
• Click tab External Compression
• Check: User external program for compression
• set Parameter passing scheme to "User Defined Encoder"
• set file extension to .flac
• indicate path to flac.exe
• set Additional commandline options to
  -5 -V -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" -T "COMMENT=EAC Flac 1.1.2 -5" %s
• Bitrate does not matter (FLAC ignores it)
• Decide whether or not you want the WAV deleted after compression
• Check: use CRC check
• Uncheck: Add ID3 tag (FLAC has own tags)
• High or low quality also does not matter for FLAC (is ignored)
• Remember to press shift-F6 (not F6) when ripping, otherwise EAC will not compress/tag!
• Also remember not to close EAC immediately after ripping, look at status bar: the last track might still be compressing

http://img306.imageshack.us/img306/9...ompress7an.jpg



Example of an EAC log from an Accurately Ripped CD
Things to note about this Exact Audio Copy log:[*]The CD drive is listed and so is the drive offset that was used during the rip. Technically you can look up this CD drive and confirm this drive offset is correct for the drive.[*]You can see most of the settings that were used in the rip.[*]You can see some of the tracks have pre-gaps; which means gaps were properly detected before the rip.[*]You can see that the test CRC and copy CRCs are identical. This could possibly be falsified if someone wanted to be an ass, but the chances of that are unlikely.

Using AccurateRip
AccurateRip may or may not necessary depending on how your'e doing your rips. If you're following this guide entirely and ripping CDs using the Test/Copy method in Secure mode, AccurateRip isn't needed. If you're not doing a Test before you Copy or using a mode besides Secure, AccurateRip is for you since you probably want to be sure that your rip is actually accurate.

I thought of writing my own guide for this but it's pretty much already been fully outlined by the help file that comes with AccurateRip and for me to say anymore would be redundant.

If you're having trouble with AccurateRip (I have in the past) check the FAQ at the bottom of this post.

You can get AccurateRip here.

Burning Guide

Making 1:1 copies
(coming soon)

Backing up as data

FNAQ (Frequently Not Asked Questions)
Q: What if the first track has a pre-gap of more than 2.00 seconds and/or a start of more than 0.00 seconds?
A: If you have the most recent version of EAC you don't have to worry about this. You can continue to read if you like.

95% of all CDs have a first-track pregap of exactly 2.00 seconds. In the rare case that they do not, 95% of these CDs have a silent pregap -- there is no audio data contained. However, it is difficult to be sure that this extra pregap time is entirely silent.

Newer versions of Exact Audio Copy account for pre-gaps of this type with a special setting in its noncompliant cuesheets (which you generate before ripping); HOWEVER, not all pre-gaps are entirely silent. That said, if you download a rip that doesn't have have the pregap ripped, there's a 99% chance that you can still burn a 1:1 copy (entirely identical to the original CD) with such a rip, but there is still a slim chance that the extra pre-gap isn't silent and that audio data was thus NOT ripped and you CAN'T burn a 1:1 copy with the rip.

That said, if you are a true audiophile and perfectionist, you should not automatically discredit the lossless-ness of a download that doesn't have the extra pregap explicitly ripped. However, if YOU are ripping a CD with a pregap of more than 2.00 seconds, you should take a few extra minutes to rip the pregap properly:

This is a specific case where the first track has been given a silent pregap. This is very common on classical CDs. On any normal CD, the first track should have a pregap of exactly 2.00 seconds. If this is off, a specific ripping procedure must take place.
Example:
http://img454.imageshack.us/img454/5...tpregap8gz.gif

• First, rip the CD as you normally would, using this guide.
• After doing that, select the first track of the CD
• Action -> Copy selected tracks index-based -> Compressed (or Uncompressed, doesn't matter in the long run)
• After the track is finished being ripped you'll end up with two separate files, one labeled "1.00 - <Trackname>" and one labeled "<1.01 - Trackname>". Delete the labeled "1.01 - <Trackname>" (this would have already been ripped if you ripped the entire CD before the pregap) and keep the other. This is the pregap track.
• Rename the file to something like "00 - Pregap" or just "Pregap"
• In EAC: Action -> Create CUE sheet -> Single WAV file. Save this CUEsheet with a different name than your Noncompliant one! People will most likely want both.

If you later want to burn this rip to make a 1:1 copy, you'll need a utility like foobar to combine all of the tracks into a single WAV file and then use the Image CUEsheet to burn it in Exact Audio Copy.

Q: AccurateRip is being buggy and shit; it's not working as it should when EAC is running.
A: First: If that ain't it... I run into this problem from time to time. Solution? Baleet AccurateRip and all associated files, then reinstall it. Arbitrarily, it malfunctions based on the timing of your installation in relation to Exact Audio Copy.

Q: But what happens if I don't... ???
A: I'm including this as part of the guide to inform you why the method to this madness is so... Well, methodical.

Why are you going through all this trouble to make a rip? Why are you getting disowned for not following these rules? Well, two issues come into play, here.

One of them is losslessness; you want to give the user everything he or she needs to burn a 1:1 copy of a CD, or as close to that as practically possible.

The second reason is verification of losslessness; sure you say you did it right, but how can anyone confirm this? How can anyone they share your stuff with confirm this?

Why append gaps to the previous track?
Because it's the most failsafe, in a nutshell.

A gap is (usually) a certain amount of digital silence. Digital silence meaning that there's nothing there for your audio player to "interpret" but the concept of "don't play anything here." A gap doesn't "belong" to any track; it exists in a realm between tracks. Of course when we are ripping, we don't want to lose any audio during the process or the concept of losslessness is a fail.

So when ripping in EAC, we append the digital silence of gaps to the track before it. If we don't care about losslessness, we don't need gaps at all. Technically, we could append the digital silence to the beginning of the track after the gap. However, let's say the gap is 10 seconds long. Imagine trying to play a a single song on your PC and you have to wait for 10 seconds to pass before you start hearing music. It's far more annoying than waiting for ten seconds to pass after the song has audibly ended anyway.

Why fill missing offset samples with silence?
There is a feature that is very rare in optical drives that is the ability to "Overread." Basically, unless you drive has this feature, you are losing the last few "frames" of audio at the end of any CD you rip! Now, you'd think this would be bad for losslessness. Thankfully, what you're missing is silent 95% of the time anyway. So you're filling the silence you didn't actually capture with silence anyway.

Why not normalize?
Some CDs are quieter than others. We've all seen this. Some CDs are louder than others. Normalization makes up for this during the ripping process. However, if you modify the actual audio of a file, then it is no longer lossless. That's why we can use ReplayGain to make up for this after we've ripped.

Read sample offset correction? Huh?
Yep. Your drive is going to either start reading a CD a few samples too late or a few samples too early. To account for this we use read sample offset correction; to force your drive to start reading earlier/later than it normally does. If we don't, we'll either end up with duplicate samples or lose some samples.

Although to be honest, a sample is very small! A sample is 1/44100 of a second; you're not really losing anything audible. If this doesn't bother you, don't be upset when you an encounter a rip with no offset correction or incorrect offset correction.

However, for the sake of losslessness, it makes sense to use offset correction when ripping your own stuff. That way, people who do and don't care will be happy with your rips.

Why should I check for gaps?
If you do not check for gaps, the worst that will happen is that it not show up in your logs. Honestly, I'm not sure why the "lossless community" insists on checking for gaps. For one, before you create a CUEsheet, the gaps will be checked (although the logs won't reflect this). Secondly, the audio you rip with gaps checked will be identical if you do not check gaps. Like I said, the worst that will happen is that the gaps will not show up in the logs.

For now, there's no reason not to check gaps. It takes only a few seconds and can be done with the press of a button. Furthermore, more people will be willing to download your rips in the future (if that matters to you).

But if you want to download a rip in which logs were not checked, you can rest assured that it is still lossless (assuming everything else was done correctly.)

I personally prefer to rip the CD as single tracks, if you have a perfect quality rip, I find no need to make a CUE image (it only adds in the gaps and other random pieces of data you won't even hear when you playback the CD, plus with an APE/CUE it dramatically increases seek times).

Is there any way to use the CUE file to indicate gaps of silence without the silence actually being appended to the end of each track?

sup eleo

EDIT: Oh, here it is:

1. Action -> [check] Leave Out Gaps
2. Action -> Create CUE Sheet -> Multiple WAV Files With Left Out Gaps

This CUESheet will insert digital silence where it belongs. Gaps are appended for losslessness sake; when the burning takes place, they don't actually stay attached to any one track, they exist in a limbo between tracks. A noncompliant CUESheet generally deals with this.

The reason people don't just rip this way anyway is because some people want to playback the audio - as it should sound on a CD - on their computer.

Why leave out the gaps ? The whole point of ripping 'lossless' is to be as accurate as possible to the original. Why screw it up by removing silence...

The reason I prefer it without gaps is because after burning it to an audio CD and playing back using a Hi-Fi stereo it seems to break the music and is really annoying for tracks that are mixed with one another. The only way I think you can burn it to a CD without having gaps is by doing a .cue file and burning it with nero, I could be wrong but I'm pretty sure that's what people go by.

I like being able to keep the data of the gaps just for the sake of "completion", but I don't care to have silence at the end of the actual files. The gaps really don't matter to me at all in terms of listening.

So, assuming I go with this method, the "perfectionist" could still use my FLAC files and CUE files to recreate lossless files with silence appended to them as if they ripped it themselves this way, correct?

The reason I don't use gaps is the fact that most CDs have two types of gaps. Two second gaps (when reading TAO CDs), or no gaps at all (in DAO mode). Since TAO CDs sound just fine being played gaplessly, it really doesn't bother me taking out the gaps. Unlike a CD-ROM rip, ripping only the tracks will not reduce quality, a complete rip would really only interest completests and those who want to perfectly duplicate a CD, nuances and all.

Just wondering, which detection method is recommended? I have EAC set to use Method B and Accurate, but all CDs show up with 2 seconds gaps regardless of which setting I have used, Accurate or Inaccurate, Method A, B or C. I guess there's always secure detection... :)

I'm actually not sure. I personally use Accurate, Method A, but since I've never seen gaps get incorrectly detected with any given method, I'm unsure.

Accurate does the trick, apparently as per the Pedro Guide... I know some detection methods are simply slower on my drives...

IIRC, I had read somewhere that A works best for the newer drives, and C is better for the older ones. With B in the middle...

Guess I'll try Method A next time around.
EDIT: Yeah, it works the best on my PC...

I'm sort of curious, is there any way to use EAC to extract the audio tracks, while letting Alcohol 120% extract the data in a Game CD? More important, whould this still guarentee a perfect rip on both sides?

I can't say for sure. I know how to deal with ripping audio and data separately, but putting them together for a 1:1 copy? I wouldn't even know how to verify the overall losslessness.

You can try ripping the audio from EAC and just copying the data files manually.

The reason I asked this question is because when I try ripping audio tracks (along with data tracks) from Alcohol 120%, the resulting image has the audio start two seconds into the track. Quite annoying for a "1:1" copy!

I'm not sure what you mean; but I believe this is normal. There is a 2-second pregap before the first track of any audio CD (sometimes longer).

Are you playing this CD on a standalone CD player or on your PC?

Here's what I mean: when I mount the file to Daemon tools (and play the game), the file will start two seconds ahead of the begining, so when the file should start playing at 0m0s it starts playing at 0m2s, cutting off the first two seconds of the song, but I do believe this only occurs in CDs that have data tracks and have gaps in them. When I use Daemon tools to mount an Audio CD that EAC ripped, the CD music plays back just fine (but keep in mind EAC doesn't rip the data tracks).

BTW, was wondering if you guys have a recommended program for burning the FLAC+CUEs? Using Nero currently, but hear it's not the best...

I do believe foobar2000 (version 0.8.3, it links to Nero to burn the CD) can do this, though I've never tried using any burning features of foobar2000.

I own the full version of Nero, just wondering if there's a better program... ;)

Exact Audio Copy is ideal since only it and another program, Burrrn, can read noncompliant cuesheets.

Exact Audio Copy also allows the use of a write offset correction. (Just like your drive reads too early or too late, it writes too early or too late also.) Burrrn does not.

Basically, if you want 1:1 copies, you have to use EAC.

Convert the file to a WAV + CUE and use Exact Audio Copy. It supports programs like write offset correction and is one of the few programs that can make a perfect copy of a CD to another CD (with the right CD Burner of course).
EDIT: Damn! Caught me to the chase! But if EAC can't read the flac file, convert the FLAC to wav, then change all references to ".flac" in the CUE file to ".wav". Of course do this with a copy of the CUE sheet, in case you screw things up and make sure the wav file had the same filename as the flac file did.

Thanks guys, though the CUE was originally made using the WAVs to begin with. So, that's not an issue...

Anyway, what's up with EAC's noncompliant cuesheets? Also, is there a reason we use them in following the above guide? What, are they better than standard CUEs? :D

Anyway, I am assuming it's in regard to ripping the tracks separately! ;)

Additional Post:

Quick question though, what about the "Copy OK" notice in the log? Will the exported log show that the copy isn't OK if they don't match up? Just wondering, since it always seems to take forever to manually go through and double check both CRC's lines. If all I have to do is check to see if it say OK, all that much the better... :D

If they fail to match up, it will say copy finished or something similar, but it will not say OK

Good to know! It takes me on average about 5-30 minutes going through each of the logs, depending on the amout of tracks and the amount of discs for each rip...

Isn't there a way to just hook up the Console to your p.c., and then use a audio ripper/sound recorder program to grab the sound you want? Obivously this would not work for every track, and obviosuly you would need some kind of an adaptor to make it work (I.E. all I have is the Red, White and Yellow wires - basic scart lead)

Sure. You need a "Stereo RCA to 3.5mm (or 1/8") Y-cable".

Make sure the RCA ends are female and the 3.5mm end is male.

Plug the audio leads from the console to the RCA ends of the cable. Plug the 3.5mm (1/8") end of the cable into your computer's soundcard's "line-in" or "aux" jack.

This conversation is COMPLETELY off-topic and should be moved to an appropriate thread... I don't mean to be moderating things here... but stop crapping Eleo's thread.

I'm just answering the question. Sure, splitting the thread sounds like a good idea.

For those who want to know, I found a program that does exactly what I asked for! It rips the data and audio tracks perfectly (if your CD-ROM drive supports good DAE), it's CDRWin (which you need to buy/crack to get any good use out of it). If your game CD is single session (aka the game data is track one, not the first audio track), this will be the program of choice, it rips the CD to BIN/CUE. It does not rip copy protected CDs well though (though most games with CD tracks are too old to have a good form of copy protection), Discjuggler and Alcohol 120% are much better suited for that purpose.
It's the most 'proper' way to rip Data + Audio CDs.

I've heard of that tool; I haven't used it in years. I don't know for sure if ripping audio as data yields a 1:1 copy. Would you mind doing a wav comparison to that audio ripped from the CD with EAC and then the audio ripped from EAC from the burned iso generated by CDRWin?

EAC has a wav comparison tool, if you didn't already know.

I did with two CDs, it yielded perfect copies (albeit I needed to use offset correction on the CD image, but I have to do that on the real CD as well). I assume this only works well on CDs in acceptable condition, I don't know if CDRWin will read damaged CDDA tracks very well.

BTW: CDRWin made a BIN/CUE CD image in the case where I used it. ISO images can only store one track/session of data or audio. But considering BIN/CUE files are greatly superior to ISOs (but not the end all format unfourtunately) and are supported in a vast number of programs such as daemon tools, I don't see any reason to use ISO over a BIN/CUE image; except if you want to convert the audio tracks to mp3 and have an ISO+Mp3.

Can your burn BIN/CUEs with EAC? Because I don't know any other software the supports write offset correction.

EAC can only burn Audio CUEs, you'd have to use some other program to burn the whole CD to a CD-R. Of course if you want to useit as an Audio CD, just extract the tracks with EAC (with the image mounted in daemon tools) and you'll get a copy of the audio. Otheriwise, settle for a non-offset corrected CD or just make a backup of the image.
Too bad EAC can't extract/burn data tracks...

Yeah that sucks. On the other hand it is pretty much perfect in every other regard.

In fact if you supplied the offset your CD-ROM uses, other people could make perfect rips, no need to make a crappy ISO and a separate WAV+CUE rip. It certainly makes more sense to me (although you can't use FLAC or MAC on a BIN/CUE, but WinRAR or 7-Zip does the job just fine).
I wish daemon-tools supported compressed CD Images.

Okay, I just ripped my first pre-gapped CD. Hadn't been thinking to look before, but anyway, I have a few questions:

I uploaded a few misc. files in a zip, the cues and log, just wanting to make sure this is the way they should look. And two, is it recommended to make both a non-compliant and Image CUE, regardless if there are pregaps? Thinking it might be useful to some at least and noticed Eleo's rips I have checked out have both, one of which didn't list it as having a pregap. So, figured I should ask...

Lastly, the FAQ lists as doing the pregap as compressed. Was wondering, wouldn't it be better to have it uncompressed like the rest of the rip? EAC on my end has both the pregap as WAV and MP3 by the time it's done. So, was wondering which of the two, or both, need to be kept with the rip? :)

In any case, thanks all! :kitsune:

EDIT: Nevermind the part about using Compressed or Uncompressed. Was using the guide at the GFF tracker which lists just using compressed, while here it says you can use either...

That said, any other info would be welcome. :)

No. What is this nonsense about data? EAC is an AUDIO rip/burn program, not a general rip/burn program.

I'd say it would be nice it it could burn audio-CD's from FLAC+CUE or MP3+CUE - but burning data CD's just isn't what EAC is made for.

Yes, but in the process of making 1:1 copies of CDs, burning Audio + Data is sometimes necessary.

Plus, if you want to perfectly preserve a game CD, copying the audio and data sectors seems awfully redundant.
EDIT: Waht I think should be done is have CDRWin, Alcohol 120%, Discjuggler, etc support forced rereads of RAW data and offset correction. This would make it very close to EAC quality copies (plus CD-ROM drives with sub-par DAE would get better copies in these programs, since they do an equivalent to burst mode in EAC).

Yeah, that would probably be best. I'm surprised if such a read mode (secure raw w/ offset correction) doesn't already exist... ?

Most likely because most CDDA games don't factor the audio into copy protection. In fact most CDs that have CDDA tracks don't have very strong copy protection (most games released in the past six years don't even use CDDA anymore, it takes up too much space). Since data CDs as a primary mode of optical disc distribution is declining due to DVDs, I don't see anyone doing this anytime soon.

Here's a quick question...

I have been using "Installed external ASPI interface" on my rips under the "Use of SCSI interface" option, since I heard it makes for better quality. However, my external DVD burner seems to only show up in EAC with "Native Win32 interface for Win NT/2000/XP" selected. Any idea why, and is there anything I can do to change that? Hell, is there really any difference between the two? If not, I'll make the switch back to the other so all three drives are listed. ;)

Overall, I can't say I care too much, only using it for ripping hybrid SACDs. None of the others in my experience can see such discs when one is in the drive.

BTW, any idea how one can find what the write offset is? That read offset database you linked to is of great help, is there one for the write offset as well?

I find that copying and pasting the WNASPI32.DLL to the EAC directory solves this problem, DAEMON Tools has a tendancy to mess with things. But unless you are having problems with the native CD interface, there's no need to switch, I've never had any problems while not using ASPI.
As for determining write offset, just follow this guide. If you can't enter the combined read/write offset in EAC (because you're using AccurateRip), move the AccurateRip.dll to another folder, enter the combined read/write offset correction and move the dll back.
Further reading on offsets:
http://users.pandora.be/satcp/eacoffsets00.htm#- Very in depth information on offsets
http://users.pandora.be/satcp/eacoffsets02.htm#- How to find the read offset
http://users.pandora.be/satcp/eacoffsets03.htm#- How to find the write offset and combined read/write offset (same as the link listed above).

Sorry for the late response. Actually there's a guide on it here. It takes some time but it's not terribly difficult.

Actually my post addressed the exact same article, but all is good, it just tells sabbey how good a source it is :).

Quick question.

Ok, how come a track that I ripped a couple of weeks ago worked fine then, but suddenly now refuses to work and is corrupt? I don't get that. And is there a way to fix this or do i have to rip it all over again?

I get this error:

FLAC__FILE_DECODER_SEEKABLE_STREAM_DECODER_ERROR

Any thoughts on this?

I don't know, can you decode it to wav, with official flac or third-party tools?

flac -> wav doesn't work either. When i initially did the rip i used flac frontend to encode, so i tried to decode with it to and still nothing.

Provided you haven't done anything to the file since you last successfully played it, the file could be corrupt. It happens for various reasons and most of them would be enough to worry about. Have any other files that depend on redundancy checking (like Zip or RAR files) produced similar errors recently?

Well, the only thing i have done to the file is move it from one HDD to another. From SATA to PATA.

Now i have read somewhere else that this sort of thing could be hardware related, something like bad transfer between HDD's, something wrong with the mobo, bad drivers, overclocking, bad sectors on HDD's etc etc, but i am really not sure.

When it comes to .rar files, i ocasionally have CRC errors. No, wait, scratch that. Recently, a lot of CRC errors. Maybe there is a connection. Im not really good with these sorts of things.

There has to be, if you get frequent CRC errors and the like, somewhere down the line data corruption is occuring. I'd suggest making some RARs and transferring them to see if a faulty connection (or HDD) is the problem. Trust me, from what I've heard so far, corrupted FLAC files is the least of your worries. Try to figure out if it's the PATA or SATA HDD (or the connection between the two), then you can find out what to do next.

Well i dont know what to make of this. I tried compressing an album that was in wav and cuting/pasting it from HDD to HDD to check if some CRC error poped up. There were no errors.

Then i compressed an album that was in flac, did the same thing, cuting/pasting it from HDD to HDD. The first transfer got me a CRC error right away.

I don't know what to do next, maybe checking the HDD's with some scanning program? What are some good HDD scanning programs?

Please elaborate. Is it that bad?

WAV files have no CRC information whatsoever. Meaning if one or 99% of the file is corrupted, you won't know (unless the header is bad as well).
With RARs and FLAC files you can tell if file corruption has happened (the non-malicious kind at least), but with WAVs and files that have little or no error checking (and critical system files). It seems either the new HDD is bad or the transfer sucks. In either case it's worthy of concern. Try making files (not just transferring them) on the SATA HDD and see what happens when you cut and paste it to a new folder, hopefully it should be fine; if not, your hard drive could be bad.

BTW: WAV files only report a bad CRC when Windows detects an error from the source disk (like from a stratched CD or bad floppy).

Okey, here is what i have done:

1. Compressed a flac album into one .rar file using winrar.

2. Move that file around old folders/new folders/different HDD's (I have 3 in this case) and tried to unpack and test it if its got any CRC errors.

3. The result: nothing, no CRC's errors whatsoever. My guess is that this thing happens randomly because i can't seem to find any pattern here. Sometimes it gets an error, sometimes it don't.

But why are errors such a big problem with flac files opposed to say mp3 files?

And a little humor to close off this post:

As i type this i see that my google ads read:

1. Corrupt File?
Free Registry scan, fix errors and improve PC performance. Try it now

2. Fix Corrupt Files Fast
All Corrupt Files Fixed Instantly Free Scan, Repair 100% Guaranteed

I thought it was kind of funny :)

being lossless, FLAC files depend on perfect (or very near perfect) file integrity for decoding, mp3 files have very good fault tolerance to corruption (due to their nature to be streamed), they just skip ahead to the next decodable frame.

What I do to guard my FLAC files against corruption is I use a program called QuickPar to make PAR2 recovery files for the FLACs. Then I burn the FLACs, the recovery files and a QuickPar installer all together to a DVD.

I have QuickPar set up to make its recovery files 20% of the size of the original data. Probably overkill... I think the default is 10%.

I use SFVs to keep check on my FLACs and keep more than just a single DVD back-up, but also all of my music is on two EXT HDDs that are only used for storing the music...

They are also read-only access! ;)

I don't get why people use simple checksum tools for their own data. If you find corrupt files, what can you do but re-rip or re-download them? Seems kind of pointless to me.

I'd rather sacrifice some storage space to be able to actually recover corrupted files.

Have you tested the robustness of QuickPar? I'd like to see how much you can corrupt a file before it becomes unreadable.

I used to make par2 files when I backed up music to guard from inevitable CRC errors. But then I realized I was killing my self trying to make them; very time/space consuming. I just gave up. I probably *should* do it for rarer things but for just downloads in general, it's just too much effort.

Doesn't sound too much of a waste of space to me. 10% backup of 4GB of files is 409.6MB.

Still takes a great deal of time to deal with.

Maybe if their was a tool that allowed me to drag and drop several folders and just make par2 files and move them somewhere. Then I could just go ahead and make par2 files for all the stuff I've already backed up and future stuff as well.

But I instead always have to drag/drop chunks of flac files, logs and cues, artwork, etc. Then there's sometimes multiple discs and such; subdirectories. I just got done backing up 200GB worth of lossless and grew tired after making par2 files for the 20th DVD or so. I thought, forget it, if some stuff get's CRC errors on it then so be it. Maybe I'll make par2 files later for rarer stuff (presumably VGM since 99% of the lossless music community doesn't have or share any.)

To help myself I've bought more reliable (expensive) media; as I have most generally gotten CRC errors on cheaper, more generic media. Ideally I'd get some Taiyo Yuden discs, but right now I am using Ritek/Ridata and Verbatim.

EDIT: Also let's not forget that DVDs have a certain amount of error correction native to their design.

Anyone have a Philips DVD+-RW (DVD8801) drive? That's one of the drives that my new PC came with, but don't see it listed at the offset site. The other drive a LG DVD-ROM (GDR-8164B) is listed though...

BTW, any ideas if these are decent drives? ;)

You might have to detect the read offset in a more manual way.

You can do this by ripping a WAV with your LG drive using its correct read offset. Then, rip the same track with your Philips drive, configured with no offset, to WAV. Then you can use EAC's WAV comparison (Tools > Compare WAVs) to see if there are missing or duplicate samples between them.

I believe if there are duplicate samples then your Philips drive would be reading too early; you want to take the number of sample differences and create a positive offset from that. If there are missing samples then your drive is reading too late, you want to take the difference in samples and create a negative offset from that.

Or it might actually be vice-versa of what I said (positive for missing samples, negative for dupe samples). Keep playing around with it until WAVs ripped from both drives are identical (ie no difference in samples).

Will give it a try I guess. Thanks... ;)

If you have the right CDs, you can find the read offset by using AccurateRip. If you CD-ROM is in the database, it'll automatically set the offset, if not you'll need three CDs on the offset list (which is over 20,000; compared to the 100ish that EAC uses internally).

Oh, I thought it was a no-go with AccurateRip unless your drive was in the database. Finding 3 CDs can be a bitch, though, as there are different pressings of certain CDs, so even though it says Nirvana - In Utero will work, your copy of it might not work and can't be used for detection.

Thanks for the help guys! It ended up being the same offset that they use on their other DVD-RW drives though. Tested both using the offset and not doing so, it worked, so... :)

Hopefully, I'll find the write offset soon enough!

Okay, that's believable.

It's a pain, but borrow someone else's CD collection to do so (like I did). It'd be stupid for those Drives not in the database to have no chance to work with AccurateRip. It's nice that AccurateRip isn't a one trick pony isn't it?

AccurateRip is a godsend.

Without it I would have never known I was using the wrong offset on my drive.

I guess I have the wrong pressing of Radiohead - OK Computer, because that's what EAC used with its internal database to determine my drive's offset. Using that, it told me my offset was something like +1092, and I believed it.

Turns out it's more like +98.

Anyone using the latest version of EAC? Having a slight issue... :(

http://www.gamingforce.com/forums/os...-beta-4-a.html

A tip for people who are having problems with Japanese tracklists from freedb that show up as a string of question marks in EAC, even when you've set the language for non-Unicode programs to Japanese in Windows regional & language options.

Change your freedb server to the following:
http://freedbtest.dyndns.org:80/~cddb/cddb.cgi

If anyone has the time, would they be able to verify something for me?

I just want to make sure I have the right offset correction for my CD drive. My drive is a "JLMS XJ-HD166S"

I searched it on Google, and came up with this:
http://club.cdfreaks.com/showthread.php?t=67103

Right now I'm using +12 offset correction, which was posted inside the thread in the link above. I have yet to test an actual CD rip though.

Double Post:
Okay, here's a print screen of my results:
http://i2.photobucket.com/albums/y21...lle/offset.jpg


I ripped the first track from a CD, and I did this twice. The first time is WITHOUT offset correction, and the second time is WITH offset correction.

Double Post:
Two last questions...


Do I need to burn a WAV to a CD-RW in order to test the offset correction, or have I already done that above?

And, the start point of the first track on the CD I test-ripped is "0:00:00.00". Does everything seem good?

Your WAV compare would say "12 missing samples" whether you had the right offset or not. All it means is that one WAV is 12 samples offset from the other. ;)

I'd say that CDFreaks is pretty reliable but not 100%.

Probably the best thing for you to do would be to get AccurateRip. AccurateRip checks your drive's offset based off of a scan of one of many known CD's, and then checks it against a database to determine your drive's offset.

Then, everytime you rip a CD, it will compare the checksums against a database to be sure that each track was ripped accurately.

The problem is, I barely have any CDs that are in AccurateRip's database. I tested most of them and they all give me an error message, stating that "This CD is not in AccurateRip's database. Please insert a different Key Disc." =/

Eleo's guide says that if I'm following it exactly as it states, then I don't need AR. Which I'm doing.

Sup Eleo? This is one of my logs from ripping. I noticed unlike your log, it doesn't have "Track quality: xx%" anywhere. Your version appears a little outdated but is there a possible solution to this that I've glanced over?

Great guide, btw.

Elixir, you used Burst mode.

Also, Blue_Kirby, AccurateRip has two functions. One is to find your drive offset. It's other function is to compare your rips to the results of other people who have ripped the CD to see if your rips match.

If you're using Test/Copy when you rip your CDs, and the CRCs are identical, AND you have the right offset for your drive, AND there are no errors during the ripping process, the chances that your rip are incorrect are very, very slim. Your drive is essentially attempting to rip the same data twice and getting the exact same results each time, which is a good thing; it means that it's most likely doing it correctly.

If you're not using a secure ripping method or not using Test/Copy, there's no way to really verify that your rip is accurate just by looking at the logs. That's when AccurateRip comes in; it checks your results against other people's results and tells you if your results match up or not.

AccurateRip isn't always perfect for a lot of reasons, BUT it will never tell your that you ripped something correctly when you didn't. But it MIGHT imply your rip is not correct when it is. This is because a lot of CDs have multiple pressings, so the results in the AccurateRip database might be from a different pressing of the exact same album you have. A different pressing of the same CD causes a slight difference in the data.

I am always using Test/Copy, and so far none of the CDs I've ripped (using this guide - I ripped two more CDs last night) are causing problems. Thanks for the tips.

Alright, I've just ripped again with Burst off.

The bitrates are identical, however, so I can assume that the songs are also?

Bitrates don't matter if you're working with FLAC. FLAC has its own bitrate, so EAC doesn't care what bitrate setting you use when ripping CDs.

Okay. So is the difference between a ripped OST using Burst, and a ripped OST without Burst of any significance? I really don't want to tag and rename a 2 disc OST if it isn't necessary.

You'll have to ask Eleo regarding that. I've never ripped using Burst mode, and I don't know what that is.

Sorry I couldn't be of help on that though.

I don't think you mean bitrates, I think you mean CRCs from the logs, right?

A CD ripped with Burst mode isn't always secure. I would recommend you rerip whatever you have ripped.

No, I mean bitrates. They're identical so I just assumed that they were alike.

I guess I'll rerip them without using burst, but I really don't see any difference.

The option's really just there because sometimes the ripping process fails to activate in one mode or the other.

Another pregap question here! Are CUE files supposed to be off in comparison to the listing in EAC and the LOG? Take a look below to see what I am talking about, though for some reason the CUE listing for the gap isn't the same as is listed in the LOG. This is an issue on all my rips! Call me confused... :tpg:

Well every audio CD has a gap of two seconds (I think; there may be some exceptions, I don't know); it's normal for the CUEsheet to exclude the first two seconds from its pregap flag because it's assumed they exist.

Then you have to take into account that EAC is measuring in seconds when time on a CD is generally measured in frames. It is my understanding that frames are the "correct" unit of measurement for time on a CD.

I believe EAC natively displays time in hundredths of a second (you can change this option in Options -> General tab), which is more precise than necessary, because there are only 75 frames in a second on a CD. So in your log you have 2.44 seconds. In your cue, those 2 seconds are ignored, leaving you with 44 hundredths of a second; which is equal to 33 frames. (100/75 = 44/33). Similarly, 64 hundredths of a second equal to 48 frames, and so on. You can do the conversions for yourself.

Bottom line, just ignore it :)

Double Post:
Thinking about it, your question would make a good addition to the FAQ.

How do i tell if a rip is accurate or not without having the original myself? I ask because someone ripped the DMC3 OST in flac and i want to up that to the tracker but sabbey asked if it was accurate.

You won't be able to compare it unless you have some documentation on the original to compare it to, sorry.

The tracker now has "Non-proper" torrent catagories for just this purpose.

Assuming it has a CUE and LOG, that should be fine as in regards to if it's proper, right?

BTW, thanks Eleo for the pregap info. Was scratching my head over that one! ;)

Yes there is a cue file with the rip BUT the filenames in the cue file are in anothe language which would make things more complicated since I had to retag all 104 tracks.

Okey, so I want to rip this CD that I have. The format is .oma or .omg, meaning that it's some sony stuff. EAC can't handle it, gives me sync errors everytime I try. So I read that dbpowerAMP can rip it.

My question being this:
Are there any differences between EAC and dbpowerAMP? Will it still be lossless when I rip it? Will it still be the same quality as any standard EAC rip?

.oma and .omg are containers for Sony's ATRAC format, which is lossy (and lousy, at that). You got shafted.

But it's an original CD, not some junk I downloaded from the net. And it's the official release of that CD, not a bootleg. How can an original CD be lossy? I'm confused.

It's probably just their crappy idea of copy-protection. Seems most now give lossy versions of the music on such protected CDs when used on a PC rather than a standard CD player. Not that it will always work either though... :rolleyes:

If you want CD quality I'd recommend either finding another version of the CD if it's mainstream (Since there's a slim chance not all versions of the CD around the globe are protected) or a way to burn it and send Sony a message, by demanding a full refund either way. Which CD is it BTW, maybe there's another issue at work?

Most CDs I've come across nowadays in the stores have two prints - one of them being a double-sided disc (one side with the music, the other side with DVD content), and another print with the music only. The print with the DVD content usually comes in these weird cases. I tried to rip one of those a long time ago but it failed since it was copy-protected. As far as I remember the CD prints with the music only didn't have copy-protection.

I don't know how Canada prints their music compared to the US, though.

Oh, okay, so then what you're looking at is the second session (a data session) as this is a "CD Extra" rather than a plain audio-CD.

Exact Audio Copy will handle it just fine if your CD-ROM drive is any good.

Is it still lossy? Cause if it is there is no point in trying to rip it, because I want it lossless.

I have a NEC DVD RW 3550A. I tried ripping it, but it gave me a bunch of sync errors. I tried it with the standard EAC lossless ripping setup (Eleo's guide). Maybe I need to change some settings?

And here is a link to the CD.

http://www.cdon.com/main.phtml?navroot=904&session=1

Duran Duran - Astronaut (CD+DVD)

Oh okay! I have that CD and it ripped fine. Didn't buy the (Limited Edition ~ CD+DVD) set though, just the regular music only release since those extra DVDs don't usually do anything for me...

No, the actual part that plays if you put it into a stereo (which is the part that EAC rips) is not lossy. But the crap that you see when you browse the contents of the CD on your computer is lossy. They are two separate things.

Either way, the point I was making is you might want to see if it's just an issue on your copy or with that particular release...

Regardless, you have some options!

Okey, apparently my DVD-ROM wasn't good enough (NEC DVD_RW ND-3550).
So I bought a new one (PLEXTOR - DVDR PX-760SA). Works like a charm.

Now on to another question. The driveoffset list on accuraterip.com only lists the ATA version of the plextor drive. I have the SATA version. Does this affect the drive offset or is the same one in both cases?

It might.

Just check the offset for yourself with a disc which is in their disc database. As long as you have a few legit CD's you shouldn't have a problem finding one that's in their database.