Greetings Spoon,
I wish to report what I believe to be a bug in the CD Ripper component of dBpoweramp that may potentially affect components. This bug manifests itself in version 13.3, but I have also noticed it in previous versions (on different computers with different operating systems and different optical drives). Okay, so what is this bug?
I regularly run multiple versions of CD Ripper, each assigned to a separate optical drive. However, often all instances of CD Ripper are suddenly assigned the same drive, usually the first optical drive but not always. Often any ripping operations that were in progress result in errors for (attempted) ripping of tracks after this event and of greater concern, sometimes this event goes unoticed and I have rips with incorrect data - meta data including file paths and names are correct, but files contain audio data from a disc in another drive!
I have noticed one event that will ALWAYS bring about this bug: Run two or more instances of CD Ripper and assign each to a different optical drive, then plug in a USB drive or any other storage device (works best), or turn on a device that is connected to the computer but had previously been switched off. Try doing this while ripping audio to duplicate the incorrect data.
The above method for duplicating the bug is for demonstration purposes, the bug manifests itself at (apparently) random intervals and is causing much frustration.
I know that I could be using Batch Ripper, but this does not utilize the CDPlayer.ini file where my meta data is stored, and due to limitations in the data that can be stored in this file, I need to add more data (such as composers, conductors, disc numbers). I do not wish to use any of the online meta data services as my CDPlayer.ini file contains normalised and verified meta data that has come directly from the discs I own and entered entirely manually (before the popularisation of online meta data services).
Thank you for your time,
Jason.
I wish to report what I believe to be a bug in the CD Ripper component of dBpoweramp that may potentially affect components. This bug manifests itself in version 13.3, but I have also noticed it in previous versions (on different computers with different operating systems and different optical drives). Okay, so what is this bug?
I regularly run multiple versions of CD Ripper, each assigned to a separate optical drive. However, often all instances of CD Ripper are suddenly assigned the same drive, usually the first optical drive but not always. Often any ripping operations that were in progress result in errors for (attempted) ripping of tracks after this event and of greater concern, sometimes this event goes unoticed and I have rips with incorrect data - meta data including file paths and names are correct, but files contain audio data from a disc in another drive!
I have noticed one event that will ALWAYS bring about this bug: Run two or more instances of CD Ripper and assign each to a different optical drive, then plug in a USB drive or any other storage device (works best), or turn on a device that is connected to the computer but had previously been switched off. Try doing this while ripping audio to duplicate the incorrect data.
The above method for duplicating the bug is for demonstration purposes, the bug manifests itself at (apparently) random intervals and is causing much frustration.
I know that I could be using Batch Ripper, but this does not utilize the CDPlayer.ini file where my meta data is stored, and due to limitations in the data that can be stored in this file, I need to add more data (such as composers, conductors, disc numbers). I do not wish to use any of the online meta data services as my CDPlayer.ini file contains normalised and verified meta data that has come directly from the discs I own and entered entirely manually (before the popularisation of online meta data services).
Thank you for your time,
Jason.
Comment