dBpoweramp Release 13.1

[bhoar]

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

[Porcus]

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?

[Spoon]

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

[bhoar]

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]

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

[ffm76600]

Lame 3.98.2 is here :

http://sourceforge.net/project/showf...package_id=309

[Spoon]

Now Released