dBpoweramp Release 13.1

[bhoar]

Re: dBpoweramp Release 13.1

Spies - can you also try EAC's C2 support with a disc in the changer drive?

-brendan

[Spies]

Re: dBpoweramp Release 13.1

Spies:

You would have to try a direct connection to the drive, and use R13.0 to verify where the problem lies. (ie if R13.0 works and R13.1 does not with a direct IDE connection then the problem is R13.1, if not then the problem is the drive reporting false c2 errors).

This may not be a practical thing for me to try at the moment since it will most likely require me to completely disassemble the changer. To be honest I am not to comfortable with the idea either. I will have to think about it.

Spies - can you also try EAC's C2 support with a disc in the changer drive?

-brendan

Excellent idea brendan! Turns out that EAC is able to use the C2 pointers with this changer without issue. This makes me wonder how different dBpoweramp's implementation of C2 pointers is from EAC's. Knowing now that C2 works with EAC will taking apart the changer still be necessary to help facilitate a solution for dBpoweramp?

[bhoar]

Re: dBpoweramp Release 13.1

Excellent idea brendan! Turns out that EAC is able to use the C2 pointers with this changer without issue. This makes me wonder how different dBpoweramp's implementation of C2 pointers is from EAC's. Knowing now that C2 works with EAC will taking apart the changer still be necessary to help facilitate a solution for dBpoweramp?

Ok. I did some build testing for spoon a couple of weeks back with two of my firewire bridges and had success. Hmmm. Might be an issue specific to the XL1B, or perhaps the fixes for C2 over firewire didn't make it correctly into the last beta release.

I'll retest my two firewire bridges tomorrow and also try a test with one of my XL1B units as well.

-brendan

[bhoar]

Re: dBpoweramp Release 13.1

The new beta (20080906) release works with my current firewire bridges (like spoon's test build did). I need to re-setup my XL1B system to test if that acts any differently.

-brendan

[Spoon]

Re: dBpoweramp Release 13.1

If EAC works with it then there is not need to take the Sony apart What is the pattern of c2 error detection? in clumps together? or spread evenly over the disc (if you switch on the most detailed logging it gives positions). With another CD are the positions the same?

[bhoar]

Re: dBpoweramp Release 13.1

If EAC works with it then there is not need to take the Sony apart What is the pattern of c2 error detection? in clumps together? or spread evenly over the disc (if you switch on the most detailed logging it gives positions). With another CD are the positions the same?

I can repeat the problem on my XL1B.

e.g.:

I have a scratched copy of The Unforgettable Fire, and am ripping the last track because it is shortest and also on the fastest part of the disc.

With C2 off, after two passes, it tells me there are 97 frames to rerip.

With C2 on, after one pass, it tells me there are 2363 frames to rerip, seemingly spread out pretty evenly across the track.

Same disc/track in my PX-230a: with c2 off, 361 frames, with c2 on 270 frames.

I sent the logs from all four tests to spoon. All four were conducted on the same notebook.

-brendan

EDIT: had the numbers for the wrong track, fixed.

[bhoar]

Re: dBpoweramp Release 13.1

Hmm. Looking at the log of XL1B/matsushita w/ c2 on, I'm seeing a lot of jumps between incorrectly-marked bad frame areas of ~20-25 frames. That seems like another indicator of some sort of IO-strategy related artifact if the buffer size is around 23 frames.

Information ripping to Test Conversion, 'Track 10' to 'C:\Documents and Settings\Super User\My Documents\My Music\U2\The Unforgettable Fire\U2 - The Unforgettable Fire - 10 - MLK.IGNORE'
   Track 10:  Ripped LBA 180942 to 192467 (2:33) in 13:57. Filename: C:\Documents and Settings\Super User\My Documents\My Music\U2\The Unforgettable Fire\U2 - The Unforgettable Fire - 10 - MLK.IGNORE
     AccurateRip: Inaccurate (confidence 11)   Insecure  [Pass 1, Re-Rip 2363 Frames]
     CRC32: 228AE5AA     AccurateRip CRC: DD12F731     [DiscID: 010-001054a3-0081c234-640a060a-10]
       Re-rip Frame: 180954 (00:00:00.160) matched 10 / 11
       Re-rip Frame: 181012 (00:00:00.933) matched 10 / 11
       Re-rip Frame: 181013 (00:00:00.946) matched 10 / 11
       Re-rip Frame: 181014 (00:00:00.960) matched 10 / 11
       Re-rip Frame: 181015 (00:00:00.973) matched 10 / 11
       Re-rip Frame: 181016 (00:00:00.986) matched 10 / 11
       Re-rip Frame: 181017 (00:00:01.000) matched 10 / 11
       Re-rip Frame: 181018 (00:00:01.013) matched 10 / 11
       Re-rip Frame: 181019 (00:00:01.026) matched 10 / 11 
       Re-rip Frame: 181044 (00:00:01.360) matched 10 / 11  =-> 25 frames
       Re-rip Frame: 181045 (00:00:01.373) matched 10 / 11 
       Re-rip Frame: 181092 (00:00:02.000) matched 10 / 11  =-> 47 frames (~23 x 2)
       Re-rip Frame: 181093 (00:00:02.013) matched 10 / 11
       Re-rip Frame: 181094 (00:00:02.026) matched 10 / 11
       Re-rip Frame: 181096 (00:00:02.053) matched 10 / 11
       Re-rip Frame: 181097 (00:00:02.066) matched 10 / 11
       Re-rip Frame: 181140 (00:00:02.640) matched 10 / 11 =-> 43 frames (~21 x 2)
       Re-rip Frame: 181141 (00:00:02.653) matched 10 / 11
       Re-rip Frame: 181142 (00:00:02.666) matched 10 / 11
       Re-rip Frame: 181143 (00:00:02.680) matched 10 / 11
       Re-rip Frame: 181144 (00:00:02.693) matched 10 / 11
       Re-rip Frame: 181146 (00:00:02.720) matched 10 / 11
       Re-rip Frame: 181147 (00:00:02.733) matched 10 / 11
       Re-rip Frame: 181148 (00:00:02.746) matched 10 / 11
       Re-rip Frame: 181149 (00:00:02.760) matched 10 / 11
       Re-rip Frame: 181172 (00:00:03.066) matched 10 / 11 =-> 23 frames
       Re-rip Frame: 181173 (00:00:03.080) matched 10 / 11  (c2 dropped 1)
       Re-rip Frame: 181174 (00:00:03.093) matched 10 / 11
       Re-rip Frame: 181175 (00:00:03.106) matched 10 / 11
       Re-rip Frame: 181198 (00:00:03.413) matched 10 / 11 =-> 23 frames
       Re-rip Frame: 181199 (00:00:03.426) matched 10 / 11
       Re-rip Frame: 181200 (00:00:03.440) matched 10 / 11
       Re-rip Frame: 181201 (00:00:03.453) matched 10 / 11
       Re-rip Frame: 181203 (00:00:03.480) matched 10 / 11
       Re-rip Frame: 181204 (00:00:03.493) matched 10 / 11
       Re-rip Frame: 181205 (00:00:03.506) matched 10 / 11
       Re-rip Frame: 181206 (00:00:03.520) matched 10 / 11
       Re-rip Frame: 181207 (00:00:03.533) matched 10 / 11
       Re-rip Frame: 181208 (00:00:03.546) matched 10 / 11
       Re-rip Frame: 181209 (00:00:03.560) matched 10 / 11
       Re-rip Frame: 181210 (00:00:03.573) matched 10 / 11
       Re-rip Frame: 181211 (00:00:03.586) matched 10 / 11
       Re-rip Frame: 181212 (00:00:03.600) matched 10 / 11
       Re-rip Frame: 181213 (00:00:03.613) matched 10 / 11
       Re-rip Frame: 181214 (00:00:03.626) matched 10 / 11
       Re-rip Frame: 181218 (00:00:03.680) matched 10 / 11  (c2 dropped 6)
       Re-rip Frame: 181235 (00:00:03.906) matched 10 / 11 =-> 21 frames, not including previous frame
       Re-rip Frame: 181236 (00:00:03.920) matched 10 / 11
       Re-rip Frame: 181237 (00:00:03.933) matched 10 / 11
       Re-rip Frame: 181238 (00:00:03.946) matched 10 / 11
       Re-rip Frame: 181239 (00:00:03.960) matched 10 / 11
...

-brendan

[Porcus]

Re: dBpoweramp Release 13.1

Same thing on my XL1B2. Get to re-rip thousands of frames.

Also, if I try to detect C2 errors, I get an instant hit -- it reports immediately that it has C2 errors. Evidently lots of false positives.

[bhoar]

Re: dBpoweramp Release 13.1

1. As we all know, C2 via the custom-for-Sony-XL1B Oxford FW911ATAPI bridge does not work. That bridge does work correctly without C2 enabled, of course.

2. My testing proves it is not the matsushita drive's problem. I disassembled my unit and tried some other bridges with the Matsushita drive inside the XL1B. C2 from the Matsushita via Initio Firewire (INIC-2430L) bridge and via an ACARD USB (4420P) bridge worked fine (on the same host machine that C2 fails on when using the XL1B's built in firewire bridge). And of course disabling C2 worked as well with both of them.

3. Elsewhere, EAC can do C2 using the above XL1B's built in firewire bridge.

That leaves us with yet another unfortunate interplay between dbpoweramp and a subset of firewire bridges (perhaps only this one bridge?).

Note that the Primera Composer family (Composer, XL, Pro, Max) units are also using oxford 911 bridges and they worked when I tested them a couple of weeks back with a test build.

Eli - can you check your composer max to verify that c2 now works over firewire on it?

Spoon - supposition time...perhaps the buffer size fallback code requires some sort of affirmative error from the device if the buffer size is too large and perhaps this bridge firmware isn't properly reporting the problem?

-brendan

[Spoon]

Re: dBpoweramp Release 13.1

Ok looking at it I will have to test on the Sony unit I have (currently seperated from it), but it will not make R13.1 which is in the release cycle now.

[Porcus]

Re: dBpoweramp Release 13.1

Oh well. I have ripped some 6k CDs with a second-best solution[*], so I won't cry over not having it done for the last 600.

[*] The best, for the time being, looks like being AutoITing up dBpoweramp for metadata & ripping and EAC for ripping and compare CRCs and transfering metadata if necessary. Maybe I would have done so had I thought of it a year ago, but the initial reason why I picked up dBpoweramp in the first place was ease of use combined with AR, so ...

[bhoar]

Re: dBpoweramp Release 13.1

Ok looking at it I will have to test on the Sony unit I have (currently seperated from it), but it will not make R13.1 which is in the release cycle now.

Ok, but it is driving me crazy: primera's oxford 911-based bridges do C2 just fine with LG drives, but sony's oxford 911-based bridges fail to do C2 with Matsushita drives.

It's not the Mastushita drive, though because that works fine with the Initio firewire bridge.

And, if anything, the firmware in the Primera bridge(s) is/are older, perhaps by 2-4 years. And looking at several configuration rom examples, I don't see anything different between the sony config and the primera config. *argh*.

My next experiment, later this week, will be to try the primera bridge with the matsushita and the sony bridge with the LG drive (and a plextor 230a). Perhaps I can nail down the component or mixture of components at fault.

I suppose there's always the chance that it's really an interaction of three things (cdgrab.exe code, bridge *and* drive), if there's a cascade of some maximum transaction size or number of records or something that is larger/smaller for the matsushita than the rest. Esp. since EAC doesn't seem to mind at all.

Anyway...the mind boggles.

I did re-verify that C2 worked via USB and some other firewire bridges.

-brendan

[sjmac]

Re: dBpoweramp Release 13.1

R13.1 Beta Typo:

"ID Tag update" utility codec says "Remaing" in the Information tab; should say "Remaining".

[bhoar]

Re: dBpoweramp Release 13.1

Ok. I hacked up some code to use the "IOCTL_STORAGE_QUERY_PROPERTY" call to validate the number of bytes and number of consecutive pages allowed for each interface/bustype's IO.

Several firewire connected devices have an adapter profile that returns vastly incorrect numbers, typically:

MaximumTransferLength=2093056
MaximumPhysicalPages=511

This is regardless of whether these devices work with C2 or not (both my primera oxford bridges and my sony oxford bridges give the same numbers). So the fact that the "adapter" is returning bogus values is not the cause of the C2 problem, per se.

It is also widely reported that trying large IOs, such as would be allowed if those numbers above would be trusted, on most firewire bridges will lead to failed IO transactions. So, the above numbers are not to be trusted.

Most optical drives, were they connected directly to the computer, would read something like the following:

MaximumTransferLength=131072
MaximumPhysicalPages=32 or 33 (33 is preferable)

This reinforces the notion that the firewire values cannot be trusted (since the drives themselves are limited to smaller values when attached directly).

Also, sometimes the MaximumPhysicalPages value is a bogus high value on direct connected ATA drives (all bits enabled, for example, on my laptop's internal dvd).

And for USB-connected devices, I typically see:

MaximumTransferLength=65536
MaximumPhysicalPages=16 or 17 (17 is preferable)

So...if dbpoweramp is relying on these numbers, may I suggest that they not be relied upon for firewire drives (BusType=3) and that, instead, these drives be clamped down to IO values along the lines of what MaximumTransferLength=32768 and MaximumPhysicalPages=9 would dictate. And perhaps the same rule should be enforced for USB (BusType=7) if we find any USB controllers that are also misbehaving.

I know this sounds extreme, and if dbpoweramp were a DVD-burning application, I might be concerned about performance degradation, but since it's limited to ~52x CD reading max, I doubt smallish buffer limitations would have much of an impact on ripping speed, if any at all.

-brendan

PS - Also, on a related note...firewire devices return an AlignmentMask value of 3 (which reinforces the 8-byte alignment case discussed previously). Direct-attached ATA devices typically return a less strict value of 1 (2-byte alignment). USB devices are the least strict of all, with an AlignmentMask value of 0, at least on my machine, though I doubt anyone really expects IO to work to odd memory addresses...

[Spoon]

Re: dBpoweramp Release 13.1

We do not rely on them, instead the lowest known value is used.