Ripping Fails On First Pass

**BruceH** · April 13, 2009, 06:12 AM

Re: Ripping Fails On First Pass

Here are additional diagnostics that I believe implicate a bug in Vers. 13.2

Hi Spoon,

I have been pulling my hair out over the past few days, trying to figure out why one or two tracks fail to rip every few disks, even with very clean CDs. It is always the same track that fails. I supposed that my LiteOn DX-20A4PU was just not a very good drive for ripping, and have posted extensively on CDFreaks to find information about a better drive to buy. However, veterans over at that forum insisted that my drive should be good for ripping. I tested my drive with Diskspeed 5 and see that it reads very accurately and is a speed demon.

Then I noticed that the tracks that fail (same track every time) fail at precisely the last six frames of the track, on the first pass. That is, dBpoweramp Ripper does not even attempt an Ultra Pass. The other piece that is weird here is that the failed tracks rip successfully at the first Ultra Pass using my Dell D620 laptop DVD drive. This behaviour suggested to me that the drive might be at fault, although that was puzzling since these are very clean CDs. Thus my posts in CDFreaks to find a better drive. I finally tested the LiteOn drive and found it exceptional at reading/ripping, as reported below.

By the way, please do not be concerned about FUA being enabled. It is enabled because dBpoweramp reports FUA support as available. However, the above-reported failure occurs with FUA enabled, FUA disabled and 2048 cache (actual cache size of this drive), or 1024 cache (value that you repeatedly declare as safe to use).

Here follows the log entry using the LiteOn drive:

====================

dBpoweramp Release 13.2 Digital Audio Extraction Log from Sunday, April 12, 2009 10:58 PM

Drive & Settings
----------------

Ripping with drive 'E: [ATAPI - DVD A DH20A4P ]', Drive offset: 6, Overread Lead-in/out: No
AccurateRip: Active, Using C2: Yes, Cache: None, FUA Cache Invalidate: Yes
Pass 1 Drive Speed: Max, Pass 2 Drive Speed: Max
Ultra:: Vary Drive Speed: No, Min Passes: 1, Max Passes: 6, Finish After Clean Passes: 1
Bad Sector Re-rip:: Drive Speed: 4, Maximum Re-reads: 500

Encoder: FLAC -compression-level-5 -verify
DSP Effects / Actions: -dspeffect1="Audio CD - Hidden Track Silence Removal= -digsilence -dbsilence={qt}-45{qt} -window={qt}4000{qt}" -dspeffect2="Audio CD - Silence Track Deletion= -digsilence -dbsilence={qt}-45{qt}" -dspeffect3="HDCD=" -dspeffect4="ReplayGain=-albummode={qt}1{qt}" -dspeffect5="Move Destination File on Error= -root={qt}[origpath]{qt} -naming={qt}error\[origfilename]{qt}"

Extraction Log
--------------

Track 3: ERROR Ripping LBA 36699 to 51472 (3:16) in 0:12. Filename: C:\A-temp\Judy Collins\Classic Folk\Judy Collins - 03 - Both Sides Now.flac
Unable to read CD, check CD disc (frame LBA 51467 ripping 6 frames track end LBA 51472)
--------------
1 Tracks Could Not Be Ripped

Here follows the log entry from a rip of the same track using the laptop drive:

====================
dBpoweramp Release 13.2 Digital Audio Extraction Log from Sunday, April 12, 2009 11:38 PM

Drive & Settings
----------------

Ripping with drive 'D: [HL-DT-ST - DVD+-RW GSA-T11N]', Drive offset: 667, Overread Lead-in/out: No
AccurateRip: Active, Using C2: Yes, Cache: None, FUA Cache Invalidate: Yes
Pass 1 Drive Speed: Max, Pass 2 Drive Speed: Max
Ultra:: Vary Drive Speed: No, Min Passes: 1, Max Passes: 6, Finish After Clean Passes: 1
Bad Sector Re-rip:: Drive Speed: Max, Maximum Re-reads: 500

Encoder: FLAC -compression-level-5 -verify
DSP Effects / Actions: -dspeffect1="Audio CD - Hidden Track Silence Removal= -digsilence -dbsilence={qt}-45{qt} -window={qt}4000{qt}" -dspeffect2="Audio CD - Silence Track Deletion= -digsilence -dbsilence={qt}-45{qt}" -dspeffect3="HDCD=" -dspeffect4="ReplayGain=-albummode={qt}1{qt}" -dspeffect5="Move Destination File on Error= -root={qt}[origpath]{qt} -naming={qt}error\[origfilename]{qt}"

Extraction Log
--------------

Track 3: Ripped LBA 36699 to 51472 (3:16) in 0:29. Filename: C:\A-temp\Judy Collins\Classic Folk\Judy Collins - 03 - Both Sides Now.flac
Secure [Pass 1, Ultra 1 to 1]
CRC32: A7384781 AccurateRip CRC: E32A7E8C [DiscID: 012-0015ab13-00ca5596-a60b790c-3]
--------------
1 Tracks Ripped Securely

Here follows results from DiskSpeed testing of the CD using the LiteOn drive:

General Information
Drive: ATAPI DVD A DH20A4P
Firmware: 9P59
Disc: Audio CD
Selected speed: Maximum
C1 Errors
Maximum: 32
Average: 0.93
Total: 2723
C2 Errors
Maximum: 0
Average: 0.00
Total: 0
Jitter: -
Scanning Statistics
Elapsed time: 2:00
Number of samples: 2930
Average scanning interval: 1.00 sec
Glitches removed: 0

With a quality score of 95%, as you can see, the disk/reader combination is practically pristine, with a low number of C1 errors and zero C2 errors. The DiskSpeed DAE test yields the highest DAE score of 10.

What is going on here? The track is obviously not physically bad, as demonstrated by the good rip in 29 seconds using the laptop drive and the DiscSpeed results. The LiteOn drive reads very nicely, as reported by DiscSpeed. dBpoweramp gives up at the end of the track without even attempting an Ultra Pass. It is pretty clear to me that there is a bug in 13.2 causing this, probably an improper branch to the abort routine upon sensing some condition from the LiteOn drive, given that the problem does not occur with the cheap laptop drive.

Please fix this ASAP, because I need to rip CDs. Feel free to email any patched version to me for testing.

Thank you,
Bruce

**BruceH** · April 13, 2009, 07:38 AM

Re: Preventing Secure Rip Aborts

Spoon,

Does de-selecting C2 support decrease the security of an Ultra Pass or simply slow it down?

Thanks,
Bruce

**bhoar** · April 13, 2009, 01:17 PM

Re: Preventing Secure Rip Aborts

Originally posted by BruceH

For grins, could you try ripping one or more of the "bad" tracks again with the C2 option unchecked to see if behavior is different? Please report results here.

I have experienced a similar but somewhat different problem that resolved by turning C2 off in dBpoweramp options, possibly indicating a bug in dBpoweramp's C2 logic. If your results change by turning C2 off, that could add support to this idea.

Bruce,

Possibly, but it could also indicate a bug in that specific drive's C2 logic or the error detection/correction data itself on some discs may be faulty.

-brendan

**BruceH** · April 13, 2009, 06:58 PM

Re: Preventing Secure Rip Aborts

Originally posted by bhoar

Bruce,

Possibly, but it could also indicate a bug in that specific drive's C2 logic or the error detection/correction data itself on some discs may be faulty.

-brendan

Brendan,

Not likely the disk, because same behavior across several disks. Yes, could be the LiteOn, except that DiskSpeed reports zero C2 errors for this disk with the LiteOn (see this thread for the full report:

http://forum.dbpoweramp.com/showthread.php?t=18871

It may well be an incompatibility between dBpoweramp's C2 logic and the C2 logic in certain drives. (E.g., dB reads the C2 register before/after it is valid, slow to react to an interrupt from the drive, etc.) However, dB must work with all drives, or certainly with all common drives such as LiteOns.

**Spoon** · April 13, 2009, 09:30 PM

Re: Ripping Fails On First Pass

The DiscSpeed program would read the disc differently (asking for data in different ways, such as block size, etc).

C2 logic is very simple it is a 1 bit flag, if dBpoweramp asks for it ie '1', rather than '0' then the drive should return valid data - never fail as your liteon drive is doing.

It is a failure of the drive, as:

Unable to read CD, check CD disc (frame LBA 51467 ripping 6 frames track end LBA 51472)

Notice it is right at the end of the track, normally we request that ~30 frames are read, but obviously for the last read less frames are read.

On this CD how many tracks are there?

However, veterans over at that forum insisted that my drive should be good for ripping

CD drives have internal CPUs, programs which have been known to have issues (there are many drives which have issues, because of the drive).

**bhoar** · April 13, 2009, 09:38 PM

Re: Preventing Secure Rip Aborts

Originally posted by BruceH

Not likely the disk, because same behavior across several disks. Yes, could be the LiteOn, except that DiskSpeed reports zero C2 errors for this disk with the LiteOn (see this thread for the full report:

Ripping Fails On First Pass - dBpoweramp Forum

http://forum.dbpoweramp.com/showthread.php?t=18871

Hi All, I have been pulling my hair out over the past few days, trying to figure out why one or two tracks fail to rip every few disks, even with very clean CDs. It is always the same track that fails. I supposed that my LiteOn DX-20A4PU was just not a very good drive for ripping, and have posted extensively on CDFreaks to

It may well be an incompatibility between dBpoweramp's C2 logic and the C2 logic in certain drives. (E.g., dB reads the C2 register before/after it is valid, slow to react to an interrupt from the drive, etc.) However, dB must work with all drives, or certainly with all common drives such as LiteOns.

Well, I don't think the proposed reasons above are possible with the way that C2 works. Turning on C2 (via a single flag in the read request) isn't supposed to change the way the drive works, it just means that instead of each read returning this:

...DATA+DATA+DATA+DATA+DATA+DATA...

Each read returns this instead:

...DATA+C2+DATA+C2+DATA+C2+DATA+C2+DATA+C2+DATA...

Other than returning extra c2 flag data, there's no particular behavior change requested. Due to buffer size limitations, the number of frames per read request might differ with C2 on because of the larger amount of information reported for each frame.

If having C2 enabled *is* leading to different behavior when requesting the same LBA frames (or MM:SS:FF frames), then it means the drive is unexpectedly flipping out, perhaps due to some sort of larger-than-expected read request or perhaps a read-request w/ C2 on that has an odd number of frames aligned a certain way, etc... That's really gotta be a firmware issue on the drive. e.g. it's not C2 per se that triggers the problem, but rather the per frame data size changes trigger it.*

If other programs don't trigger it, then the drive is acting out due to the particular access pattern that dbpa uses, but that's not really dbpa's fault...

-brendan

* something similar has come up in the past regarding USB and firewire bridges, which were sensitive to both buffer sizes as well as buffer-alignment issues...this wasn't generally drive specific, but interface specific.

**BruceH** · April 13, 2009, 09:40 PM

Re: Preventing Secure Rip Aborts

I just used EAC with C2 enabled to rip a track that fails every time with C2 enabled on dBpoweramp. The track also rips perfectly in dBpoweramp with C2 disabled. So it is not the drive; it is a bug in dBpoweramp.

Why the author cannot admit that there is a bug and fix it is beyond me.

See EAC log below:

[COLOR=navy][SIZE=3]Exact Audio Copy V0.99 prebeta 4 from 23. January 2008[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]EAC extraction logfile from 13. April 2009, 16:25[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Judy Collins / Classic Folk[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Used drive : ATAPI DVD A DH20A4P Adapter: 2 ID: 0[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Read mode : Secure[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Utilize accurate stream : Yes[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Defeat audio cache : Yes[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Make use of C2 pointers : Yes[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Read offset correction : 6[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Overread into Lead-In and Lead-Out : No[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Fill up missing offset samples with silence : Yes[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Delete leading and trailing silent blocks : No[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Null samples used in CRC calculations : No[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Used interface : Native Win32 interface for Win NT & 2000[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Gap handling : Not detected, thus appended to previous track[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Used output format : User Defined Encoder[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Selected bitrate : 768 kBit/s[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Quality : High[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Add ID3 tag : No[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Command line compressor : C:\Program Files\Exact Audio Copy\FLAC\FLAC.EXE[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Additional command line options : -6 -V -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" -T "COMMENT=%e" %s -o %d[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]TOC of the extracted CD[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Track | Start | Length | Start sector | End sector [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] ---------------------------------------------------------[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 1 | 0:00.00 | 3:36.62 | 0 | 16261 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 2 | 3:36.62 | 4:32.37 | 16262 | 36698 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 3 | 8:09.24 | 3:16.73 | 36699 | 51471 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 4 | 11:26.22 | 5:16.60 | 51472 | 75231 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 5 | 16:43.07 | 4:47.50 | 75232 | 96806 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 6 | 21:30.57 | 2:41.74 | 96807 | 108955 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 7 | 24:12.56 | 3:50.42 | 108956 | 126247 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 8 | 28:03.23 | 4:10.31 | 126248 | 145028 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 9 | 32:13.54 | 3:38.71 | 145029 | 161449 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 10 | 35:52.50 | 4:18.46 | 161450 | 180845 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 11 | 40:11.21 | 4:25.02 | 180846 | 200722 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 12 | 44:36.23 | 4:21.29 | 200723 | 220326 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Track 3[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Filename C:\A-temp\Both Sides Now.wav[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Peak level 98.8 %[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Track quality 99.8 %[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Test CRC DE6A76C3[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Copy CRC DE6A76C3[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Track not present in AccurateRip database[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Copy OK[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]None of the tracks are present in the AccurateRip database[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]No errors occurred[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]End of status report[/SIZE][/COLOR]

**bhoar** · April 13, 2009, 09:47 PM

Re: Preventing Secure Rip Aborts

Again, just because the issue comes up with dbpa doesn't mean it's a bug in dbpa. e.g. let's imagine that EAC only uses LBA frame addressing, but dbpa uses both LBA frame and MMSSFF frame addressing and lets also imagine the drive in question works correctly with LBA frame addressing all the time, but fails under some circumstances at the end of some tracks when using MMSSFF frame addressing with C2 enabled...then you'll only see a problem with dbpa.

Spoon could consider engineering a workaround for specific buggy drive firmwares. He could consider blacklisting the buggy drives and reporting the drives as unsupported to the user. He could also consider rewriting his read routines specifically to notice odd situations like this and try adaptively different IO pattern approaches until the read worked. He could tell people to avoid the drive.

But it's not a bug in dbpa, it's a bug in the drive.

-brendan

**BruceH** · April 13, 2009, 09:51 PM

Re: Ripping Fails On First Pass

Originally posted by Spoon

The DiscSpeed program would read the disc differently (asking for data in different ways, such as block size, etc).

C2 logic is very simple it is a 1 bit flag, if dBpoweramp asks for it ie '1', rather than '0' then the drive should return valid data - never fail as your liteon drive is doing.

It is a failure of the drive, as:

Unable to read CD, check CD disc (frame LBA 51467 ripping 6 frames track end LBA 51472)

Notice it is right at the end of the track, normally we request that ~30 frames are read, but obviously for the last read less frames are read.

On this CD how many tracks are there?

CD drives have internal CPUs, programs which have been known to have issues (there are many drives which have issues, because of the drive).

No, Spoon; it is not the drive. Please see log of successful C2 rip using EAC with C2 of the track that rips perfectly in dBpoweramp with C2 disabled but fails every time with C2 enabled. I am a EE and not so easy to put off with finger-pointing toward the opposite side of the interface. I have been in this industry too long and seem way more than my share of the finger-pointing routine. I have methodically narrowed this problem down to your application. Please fix it. This denial mode will not help your sales.

To answer your red herring question, the CD has 12 tracks total.

[COLOR=navy][SIZE=3]Exact Audio Copy V0.99 prebeta 4 from 23. January 2008[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]EAC extraction logfile from 13. April 2009, 16:25[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Judy Collins / Classic Folk[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Used drive : ATAPI DVD A DH20A4P Adapter: 2 ID: 0[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Read mode : Secure[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Utilize accurate stream : Yes[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Defeat audio cache : Yes[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Make use of C2 pointers : Yes[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Read offset correction : 6[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Overread into Lead-In and Lead-Out : No[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Fill up missing offset samples with silence : Yes[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Delete leading and trailing silent blocks : No[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Null samples used in CRC calculations : No[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Used interface : Native Win32 interface for Win NT & 2000[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Gap handling : Not detected, thus appended to previous track[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Used output format : User Defined Encoder[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Selected bitrate : 768 kBit/s[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Quality : High[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Add ID3 tag : No[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Command line compressor : C:\Program Files\Exact Audio Copy\FLAC\FLAC.EXE[/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Additional command line options : -6 -V -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" -T "COMMENT=%e" %s -o %d[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]TOC of the extracted CD[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Track | Start | Length | Start sector | End sector [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] ---------------------------------------------------------[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 1 | 0:00.00 | 3:36.62 | 0 | 16261 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 2 | 3:36.62 | 4:32.37 | 16262 | 36698 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 3 | 8:09.24 | 3:16.73 | 36699 | 51471 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 4 | 11:26.22 | 5:16.60 | 51472 | 75231 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 5 | 16:43.07 | 4:47.50 | 75232 | 96806 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 6 | 21:30.57 | 2:41.74 | 96807 | 108955 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 7 | 24:12.56 | 3:50.42 | 108956 | 126247 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 8 | 28:03.23 | 4:10.31 | 126248 | 145028 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 9 | 32:13.54 | 3:38.71 | 145029 | 161449 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 10 | 35:52.50 | 4:18.46 | 161450 | 180845 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 11 | 40:11.21 | 4:25.02 | 180846 | 200722 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] 12 | 44:36.23 | 4:21.29 | 200723 | 220326 [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]Track 3[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Filename C:\A-temp\Both Sides Now.wav[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Peak level 98.8 %[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Track quality 99.8 %[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Test CRC DE6A76C3[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Copy CRC DE6A76C3[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Track not present in AccurateRip database[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] Copy OK[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]None of the tracks are present in the AccurateRip database[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]No errors occurred[/SIZE][/COLOR]
[COLOR=navy][SIZE=3] [/SIZE][/COLOR]
[COLOR=navy][SIZE=3]End of status report[/SIZE][/COLOR]

**BruceH** · April 13, 2009, 09:52 PM

Re: Ripping Fails On First Pass

P.S. I am getting REALLY fed up with this.

**LtData** · April 14, 2009, 12:06 AM

Re: Ripping Fails On First Pass

Posts on this topic from another thread moved to this thread to keep the conversation in the same thread.

**BruceH** · April 14, 2009, 12:09 AM

Re: Preventing Secure Rip Aborts

Originally posted by bhoar

Again, just because the issue comes up with dbpa doesn't mean it's a bug in dbpa. e.g. let's imagine that EAC only uses LBA frame addressing, but dbpa uses both LBA frame and MMSSFF frame addressing and lets also imagine the drive in question works correctly with LBA frame addressing all the time, but fails under some circumstances at the end of some tracks when using MMSSFF frame addressing with C2 enabled...then you'll only see a problem with dbpa.

Spoon could consider engineering a workaround for specific buggy drive firmwares. He could consider blacklisting the buggy drives and reporting the drives as unsupported to the user. He could also consider rewriting his read routines specifically to notice odd situations like this and try adaptively different IO pattern approaches until the read worked. He could tell people to avoid the drive.

But it's not a bug in dbpa, it's a bug in the drive.

-brendan

Do you work for Spoon, Brendan, or are you a principal in the company? You certainly are a "yes man" for Spoon and for the product. It amost seems as though you were his alter ego.

And you must be intimately familiar with the software internals to declare that there is no bug in the application. How do you know that the application is bug-free in this area? If dBpoweramp were bug free there would be no dot revs; and we know that there are (.2 currently). And how can you be so sure that my drive is not handling C2 properly? You are making quite a determined statement that flies in the face of all the testing that I have done. And the red herring remote possibility that you have conjured up also flies in the face of my testing.

Why? Because it does not explain why dBpoweramp aborts the rip at the end of the first pass instead of moving on to the the Ultra pass(es). At best this is a bug, because a clean track (as I have shown this test track to be--very clean) would almost certainly pass secure with a good compare of first and subsequent passes. But the software aborts.

Are we into semantics here? Do you not like the term "bug"? Ok; call it whatever you wish, just fix it! dBpoweramp detects the drive's C2 capability and then aborts when the C2 mechanism somehow fails as a result of some condition on a track that is not related to errors on the track. The least that Spoon could do is identify the condition and eliminate the call to the abort routine on occurrence of the condition so that the track can rip secure at the second pass. I have even offered to run a debugger version of the application here with breakpoints to help Spoon find the failure condition, if he wants to send me such a tool. How you two can struggle so hard against this simple logic and lose customers over it is beyond me.

You have hinted at the problem. dBpoweramp is not advertised as being limited to a certain population of drives or conditions of drive registers; but it appears to be. The application needs to work with all common drives. A LiteOn DVD RAM drive is not an exotic and should be no exception. I believe that one of your conjectures is correct. dBpoweramp has a narrow envelope of operation in some situations that causes ripping failures to occur in these situations. It is not unusual for problems to occur at the interface of different vendors' equipment/software. That is why we have standards.

I suspect that there is a standard governing use of the C2 bit. And when there is a conflict, as apparently exists here under certain conditions associated with certain tracks (not errors), I would put my money on LiteOn as having engineered their product to the standard and dBpoweramp being the entity out of spec any day.

In any case, responsible companies dig in to characterize the problem so that they can fix it or know for certain that the source is at the opposite side of the interface. Less responsible companies simply make up excuses, issue bald assertions that the problem is not theirs (which is impossible to know without characterizing the problem), and leave the customer stuck. Such a pattern is seen time after time in these dBpoweramp forums.

It is unacceptable to sell drive software and then simply say to the customer "sorry, your drive is the problem; get another drive." And that is what I hear you and Spoon saying over and over in these forums. In this case, I have handed Spoon hours of diagnostics on a silver platter to point him to the general code location that is causing the problem. And the only response from you two is to brazenly assert that the drive is at fault without presenting a shred of evidence supporting the assertion. I suspect that the LiteOn engineers would disagree with you. And which entity is more likely to create a product with bugs, a huge corporation with massive engineering resources, whose engineers create the standards, or a garage-shop software author?

I have read enough posts on this forum to have noticed a distinct pattern. If a customer has a simple problem that can be solved with a short answer, the answer is provided and that customer's problem is solved. However, when a serious problem is posted that may implicate the application, Spoon often provides a short answer that is either off-topic (red herring) or is of a finger-pointing nature. And then you chime in with support for Spoon's position. (You seem to be on the forum at the same time as Spoon with surprising regularity.)

The earlier part of this thread is a case in point. Spoon at one point agreed that ShrinerMonkey's results were unexpected "The secure rip should never abort unless you set an 'Abort After' option on the secure page." Spoon then asked a few questions and requested a log, which Shriner quickly supplied. During these exchanges you supplied these standard, tired words of wisdom, "I'd probably try a different manufacturer's drive. Or, if the disc in in accuraterip, a burst rip and hope it comes through accurate." Things work as they should in EAC; but if you have problems in dB under the same conditions, blame it on the drive or live with the problem. Soon the customer becomes weary of this game and goes away.

I am getting really fed up with this nonsense; and I an not going away.

Your response is a real shame, because you have the foundation for a great product. It is well-known on the street that dBpoweramp has the best GUI and that EAC has the most reliable ripping engine. But note that customers can live without the GUI but cannot live with unreliable ripping engine guts. With a quirky ripping engine, dBpoweramp is just another pretty face.

Please characterize the problem and fix it if it is on your end, the latter a likelihood that my testing suggests. At the very least, fix the unhelpful call to the abort routine so that we can get a secure rip when C2 fails.

**bhoar** · April 14, 2009, 03:24 AM

Re: Preventing Secure Rip Aborts

Originally posted by BruceH

Do you work for Spoon, Brendan, or are you a principal in the company? You certainly are a "yes man" for Spoon and for the product. It amost seems as though you were his alter ego.

No. My specialty is in automating robots. I do have an interest in the batch ripper doing well as I sell some add-on drivers directly to folks (I can count them all on one hand so far).

The reason I'm somewhat experienced in the C2 logic and have some knowledge of this is that I have, in the past, helped zero in on a bug in the product when dealing with firewire drives. Yes, indeed, the product had bugs in the past, has bugs now and will have them in the future. That's software.

Because of the firewire issue in the past, I have studied the T10 MMC-3 spec in depth, which describes how to obtain C2 flag data from modern drives using new flags on two standard read commands. Spoon did email me (once) a very short snippet of code related to how large reads were split in half when I was trying to figure out what was going wrong.

I used his code snippet as a model for creation of some tests with the plscsi ata/scsi command-line tool and created log files which I later submitted to spoon to show evidence for my theory on why the original code (now fixed) was leading to the problems with firewire, due to firewire controllers requiring more strict buffer alignment than all other interface types.

So let me be clear: I have never completely ruled out that there's a bug in spoon's code and if I said that unconditionally, I offer an apology and I should not have. What I should have be more explicit in saying is that, in my opinion, a bug in the drive's firmware or interface bridge firmware is a more likely culprit with the symptoms you have described.

If it is the drive (or drive + interface...this is a USB device, right?), that doesn't mean spoon can't work around the problem. This wouldn't be the only drive out there that has some strange behavior of one kind or another, though.

-brendan

PS - the reason I was so focused on the firewire issue was due to having collected about 30 cd robots that all came with firewire interfaces...and I wanted C2 to work correctly with them. It was frustrating that it did not, so really, I understand how you feel... x30 or more.

**Spoon** · April 14, 2009, 08:32 AM

Re: Preventing Secure Rip Aborts

Because it does not explain why dBpoweramp aborts the rip at the end of the first pass instead of moving on to the the Ultra pass(es).

If the drive is failing to read audio then there will be no ultra passes - the SCSI spec states a drive should never fail like this, of the ~5,000 drives out there very few do.

I have even offered to run a debugger version of the application here with breakpoints to help Spoon find the failure condition

We do not give out our source code...

I suspect that there is a standard governing use of the C2 bit. And when there is a conflict, as apparently exists here under certain conditions associated with certain tracks (not errors), I would put my money on LiteOn as having engineered their product to the standard and dBpoweramp being the entity out of spec any day.

You have read the SCSI spec? Unless you have you cannot make such assumptions. I would hazzard guess we have spent more time working with the SCSI spec than the developers of the drive firmware - it is what we do year in year out.

t is unacceptable to sell drive software and then simply say to the customer "sorry, your drive is the problem; get another drive." And that is what I hear you and Spoon saying over and over in these forums. In this case, I have handed Spoon hours of diagnostics on a silver platter to point him to the general code location that is causing the problem. And the only response from you two is to brazenly assert that the drive is at fault without presenting a shred of evidence supporting the assertion. I suspect that the LiteOn engineers would disagree with you. And which entity is more likely to create a product with bugs, a huge corporation with massive engineering resources, whose engineers create the standards, or a garage-shop software author?

Hence why we offer a full 21 day trial, so people can fully try the software.

I have read enough posts on this forum to have noticed a distinct pattern. If a customer has a simple problem that can be solved with a short answer, the answer is provided and that customer's problem is solved. However, when a serious problem is posted that may implicate the application, Spoon often provides a short answer that is either off-topic (red herring) or is of a finger-pointing nature. And then you chime in with support for Spoon's position. (You seem to be on the forum at the same time as Spoon with surprising regularity.)

...and did you read all 15,000 posts I have made? you state you have been in this game for a long time, I have been in it for 12 years - I have seen all sorts over the years - including one guy who was sure that CD Ripper had broken his mouse and was demanding (like you) instant fixes. When a program is used on 20 million installations that exposes you to a large sway of the population. I wish we could help everyone, help is given to those who can be helped.

Please characterize the problem and fix it if it is on your end, the latter a likelihood that my testing suggests. At the very least, fix the unhelpful call to the abort routine so that we can get a secure rip when C2 fails.

We will not code specifically for bad drives - our code base would grow to many times its current size and people with good drives might suffer from induced bugs.

I am getting really fed up with this nonsense; and I an not going away.

This is an open forum, but be warned, if this thread deteriorates into name calling (it is border-line of how you are responding to Brendan, with almost contempt - he is not affiliated to Illustrate and is giving up his time to help you) - this thread will be locked. If your time is 'cheap', please persist, you could spend $25 on a DVD drive with no issues, or use a different program, your choice...

Ripping Fails On First Pass

Ripping Fails On First Pass

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment