Page 1 of 1
MAX 0.6 ripper details?
Posted: Tue May 30, 2006 8:49 am
I launched 0.5.6 and was notified of the new version.
Are they any pointers for the new ripper settings?
Thanks for the development,
Posted: Tue May 30, 2006 12:49 pm
I too am interested in a bit more details. I see that a new "comparison" ripper has been implemented. Is this the "secure rip" functionality that that was discussed some time ago in the developer forum? How does it work? (It doesn't seem to be taking that much longer than the cdparanoia rip even with 3x comparison, so I guess each read is much faster?) How did you decided to deal with the cache problem?
Thanks for your continued development. This is an invaluable tool. (Now, I don't have to make my intel mac dual-boot just to run EAC!)
Posted: Tue May 30, 2006 1:14 pm
Max's comparison ripper rips a section of a track multiple times, compares the multiple rips, and if they're the same, then the ripper moves on to the next section. If they're not the same then that means that one of the multiple rips has glitches in the data which could mean the CD is scratched, so the ripper rips the section again.
You can specify the number of sections Max should rip and compare (Required matches). You can also set the maximum of number of times that Max should rip and compare the sections (Maximum retries). The higher the number for either setting, the more thorough Max will be and so the rip will take longer. If you check the box for SHA-256, Max will use SHA-256 to generate a unique ID for each ripped section. This will enable Max to better determine dissimilarities.
That was all an explanation of a concept that has a more complex technical definition, which I don't understand too well myself.
Posted: Tue May 30, 2006 2:04 pm
Shane's explanation is a good one- I want to add that the SHA-256 option will use SHA-256 hashes to determine if sectors are equal, instead of comparing each sector byte-for-byte. My tests were inconclusive as far as performance is concerned, but the ripper should work correctly either way.
Also, the way the comparison ripper handles caching is as follows. Let's say the track we are ripping consists of sectors 1-100. Before each rip, an amount of data not in sectors 1-100 is read to fill the drive's cache. Then, the track is ripped in its entirety. The process is then repeated until the specified number of matching rips is achieved. Comparison is performed on a sector-by-sector basis.
Posted: Tue May 30, 2006 2:24 pm
Beautiful simplicity. Can't believe it wasn't done before.
Thank you for your work!
Posted: Tue May 30, 2006 3:54 pm
Stephen, you are a hero to Mac users (who own CDs) everywhere.
Goodbye Windows, goodbye EAC, hello Max.
Posted: Tue May 30, 2006 4:10 pm
Aha, so Comparison is the new secure ripper. OK, thanks for working on this, if it works it's filling a huge gap on OS X.
I'll give it a try before posting on ABSL. I don't want to be torn apart over there so I'll check first if I can have Max generate a .log and .cue. Well, at least a .log.
And then I will be inevitably asked how the Drive Offset is handled or put in. Can you enlighten us on that one, please?
You see, purists won't even d/l posted rips without the correct drive offset and I'd really like to be able to play along...
Posted: Tue May 30, 2006 6:48 pm
Hermie wrote:Aha, so Comparison is the new secure ripper. OK, thanks for working on this, if it works it's filling a huge gap on OS X.
The "if it works" part might be correct- there may be a bug or a flaw in the implementation of the comparison ripper. I need to investigate some reports I've received to determine what exactly could be going on.
Posted: Tue May 30, 2006 6:54 pm
Thank you very much for all your efforts, I'm sure you'll get it right!
But what about the drive offset, please?
Posted: Tue May 30, 2006 7:08 pm
Hermie wrote:But what about the drive offset, please?
This is something I plan to implement in a future version. Hopefully within the next month or so, but I suppose it depends on the progress of the ripper.
Posted: Tue May 30, 2006 9:04 pm
This discussion has answered my question (in the other topic in Max Help) about what is "comparison ripping". I suppose it could produce excellent results if it works as it is supposed to, but from the forum Max Development I understand that more work needs to be done to this new feature.
In the meantime, I now wonder what is "drive offset" and whether I should bother.
Posted: Tue May 30, 2006 9:29 pm
Yes, I think you should bother. Perhaps this page might explain what it's all about:
At the bottom it has a link to their current drive list...
Posted: Tue May 30, 2006 9:38 pm
RonaldPR wrote:This discussion has answered my question (in the other topic in Max Help) about what is "comparison ripping". I suppose it could produce excellent results if it works as it is supposed to, but from the forum Max Development I understand that more work needs to be done to this new feature.
I think the jury is out on this- I believe the ripper works as advertised, but it cannot necessarily detect whether a disc is damaged or not. It does not perform any error checking/correction, only compares data.
RonaldPR wrote:In the meantime, I now wonder what is "drive offset" and whether I should bother.
When a CD drive accesses a point in a disc, it very rarely locates the "exact" location desired. The difference between the requested location and desired location is called offset. Since CDs are sampled at 44.1 KHz, and offsets are measured in samples, even for large offset values like 1000 we are talking about 1000/44100 = 0.02 seconds. So while for the absolute best DAE one wants to compensate for offset, in reality it may or may not be an issue.
Since for a given drive model the offset doesn't usually change, you can create more accurate representation of CD audio by adjusting for your drive's offset.
Posted: Tue May 30, 2006 10:09 pm
macfeller wrote:Beautiful simplicity. Can't believe it wasn't done before.
Sad to see that now I know why it wasn't done before. But hopefully it's a step in the right direction.
Again, thanks for the work.
Posted: Thu Jun 01, 2006 6:33 am
On the subject of drive offsets, I would love to see the same functionality and behavior as that in foobar2000 0.9.x. Adding this into the Ripper preferences would seem logical, and it would suit me fine if users would be on their own to determine whether 1) their drives support Accurate Stream, and 2) what the read offset is.
EAC's drive configuration is quite elaborate, but I think it's easy enough for users (especially those switching to Max from Windows rippers like EAC) to get a drive properly configured (with the correct read offset) on a Windows machine, rip a pressed CD, and then rip the same pressed CD with Max. Moving the Max output files from the Mac to the PC, the user can use a WAV comparison tool such as the one in EAC and easily determine the read offset of the drive in the Mac by comparing the Max output files with the ones ripped by EAC or other offset-corrected ripper.
Unfortunately, many of the stock drives in Apple computers are not listed at accuraterip.com, so a method such as the one I've described could be useful in some cases. In my case, I have already determined that the read offset of the drive in my Mac is +692 samples.
As far as I know, the command line cdda2wav (and related) tools allow the user to manually enter the drive offset at the time of ripping, so perhaps it wouldn't be such a complex process to take the value supplied in the Ripper preferences and modify the commands sent to the ripper.