I found than 'Array index is out of range..' error (which occurs with mono) doesn't occur when checkbox 'use Accurate Rip' is unchecked.
24-bit HDCD decoding is broken in 2.1.1. I had to go back to 2.0.9 (which link was a guess, but it worked).BTW, is there any possible script which would go through a whole media library and decode all the CDs which it detecs as HDCD? But only the HDCD ones.Or is it not needed now, that foobar2000 has a HDCD component? Is the foobar2000 component on a level as the one in CUETools?
I've searched this topic but nothing found: is it planned to verify XLD extraction logfiles along with EAC logs?
Is it possible to write settings to the folder where CUETools.exe is located, instead of the /%APPDATA%/CUE Tools/ folder?
Yes, it's support FLAC, but OGG Flac (FLAC in OGG container) is not supported.
Problem: I can't repair it, there 's no possibility (afaict) to tell cuetools which CTDBID to use if there's more than 1.
UPD: works for me:
There will be. In current version you can only delete the whole database ("C:\Users\<username>\AppData\Roaming\CUE Tools\LocalDB.xml.z")
AR v2 was AR v1 with the calculation hole fixed, nothing more, nothing less - the offset detection is the same for both.
And when verifying with AR v2 you can only use CRCs from the same pressing as yours.
Verifying against CRCs from several pressings would require the application to detect those pressing offsets in advance using magic 450th frame CRCs, and then calculate CRCs for all of those offsets independently, decreasing verification speed by an order of magnitude. I will not implement that in CUETools, it's just too slow.
First of all, you didn't really have to change CRC, because it was good enough to detect real-world ripping errors - C2 error correction is very-very-very unlikely to produce isolated errors.
That is how you are supposed to do it, dBpoweramp R14 does this and by doing this the detection is not weakened by side by side calculating every crc and comparing, just the specific ones that the offset crc has highlighted. I think R14 limits to 20 calculations in the back ground, which even a Pentium 3 could do when ripping at x30
I have tested drives where C2 pointers are incredibly weak, almost as though there are not there (let so many errors through undetected). C2 cannot be relied on for all drives.
AccurateRip v2 does detect across pressings
So switching to CRC32 would have allowed "AR verification speed >which< is limited only by flac decoding or HDD speed."? You cannot have your cake, and eat it too.
If AR is as flawed as you speak, don't use it, I personally do not think it is flawed, yet it seems to be the current craze to bash it.
"Bashing" wouldn't be the "current craze" if the developer were actually receptive to legitimate criticism and interested in improvement.
improve the CRC (although I have never seen a false positive)