Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Von]

Hi,
Just made a giant leap and upgraded from MC 9.1 to MC 15. Looking forward to explore all the new features! I have a couple of questions regarding CD ripping:

1. Can I create cue sheets with MC 15?
2. Is there a particular reason why it's not possible to adjust read offset in a similar fashion to EAC?

I know you must be pretty fed up with EAC comparisons/questions. I feel convinced that MC's secure ripping is just as secure, but being able to adjust the offset and create cue sheets is what keeps me from using MC as my default ripper. Even though using only MC would make my life much more comfortable!

Von

[JimH]

Thanks.

1.  Yes, I think so.

2.  I think the offset feature is a solution in search of a problem that no longer exists.  Modern drives work very well.  Use MC's Secure Rip if you're concerned.  MC's ripping is second to none.

[Von]

Thank you for your swift reply. I know, it's almost just a theoretical issue. With EAC, I liked how (after a lot of configuration work and testing) I could rip an original - burn a copy - rip the copy - burn again etc, and every time the files would be bit identical. It just gave me another level of confidence that my ripping procedure was solid. That's why I'm just curious why offset correction isn't offered.

Now then, slightly off topic, but highly related: 

• How many of my albums have i ripped? More than 2000.
• How many times have I had to burn a copy? Less than 1.
• How many times do I see myself having to burn copies in the future? As few as possible.
• How much time could I have saved, and spent enjoying the smooth workflow of MC? A lot... 

So, perhaps the time has come to realize that once my music enters "cyberspace" it's not meant to go back to CD again. Guess I'm ready to make another giant leap.

One more thing: Does the quality of the DVD/CD drive matter at all when using secure ripping in MC?

Von

[JimH]

With EAC, I liked how (after a lot of configuration work and testing) I could rip an original - burn a copy - rip the copy - burn again etc, and every time the files would be bit identical.

That's also true with MC and has been for years.

[Von]

In that case, I apologize. I seem to remember that it wasn't the case due to read/write offsets, as for every operation it would shift a number of samples.

And to rephrase my question: I take it when a secure rip has no errors reported, the rip is equally reliable regardless of the quality of the drive?

[trhunnicutt]

I think the offset feature is a solution in search of a problem that no longer exists.  Modern drives work very well.  Use MC's Secure Rip if you're concerned.  MC's ripping is second to none.

Actually, Jim... that's not completely correct.

Von's premise is actually true.

Providing that one of the secure rips was performed by a ripper like EAC or dbpoweramp that applied the drive's offset before the rip.

Since MC does NOT use a drive's offset, the resulting ripped files, even though both were "ripped secure" would not be identical.

The MC ripped file(s) would be identical with EACH OTHER, ad infinitum.

As would the offset ripped file(s).  But, they would not be identical comparing ripped with offset, and ripped without offset.

That's just the nature of the bits/samples.

[hit_ny]

And to rephrase my question: I take it when a secure rip has no errors reported, the rip is equally reliable regardless of the quality of the drive?

I'm not sure whether C2 correction helps here at all. It used to be the norm with good cd drives a while back but its not always present in many drives of the dvd era.

[flac.rules]

Thanks.

1.  Yes, I think so.

2.  I think the offset feature is a solution in search of a problem that no longer exists.  Modern drives work very well.  Use MC's Secure Rip if you're concerned.  MC's ripping is second to none.

I am abit confused to why offset as a problem does not exist? Modern drives works well for sure, but they have offset correction as every old drive? you might argue thats a miniscule problem that is rarely relevant in any actual percived quality-way. But as far as I know, you cannot get a perfectly indetical rip without offeset correction (the tracks not starting the right place). But perfect is perfect, I like do to do my rips 100% correct when i do them, once and for all.

[flac.rules]

In that case, I apologize. I seem to remember that it wasn't the case due to read/write offsets, as for every operation it would shift a number of samples.

And to rephrase my question: I take it when a secure rip has no errors reported, the rip is equally reliable regardless of the quality of the drive?

I am not quite sure how MC does it, but the rip should be pretty reliable, but not 100% i guess, with EAC, where the combination drive and Cd-quality (scratches and so on) are on the very edge of a good read, you can get no reported errors, and still have errors. For instances in EAC i have ran test and copy several times in the same track, and been getting two different checksums twice. That is for instance

First run: Checksum A&B
Second Run: Checksum A&C
Third Run: Checksum B&D

Both checksum A and B occur 2 times, even though one of the two must be wrong. Same checksum twice is same read 4 times (EAC reads twice per test or copy), so you can actually have bitfaults even if the track is read excactly the same 4 times. Only happens maybe 1-2 of 1000 rips for me though.

[hit_ny]

No C2 correction in your drive is there ?

[flac.rules]

No C2 correction in your drive is there ?

My drive has c2-errror correction, the example is done without c2-error correction. (well actually, the drive will do c2 error correction anyway, afaik, turning off c2 error correction in EAC only turns off that EAC relying on the drive reporting where the c2-errors has occured. The correction is applied regardless(?)

[hit_ny]

Which drive is it ?

[flac.rules]

Which drive is it ?

Plextor Premium and Plextor Premium 2, depends on wich comp.

[JimH]

I am abit confused to why offset as a problem does not exist? Modern drives works well for sure, but they have offset correction as every old drive? you might argue thats a miniscule problem that is rarely relevant in any actual percived quality-way. But as far as I know, you cannot get a perfectly indetical rip without offeset correction (the tracks not starting the right place). But perfect is perfect, I like do to do my rips 100% correct when i do them, once and for all.

If you can find an example of a problem track ripped from MC, please let us know.

[hit_ny]

Plextor Premium and Plextor Premium 2, depends on wich comp.

The premium is the better ripper, the premium 2 is the better writer.

There's two things that might be worth checking,
- whether your EAC config is setup correctly for your drive. You might want to dig around some more in this forum

- the other is to try plextools to rip the track that gave you differing checksums.

Some albums might require different ripping settings. C2 might not work and AccurateStream is needed.

[flac.rules]

The premium is the better ripper, the premium 2 is the better writer.

There's two things that might be worth checking,
- whether your EAC config is setup correctly for your drive. You might want to dig around some more in this forum

- the other is to try plextools to rip the track that gave you differing checksums.

Some albums might require different ripping settings. C2 might not work and AccurateStream is needed.

I can't see a notice any difference between the too ripping wise, both ahandle all copy protection, both overreads into lead-out and in, and has c2 error-correction, both are seemingly equally good (wich is pretty good, but not the best) at reading scratched records. I guesss it could be a difference with the latter point, but I would assume the points i have listed covers all relevant aspects of a drives ripping capacity?

EAC is setup correctly, the problems is simply that the CDs are very scratched, and you might be unlucky enough to red the same wrong value several times.

[flac.rules]

If you can find an example of a problem track ripped from MC, please let us know.

I'll let you know if i stumble upon a track like this again, as mentioned, its pretty rare to have CDs like this (they need to be in pretty bad shape), I don't have the given CDs any longer (i throwed them away, because they where so scratched). I can try the ripper in MC too if i get a problem track like this.

[Von]

So, I see I am not alone in being hung up on offset correction...

Why shouldn't this "insignificant" option be available in this magnificent piece of software that is MC 15? I would guess that many clever features have been added over the years that are used by fewer people than this would be - my point being that a feature which is pointless to one person, might be priceless to another. I would still like to know if it is because it's hard to implement technically, or if it is for some other political or philosophical reason. And if nobody wants to answer, I will still be a happy user of MC and maybe make it my default ripper as well.

First run: Checksum A&B
Second Run: Checksum A&C
Third Run: Checksum B&D

I have also experienced this a couple of times.

Regarding PlexTools, since some of you guys seem to have experience with it: I did some testing once, and I believe I found that ripping an album with PlexTools to separate tracks, then burning those tracks to a CD, gave me a new CD that had the correct pre-gaps and everything (when using EAC to compare the original with the copy) - without me using cue sheets. Can this be? If so, I wonder how. Does PlexTools store information internally after a rip? Or if this is nonsense, please tell me so, and I'll write the memory off as a weird dream. Thanks.

Von

[Alex B]

The audio stream in a Red Book Audio CD is one continuous track. Because of the limitations in the used technology the placement of this track is not precise. The exact start position is allowed to vary.

It varies already at the manufacturing stage. Different manufacturing plants may produce CDs with slightly different offsets even from the same master recording. Also the CD players have some tolerance in this and each different player mechanism may vary slightly.

For playback purposes the amount of this skew is a non-issue. A correctly manufactured CD doesn't contain the actual recording in the very beginning or the very end of the CD.

In a Red Book Audio CD the individual tracks are created by using a separate index. Even though the start position of the audio stream may vary slightly the individual track durations are always correct. All tracks will have exactly the same amount of shift.

When Andre Wiethoff developed EAC he wanted to create a system that would allow to compare rips that were done on different drives that may have different offsets. He performed empirical tests and determined a reference offset that is used in EAC. There is no official standard for this kind of offset. Since then the "EAC reference" has become a de facto standard and some other programs have started to use it.

A read offset correction system is only useful for comparing rips that were created with different drives to each other. It has no effect to the audio quality. Similarly a combined read and write offset correction system doesn't make possible to burn a more precise audio CD because the offset is allowed to vary. It is only useful for burning an Audio CD that has the same amount of shift as the source Audio CD.

Here are two links to external threads. I'd recommend reading them before posting further comments.
http://www.digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html
http://www.hydrogenaudio.org/forums/index.php?showtopic=50301

[mojave]

For those that don't want to read the links, I thought the final words from Andre Wiehoff, the developer of EAC, to be helpful:

I think I will now close this topic with some closing remarks:

- No program will ever exactly copy an audio CD (including all subchannels, TOC, CD-Text, pregaps and so on). This is technically not possible (but perhaps special (hardware only) CD copier)
- There is no "correct" read offset, even the second proposed offset is only proposed, there is no real "proof" that it is correct. I just believe it could be correct. Does it make that offset better than the first - I don't think so.
- Offset correction does really only matter as a combined offset. If you use a "bad" read offset, only some samples(!) (around 0,0006 seconds) of audio from the very beginning or the very end of a CD will be "wrong" (and only if there is no silence in that area, otherwise the copy _will_ be correct!)
- It is much more probable that your reader has more limitations that this, so a real exact copy would not be possible anyway (with a very high probability), so I don't think that we should care about 30 samples.
- Using the AccurateRip compatible offset has more advantages than disadvantages, perhaps(!) it will remove 0.0006 seconds of audio at the beginning of a CD, but it is able to tell you (with a probability) whether you ripped your track in burst mode ok or not...

As I said, I think most opinions here come from believe! Nothing is really proofed and the small offset is not really important (as there is no problem to use the correct combined offset).

Finally, this topic is closed!

cu, Andre

[HiFiTubes]

So is AccurateRip, for those who have or have used it, worth pursuing? I'm trying to dig up arguments, both pro and con.