Erratic Behaviour Gathering Metadata and Trying to Rip

[d2b]

Scenario *1: Dell 380 mini-tower w/dual core Intel 2.93GHz processor, 8GB RAM, new ASUS SATA Optical drive, Window 10 64-bit
Scenario *2: HP dc7800 desktop w/dual core Intel processor, 4GB RAM, nice SATA optical drive, Windows 7 Pro, 64-bit

Wheels turn while gathering metadata, sometimes successfully and sometimes not, using several CDs. Sometimes takes 1-2 minutes (maybe 3, but who's counting by this time) on a fast Internet connection to get any results at all, and sometimes no results even with repeated tries on the same disc. Sometimes, metadata appears and almost instantly disappears just before my hand reaches for the mouse. I've tried dBpoweramp 15.3 which "seems" more reliable in this respect. I've tried 16.4 with mixed results&*8212;exhibited weird behavior as described above sometimes but then seemed to settle down and ripped a couple of CDs w/o incident. Delivered the Dell with 16.4 installed and fully configured to client and on the very first attempt at ripping a CD, metadata appeared and then disappeared. Tried a different CD and after one failed attempt to gather metadata, another prompt to seek on-line resulted in metadata AND a successful RIP. This behavior was encountered with 3 different optical drives: the new one was a bit faster and appear to behave reliablely but that's the one that was in the Dell when I delivered it today.

We've been using dBpoweramp in its latest versions for at least 6 years, maybe even 8, but we've never seen a problem like this.

The HP didn't seem to work any better in this regard. All in all, I've tried 3 different optical drives. Any idea of what might be going on?

I fear another processor incompatibility, ala the AMD Opteron 64 fiasco when set to compression level 5.

Dennis...aks "d2b"

[Spoon]

Re: Erratic Behaviour Gathering Metadata and Trying to Rip

>metadata appeared and then disappeared

Appeared where? in CD Ripper? Windows Explorer?

[d2b]

Re: Erratic Behaviour Gathering Metadata and Trying to Rip

Scenario: Dell 380 with Windows 10, 64-bit; 8GB RAM, New ASUS optical drive; dBpoweramp 16.4.

Roughly speaking, about 3 times out of 5, retrieved metadata would appear in the CD Ripper fields and then, as I watched, disappear in the blink of an eye. When it did not disappear, I tried ripping and after pondering each track for say, 20 seconds or so, dBpoweramp Would report 'Error' and jump to start ripping the next CD with the same result. It would go through the entire album this way.

Sometimes it would rip one track and then give the same 'Error' result with the remaining tracks.

This problem MAY have something to do with the installed security software, the FLAC codec employed (1.3.2) or maybe both acting hand-in-hand. I have no idea, but I'm under the impression that you should not be offering the latest FLAC codec if it is responsible for any of the error and issues reported on this forum. Yes, I realize that Illustrate has no control over the efficacy of the codec, but why offer it if there are known problems with it? What advantage does the 1.3.2 codec offer over 1.3.1?

Except for possible security software exclusion issues, are there ANY known issues with dBpa 16.2/FLAC 1.3.1? I certainly plan on backing away from dBpa 16.4. This is a big PITA for me, as I coordinate the support FOR about 10 installations in several locations, some Windows 7 and some Windows 10, in order to get uniform results using dBpa and Mp3Tag to build an up-to8TB media library in FLAC.

[Spoon]

Re: Erratic Behaviour Gathering Metadata and Trying to Rip

We release R16.5 in the next few days, which includes 1.3.3 which does not have the issue. However the problem of where you had metadata appear in CD Ripper then disappear, this is not related to flac, I have never heard of this before, it suggests that CD ripper thinks a new cd is inserted and is refreshing the track listing.