Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Current bests for accurate ripping, flexible encoding, tagging, etc.? (Read 10854 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

I have been away from the ripping scene for quite a while happily using a pre-beta version of EAC with REACT to rip the occasional CD.  Then my laptop went belly up.  Now I find myself having to set up a "new" machine to get back into ripping and I see that many things have changed.

Do I try to replicate my old setup using the old version of EAC?  Do I try the new version and start playing with CUETools for the post-rip processing? Do I go to something else entirely?

Is there a current "gold standard" for accurate ripping and flexible encoding, tagging, and other processing?

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #1
Well, let's start with the basics which you may already know, so I'll be brief… the standard in Windows is still good old EAC, whose latest release was last September. It's currently at 1.0 beta 3. I have been using this beta since it came out and have experienced no problems with it. If like you said, you're an old school user of EAC, the most likely changes/new features you'll notice off the bat are:

1- Support for alternate metadata providers (other than the standard freedb/CDDB database); MusicBrainz is a choice using this URL (http://freedb.musicbrainz.org:80/~cddb/cddb.cgi)… though I can't say if that's simply a mirror of the original freedb, or if it contains the extra goodies that MusicBrainz provides. You also have a CUETools DB metadata source, and a third. Select each one and then choose the advanced options to see what specifics they have, if you haven't already. What this ultimately brings to the table for the user (besides the obvious variety) is the ability for EAC to immediately import both LYRICS and ARTWORK along with the standard metadata tags (pre-rip). You can also add these manually if you choose, as I see you are using an automation script it looks like (I've heard of it tons, but never tried it; so I am not familiar). Since the CUEToolsDB is "fairly new" compared to the others, here is a fantastic manual/resource/FAQ to get you caught up on what's different about it: CUETools Database (actually, I'm gonna read that myself, after this… lol; looks like a pretty tasty source of good info!

2- As in previous versions, all the work is pretty much done for you. Upon first install and opening EAC, it will go through the setup wizard, ask for reference CD(s) to find your correct offset, then apply it in the options, plus test the features of your drive and set those (C2 pointers, audio cache, etc) for when you're ripping using secure mode. Just as another reference, this is what settings I have set in the options, and I have had no problems with errors in ripping/matching to AR database. Here:


Read offset correction                      : (gonna be specific to your drive, obviously, mine's 6)
Overread into Lead-In and Lead-Out          : No (I don't know explicitly that my drive has this capability, and have had no ill effects from leaving this off/no, so that's where it has stayed)
Fill up missing offset samples with silence : Yes (Pretty clear, standard)
Delete leading and trailing silent blocks  : No (Same here)
Null samples used in CRC calculations      : Yes (I believe this is also standard)
Used interface: Native Win32 interface for Win NT & 2000 (I use Windows 7 x64, other options like ADAPTEC/Nero ASPI layers are so OLD they warn of using it past Windows 98! That concerns me, plus the native works great, it's the jam; never a problem… thus no need to stray from it)


Other than that in the first main EAC options dialog, I always check pull UPC/ISRC codes from the disc, and also to pull CD-TEXT for CUE sheet generation though… likely not needed and will be overwritten.

Drive options dialog, gonna be specific mostly… but I make sure to check all the "features" like drive is CD-TEXT capable, use AccurateRip with this drive, spin drive up before extraction (I just set that for comfort, LOL)

Metadata options is where you'll see your new choices for metadata servers, pretty self explanatory.

Compression options (I always rip to single file IMAGE+CUE), and it's not a big deal to encode to FLAC (my preferrence for storage after rip, for lossless...) then if I need a specific format/bitrate down the road, well; I always have the bit-perfect source so thanks to foobar2000, nothing is impossible really from there. I also embed my CUE sheet into my FLAC files using foobar, which automatically populates any data contained in there, and I go manually from there if extra fields, etc are needed. The reason why I don't just simply use flac.exe and have EAC auto-encode afterwards… I think the issue was twofold. One, there *was* (I don't know if it got fixed or not) but there was a bug that screwed up FLAC file output names (supposedly because they used four letter extentions). I would end up with either a filename with no extension, or one with .flac.flac; I could never get the damned thing to act right, so I just said screw it, the generic cheap little FLAC frontend that comes with the codec is a drag and drop away. Not a big deal.


Other than that, since inherently CD's haven't changed, neither have the standards as far as ripping is concerned. Encoding, that depends on your choice output file. I see LAME's encoder just landed on 3.99? Though, I've read by a lot of the audio gurus and scene people that they never use the latest version because they're often a bit buggy at first... so they fall back usually (it seems to me that 3.97 is the most common. 3.98 was the newest until just a few days ago… but again, your choice if you want to use the latest version or not. I honestly am not sure what they're still changing this far into development! Still stuff to do/improve, I suppose!

If you're wanting to go lossless for archival, my fav, as mentioned is FLAC. Reasons being familiarity, ability to embed CUE sheets and ALBUMART as well (even the log file if you want can be tossed into a tag, named either LOG or LOGFILE. I see so many "rippers" supposedly doing professional or proper rips, but always leaving the CUE and LOG file out! Those two are very important, if you ask me. Especially the CUE sheet, since if there's lead-in's (INDEX 00 entries) or if you're using it as a single image, it's necessary to define the track points, etc! Of course there are hacks and ways around that, which you already mentioned: the other powerhouse and great utility– CUETools. Recently released the newest version which is 2.1.14 (thread subject still says .12 is latest, but always refer to the home/opening page "Portal" at the bottom left and you'll see the latest major software releases.

And that's pretty much it, man… as far as my process goes, it's pretty straightforward and quick. One note I will make about my personal habits:

CUETools is a great enhancement/addition to the postrip process (though, I believe it comes with its own ripper now… at least there's a file named CUERipper.exe (I could be wrong in its purpose, that will be found on the upper link which heads to cuetools.net where you can find all that info. Oh– but my point is, it's a great adjunct, but for me it doesn't play any "post processing" role, save for VERIFICATION against the CDTB and AR database. That's what I see it's greatest use in. Rare times I also use it to combine a file-per-track rip into a single image + embedded CUE as per my preference. As far as process, it's just 1- EAC rip to IMAGE+CUE+LOG; 2- Use FLAC Frontend to quickly go WAV->FLAC using the -8 and -V options, which are to use the highest compression level and to verify that the encode/write was successful. Then, all I do is drag that FLAC file into foobar2000, right click and Embed CUE sheet… load the right one in, then right click... add my album art (front cover) embedded… and as said; foobar2000 populates ARTIST/ALBUM/TRACK/NUMBERING/GENRE/DATE and writes the correct reference points for key audio stuff (track start/length).

The only freakin' huge nag I have is that after either a) embedding a CUE file (which it will show originally as a single line entry clearly, because it's a single long audio file) or b) added art, the front cover – if I do either one of these, doing any kind of refresh, or choosing the Reload info from file... type options will not pick up that art, or separate and show the individual tracks until I remove it from the queue, then drag/drop it back into the queue. At that point it shows the album art great, tracklisting is perfect, all the tracks are there… I update any additional tags I want the final produce to have, then I'll usually open CUETools and run a verify on the CUE file and make sure my results are matching good. That's it! I'm so used to it, as soon as the CD finishes the physical rip, I can go from untouched WAV file to finished product in usually less than a minute – so it's far from tedious and I don't have any real reason to be in a hurry, since I already have ripped my entire CD collection in this way... so the only time I create a new file is whenever I buy a new CD– the first thing I do, it goes from CD case -> CD drive and is ripped so I have no worries about any defects later down the road that might make a less than perfect rip (gotta be perfect, or else OCD gets angry! Obnoxious, Complaining Dome… uh oh, that letter is lowercase, it shouldn't be… start over from scratch! LOL. Not quite that intense, but I am admittedly as close of a perfectionist as I can get.

So I hope that info at least gets you started… I like to consider myself pretty veteran at the whole process, and my simple picks to do the job are EAC, foobar2000, and the FLAC format/codec. Those three, and I can accomplish anything I wanna do! If you have any specific questions or want elaboration on anything, yell and I'm be glad to answer whatever I can. Later!


Depending on how long you've been away, you may or may not know AccurateRip has evolved to AccurateRip v2, an improved version; I'll let you do the research if you want to know more.

Last thought: the formatting of the output from CUETools changed in this last version, to include ARv2 support maybe? Here's a preview:

Track  [  CRC  |  V2  ] Status
01    [35807803|99115a3d] (200+069/549) Accurately ripped
02    [3f0a3394|3ef24cd0] (200+068/549) Accurately ripped
03    [c6710c35|0d7b75d6] (200+069/549) Accurately ripped
04    [9ff988a6|747815f2] (200+068/551) Accurately ripped
05    [9976e250|7b3372ea] (200+068/550) Accurately ripped
06    [0111bcf0|f149afb4] (200+067/553) Accurately ripped
07    [f81b8bd0|5c61da5e] (200+068/546) Accurately ripped
08    [570ca935|8ee842a6] (200+064/542) Accurately ripped
09    [00641a19|3fe40772] (200+066/544) Accurately ripped
10    [e64c62d7|829b1ef8] (200+062/537) Accurately ripped
11    [e2126972|151cd51e] (200+060/540) Accurately ripped


I believe the 200 is how many matches from ARv1 database, and + the 60 something numbers are ARv2 rips,  / (total entries in both versions, combined). Some of it is still a bit confusing but I haven't read anything about it yet so… that's probably all I need. Such as this… one hell of an output line, geez:

11  | (100/103) Accurately ripped, or (1/103) differs in 19415 samples @02:44:48-02:44:49,02:44:70-02:44:71,02:45:17-02:45:18,02:45:39-02:45:40,02:45:61-02:45:62,02:46:30-02:46:31,02:46:52-02:46:53,02:46:74-02:47:00,02:47:21-02:47:22,02:47:44-02:47:45,02:48:13-02:48:14,02:48:35-02:48:36,02:48:57-02:48:58,02:49:04-02:49:05,02:49:26-02:49:27,02:49:48-02:49:49,02:49:70-02:49:71,02:50:17-02:50:18,02:50:39-02:50:40,02:50:61-02:50:62,02:51:08-02:51:09,02:51:30-02:51:31,02:51:52-02:51:53,02:51:74-02:52:01,02:52:21-02:52:23,02:52:66-02:52:67,02:53:13-02:53:14,02:53:35-02:53:36,02:53:57-02:53:58,02:54:04-02:54:05,02:54:26-02:54:27,02:54:70-02:54:71,02:55:17-02:55:18,02:55:39-02:55:40,02:55:61-02:55:62,02:56:08-02:56:09,02:56:30-02:56:32,02:56:53-02:56:54,02:57:00-02:57:01,02:57:22-02:57:23,02:57:44-02:57:45,02:57:66-02:57:67,02:58:13-02:58:14,02:58:35-02:58:36,02:58:57-02:58:58,02:59:04-02:59:05,02:59:26-02:59:27,02:59:48-02:59:49,02:59:70-02:59:72,03:00:17-03:00:19

F'kn A! I guess "verbose" is a little more true to its name, now, huh? I probably should change that back to normal output. If you're curious (probably not) the CD tested there was TOOL - 10,000 Days. TOOL is always reliable for maxing out your results. I always nail 200/200 matches, which makes me feel good inside, LOL (which is ARv1 match limit return, as far as I have witnessed).

Again, lemme know if any questions!

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #2
Regarding specific settings within in EAC one should refer to the forum's wiki for reliable information.

I personally hate the term "gold standard" but I think it is perfectly fitting here.  While gold might win the popularity contest it is not the most precious substance.  The same applies with EAC.

dBpoweramp pretty well raised the bar on ripping several years ago, and with the exception of CueTools integration and while it has seen some improvements in the way of features, EAC still hasn't matched dbpa in terms of ripping efficiency and accuracy. Improvements in accuracy with dBpoweramp will be dependent on capabilities of the drive and will be tied to specific problematic discs.

Before dBpoweramp was rewritten, one could argue the previous state of the art ripper was PlexTools.

Apologies to Mac users who have also seen advancements over the past few years.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #3
the vague title should be more specific

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #4
RE: dBpoweramp supposedly being more "efficient" at ripping that EAC?

The program's so called "ripping efficiency & accuracy" advantage is achieved by simply doing a test & copy on a track only if it can't get a CRC match with AccurateRip. You can easily get the same results in Exact Audio Copy by ripping tracks in Burst mode (with offests), then re-ripping the tracks in Secure mode that don't get an AR match the first time. Same results with EAC, only you don't have to spend around $45 (or more) to get them ;-)

RE: Upgrading from the EAC/REACT method you have now

Other than the CUETools plugin for the current version of EAC (v1.0b3), there isn't really a compelling method for upgrading for a lot of people. So sticking with what you have now would be just fine.


Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #5
...and if you can't get a match with AccurateRip or precision in burst mode (which is less of a guarantee of accuracy than AR)?

With drives that provide C2 pointers, dBpoweramp will be a more effective ripping program.  It is also has a far superior method to get accurate rips quickly, whereas attempting to rip with EAC using a similar method requires manual re-configuration as part of the process when an AR match can't be obtained with a single pass (let alone multiple passes); hence it is more efficient.

Regardless of C2 pointers, ripping with caching drives is also much more efficient with dBpoweramp.  In secure mode EAC reads data from the disc one extra time, whereas dBpa does not.  With C2 pointers and cache flushing, EAC must read 4MB for every 2MB written to the disc.  Without C2 pointers and cache flushing EAC must read 6MB for every 2MB written to the disc.  dBpa can be configured to read 2MB less than EAC per 2MB written in either case with the same level of security as EAC (two passes without C2 pointers and only one pass with C2 pointers).  What's more, if you configure dBpa to rip the same amount of data that EAC wastes then the ability to get accurate rips increases.  This is especially true when C2 pointers are in use.

Finally, unlike EAC, the data from each complete pass over the track will be mixed and matched in order to attempt to get a verifiable result with AR in dBpa.  This is without even having to go through re-reads over suspicious sectors, but dBpa will do this too if necessary. When it is necessary, dBpa will also interactively check the data against AR during the process, just as it does with complete passes.  On the other hand, with EAC AR verification is done only once after the ripping process is over using whatever EAC thought was the best data based on what was most consistent.  These days it's fairly well understood that sometimes errant data can appear more often than error-free data.  Finally, dBpa attempts to detect if a drive is concealing errors through interpolation, whereas EAC makes no such provision.

My comments very much stand.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #6
There's no standard for C2. For all intense and purposes, it's a total joke. Even if a drive has it, there's no guarantee that it's going to work correctly. I think dBp depends too much on that, and the AccurateRip database. Maybe it's just me, but I want my matching test & copy CRC's. I refuse to put 100% trust in any database to tell me if something is accurate or not. Especially with the bug in the current version of it, ARv2 (which is, pretty much, a dumbed down version of CRC32). I'll wait the long, arduous, 4-5 minutes  using EAC, thank you very much.

Also, if you look at this part of their web site, you'll see they compare their program to EAC using Secure Mode on the high error-correction setting...something even Andre (the developer) doesn't even recommend. Why? Too many re-reads, which can lead to false positives. The comparison between the two programs, because of this, doesn't make any sense, and isn't fair.

BTW: Drives with caches? Also a total joke. The bad experience I had with them caused me to ditch my old drive for a new one without that in the mix (Never been happier  )

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #7
There's no standard for C2. For all intense and purposes, it's a total joke. Even if a drive has it, there's no guarantee that it's going to work correctly.

dBpoweramp makes use of C2 pointers differently than EAC.  Do you actually know how it works or are you just parroting the same old nonsense?

I think dBp depends too much on that, and the AccurateRip database. Maybe it's just me, but I want my matching test & copy CRC's.

It's just you.

I refuse to put 100% trust in any database to tell me if something is accurate or not.

I recommend you be at least as skeptical about matching CRCs.  Have you ever done any research into consistent errors?  I'm thinking the answer is no.

Especially with the bug in the current version of it, ARv2

Link please?

(which is, pretty much, a dumbed down version of CRC32).

Well, no, not really.

I've read as well as debated both sides of the issue and am really familiar with the strengths and weaknesses of each program and at the end of the day when it's all said and done there really is no question that dBpa is the better ripper.  The good news is that there's nothing that prevents an owner of dBpa from using EAC if it so happens to do a better job on a small percentage of discs in his collection.  Anyway, with the exception of your claim that ARv2 has a bug, there is nothing you've said that I haven't already seen addressed thoroughly.  Please, feel free to read the discussions.  You might learn something.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #8
Yes to clarify the FUD there are no issues with ARv2

And Greynol has correctly pointed out reading a cd twice and comparing crcs, you can have consistent errors, especially as drives these days interpolate, c2 pointers would help detect this error.

AccurateRip is immune to consistent errors, as a different disc is ripped, so unless the manufacturing plant put an error on every cd it produces...

So in short if you rely only on the cd drive (test and copy, or c2) then errors will still slip through undetected.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #9
Maybe it's just me, but I want my matching test & copy CRC's.

Something to consider:  What matching test & copy CRCs tell you is that ripping the same physical disc in the same drive with the same settings gives you the same result.  Even if you vary the ripping mode, you're still using the same disc and drive.  That's fine and helpful to some degree, but it's not exactly a rigorous comparison.

On the other hand, when you compare your rip to AR or the CTDB, you're now comparing your rip to those done with different physical discs and different drives and different settings (and even different software, too).  If, despite all those variables working against you, you still get a matching rip, you can be far more certain of an accurate rip than what test & copy can deliver. 

In short, matching results when there's diversity is more informative than matching results when there's uniformity. 

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #10
Maybe it's just me, but I want my matching test & copy CRC's.


Greynol is right that yeah, this is just you:
You refuse to trust a second opinion from someone else's rip of another physical disc (... which is of course not foolproof if you bought the CD 2nd hand, it could then be ripped and submitted already), but instead you want the same drive to read the same disc again. That's very far from an independent second opinion.

Now if you still insist on doing a re-read and compare checksums even when your rip is verified by AR, then dBpoweramp can do that for you by the click of two buttons: you just hit 'Rip' once more, and hit OK to overwrite. If the CRC matches the previous run, it goes green. If not, it goes red. (And in case you worry: that is the full-track CRC, not the AccurateRip hash which removes a few samples at the ends.)

Not only that: dBpoweramp allows you to change drive in the meantime, enhancing your chances of discovering errors (at least if the second drive is truly different, not just a re-badge of the other).

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #11
On the other hand, when you compare your rip to AR or the CTDB, you're now comparing your rip to those done with different physical discs and different drives and different settings (and even different software, too).


By the way: AFAIK is not possible to submit ripping results to AR  db from XLD on Mac, and actually only dBpoweamp and EAC can. Right?
... I live by long distance.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #12
Correct

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #13
Now if you still insist on doing a re-read and compare checksums even when your rip is verified by AR, then dBpoweramp can do that for you by the click of two buttons: you just hit 'Rip' once more, and hit OK to overwrite. If the CRC matches the previous run, it goes green. If not, it goes red.

dBpa also has a test mode that doesn't write to the hard drive, correct?

(And in case you worry: that is the full-track CRC, not the AccurateRip hash which removes a few samples at the ends.)

Just at the ends of the disc and not at the ends of the tracks, or am I mistaken?

Not only that: dBpoweramp allows you to change drive in the meantime, enhancing your chances of discovering errors (at least if the second drive is truly different, not just a re-badge of the other).

With EAC you can do the same.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #14
There's no standard for C2. For all intense and purposes, it's a total joke. Even if a drive has it, there's no guarantee that it's going to work correctly.

dBpoweramp makes use of C2 pointers differently than EAC.  Do you actually know how it works or are you just parroting the same old nonsense?


No problem? Really? I guess somebody should tell Gregory that, because I've read numerous posts (in his CUETools thread) that mention how he had to modify how AccurateRip worked in CUETools just to get around it. He and Spoon have gone back and forth on it numerous times. Take a trip over there. Maybe you'll learn something.

There's no standard for C2. For all intense and purposes, it's a total joke. Even if a drive has it, there's no guarantee that it's going to work correctly.

dBpoweramp makes use of C2 pointers differently than EAC.  Do you actually know how it works or are you just parroting the same old nonsense?


I know that whether C2 works or not (with EAC or dBpa) depends on the drive you have, and how it's manufacturer implements it. I also know that, from posts I've read here, that rips, sometimes, actually taken longer to complete with C2 on compared to when it's off. Again, there is no standard, so nobody knows what to expect.


Maybe it's just me, but I want my matching test & copy CRC's.


Greynol is right that yeah, this is just you:
You refuse to trust a second opinion from someone else's rip of another physical disc...


No, I just refuse to let AR be the ultimate decider of whether a rip is great or not. We've all been there when AR claims a track, mysteriously, doesn't agree with the system, only to double-check with CUETools to have it say there's nothing wrong. And, on top of that, the track has matching CRC's, no detectable errors, and it sounds just fine. Obviously, the system's a little screwy.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #15
No problem? Really? I guess somebody should tell Gregory that, because I've read numerous posts (in his CUETools thread) that mention how he had to modify how AccurateRip worked in CUETools just to get around it. He and Spoon have gone back and forth on it numerous times. Take a trip over there. Maybe you'll learn something.

That's strange. I was somewhat involved in the very same discussion you're talking about and while I have my own reservations about ARv1 and v2 checksums which aren't much different than Mr. Chudov's, I came away from the conversation with quite a different take than you. It is becoming increasingly obvious that you don't quite understand what it is that you've read.

I know that whether C2 works or not (with EAC or dBpa) depends on the drive you have, and how it's manufacturer implements it. I also know that, from posts I've read here, that rips, sometimes, actually taken longer to complete with C2 on compared to when it's off. Again, there is no standard, so nobody knows what to expect.

It really isn't nearly as complex as you're presenting it; drives either reliably provide C2 pointers indicating there was an error or they don't.  dBpa uses C2 pointers as an enhanced way to detect errors and does this in combination with multiple passes, whereas EAC uses them exclusively to detect errors.  There is a world of difference between the two methods and how they work with real-world drives.  To put it simply: using a drive with doesn't report all errors with C2 pointers in dBpa is safe; in EAC it isn't safe.

No, I just refuse to let AR be the ultimate decider of whether a rip is great or not. We've all been there when AR claims a track, mysteriously, doesn't agree with the system, only to double-check with CUETools to have it say there's nothing wrong. And, on top of that, the track has matching CRC's, no detectable errors, and it sounds just fine. Obviously, the system's a little screwy.

That doesn't tell me the system is screwy.  It tells me that you don't understand how to interpret AR results properly.  Perhaps you can provide a specific example so someone can provide you with an explanation.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #16
I know that whether C2 works or not (with EAC or dBpa) depends on the drive you have, and how it's manufacturer implements it. I also know that, from posts I've read here, that rips, sometimes, actually taken longer to complete with C2 on compared to when it's off. Again, there is no standard, so nobody knows what to expect.


This is getting a bit too dumb ... true, you might encounter a drive which reports nonsense or nothing at all. Then you might disable the use of C2. But going from the fact that there are unreliable drives, to denying that this layer of error correction is useful ... look, a CD drive doesn't cost that much. If you have an unreliable drive, you don't solve the problem by asking the ripper again if it is serious about its result. You solve it by replacing the unreliable drive.

('sometimes, actually taken longer'? If that is an issue, why do you then want to read twice?)


Quote from: RastaMan link=msg=0 date=
No, I just refuse to let AR be the ultimate decider of whether a rip is great or not.


But you want to re-rip the same physical disc with the same drive -- and such a bad drive that you cannot trust its error reporting -- and be satisfied if it agrees with itself?


Quote from: RastaMan link=msg=0 date=
We've all been there when AR claims a track, mysteriously, doesn't agree with the system, only to double-check with CUETools to have it say there's nothing wrong.


That's because CUETools did cross-pressing verification, which your ripper probably did not.

You are aware that you have spent many posts claiming that a rip AR claims to verify, isn't reliable -- and then you switch over and complain that the problem is when you do not get an AR match? In that case, dBpoweramp will re-read multiple times and report as 'Secure' if they match each other (according to the n-out-of-k criterion you have set), and 'Secure (Warning)' if individual frames had to be re-read. This is a case where dBpoweramp will automatically resort to what you suggest (or something better). (Someone can fill in on how EAC does this in all modes, I don't have it up and running after a reinstall.)

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #17
You solve it by replacing the unreliable drive.

He apparently did this with a drive that caches, likely costing about what it would have cost to purchase dBpa which would have also fixed the caching issue. You wonder why he didn't find a drive that provided reliable C2 pointers.

That's because CUETools did cross-pressing verification, which your ripper probably did not.

Yes, and guess which ripper he was most likely using.  Yet another feature that distinguishes dBpa from EAC.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #18
Do I try to replicate my old setup using the old version of EAC?
For sure I would use the newest version available.

Is there a current "gold standard" for accurate ripping and flexible encoding, tagging, and other processing?
IMHO, it depends. AFAIK, both EAC and dbpoweramp (dbpa; and maybe some others) will give you "exact" results (secure ripping). With respect to tagging, I prefer dbpa, because I can easily change and add metadata, I can even add my own tag fields. I missed such things in EAC and switched to dbpa. Regarding "flexible encoding and other processing" you might want to specify your needs in more detail to get sufficient answers.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #19
AFAIK, both EAC and dbpoweramp (dbpa; and maybe some others) will give you "exact" results (secure ripping).
Secure ripping should not be conflated with a complete guarantee of exact extraction, due to the possibility that this mode might repeatedly return the same erroneous data, a fact that has already been discussed at length. Those desiring the best guarantee of an exact rip but lacking multiple drives should compare their rip against those of others, rather than trusting verification from within (secure mode) or between (CRCs) rips of their own. It is at this point that people begin to make distinctions between EAC and other programs in terms of their capabilities.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #20
I know that whether C2 works or not (with EAC or dBpa) depends on the drive you have, and how it's manufacturer implements it. I also know that, from posts I've read here, that rips, sometimes, actually taken longer to complete with C2 on compared to when it's off. Again, there is no standard, so nobody knows what to expect.


This is getting a bit too dumb ... true, you might encounter a drive which reports nonsense or nothing at all. Then you might disable the use of C2. But going from the fact that there are unreliable drives, to denying that this layer of error correction is useful ... look, a CD drive doesn't cost that much. If you have an unreliable drive, you don't solve the problem by asking the ripper again if it is serious about its result. You solve it by replacing the unreliable drive.

('sometimes, actually taken longer'? If that is an issue, why do you then want to read twice?)


Quote
No, I just refuse to let AR be the ultimate decider of whether a rip is great or not.


But you want to re-rip the same physical disc with the same drive -- and such a bad drive that you cannot trust its error reporting -- and be satisfied if it agrees with itself?


You solve it by replacing the unreliable drive.

He apparently did this with a drive that caches, likely costing about what it would have cost to purchase dBpa which would have also fixed the caching issue. You wonder why he didn't find a drive that provided reliable C2 pointers.[/quote]

And you guys are accusing me of not reading? If you bothered to read my previous post, you would've easily seen that I mentioned that I purchased a new drive recently. And guess what? It has (besides Accurate Stream and no cache, totally reliable and highly rated) C2 in it. I've used this drive to also re-rip discs that don't jive in EAC, yet it does jive with dBpa and CUETools. And, at the same time, AR results are all over the place...even with rips that got two thumbs up with the last two programs. The same thing, interestingly, happened with my original drive which has no C2.

Now when all three rips have matching CRC's, have no errors, sound totally fine, yet have AR results that are all over the place, how can one say that rips are fine just because AR says they are?  Obviously, IMO, the system needs more work & standardization, because it doesn't make any sense at all to have one disc that puts out a solid rip not being able to have AR simply say it's fine. With or without cross-verification. That doesn't make any sense.

BTW: Nice job, greynol, making my previous post disappear.  Do you get paid by dBpa by the post, or just a regular salary? You should become an offiicial spokesman for the company that put dBpa out, because it's batently obvious you have a huge bias for them. Disgusting. Have fun spewing their propaganda, because you obviously don't like dealing with facts.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #21
BTW: Nice job, greynol, making my previous post disappear.
Without presuming to speak for greynol, I don’t recall any post of yours that is not still here. Are you completely sure about your allegation? In any case, I don’t see how it justifies your over-the-top tantrum and probable violation of TOS #2. And even if a post had been deleted—which I don’t believe—you would be violating TOS #7 by complaining about it publicly rather than confining your disagreement to a private message. High score!

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #22
No posts from that user account were deleted by me or anyone else since it was created back on 5-May 11.  Any other moderator or administrator can easily verify that this is true.

Regarding TOS violations, I've yet to read his latest post and probably won't since there's no point talking to a completely clueless wall, but I do have reason to suspect he's violated #12.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #23
Nowhere in my wildest thought did I think I'd spark a conversation like this.  Thank you all for the great information.  I certainly have a lot to consider.

I only wish I hadn't started a bit of flame war.  I understand people being passionate about their chosen solution.  I don't see why the information can't be shared with civility.

Current bests for accurate ripping, flexible encoding, tagging, etc.?

Reply #24
It generally happens when people hold on to their misconceptions with conviction.

That someone offering nothing but gut feelings backed by anecdotes an misinformed opinions then turns to accuse someone else of being a shill or abusing his power as a moderator should raise a red flag.

To be frank, this is hardly a new debate which is probably why I don't feel particularly inclined to try to convert someone who pretends to know more than he really does about the subject.  Feel free to look into the following search results in this sub-forum using the keywords "+dbpoweramp +EAC +cache +pointers +Accuraterip":
http://www.hydrogenaudio.org/forums/index....+%2BAccuraterip

Only speaking for myself, I am not passionate about any particular solution.  I actually use EAC most of the time and have been manipulating it to check against alternate pressings years before TripleFlac! which actually was the first widely available software to do the job, coming before Gregory Chudov's work on Moitah's CUETools, tmkk's work on XLD and sbooth's Rip, all of which came before dBpoweramp was able to do so.  When I can't get a reliable result with EAC, I generally turn to other software such as PlexTools, dBpoweramp and now CUETools/CUERipper.  I use EAC because I'm most comfortable with it; I don't pretend that it is as good as software that employs more advanced ripping techniques.