Re: Beginner: some questions
Spin up/down are really only used when ripping is starting or finishing, between tracks it is at full speed.
SCSI pass through is best.
>then I can't be 100% sure if the rip is really accurate (even with 5 ultra secure passes), right?
Correct.
You would not spoil AccurateRip with your plan, the database can take around 2 months before it is updated. Your best bet is to rip on one drive and then the 2nd drive on the same pc (two different drives) and compare the CRC (in CD Ripper add the CRC column if not already shown).
>When I buy R12.3 Reference, can I use it on my 2 PCs,
Yes you can, as long as it is not used on 2 pcs at the same time.
Re: Beginner: some questions
First of all, thanks for the quick answer.
But sorry for asking again. Need to know it exactly. :D So...
[QUOTE=Spoon]
SCSI pass through is best.[/QUOTE]
Why this is "better" than ASPI? Is there any good reason?
[QUOTE=Spoon]
You would not spoil AccurateRip with your plan, the database can take around 2 months before it is updated. [/QUOTE]
How come? Do you have any flow charts showing what happens when someone produces some input for AR? Why this could take so long?
Re: Beginner: some questions
ASPI uses SPT, so is an extra layer which can go wrong.
It takes 2 days of computer processing to generate the AR database, it is not a miss mash of peoples posted results.
Re: Beginner: some questions
Is there still a possibility to access the AR database directly? The perl script mentioned [URL=http://forum.dbpoweramp.com/showthread.php?t=15340]here[/URL] leads to a dead link.
It is implemented as a webservice? If so, a WSDL file would also be sufficient.
Re: Beginner: some questions
Re: Beginner: some questions
Thanks, the link is working now.
But the possibilities of the perl script are very limited. Is there a documented AR API for public use, or is the script everything which shows access to the AR database?
Re: Beginner: some questions
No api documents, the script shows how to access ar.
Re: Beginner: some questions
OK...
Next question: Is it possible to change the behavior that ripping and encoding is done simultaneously? I'm planning to use a machine with a P4 processor - it has hyperthreading, that means it's simulating 2 cores, but it only has 1. So the ripping won't be really faster and would be more error-prone, wouldn't it?
Re: Beginner: some questions
Hyperthreading is far from 2 real cores, but saying that windows will detect it as 2 cores and is used automatically by dBpoweramp.
Re: Beginner: some questions
[QUOTE=Spoon]Hyperthreading is far from 2 real cores, but saying that windows will detect it as 2 cores and is used automatically by dBpoweramp.[/QUOTE]
What hyperthreading does primarily, when it works properly, is to reduce the swapping of cpu register data to RAM (and vice versa), which can be a noticable amount of overheard in certain processing situations. It does this by creating a shadow register set (and some additional state save areas for the sub-cores). In addition, it allows existing software to utilize this overhead-saving technique by presenting these dual register sets and state save capability as a virtual second processor.
What you don't get is any more sub-cores, so if a particular program was already maxing out the sub-cores that handle the kind of processing the program needs, hyperthreading can only help a little and, in some citcumstances dual-processor aware software might end up trying to maximize usage of the two CPUs the software sees, leading to slightly lower performance.
-brendan
Re: Beginner: some questions
Yes, it looks like hyperthreading won't speed up dBpoweramp. When it finishes extracting one track, one "CPU" encodes it, the "other" goes on with extracting the next track. And for a few seconds, nothing really happens (status 0% twice).
So it would be a nice feature if there's an option where you can disable this behavior (extracting [b]or[/b] encoding, not both at the same time).