dBpoweramp Release 13.1

[Spoon]

Re: dBpoweramp Release 13.1

Now Released

[ffm76600]

Re: dBpoweramp Release 13.1

Lame 3.98.2 is here :

http://sourceforge.net/project/showfiles.php?group_id=290&package_id=309

[Spoon]

Re: dBpoweramp Release 13.1

We do not probe, only reverting to lesser values when fails - it can revert at any time.

[bhoar]

Re: dBpoweramp Release 13.1

Try enabling the debug mode (dBpoweramp Configuration >> Music Converter), then run cd ripper, post the results after the crash (will be shown in Notepad).

Speaking of debug mode...

Would it be possible to include in the cd ripper's log the maximum transaction size, maximum buffer size and buffer's byte-alignment rules used after determining such things by probing the drive/inteface detail?

I don't see anything in the R13.1 logs about that in the current release and since you're now performing the probes...

-brendan

[Spoon]

Re: dBpoweramp Release 13.1

Try enabling the debug mode (dBpoweramp Configuration >> Music Converter), then run cd ripper, post the results after the crash (will be shown in Notepad).

[Porcus]

Re: dBpoweramp Release 13.1

There is a CD which crashes my R13.1 (the September 6th version). Only when I pick one particular of the multiple freedb matches.

What could I do for further testing?

[bhoar]

Re: dBpoweramp Release 13.1

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.

...

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...

Two corrections to my post above.

1. Firewire is bustype 4, not bustype 3, my error above. So, my recommended 32KB restrictions would be on bustypes 4 and 7 (firewire and USB) not 3 and 7. Note also that 32KB is exactly the recommended buffer size for DVD reads due to the user data+EC data mixing algorithm (unless falling back to re-read bad sectors one at a time) so it's a good catch all mid-size and high-compatibility buffer size when dealing with optical drives.

2. An alignment mask of 3 means 4-byte aligned, not 8-byte aligned. Of course, there's nothing wrong with being more strict and until the most recent 13.1 code fix, the code was only 2-byte aligned so it needed fixing anyway. From past discussions with spoon, I believe he's now 4KB-aligned or 64KB-aligned all buffers, which covers all cases anyway and 64KB-aligned is especially good in order to avoid issues with chains that fail when transitioning 64KB boundaries.

-brendan

[Spoon]

Re: dBpoweramp Release 13.1

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

[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...

[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 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

[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 ...

[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.

[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

[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.