Duplicating audio CDs

I use Plextor drives (REAL Plextor drives) in combination with EAC (Exact Audio Copy) when I want to duplicate an audio CD for use in the car, or to give to my daughter to listen to, so I don’t lose the original due to lack of care or theft (yes, I own the original CD).

The procedure I’ve come up with, and which seems to work and provide me with EXACT copies of the tracks is as follows:

1. Load the CD into the drive and use the FreeDB to pull down the disc information (Artist, title, track titles, etc.)
2. Once I verify the titles are accurate, I select all tracks and select “Test selected tracks (F8)”. Now I have the reference CRC value for the tracks from the original disc stored in the DB
3. If all tracks tested successfully, I now click the image button on the left to create a CUE sheet and read the tracks into one wav file. When this completes, I save the log.
4. I repeat step 3, again saving the log.
5. I open the log, and compare the CRC values. If they are identical, I know I have a good image and proceed to the next step.
6. Usually I will edit the CUE sheet, removing pregaps and DCP entries. I find that removing these entries allows EAC to recognize the copy as the original disc.
7. I remove the original CD, and place a blank CD-r into the drive, then click the button on the bottom left to write the image, and select the CUE sheet created in step 3, above.
8. Once the copy is written and completed, I verify that the disc is recognized as the original (the tested CRC values obtained in step 2 above should be displayed in EAC)
9. Now I select all tracks, and copy them (either compressed if I want them on my iRiver, or uncompressed if just verifying the copied disc). So long as the read CRC value in EAC matches the test CRC value, I feel that I have the tracks copied accurately.

One thorn in my side using this method is that sometimes the last track will produce a different CRC value. I believe I have finally discovered the reason for this, which from what I understand is due to the inability of EAC to overwrite the final few samples of that last track (see these links for some details: http://www.hydrogenaudio.org/forums/...hp/t34846.html & http://www.hydrogenaudio.org/forums/...dpost&p=308548).

Is there any software out there that not only takes into account the read & write offset values, but also allows the overwriting feature to be used so that the last track matches the original? Does it really matter? Are these last few samples inaudible anyway?

I'd sure feel much more convinced of the copy quality if ALL tracks matched CRC values from the original to the duplicate discs.

That sounds a very convoluted proceedure which shouldn't be necessary with a drive that can properly report errors during audio extraction like most Plextors can. You should be able to trust EAC to do things correctly without all the intermediate checking that you are currently doing.

In my opinion the last few samples can usually be safely ignored although I know that there are others here with different views.

If you ever get fed up with your method, try downloading Plextools XL and do a straight disc to disc copy. Plextools will allow you to automatically verify the copy against the original and it also understands offsets.

Cheers

James.

Plextools also drops off the last samples of the last track, thus resulting in a changed track as compared to the original (different CRC values).

You sound a lot like me, once upon a time.
Except the world isn't anymore ready for my children than I am, so I'm sparing everyone the agony.

You should be checking for any possible CD-Text, and you should be saving out a CUEsheet based on the untouched CD-Text, before you try to get the album organized in a manner more to your liking, then you should review the CUEsheet in Notepad to eliminate any "Unknown Artist" or "Unknown Title" entries. If the original disc has no CD-Text, then it is your duty as an exact-copier to make sure your CUEsheet includes absolutely no PERFORMER or TITLE entries.

I never do Test without doing Copy in the same process. This way you will get two CRCs per-rip for each track instead of just one, because in my experiences with an extremely small percentage of original discs, the CRCs won't always match from securely reading the same disc twice.

Also, depending upon your EAC settings, you can get unreliable CRCs if you don't fill up missing offset samples with silence, or if null samples are not applied in CRC calculations.
Unless you are dealing with an album which features a hidden first track, Image+CUE isn't anymore capable of burning exact copies than track-split WAVs with a "noncompliant" CUE (unless your track-split WAVs are scattered throughout your HDD sectors and you are trying to burn very fast with little or no buffer). While there are some unique advantages to Image+CUE, I think a lot of people are embracing that setup for the wrong reasons or the wrong scenarios. I've successfully duplicated dozens of albums with split WAVs and noncompliant CUEs. You should be consolidating the time you spend on your Test read with the time you spend on your Image read - into a Test & Copy, so that both reads can be more credible together than they ever could be separately. Or, if you don't think you need two (almost always matching) CRCs per-track per-disc, then you should always just be doing Copy for purposes of comparing old rips with new rips.

If you insist on ripping or hoarding Image+CUE, you can rip one Image+CUE of the original, one Image+CUE of the copy, with no Testing, then compare logs. If the Image WAVs don't match, it is more than likely because of the final tracks. At that point you can use foobar2000 or CUE Tools to save out individual track WAVs from each Image, then use dBpowerAMP to generate EAC-style CRCs of each individual track WAV. If one track doesn't match (usually the last one), you will know which one, and you only had to read the CD twice instead of 3 or 4 times. There are quicker or more automated means of verifying secure copies, but I'll talk more about that later.
First of all, logs aren't the fastest or most automated means to compare multiple rips that you yourself have done on the same day. If the artist names and titles in your music collection don't involve a lot of "special" characters, then you should try a program called hkSFV. It's not specifically designed for comparing audio rips, but it's extremely handy for that because it's automated, and because it doesn't care what the track files are named. You use EAC to just plain old "Copy" the original album (this gives you track-split WAVs). You save a ".md5" file from scanning your first rip of track-split WAVs with hkSFV, then you copy or move that MD5 file to the location of your second EAC "Copy" (more track-split WAVs), launch the MD5, and a few seconds later you know which tracks are a match. This isn't database-dependent cross-checking because everything hkSFV needs to know is inside the MD5 file, so the computer which tests the burn doesn't necessarily have to be the same computer which did the burning or the first ripping. It doesn't matter if or how EAC on the testing computer recognizes the disc (whether it's the same computer or a different computer), and you won't have to freedb or in any other way inform EAC of anything about the disc, and you won't have to humanly review the before-and-after EAC logs.

Second of all, I wasn't aware that logs of an image-style rip included the CRC(s) of anything other than the overall album, unless this is a newer feature of EAC (I'm still using an older version due to many of my CDs being copy-protected). I was under the impression you only got CRCs of individual tracks if you were reading individual tracks.
There's one main reason why an "exact" copy wouldn't be recognized by EAC as the original, and that's when the original CD has a data track of some kind, while the copy isn't including this data track and completely throws off EAC's perception of the disc. In an effort to avoid this problem, I suggest installing PlexTools, and enabling Single Session on your drive. This way EAC will perceive the original and the copy with exactly the same track layout, plus the CUEsheet you will generate, won't have any mentioning of a data track.

As for your other CUEsheet editing, now you're talking about a copy that might match the audio data of the original, but won't match with the metadata. The only miscellaneous information I will consistently remove from a CUEsheet, are bogus ISRC codes (all zeros), because Exact Audio Copy will reject such CUEsheets when you try to burn off of one. I'll remove pre-gap information if I'm creating a custom compilation, otherwise if it was on an official disc, then I leave it in any CUEsheet based on that disc.
As per my response to #3, image-style rips are not the only rips you can burn exact copies off of, so if that's primarily why you think you're doing Image+CUE, then I would drop that part of your routine real quick.
In the context of an optimized duplication/testing routine, it is irrelevant if or how EAC initially recognizes the disc, because you should not be relying on EAC's database. It's not a bad database for casual operations, but once you start getting more industrial about ripping/archiving/burning/testing, you're going to wish you could alias your CDDB.DAT file between multiple instances of EAC with their own separate folders and ENCQUEUE.DATs, but if you're a pure Windows guy then that's not going to happen. I've abandoned EAC's database for those reasons and mainly because even if I become a Linux guy (I'm gradually getting there), I often want Kanji (non-ANSI) characters that EAC doesn't support. Why would I want a database full of "???" entries? If I re-rip such an album, I would have to organize it outside of EAC all over again. Now in recent months I have my own engineered setup to avoid re-organizing anything I might ever have to re-rip, but that kind of discussion belongs in a different thread entirely.

Here's how EAC Tests should be prioritized:
You get two CRCs per track from Test & Copying the same physical disc.
Are the two CRCs a match?
If so, then this is definitely a safe rip for you to burn with. If not, then try Test & Copying the same disc with a different drive.
Once you have two matching CRCs of the same track on the same disc, neither one of these CRCs are more important or hoard-worthy than the other. What matters is that they came from the same physical disc, and they match.
Once you burn a copy and eventually begin ripping the copy, you don't compare the CRC of the new track to specifically the "Test" CRC of the old track, because the original Test CRC is a second opinion of the original track - it's not a second opinion of the new track. If first and second opinions about the same medical patient don't necessarily match, you should not be comparing either of those "discoveries" to a new patient with similar symptoms, until you have multiple opinions about the old patient which match. It is technically possible for you to have an old Test CRC that doesn't match what the old Copy CRC would have been, therefore old "Test" CRCs should be part of an old consensus before you compare them to anything new, and then what you are comparing is the old consensus to the new rip, instead of comparing specifically the old "Test" CRC to the new "Copy" CRC. This is another reason why you shouldn't rely on your EAC database.

If Test CRCs are worth anything (a highly debatable topic), then I don't think you should be relying on old Test CRCs alone (if any Test CRCs). Now admittedly it's not as important to "Test" a CD-R you just burnt, because let's say you did a single-scan "Copy" of the CD-R, and one of the Copied tracks from the CD-R doesn't match its parent track from the original CD. The results I "might have" seen from a Test & Copy of the CD-R don't seem very relevant to me because any fresh CD-R with middle tracks that don't match the original CD in one scan or the only scan - wasn't a very good burn and you should probably re-burn and retest (with a different drive, different burning speed, or different type of CD-R), while it can't be helped if an original CD takes many scans for you to make sense out of it.

It's not specifically an EAC problem. It's a problem you will periodically have with any burner with a write offset of anything other than 0, no matter what software you use. PlexTools has its own way of trying to skate around this problem, but it still fails to produce exactly-matching copies, due to hardware limitations.

A typical Plextor drive has a write offset of -30, when there are models from other brands with -6 or +6. What these numbers represent from an offset-corrected burning standpoint, is how much absolute silence your burning process will insist on including at the very beginning or the very end of the album, regardless of little or much silence is actually supposed to be there. Most albums will have at least some absolute silence at the beginning and/or the end, and in many burning scenarios you will be replacing old silence with coincidentally-matching new silence.

The larger the write offset (whether positive or negative), the more silence you are overwriting on the intro or outro, which means you are more likely to be exceeding the amount of silence that was originally there, and if this happens you will get mismatched CRCs when testing the original versus testing the copy. If your write offset is positive, then it's the first tracks which sometimes won't match, instead of the final tracks.

If different albums feature different amounts of absolute silence, and in different areas (beginning or end), then a drive with a smaller or positive write offset should be involved with burning any album a Plextor drive cannot authentically duplicate. With the exception of a burner with a true write offset of 0, there is no one burner that will perfectly duplicate all audio CDs (not a lot of people around here want to see this as true and relevant). If you had such a drive, it would offer you the one-stop-shop convenience of not having to swap between different burners for different albums, however.. such drive(s) have no bells & whistles like the Premiums, they might not be very great workhorse drives for taking years of abuse, and I can't find any information on what the jitter/C1/etc. is like. Plus in any case, you'd still at least want to be ripping the original discs and testing the copies with a true Plextor drive, for the full overreading capability - no matter what kind of write offset you need for a particular album.

Supposedly the missing/overwritten/replaced Offset data "doesn't matter", but I like the idea of any disc I burn, being able to serve as a true backup copy of the original. Even if it's my intention to stash the originals away and never touch them again, and use CD-Rs in any outside-of-computer situation (such as your car) where an idiot would use a factory-pressed original, I sleep a little better at night knowing that if theft or some other disaster hit my house, that from now on anything I do or make from my CD-Rs is exactly the same as what I could have done or could have made with the original CDs.

Wow.

You could spend your entire life just trying to get perfect audio rips.

It doesn't take more than a few weeks or a few months to get comfortably familiar with all the nuances of "perfect" ripping. Once you've got the drive(s) for it and you really know what you're doing, you can get some very certain rips in as quickly as 6 minutes per disc.

You can cut that down to 3 minutes, if it's a disc that you've taken plenty of extra time to rip before, and if you still have your own records from before to ensure that the new hasty rip matches the old slow rip. Most hasty rips will match the slower alternatives, but you'll never know which discs need the slower alternative ripping method until you try it on them, otherwise you have a false sense of security from hasty ripping if that's the only way you've ever approached a particular disc.

I will invest extra time into a first rip, if it means not having to spend much time on the majority of my re-rips (if I were to lose all my rips). I have roughly 200 albums, and it's taken me at least 50 real life hours to rip through all of them with confidence the first time, plus an unspeakable number of hours has gone into organizing the content. If I ever had to rip my whole collection again, it would only take me 2 hours with my portable metadata and my stack of PlexWriter Premiums. I make it my business never to be slow in any territory I've already charted.

If the written (duplicated) disc produces the same CRC values as the original disc did, then I am satisfied that the copied disc's track matches the original. What I am unhappy with is when the first or last track of a disc mismatch due to the inability of the drive to overwrite into either the lead-in area or lead-out area.

Since I can't write either of these areas, why then is it deemed important or "good" to have a drive which can read these areas? I mean, so what if I can read the data, but I can't duplicate that same data correctly? In this case then, to my way of thinking, I should always turn off the options to overread the lead-in & lead-out. Am I missing something here?

The goal is not just to make CRCs match - the goal is to make them match for the right reason.

If you disable overreading, then you are eliminating the symptoms - not the disease. I should also mention that this is in a best case scenario where your read/write offsets are equal size and would "cancel each other out" (I use this phrase very loosely and make no attempt to associate it with complete credibility).

If your write offset is larger than your read offset, you could still get mismatched CRCs even with overreading disabled. Overreading is worth having the drive for and enabling, because if one particular burner cannot pass on what you've overread, then another burner can. While there is no single burner with any write offset that can perfectly duplicate everything, there is no such thing as audio data that no burner could ever perfectly duplicate. For any given album, there is a burner model somewhere that will pass on everything (in the first/preExtra session) that the original disc had.

Even if you don't have an appropriate burner for a particular album yet, there's nothing wrong with already having a perfect rip on-hand for computer-listening purposes, or for when you might get access to an appropriate burner later on. A safety deposit box could include a hard drive featuring perfect rips of everything you own, in-case of disaster. If you later acquire additional albums, then you keep two backup hard drives - one at a home and one in the safety deposit box, and swap them every season or every year, always keeping at least one drive in the safety deposit box at any given time.

If you're really uncomfortable with the idea of employing different burners for different albums, then you could go find yourself a 0 write offset drive (I know they exist), but again - I don't know if the jitter/C1 would be respectable. CD Freaks tends to focus more on the readability of discs, than whether or not those discs contain perfectly-matching audio, and while I think that emphasis has gone a little too far, I don't think it's entirely uncalled for to care about readability. You could have two perfect duplicates of the same album, and one is more or less easy to read, due to CD-R material, or the burn speed, or the pit width, or the laser strength. Don't be fooled by "gold" discs - they read like crap compared to many of the cheaper alternatives, but at least they're consistently crappy - instead of starting out great, and then one day you can't even read them anymore.

My point is that the last few milliseconds are usually silent and won't be missed - after all, this is for your own private use isn't it. There are other ways of ensuring good copies without using CRC's. Relying on C2 error flags is usually sufficient.

Cheers

James.

Pop into Itunes, Import disc.

Done...

Seriously, there is a lot of debate on the net as to just how necessary it is to use EAC or XLD for every single CD, when the majority of albums people are ripping are not that complex in their structure. I understand that if you're living in or importing stuff from Japan, for example, that EAC may be critical, but many have been satisfied with simply using iTunes w/Error Correction and using the Apple Lossless or AIFF format.

BTW, this is probably a stupid question, but how does ripping to a lossless codec compare to simply copying a disc? In other words, if I pop a disc in and tell Nero or Toast to make a copy directly to a CD-R, is that in any way more accurate than the two-step process of ripping then burning, or does it have the same limitations?

I will admit I've done some burst rips (for testing purposes) that turned out to be the same as the slower and repetitive "Secure" methods that EAC does, but every album is different, and you unfortunately have no idea which albums need Secure ripping until you go through with it.

I thought SHM-CDs were going to be the shit, but in my recent ripping experiences, most of them need even more error-correction than the average nonSHM disc. I am still going for the aesthetic benefits of the mini-LP cardboard sleeves that come with SHM-CDs, though.

Once you get raw audio into Apple Lossless, it's not so easy to extract the raw audio back out of it. The format is just a proprietary-like convenience that sounds good for the people who use Apple products. dBpowerAMP can produce Apple Lossless files that iTunes supports, but iTunes doesn't necessarily produce Apple Lossless files that dBpowerAMP can support.

I've had some recent experiences where I was using dBpowerAMP to produce FLAC or WavPack or WAV files from up-to-date iTunes-encoded Apple Lossless, and the resulting files all had problems near the end (the last few seconds) of their playback duration, but dBpowerAMP thought everything went okay during the conversion process. This never happens in reverse. dBpowerAMP never produces Apple Lossless files that iTunes users have any problems with.

iTunes also doesn't produce CUEsheets. You sort of kind of need them for burning authentic copies from your lossless. If all you want to do is just casually listen to your music, then iTunes gets the job done (except it can't do Kernel Streaming in Windows - so audiophiles will still use foobar2000), but if you additionally want to archive your music in such a way that authentic copies can be burnt at any time without having the originals on-hand, then iTunes almost completely and totally blows.

You can't use iTunes for true playback (maybe OSX is an exception) and you can't use it for true archiving. It's convenience software for people who don't want to think very hard. If you go through life thinking only as little as you have to, eventually you reach a point where you get old and there's no going back. Someday there's going to be an iTunes/iPod generation filling up nursing homes everywhere, and I don't know yet if I want to live long enough to witness that.

There are several things wrong with telling Nero or Toast to "copy" a disc.
1.) These programs don't perform offset correction, and no drive has a read offset of 0. Copies you burn with Nero will rarely ever match, and the only time they truly will match is when your drive(s) have symmetrical read/write offsets and the original disc has enough null samples near the lead-in and lead-out.
2.) On-the-fly copies (straight from one CD/DVD drive to another) are one of the most incredibly careless things you could ever do, even if your software supported offset correction on both drives. Not only aren't you giving yourself any time to re-read any sections of the disc which might need it, but a steady burn can only come from a steady source (and/or a really large buffer and you give the reads at least somewhat of a head start), which means you should always have the content on hard drive (or fully loaded into RAM) before you burn. Going from CD/DVD drive to NRG, then going from NRG to your burner, is better than going straight from one optical drive to another. This is basically what Nero does in the background within a temp directory when you tell Nero you want to go from same drive to same drive and swap out the original disc for a blank CD-R. The disadvantage of NRG is it's never associated with offset correction or Secure ripping.

So you could say that lossless is potentially better than Nero/Toast copying, because of lossless's association with ripping programs such as EAC. However, lossless is only as authentic as whatever CD-reading you feed into it, so if your ripping process is nothing special, then Nero/Toast copying is no worse than burning from lossless. In fact, if someone's ripping process is nothing special, then not only is the raw data probably wrong, but chances are they haven't included a CUEsheet with their rip, so they really are better off if they just do same-drive copying with Nero or Toast.

Most disc burning programs have settings where you can adjust the size of the buffer to allow for the reading of more data into RAM or the hard drive before burning, so as to deal with just that issue.

FYI, Toast 8 and later has a data recovery mode for copying discs, where it reads the entire disc first using error correction, and only when successful does it then burn the copy. You also have time, if you find that the recovery will not be successful, to cancel the operation before a burn is attempted. This mode works whether you have one drive or two:

http://www.macintouch.com/reviews/toast8/

' Toast 8 introduces a new "Disc Recovery" option for making disc copies. Intended for scratched discs, Toast runs the optical drive in a data recovery mode, in which it "gracefully recovers" from errors then attempts to re-read damaged sectors. If it can't recover the damage, Toast recovers the surrounding data and presents you with a recovered file incorporating an empty segment – a very reasonable best effort. Upon completion, Toast provides a report of disc damage and recovery notes.'



Spoken like a true arrogant audiophile. I'm an arrogant cinephile, so I recognize the symptoms.

---

Last edited by negritude; 24-07-2009 at 11:45.

When an option like "Disc Recovery" is effectively buffering the entire disc before the burning has even began, it's no longer on-the-fly copying because you're not really going straight from one drive to another - you're using a complete intermediary.

If you could only on-the-fly copy one type of disc in your life (with or without Toast), data CDs would let you get away with the most murder. If you're not going to be reading the copy at 1x, then jitter doesn't matter. There are some considerable problems if you do on-the-fly copying with DVD videos, and far too many problems if you do on-the-fly copying with audio CDs.

Toast doesn't really have to do anything special or be anything special to accomplish what you've just shown me. Software can't get read errors from data CDs without knowing about it - the only difference is that Toast is being more pro-active about the errors that any other disc-copying software would automatically know about but not necessarily expect you to care about.

You're forgetting that audio CDs are almost an entirely different animal altogether. Unless you have a Redbook-compliant disc (instead of what dBpowerAMP Reference would refer to as "Detective By Design") and a drive that is extraordinarily good with C2, you pretty much have to read through every sector at least twice. Toast doesn't have to read through a data CD twice to even be aware that there is a problem - Toast only performs additional reads after Toast has already detected the problem(s) from the first reading. This method doesn't work particularly well for audio CDs, because unauthentic first readings will often slip under the radar.

But again, Toast is doing no worse than someone ripping and burning with unSecure lossless. At least Toast is preserving the original Table of Contents, so the copy includes no additional gaps or the lack of original gaps.