dBpoweramp Batch Ripper: Discussions

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

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

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

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

[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

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

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

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

[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

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

[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

3 CDs an hour could be the norm for Secure ripping, you can right click on the drive in Batch Ripper and show the CD Ripper, to view the tracks as they are ripped.

Rejected CDs: you are best to eject all (they will be in order), take out the rejected discs and rip them manually with CD Ripper.

Batch Ripper limits to 400 lookups (if you have a registered AMG licnese)

[peterfs]

Re: dBpoweramp Batch Ripper: Discussions

I have the same setup as latefordinner and sometimes notice slow ripping. The ripper might indicated that the CD is re-ripping a number of frames which can take a really long time. If I catch this, I tend to cancel the disc and re-rip using the manual CD ripper. When there are no problems I get closer to 5-10 minutes per CD on the XL1B3 (using Secure ripping).

I also do what Spoon suggests for the rejected discs by verify each disc in order after unloading and then re-rip individually.

For meta-data, I paid for GD3 lookups but so far I'm not as impressed as I was with AMG. Not bad but lot's of missing album art and the genre categorization is not as accurate. I'm looking forward to when AMG is available for bulk lookups.

Is there a way to batch update meta-data without re-ripping discs? That would be a nice feature if it doesn't exist.

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

These issues with slow ripping are why I have been pressing spoon for more options in the secure ripping settings, see my R13 request thread:

http://forum.dbpoweramp.com/showthread.php?t=14420

In terms of meta-data, I think spoon plans to implement a multi source scheme with intelligent meta-data selection to get the best meta data from multiple sources.

In terms of re-doing meta data later, that is what the discussions regarding storing CD TOC are about. I dont personally understand the details but I hope a consensus can be reached for the benefit of us all.

[latefordinner]

Re: dBpoweramp Batch Ripper: Discussions

Thank you for your comments. I take it that paying the AMG license fee ($5, I believe) on this dBpoweramp site would not solve the look-up problem. Does that license work only for CD Ripper lookups?

If so, for now, it sounds as if users are limited to using the other supported databases for the metadata. I agree that it would be a welcome feature to allow users whose limited AMG licenses have expired to acquire the metadata without reripping.

In the meantime, it would be great if Batch Ripper allowed users to eject discs selectively instead of wholesale. It would be easier to spot the rejected CDs that way.

I have the same setup as latefordinner and sometimes notice slow ripping. The ripper might indicated that the CD is re-ripping a number of frames which can take a really long time. If I catch this, I tend to cancel the disc and re-rip using the manual CD ripper. When there are no problems I get closer to 5-10 minutes per CD on the XL1B3 (using Secure ripping).

I also do what Spoon suggests for the rejected discs by verify each disc in order after unloading and then re-rip individually.

For meta-data, I paid for GD3 lookups but so far I'm not as impressed as I was with AMG. Not bad but lot's of missing album art and the genre categorization is not as accurate. I'm looking forward to when AMG is available for bulk lookups.

Is there a way to batch update meta-data without re-ripping discs? That would be a nice feature if it doesn't exist.