I also don't think we should create a chart that is heavily skewed based on a list of features belonging to just one ripping program. Still, any type of feature/technology that makes a clear difference in performance should be listed.
I have an objection with footnote 4 since it implies that dBpoweramp is the only current ripper that can check your rips against different pressings, especially considering that it isn't even the first ripper to be able to do this.
I argue that its important enough of a feature to warrant its own row.
dBpoweramp is the best ripper for Windows, in terms of features and performance, hands down. Whichever way the chart is sliced and diced this will be reflected, Eli, I assure you. Still, the chart doesn't need to look like dBpoweramp marketing material.
Quote from: Eli on 27 July, 2010, 08:16:06 PMI argue that its important enough of a feature to warrant its own row.Only after the fact.
I'm certainly not trying to market for dBpoweramp.
Quote from: Eli on 27 July, 2010, 11:03:00 PMI'm certainly not trying to market for dBpoweramp.Please don't make me count posts, let alone point to your signature.
Careful about post-processing. With at least dBpoweramp and Rip, AR is more integrated into the ripping process; decisions are made based on its results. In the case of dBpoweramp, any combination of results from multiple passes that differ are checked against the database.
I'm starting to think that just specifying Windows in the OS is not adequate. Many people are having quite a bit of difficulty getting EAC to work properly with 64-bit versions of Windows specifically and post-XP Windows in general. While some people are finding solutions, more and different problems are being reported regularly. There seem to be more and more drive-based or interface-based issues as well.
All good, CD-Text might be listed under the metadata for rippers which support it.........The AR column, instead of Yes / No could be the version of AR, ie 1 or 2, or No.
Unless there are some objections, I'd like to remove the row and add a footnote to the metadata entry for dBpoweramp. I think the same should be done for the CUETool DB with a footnote added to its entry in the AccurateRip row. Perhaps the row be renamed to something that describes what the two services do.
FWIW, I considered making mention of PerfectMeta, but figured that it already took the crown in that row. I still feel it should be included, BTW, though perhaps is should be noted that some of those options cost $$$(?).
I also think that the (natively) part be removed from the artwork and that the entries be done in a similar fashion as the metadata. Entries designed in such a way as to limit information should be avoided.
Footnote 4 is correct in that dBpoweramp is the only current ripper to support AR2. But you are also correct in that others support checking against different pressings. Does it warrant 3 rows; accuraterip support, cross pressing checks, and accuraterip 2 support? That would be most accurate, but also somewhat combersome.
Sorry, a request was made to help build the chart. I actually spent an hour making changes last night. However, when I saved they were lost. I think someone else was editing at the same time. Wasn't aware I needed to make the argument before making the change, but feel I can support it.
Why is over-reading in the cache column?
Why does "no" have a different color for C2?
I think some explanation of the C2 pointers is needed.
Quote from: greynol on 27 July, 2010, 11:14:06 AMCareful about post-processing. With at least dBpoweramp and Rip, AR is more integrated into the ripping process; decisions are made based on its results. In the case of dBpoweramp, any combination of results from multiple passes that differ are checked against the database."Ripping process" can be renamed to "data acquisition" and "Post processing etc." just to "Additional features". This will suffice?
Any help is greatly appreciated. If someone disagrees it can always be discussed and changed
Quote from: Jan S. on 28 July, 2010, 07:15:09 PMWhy is over-reading in the cache column?It is the mechanism by which the audio cache is cleared. I decided to cite specific methods available in order to remove an unnecessary row.
Quote from: Jan S. on 28 July, 2010, 07:15:09 PMI think some explanation of the C2 pointers is needed.I agree completely and think this should be done for many of the categories. The same problem exists with the lossless comparison table as well. I'm not sure how it should be structured in the wiki, but I'd be more than happy to add the information once the structure is in place.
So we need another row for the overreading (leadin/leadout) feature[...]?
IMO the page on secure ripping should be much more limited with references to separate pages explaining the different features/technologies.
Quote from: Jan S. on 29 July, 2010, 06:56:22 PMhttp://wiki.hydrogenaudio.org/index.php?ti...xact_Audio_CopyI also feel that this article should be removed unless its contents are approved by the original author(s) since it was completely plagiarized from the EAC website.
Added option to use C2 error pointersWhen the option is turned on, XLD first read a sector in burst mode, and check the occurrence of C2 error. If C2 error occurs, then XLD re-read the sector with cdparanoia. This accelerates ripping extremely for the drive with C2 error support (Plextor, NEC, etc), without losing safety. If you use this option, please make sure that your drive supports reporting C2 errors.
I think adding a row about AR results across multiple pressings and continuing to specify AR1, AR2 is redundant. A stronger checksum is the only other difference and IMO does not warrant so much visibility in the table. There has never been any evidence (and will likely never be any evidence) presented showing that the checksums as calculated in AR1 have ever given someone a false positive.