dBpoweramp Release 13.1

[Spoon]

Instal over the top of existing R13 (when asked to uninstall old select No) version to maintain registration status.

The beta will function until the end of 10 2008, the full release should be soon.

Download:

<now released>

4.9MB

Changes:

mp3 (Lame) updated to v3.88
PerfectMeta enchancement - album artist could overide various artists from other providers
CD Ripper - better handling of display when starting program
CD Ripper - Copy to clipboard can copy the filename
CD RIPPER - default naming is having Various\xxxx Disc 1 Disc 1\ because album name has disc number (from perfect meta), so removed from naming default
CD RIPPER - default naming removed album from the filename
CD Ripper - Much faster as skipping a track on a damaged disc (if user skip)
CD Ripper - now supports c2 error pointers over firewire
CD Ripper - fail safe detection of drives (will return Unknown for name)
CD Ripper - folder.jpg changed to Folder.jpg as default
CD Ripper - mouse wheel scrolls in manual meta review page

ID Tag + CD Ripper: Better handling of comments with CRLF and display of such. In Tag Editor carriage breaks shown as {CR}{LF}
GetpopupInfo faster when tags contain a huge binary encoded as UUEncoded text (200KB single txt element)

File Naming - [MAXLENGTH] naming element to set the maximum length of items such as folder, or file names
File Naming - Now possible to do: [ifvalue]artist[] [ifvalue][artist][] [ifvalue][tag]artist[][] [IfEQUALS]artist,[album artist],bob[] [IfEQUALS][artist],[album artist],bob[] [IfEQUALS][tag]artist[],[album artist],bob[] [IfEQUALS]The ,[MAXLEN][album artist],3[],bob[]


Core Converter can send over replaygain tags at request of DSP Effect
Core Converter attempts to write ID Tags, even if there was an error

bug fix: All programs - folder creation able to correct folders ending in '... '
bug fix: Edit ID Tag would stall if a huge binary encoded as UUEncoded text (200KB single txt element)
bug fix: cd ripper - changed scanner to only load, get around 16 bit errors people are seeing (also ntvdm)
bug fix: mp3 lame any abr mode was vbr -v4
bug fix: CD Ripper - was possible a device change (new drive appearing) could effect existing CD Ripping
bug fix: CD Ripper could say Encoding CPU1, CPU2 even when only 1 cpu on system
bug fix: Batch Converter, if folder had an . it would readd the folder on refresh
bug fix: cd ripper - if viewing manual review page and eject cd now auto close the page

[Kim K.]

It deleted my Reference registration. If there are special steps to follow please list the process in detail.

I assume I now have to uninstall 13.1, download Reference and the codecs, install Reference, register, set-up my profiles and settings. Is that correct?

Very frustrating and time consuming.

[bhoar]

It deleted my Reference registration. If there are special steps to follow please list the process in detail.

That's probably because you chose the option to uninstall R13. Don't do that. Install it "over" R13.

-brendan

[Spoon]

Sorry I forgot to add the bit about selecting no. You will have to install R13 regsitered, then R13.1 over the top.

[hanschke]

lame.exe crashed. file will come via mail.

[Nonreality]

It says it will function until 8/08 is this going to be a problem?

[LtData]

That is just for this beta, normally betas have limited functionality period, new beta versions push this date back further.

[ffm76600]

Hi Spoon

Lame 3.98 final version is out !!!

Can you include the new lame 3.98 (final version) to the version 13.1 and when will you release the final version of dmc ?

http://lame.sourceforge.net/index.php

[Spoon]

Updated 5th July

To Lame 3.98

[ffm76600]

Thanks ! :thumbup: :D

[EliC]

spoon, will we see any updates on the way firewire is handled with respect to possible better C2 support in 13.1? Now that the composermax is functional this would be HUGE!

[Spoon]

It is planned for r13.1

[Porcus]

Re the "firewire" support: Any chances to get C2 support through my Sony XL1B changer?

(Would be quite a bit annoying given the 4000 CDs I have already ripped ;-))

[Spoon]

If c2 works in other programs on the sony theny there is a good chance it would be supported.

[Porcus]

If c2 works in other programs on the sony theny there is a good chance it would be supported.

Anything else than EAC?

[bhoar]

Anything else than EAC?

I used both EAC and Nero DiscSpeed in testing C2 capabilities via firewire. The fact that both were seeing valid C2 error flag data on several firewire drives (with dbpoweramp failing the C2 test and failing to rip tracks on the same drives) helped in tracking down some potential roadblocks in dbpa's approach that spoon is looking into at the moment.

-brendan

[tbooty]

for me when i convert my lossless music to mp3, with the lame 3.98, it's converting only to joint stereo.
even when it specifically says convert to "stereo"

i tried it with automatic and it was joint stereo
and i tried it with joint stereo and it was joint stereo.

anyone else noticing this?

[Spoon]

Select the dual channel.

[ffm76600]

for me when i convert my lossless music to mp3, with the lame 3.98, it's converting only to joint stereo.
even when it specifically says convert to "stereo"

i tried it with automatic and it was joint stereo
and i tried it with joint stereo and it was joint stereo.

anyone else noticing this?

Yes use the dual channel mode ! It's ok for me :smile2:

[bhoar]

for me when i convert my lossless music to mp3, with the lame 3.98, it's converting only to joint stereo.
even when it specifically says convert to "stereo"

i tried it with automatic and it was joint stereo
and i tried it with joint stereo and it was joint stereo.

anyone else noticing this?

FYI, with the default joint stereo setting at normal bitrates, lame 3.98 decides on a frame-by-frame basis whether to use strict stereo or mid-side stereo encoding. Basically, joint stereo will tend to give you a significantly higher quality file than forcing strict stereo for nearly all music.

-brendan

[Teknojnky]

recent JS thread @ HA

http://www.hydrogenaudio.org/forums/index.php?showtopic=64531

[Spoon]

Update 21st July

ID Tag + CD Ripper: Better handling of comments with CRLF and display of such. In Tag Editor carriage breaks shown as {CR}{LF}

Use this version with the latest beta codecs (flac, etc) and all line break issues will be gone (in id tags).

[Shivek]

I've got two questions here:

1.) Since I have no idea what is Join Stereo or Dual Channel when converting my FLAC files to MP3 with LAME 3.98, should I just leave it as Auto?

2.) When will dBpoweramp 13.1 full (not BETA) will be available for download?

Thanks in advance.

[bhoar]

spoon, will we see any updates on the way firewire is handled with respect to possible better C2 support in 13.1? Now that the composermax is functional this would be HUGE!

Hi spoon. How's the improved support for C2 over firewire (and perhaps certain previously difficult SATA and/or USB interfaces) going? :)

-brendan

[Spoon]

Auto is best for mp3.
R13.1 will be about 4-8 weeks

----

C2 over firewire: soon

[Shivek]

Auto is best for mp3.
R13.1 will be about 4-8 weeks

----

C2 over firewire: soonThanks for the quick response. :)

[bcat]

Hi Spoon. I think I've found a bug in R13.1. dBpoweramp doesn't work with files on a network share if the path name contains certain accented characters, like "ē" (U+0113 (http://www.fileformat.info/info/unicode/char/0113/index.htm)).

As an example, there's an album on my file server that I can access from my desktop at the path "\\Zach\music\Lossless\Dogs of Peace\{spēak}". If I open that folder in Windows Explorer, the path displays properly and I can access the FLAC files it contains. dBpoweramp, on the other hand, cannot. If open Explorer's properties window for one of the files, the Audio Properties and ID-Tag tabs are displayed, but all the fields are completely blank. If I try to convert them to another format, I get an "error opening file" message. Finally, if I select the folder in the Batch Converter, I don't get any errors, but it shows up empty.

There are two other things I've noticed about this. First, this problem occurs with some paths containing accented characters, but not with others. I can access files at "\\Zach\music\Lossless\Béla Fleck & the Flecktones\The Hidden Land" just fine, for example. (Could this be because "é" is contained in the Windows-1252 character set but "ē" is not?) Second, this problem only occurs when the files are stored on the network. If I copy the "{spēak}" folder to my desktop, everything works perfectly.

[LtData]

dMC has never worked properly with network drives unless you map them as a local drive. If you map it as a local drive, does it work better?

Edit: see below

[bcat]

dMC has never worked properly with network drives unless you map them as a local drive. If you map it as a local drive, does it work better.

Yeah, it seems to work if I map it as a drive. Still, I don't think I should have to do that. Network share support is touted as a new feature in the R13 changelog for the Batch Converter, and it works perfectly for every album except the one that happens to have an "ē" character in its network path.

[LtData]

My mistake, I missed that in the changelog and, as I don't convert over the network, didn't notice that. So you are using the Batch Converter to select these files, or are you trying to right-click and "Convert To"?

[Spoon]

What is creating the share? (on which device) which Windows version do you have?

[bcat]

Thanks to everyone for your help so far.

My mistake, I missed that in the changelog and, as I don't convert over the network, didn't notice that. So you are using the Batch Converter to select these files, or are you trying to right-click and "Convert To"?

I've tried it both ways and neither works.

If I use the Batch Converter, I can browse to the folder in question, but it can't find any audio files inside. The file list is completely empty.

If I use the Convert To menu item, the files show up in dMC's list, but when I click the convert button it fails, and I get an error log like this:

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\01 In the Event.flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\01 In the Event.IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\01 In the Event.flac' check no other program has it open. [clDecoder::Open]

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\02 Necessary Pain.flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\02 Necessary Pain.IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\02 Necessary Pain.flac' check no other program has it open. [clDecoder::Open]

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\03 Thrown Away.flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\03 Thrown Away.IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\03 Thrown Away.flac' check no other program has it open. [clDecoder::Open]

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\04 Dogs of Peace.flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\04 Dogs of Peace.IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\04 Dogs of Peace.flac' check no other program has it open. [clDecoder::Open]

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\05 Do You Know_.flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\05 Do You Know_.IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\05 Do You Know_.flac' check no other program has it open. [clDecoder::Open]

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\06 I Wanna Know.flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\06 I Wanna Know.IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\06 I Wanna Know.flac' check no other program has it open. [clDecoder::Open]

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\07 The Truth.flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\07 The Truth.IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\07 The Truth.flac' check no other program has it open. [clDecoder::Open]

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\08 Pray to God.flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\08 Pray to God.IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\08 Pray to God.flac' check no other program has it open. [clDecoder::Open]

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\09 The Burning Bush.flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\09 The Burning Bush.IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\09 The Burning Bush.flac' check no other program has it open. [clDecoder::Open]

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\10 When I Believe It.flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\10 When I Believe It.IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\10 When I Believe It.flac' check no other program has it open. [clDecoder::Open]

Error converting to Test Conversion, '\\Zach\music\Lossless\Dogs of Peace\{spēak}\11 [Blank].flac' to '\\Zach\music\Lossless\Dogs of Peace\{spēak}\11 [Blank].IGNORE'
Error opening file '\\Zach\music\Lossless\Dogs of Peace\{spēak}\11 [Blank].flac' check no other program has it open. [clDecoder::Open]

What is creating the share? (on which device) which Windows version do you have?

I'm running dBpoweramp from my desktop (LAN name: norm), which is running Windows XP Professional. The server where my music files reside (LAN name: zach) is running Ubuntu Hardy with Samba 3.0.28a.

I initially thought that Samba might be causing the problem, but I can also reproduce this bug if I copy the files to an XP Pro machine and share them from there.

[Shivek]

Will the full 13.1 feature any changes in the implementation LAME 3.98 or will it be the same as in the 13.1 BETA?

[EliC]

Win XP Pro SP3
13.1
Flac 1.2.1b

I was ripping using the CD Ripper (not batch) last night when both drives slowed to a crawl. I finally gave up on the rips, took the discs out, inspected one and put it back in. I noticed that the same CD popped up for both instances of the ripper. This made me notice that both were now pointing to the same drive. They had been pointing to 2 separate drives, and somewhere in the middle of the rip they both started pointing to the same drive and trying to rip the same disc. Of course one still had the meta-data and track lengths for the other disc. On re-inserting the 2 discs and changing the second instance back to the correct drive they both ripped accurately without any problems.

[Spoon]

When you removed the disc it might have jumped to the 2nd drive with the disc present. When ripping the drive should remain fixed.

------

Will the full 13.1 feature any changes in the implementation LAME 3.98 or will it be the same as in the 13.1 BETA?

Same

-------

RE: Converting with share, will note to look at.

[Sebastian Mares]

Any news about my problem (http://forum.dbpoweramp.com/showthread.php?t=17035)?

[EliC]

When you removed the disc it might have jumped to the 2nd drive with the disc present. When ripping the drive should remain fixed.



I don't think this is what happened. The other thing I forgot to mention is that I noticed even after ejecting the disc the meta-data remained on the screen. I restarted the ripper, and everything was clean.

[bhoar]

I don't think this is what happened. The other thing I forgot to mention is that I noticed even after ejecting the disc the meta-data remained on the screen. I restarted the ripper, and everything was clean.

Is there any way to know that you didn't have both cdgrab.exe's pointing to the same drive before you started ripping those two CDs?

That is, perhaps they were both pointing at the same drive earlier than you thought? I've had a single instance of the cdgrab.exe window switch drives on me in the past between CDs, I just don't remember what the trigger was - perhaps it was a misclick on the lower-left-hand corner drive selection box (which I always forget is there, so familiar am I to the mid-screen drive selection box that shows up when no disc is inserted).

-brendan

[ahp54]

BUG: Problems when lyrics tags are converted from WMA lossless (wma) to AAC with (m4a) apple tags.

When converting between (wma) to (m4a)
After the conversion all the WMA meta data tags converted over correctly execpt for lyrics tags which only about 100 bytes get transferred over. The rest is lost

When converting between (mp3) to (m4a)
After the conversion all the WMA meta data tags converted over correctly except for the lyrics tags which are lost all together.

PS.
Thanks for resolving the lyrics tags that did not handled CR-LF correctly for MP3.

[LtData]

I believe those bugs would be related to the codecs, not dMC r13.1.

[atlantic]

I notice the bottom part of the CD Ripper window (containing player, metadata, album art) is still not resizable in the latest beta.

Could it be implemented, since it must be rather a simple fix? It would save a lot of clicking and scrolling while editing and especially adding various metadata fields.

In the present version there is a huge unused white area in the middle of my 1200 pixel high screen. The unused space is there on smaller screens too.

[atlantic]

If an artist name includes the & character, perfectmeta changes it to a semicolon, for example:

Earth, Wind & Fire --> Earth, Wind; Fire

This results as the following tag fields:
ARTIST=Earth, Wind
ARTIST=Fire

I suppose it would be best if the & character would not be renamed like this since there are so many groups with that character part of the name.

[Spoon]

It is an option you can switch off under Options >> Meta Data & ID Tags.

[atlantic]

Aah, sorry about that. I think I remember it now. I left it ticked since it included also "feat." and "ft.".

Wouldn't it be better to leave "&" out? More often than not "&" doesn't indicate different artists but a whole group. And if it does, more often than not that group+artist is known for being a single group.

"feat." and "ft." however pretty always refer to an artist not known to be part of the group but just a brief guest star.

Well, in the end it's by far not the most important issue.

[atlantic]

To reply to myself: I guess you could just untick the option and make custom rules for feat. and ft.

Sorry about the mess :)

[EliC]

Wouldn't it be better to leave "&" out? More often than not "&" doesn't indicate different artists but a whole group. And if it does, more often than not that group+artist is known for being a single group.

"feat." and "ft." however pretty always refer to an artist not known to be part of the group but just a brief guest star.

Well, in the end it's by far not the most important issue.

same thing I suggested

[jfkaess]

I agree. I've been forced to not use this feature because 95% of the time & does more harm than good because its a group, not another artist.

[sjmac]

13.1 beta CD Ripper: PerfectMeta overwrites CD-Text and ISRC data

In my Meta options I have CD-Text, CD-ISRC, and CD-UPC selected, as well as PerfectMeta and the internet services. (Chosen by clicking the down arrow next to the Meta button.)

In the CD ripper application I have switched on the ISRC column. (Right click the column headers and select ISRC).

When I put a CD in initially I see values read from the CD-Text and ISRC values, and then these are immediately over-writen by values read from PerfectMeta. That's maybe OK for the CD-Text, but none of the internet services provide the ISRC numbers, so they are all blanked off. (Even if the net service did provide ISRC, should I expect them to be more correct than the value read from the disk?)

[Edit: This is what happens if I use a Virtual CD ROM drive with an image mounted. The image in my test was ripped on the same PC and drive using EAC > Action > Copy Image and Create CUE Sheet.]

I can merge ISRC numbers back again by choosing the Down Arrow next to Meta > Retrieve > CD-ISRC and then Down Arrow next to Meta > Retrieve From > dbPowerAmp Cache (local)

[bhoar]

sjmac-

What vcd program and image format are you using that supports cd-text and isrc numbers?

-brendan

[sjmac]

My virtual CD drive is DAEMON Tools Lite 2.12.3 (C) DT Soft Ltd

PC is running Windows Vista x64 (64 bit), quad core cpu.

ISRC/CD-Text in cue sheets in an option in EAC (EAC Options > Tools)

[sjmac]

Missing ISRC number behavior is present if using a virtual CD drive or a real one on my system.

Different symptoms if the cd is inserted in to the drive before CD Ripper is started or after.

If inserted before, then ISRC numbers are not shown in the track grid and not written to track metadata after ripping.

If inserted after CD Ripper is started then ISRC numbers are shown in the track grid, but not written to the file metadata.

(Checked for ISRC numbers by right-clicking the file and choosing "Edit ID-Tag")

ISRC numbers can be put in to the file by following the procedure in post #48 above, but then I loose any scanned artwork that I might have added.

[Spoon]

ISRC would not be used with PerfectMeta, I will make a note for R13.2 to re-add it.

[festus1s]

I am having trouble getting back to release 13. I hit yes to uninstall 13 when I went to the Beta 13.1 by mistake. It went to trial version. So I uninstalled 13.1 and re-installed my registered version 13 but I am still in TRIAL with 17 days remaining. What can I do to get this corrected?

Thank You

[Spoon]

Re-issue registered version of dBpowerAMP can be downloaded from this page:

http://www.dbpoweramp.com/registration/

[festus1s]

I am sorry to bother you again but that didn't work or am I reading this wrong? I down loaded again uninstalled then re-installed

__________________________________________________ ______________
dbpoweramp Music Converter
Release 13

Registration Status [Register]

Reference: Trial(17 days remaining) Power Pack:Registered

AMG, ETC. ETC.
__________________________________________________ ______________

(On Wednesday, May 21, 2008 you purchased dBpoweramp Music Converter R13 (Registered),
costing $18. This charge appears on your credit card from 'WP-ILLUSTRATE'
if paid by WorldPay, or 'DBPOWERAMP' if Paypal was used.)

Thank You Again

[Spoon]

It is only because you have activated the Reference trial, so you have the reference version until that trial runs out, then it will revert to your Power Pack. To manually do it, set the month forward 2 months, run CD Ripper, then put the month back.

[Spoon]

Update 6 Sept2008

Big update (see first message), full release should be 2-3 weeks (need a few minor issues to fix).

[bhoar]

Changes:

CD Ripper - now supports c2 error pointers over firewire
CD Ripper - fail safe detection of drives (will return Unknown for name)
bug fix: CD Ripper - was possible a device change (new drive appearing) could effect existing CD Ripping

Three cheers!

-brendan

[Spies]

CD Ripper - now supports c2 error pointers over firewire

This new functionality does not seem to work properly with the Sony VGP-XL1Bx series changers. CD Ripper will report that the drive supports C2 pointers however when performing a rip many C2 errors will be reported when there should be none.

For example with a new undamaged CD I get over 2900 C2 errors reported on the first 3 minute track alone. If I disable C2 the track rips fine without errors and is Accurate Rip verified.

CD Ripper reports the drive mechanism as MATSHITA - DVD-RAM SW-9584 with 4 KB of cache and C2 pointers. Not sure of its ability to read into Lead-in and Lead-out.

[Spoon]

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

[bhoar]

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

-brendan

[Spies]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

R13.1 Beta Typo:

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

[bhoar]

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]

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

[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/showfiles.php?group_id=290&package_id=309

[Spoon]

Now Released