title
Products            Buy            Support Forum            Professional            About            Codec Central
 

Preventing Secure Rip Aborts

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • ShrinerMonkey
    • Apr 2009
    • 17

    Preventing Secure Rip Aborts

    I have been using EAC and it would rip damaged tracks and report the errors instead of aborting. I could then listen to the suspicious portions to listen for artifacts. 99% of the time there were no audible problems so I could just ignore it.

    I have Secure rip enabled and would like dbpoweramp to rip damaged tracks instead of just aborting. Dbpoweramp will just abort the rip and I get nothing. How do I get dbpoweramp to behave like EAC on damaged disks?
  • ShrinerMonkey
    • Apr 2009
    • 17

    #2
    Re: Preventing Secure Rip Aborts

    To clarify:

    I want dbpoweramp to give me the best quality rip possible from damaged disks without aborting and deleting the entire rip. I would prefer to have the software do it's best job and then let me decide if the track is okay by listening to the portions that have errors. What options do I need to set in order to do this?

    Comment

    • Spoon
      Administrator
      • Apr 2002
      • 43902

      #3
      Re: Preventing Secure Rip Aborts

      The secure rip should never abort unless you set an 'Abort After' option on the secure page.
      Spoon
      www.dbpoweramp.com

      Comment

      • ShrinerMonkey
        • Apr 2009
        • 17

        #4
        Re: Preventing Secure Rip Aborts

        Right, but dbpoweramp guide recommends setting the Secure rip to abort after 1 unrecoverable frame, 100 re-rips, or 10 minutes of rip time. Even after changing those options to 'no abort' it still aborts the rip and deletes the file.

        I guess I am concerned that I am not getting as good a quality rips as I do with EAC. EAC will spend a lot of time doing error correction and only reports a few bad areas on tracks afterward. I guess this can be interpreted as EAC letting more errors through or it is better at error correction.

        I may be left with unpleasant option of having to re-rip damaged tracks with EAC.

        Comment

        • Spoon
          Administrator
          • Apr 2002
          • 43902

          #5
          Re: Preventing Secure Rip Aborts

          An unrecoverable error is an unrecoverable error, if you set the abort after then you are effectivly saying that on error do not continue to recover, if EAC reports errors at the end then it is the same as disabling the abort after option.
          Spoon
          www.dbpoweramp.com

          Comment

          • ShrinerMonkey
            • Apr 2009
            • 17

            #6
            Re: Preventing Secure Rip Aborts

            So if it can't recover an error the whole rip is canceled even if I disable the abort option? I turned off the abort options and it still aborts leaving me without a rip.

            Comment

            • Spoon
              Administrator
              • Apr 2002
              • 43902

              #7
              Re: Preventing Secure Rip Aborts

              Ripping to which format? multi encoder?
              Spoon
              www.dbpoweramp.com

              Comment

              • ShrinerMonkey
                • Apr 2009
                • 17

                #8
                Re: Preventing Secure Rip Aborts

                Originally posted by Spoon
                Ripping to which format? multi encoder?
                FLAC

                However, I do plan on using multi-encoder to do FLAC and MP3.

                Comment

                • Spoon
                  Administrator
                  • Apr 2002
                  • 43902

                  #9
                  Re: Preventing Secure Rip Aborts

                  Using R13.2? this latest release should encode the file even if there is an error.
                  Spoon
                  www.dbpoweramp.com

                  Comment

                  • pangit
                    • Mar 2009
                    • 17

                    #10
                    Re: Preventing Secure Rip Aborts

                    ShrinerMonkey, I agree with you and have had the same concerns and frustrations. I often have to use EAC to rip a problematic track that dBpoweramp won't seem to handle. What always happens to me with these - even though I have also set mine NOT to abort in case of errors - is that the resulting unplayable file has a very small size, typically only a few kilobytes. So I go into EAC, and in every case (and there have been many) I've been able to get the track ripped that dBpoweramp wouldn't encode. I rip it to a WAV, and then use dBpoweramp to encode it to a FLAC.

                    Incidentally, after reading Spoon's comment about using version 13.2 (which supposedly should encode even in the case of errors), I upgraded to that version today, and then tried re-ripping a disc I know to be problematic. Same exact results - the problem track produced a useless 15Kb file, so I had to rip it with EAC. The problem track did NOT encode successfully.

                    I also agree that EAC's feature of allowing you to listen to potential problem spots after a track rips with errors is extremely useful, and I really wish dBpoweramp did something like that.

                    I love dBpoweramp overall, but this aspect of it does frustrate me quite a bit. :cry:

                    Comment

                    • bhoar
                      dBpoweramp Guru
                      • Sep 2006
                      • 1173

                      #11
                      Re: Preventing Secure Rip Aborts

                      What happens if you burst rip the track in dbpoweramp?

                      -brendan

                      Comment

                      • ShrinerMonkey
                        • Apr 2009
                        • 17

                        #12
                        Re: Preventing Secure Rip Aborts

                        Originally posted by pangit
                        ShrinerMonkey, I agree with you and have had the same concerns and frustrations. I often have to use EAC to rip a problematic track that dBpoweramp won't seem to handle. What always happens to me with these - even though I have also set mine NOT to abort in case of errors - is that the resulting unplayable file has a very small size, typically only a few kilobytes. So I go into EAC, and in every case (and there have been many) I've been able to get the track ripped that dBpoweramp wouldn't encode. I rip it to a WAV, and then use dBpoweramp to encode it to a FLAC.

                        Incidentally, after reading Spoon's comment about using version 13.2 (which supposedly should encode even in the case of errors), I upgraded to that version today, and then tried re-ripping a disc I know to be problematic. Same exact results - the problem track produced a useless 15Kb file, so I had to rip it with EAC. The problem track did NOT encode successfully.

                        I also agree that EAC's feature of allowing you to listen to potential problem spots after a track rips with errors is extremely useful, and I really wish dBpoweramp did something like that.

                        I love dBpoweramp overall, but this aspect of it does frustrate me quite a bit. :cry:
                        That is the EXACT problem I am having.... useless 15kb file after errors even with abort options disabled. I am also running R13.2 also BTW. This problems is very frustrating because I was planning on re-ripping about 200 CDs but don't want to bother if I will have to deal with the error tracks in this way. I am weighing the hassle of fixing bad tags from EAC vs re-ripping in dbpa and dealing with the poor error handling.

                        I am a little bit vexed that I paid money for this software and have to deal with such an obvious flaw. Next time I will test the trial version more before purchase.

                        Unrelated question:

                        Does DBpoweramp have a feature that allows editing tags of already ripped files using it's metadata providers?

                        Comment

                        • ShrinerMonkey
                          • Apr 2009
                          • 17

                          #13
                          Re: Preventing Secure Rip Aborts

                          Originally posted by bhoar
                          What happens if you burst rip the track in dbpoweramp?

                          -brendan
                          The track rips and doesn't report errors. Funny thing, I listened to the track and could hear no audible errors, but that is the case with almost every problematic track. Regardless, I don't really care because I don't intend to rip without accurate rip options.

                          Comment

                          • pangit
                            • Mar 2009
                            • 17

                            #14
                            Re: Preventing Secure Rip Aborts

                            I haven't tried burst rip myself. It never occurred to me to do so, since I have a few thousand discs to rip and want the highest accuracy possible. I have UltraSecure rips enabled and my setup is AccurateRip verified - it seems this sort of configuration should be more robust, not less.

                            If I get time I may give the burst mode a shot to corroborate what ShrinerMonkey reported, but ultimately that mode is of no interest to me. The ultra-secure and AccurateRip capability is one of the main reasons I purchased this product, so I would hope these issues could be resolved at some point.

                            Comment

                            • ShrinerMonkey
                              • Apr 2009
                              • 17

                              #15
                              Re: Preventing Secure Rip Aborts

                              So is the concensus that I will have to use EAC to rip tracks that dbpoweramp aborts on? Should I contact support about this issue to see if they can help?

                              Comment

                              Working...

                              ]]>