dBpoweramp Batch Ripper: Discussions

[latefordinner]

Re: dBpoweramp Batch Ripper: Discussions

I am having an odd problem with ripping speed. While using a Sony XL1B3, the highest-quality ripping settings (including verification of FLAC conversions), Windows Vista 32-bit, and the highest-speed FLAC encoding, I am ripping about three CDs an hour. If that is the price of accurate ripping, I am willing to pay it, but I wonder whether I am doing something wrong.

On a different note, what does one do after a batch rip leaves a dozen or so rejected CDs? I cannot figure out how to make my Sony go to discs 3, 15, 72, 108, etc., and eject those rejected CDs. Perhaps I must do it manually, but it will prove difficult to select by number the rejected CDs to be ejected.

The reason that I would like to reject them is that I would like to attempt to rip this individually (perhaps with CD Ripper) so that I can manually enter the apparently missing metadata (the reason for most rejects).

At bottom, what does one do with rejected discs? I see no way to select only certain discs to re-rip, so it seems that the manual method remains the only solution.

Since Batch Ripper rejected the last nine or ten CDs for lack of metadata, I wonder whether I have exhausted my AMG initial lookups. If so, will paying the $5 fee mentioned in the products section free the program to resume lookups?

Are there any benefits with Batch Ripper to pay for an upgrade to the highest level of CD Ripper or the main Amp program? I am happy to pay the requested licensing fees for these most-useful and innovative programs.

Hit a high-water mark of 172x earlier tonight with FLAC at standard using six drives on a four core system. Still seeing only four drives able to rip at full speed at once, the last two drives are at 1/4 to 1/2 speed. I've tried swapping out firewire<->ATAPI bridges and/or firewire controllers but get the same result. I even started playing with Microsoft's Interrupt Affinity Tool (and filter driver) to see if I could somehow move all the PCI IRQs for firewire to one or two CPUs to see if that made a difference and it did not.

Planning to try SATA<->ATAPI bridges next week.

I'm wondering if the drives are resetting their speed to non maximum, if CDGrab.exe is setting their speed to non maximum, or...?

None of the cores are seeing anywhere near to full utilization.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Different competing 'standards', we are non-partizan and will go with the largest standard.

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

Say a CD starts at 180, the Raw method would return 30, so nothing is lost.

NP, for my education, can you tell me why other developers do not see it as simply?

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Say a CD starts at 180, the Raw method would return 30, so nothing is lost.

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

but the problem, as I understand it, is that not all discs have the same 150 value, and this value is lost with the RAW TOC.

I have no problem with the RAW TOC, but if there are other incompatible systems can we at least have the option to support these?

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

There is no offset lost, their way of storing it is Value + 150, and if there is a CD Extra then last track + 150 + 150 (which is wrong as it is into the Lead out...).

See this thread:

http://www.hydrogenaudio.org/forums/index.php?act=Print&client=printer&f=67&t=57010

There is no consensus how it should be stored, we store as given direct from the CD drive, no adjustments.

Now Microsoft say one thing:

http://msdn2.microsoft.com/en-us/library/aa391939.aspx

And do another (with WMP11), their binary dump is really a Unicode string:

10+150+etc..

10=Track Count
150=first track

And finally Musicbrainz seem to agree with us (not having 150 offset):

http://musicbrainz.org/doc/DiscIdsAndTagging

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

>In addition there is some concern that the RAW TOC that spoon is using is not the right TOC that all the metadata services use.

Do you know that each audio format stores the TOC differently? so it is not the 'standard' as set by the metadata service providers, rather the standard of the audio format which we are following 100% correctly...

Its my understanding that some data is lost with the RAW TOC, namely the TOC offset, which is why its RAW? I understand wanting to support the most correct standard, but at the same time if there is additional information that can be stored at least give the end user the option to store it for maximum compatibility with real life services and the way they DO work, and not should work.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

>In addition there is some concern that the RAW TOC that spoon is using is not the right TOC that all the metadata services use.

Do you know that each audio format stores the TOC differently? so it is not the 'standard' as set by the metadata service providers, rather the standard of the audio format which we are following 100% correctly...

[LtData]

Re: dBpoweramp Batch Ripper: Discussions

If you click the arrow beside Meta --> Settings --> FreeDB, you have the option to use an offline database instead of the online one. Do note it is either-or, not if-else, so you have to manually change the option to offline and then only offline will be used.

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

kevin, agreed. In addition there is some concern that the RAW TOC that spoon is using is not the right TOC that all the metadata services use. IF spoon wants to write the RAW TOC, I would at least like to have the option to write the TOC as well or instead.

[kevinoconnor]

Re: dBpoweramp Batch Ripper: Discussions

Regarding meta data, I'm very interested in doing the meta-data lookup offline instead of, or in addition to during the batch rip. Doing it during the batch rip is ok, but I wouldn't want to come home to a pile of rejected discs if my ISP goes down or discs tagged with freedb data instead of AMG data because AMG was down today.

I think it's critical that as much disc information as possible (TOC etc) is captured from the disc at the time of rip and saved in either a sidecar xml file, or even better, as a custom tag where supported.

If, a year after I've ripped my CDs, a new meta-data service appears, with much better data, I can then run a batch re-tag without ever touching the original CDs.

Another reason to store detailed CD data is to be able to reproduce the original CD as accurately as possible if I ever need to.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

@peterfs - AMG is limited to 400 loopups, once over that it will disable AMG. We are hoping to add commercial AMG support (pay per lookup) soon.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

I think I may have posted this question in the wrong thread. :(

I responded to the original post...

http://forum.dbpoweramp.com/showthre...2396#post72396

-brendan

[CBQ]

Re: dBpoweramp Batch Ripper: Discussions

I think I may have posted this question in the wrong thread. :(

Reposting it here.

Spoon listed experimental support for the Rimage DTP. I think those came in two different models. One model had a SCSI interface and the other model was Firewire (with a serial port maybe?).

Is the experimental support for both models or just one?

Also curious about multiple robots connected to one system. I have seen Brendan's youtube video and it is amazing. Kudos Brendan.

Are there any limitations on multiple robots connected to one computer? Can I connect two USB robots, and one SCSI robot, and two Firewire robots to the same computer?

Thanks in advance for any help/guidance,
CBQ

[peterfs]

Re: dBpoweramp Batch Ripper: Discussions

I'm seeing something weird with the metadata handling this afternoon (12/9). I needed to re-rip a couple of CD's and they're ripping without album art and some of the track names have changed from the previous run; it appears that AMG access is not working where it did before. When I disable freedb lookup as an active meta-data provider, the discs are getting rejected as having no meta-data. The same disc works as expected using CD ripper.

I'm using ethereal to analyze the network traffic and I see access to dmr.allmusic.com from the CD ripper but not when using the batch ripper. From the batch ripper I see access to dbpoweramp.com and an IP address that's not resolving to a meaningful domainname (195.214.216.38). Anybody know what's going on?