strategies for faster secure ripping

Discussion in 'Exact Audio Copy - English' started by semb, Nov 11, 2006.

  1. semb

    semb New Member

    One thing I would like EAC to do is for each track - first check to see if a CRC is available through AccurateRip - if it is, then try to rip the track using Burst mode, and only if this fails try again using Secure mode.

    Can I request this feature?

  2. calestyo

    calestyo Member Deluxe

    The thing is AccurateRip does not give you surely secure rips. Imagine different pressings or if someone transmitted multiple times wrong data. And Accurate Rip does not caculate its hashes over the whole file.
    I consider it more as an indicator.
  3. greynol

    greynol Member Deluxe

    That is not correct.

    First, if AccurateRip says the rip is accurate, even with a confidence as low as one (and the match isn't from your own submission), then you better believe it is accurate!

    Next, the only tracks for which the hash isn't calculated over the whole file are the first and last tracks. Respectively, these tracks do not have their first five frames and last five frames used as part of the calculation in order to compensate for drives with different offsets that cannot overread. The hashes for all the rest of the tracks are based on the whole file.

    Also, while it is true that the database contains submissions based on wrong data and different pressings, you should be skeptical when it says the tracks are not accurate, but you shouldn't be skeptical when it says they are accurate.

    Finally, do be aware that matching test and read CRCs does not prove that a rip is error-free regardless of the ripping mode used (burst, secure with or without C2, secure with or without cache flushing).
    Last edited: Nov 11, 2006
  4. calestyo

    calestyo Member Deluxe

    Yes you are right,... I know,... but as I wanted to say the results of AccurateRip are nor 100% results (at least for the first and last track, where afaik 5 sectors or so are not used for caculation).

    The next things are different pressings of CDs (althoug AccurateRip) suggests the user that he may have an differen pressing.

    Last but not leastafaik AccurateRip uses some CRC32...
    If you consider the fact, that it's even for md5 and (under special circumstances) even vor sha possible to get collisions, and consider the other fact that these two are much more secure from cryptoanalytical views (i.e. CRCxx's have benn afaik never used for cryptography at all because they're much to weak) than CRC... you can imagine that it is even more likely to get collisions with CRC32.
    And the resulting files over which the hashes are computet are quite large (in the average).
  5. greynol

    greynol Member Deluxe

    I hear you about CRC32 collisions. Personally I do not believe they are an issue when it comes to DAE but I am no expert.

    In light of this and to clarify what I said earlier, when it comes to matching CRCs and rips with errors, I'm not talking about collisions, I'm talking about consistent errors.

    I also think it's safe to assume that unless there is a consistent problem with an entire pressing, you aren't going to have the same consistent error as someone else that has submitted a result to the AccurateRip database.
    Last edited: Nov 11, 2006
  6. RobertH

    RobertH New Member

    This is an excellent idea, but I would amend it:

    1) Do a copy track in Burst mode.
    2) Check for a match with AccurateRip. If a single match is found, stop.
    3) Do a test track in Burst mode. Stop if there is a CRC match.
    4) Escalate to Secure mode.

    Maybe this isn't theoretically perfect, but it's as good as most of us with CD collections of any size would ever want. CRC collisions might occur in theory but are unimportant for those of us who don't plan to live for 400 years.

    This is the process I have followed manually for the last ~1300 rips, and it sure would be better if it had been automated!

Share This Page