title
Products            Buy            Support Forum            Professional            About            Codec Central
 

PerfectTunes says "Track too short for AccurateRip Verification", CD Ripper OK anyway

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • MarktheRipper

    • Jun 2024
    • 4

    PerfectTunes says "Track too short for AccurateRip Verification", CD Ripper OK anyway

    I am trying to verify the accuracy of a rip done on a machine that doesn't run Windows or macOS. I have the complete CD -- all 24 tracks -- as WAV files. Tracks 12 and 22 are each 5 seconds long, and PerfectTunes says (a) that the entire album was accurately ripped, but (b) "Track 12: Track too short for AccurateRip Verification" (same for Track 22).

    I find this odd, not to say contradictory. If it can't verify Track 12 or Track 22, how does it know the entire album has no errors? But wait, it gets weirder:

    I borrowed the CD and ripped it using dBpoweramp's CD Ripper. ALL the tracks, including the 5 second Track 12 and the 5 second Track 22, verify with AccurateRip, and CRCs are calculated for every track. Now, admittedly, Tracks 12 and 22 have confidence 14, and every other track has confidence 23 or 24, but no matter -- the fact remains that CD Ripper can compute an AccurateRip v2 CRC for a 5-second track, but PerfectTunes can't!

    Why is that? Shoudn't it be possible to verify a track after ripping the CD if it can be verified while ripping the CD? Think about it: you have to have already gotten the data off the CD in order to compute the CRC, so logically the track has already been ripped in both cases. Shouldn't PerfectTunes and CD Ripper have the same verification capabilities?

    As things stand, one cannot rely on PerfectTunes for after the fact verification in all cases. Perhaps that can be (and thus should be) corrected in an update.
  • Spoon
    Administrator
    • Apr 2002
    • 44579

    #2
    CD ripper knows the drive offset, Perfecttunes does not, so has to work on the worst case drive offset, that is why the latter cannot work with a 5 second track.
    Spoon
    www.dbpoweramp.com

    Comment

    • MarktheRipper

      • Jun 2024
      • 4

      #3
      Originally posted by Spoon
      CD ripper knows the drive offset, Perfecttunes does not, so has to work on the worst case drive offset, that is why the latter cannot work with a 5 second track.
      A fair starting point.
      It would also be a reasonable assumption that the collection of tracks being verified as a single CD were ripped on a single CD drive, rather than insisting on the possibility that some tracks were ripped separately from others and simply collected into one directory.

      In this case, 22 out of 24 tracks were verified with confidence 23 or 24 at an offset of +6.
      Would it not be reasonable to try an offset of +6 for the two 5-second tracks also, to see if they match the database?

      It should be a very rare CD indeed that would exhibit different offsets for individual tracks when ripped on one drive. Maybe in such cases PerfectTunes should try the same offset found to work on the preponderance of the tracks.

      I have attached the PerfectTunes results for these WAV files -- keep in mind that this was reported as "accurate" even though two tracks were not, in fact, even checked. ("1 album accurate ripped", and "24 tracks accurate".)
      Attached Files

      Comment

      • simbun
        dBpoweramp Enthusiast

        • Apr 2021
        • 96

        #4
        Originally posted by MarktheRipper
        As things stand, one cannot rely on PerfectTunes for after the fact verification in all cases. Perhaps that can be (and thus should be) corrected in an update.
        Whilst it may be more of a power users tool, I'm sure CUETools will get the job done.

        Comment

        • MarktheRipper

          • Jun 2024
          • 4

          #5
          Yes, CUETools works. Which (of course) only emphasizes that PerfectTunes should also be able to check all the tracks.

          Comment

          Working...

          ]]>