Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CUETools versions 1.9.5 through 2.1.6 (Read 1894268 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1325
I found than 'Array index is out of range..' error (which occurs with mono) doesn't occur when checkbox 'use Accurate Rip' is unchecked.

Oops, forgot to test this version with mono. Does this happen on every CD or only on a particular one?

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?

Yep, it's broken  Will be fixed in the next version. Such script is probably possible, but i didn't try to write one yet. foobar2000 component probably uses the same HDCD library by Christoper Key, so there shouldn't be a problem there.

Already reported.

Thanks.

I've searched this topic but nothing found: is it planned to verify XLD extraction logfiles along with EAC logs?

I guess so  But i'm a bit overstretched at the moment. I'm trying to do too many things at once. So for now i decided to focus on CTDB and AR2 and Local DB. Would be really cool if there were some developers ready to help with at least the more trivial stuff like XLD log parsing. Such things don't require much work each on their own, but there's million of them.

Is it possible to write settings to the folder where CUETools.exe is located, instead of the /%APPDATA%/CUE Tools/ folder?

Yep, just remove the file called user_profiles_enabled from the CUETools folder.

Yes, it's support FLAC, but OGG Flac (FLAC in OGG container) is not supported.

Yep, it was even supported at some point, but i decided to remove it, because it added about 200-300k to the download size, and you are probably the first user who asked about it. I can probably add some support for it via external decoder, e.g. flac.exe.

Problem: I can't repair it, there 's no possibility (afaict) to tell cuetools which CTDBID to use  if there's more than 1.

I thought CUETools was displaying a choice in such cases. I'll check if it's broken when i get home.
UPD: works for me:
Make sure you selected 'Encode' action and 'repair' script. Just in case, i removed the duplicate entry from the database. There was a bug for some time last year which caused some duplicate entries, i thought them harmless and didn't get around to remove them.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1326
One more question.
It was possible to select the appropriate log file if there were several ones in a folder (for example in russian and in english). I don't see this selection window anymore.
Has the last version lost this feature?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1327
Thanks very, very much for CUETools.  It has completely replaced Foobar2000 for me, because my primary usage is unpacking full-CD APEs and FLACs into their original tracks.  CUETools is much more robust for this.

==>  Which leads to my request:  Please flag fatal errors in color or some other highlight.

I sometimes unpack many CDs at once, and the total pathnames can be long (separate subject...).  The result is that the log window may have hundreds of entries and many of these scroll off to the right.  While it's good to be told that a disc wasn't in the Accurip database, or didn't match what's there, I consider these merely warnings.

But if a track didn't unpack for any reason (often path too long) I REALLY want to know about it!!  And looking for errors like this in the log window is very tedious, because they don't stand out.

I hope you can add some kind of highlighting for these cases.

Thanks again,

Arbie

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1328
Quote
UPD: works for me:


Because there's only one entry now, I could repair the album now, thanks.
UPD didn't work for me when I first tried to repair this album, but will report back if I find another rip which needs repairing and has more than one CTDB entries. 


I do have a request, I would like the possibility to move the result of a verify to the front of the line, this because the length of path & name of an album is always different and that makes it hard to find the inaccurate ones with batch verifying.
So instead of this:
F:\325 - Talking Heads - 1980 - Remain In Light\1980 - Remain In Light\01 - Born Under Punches (The Heat Goes On).flac: AR: rip not accurate (0/1), CTDB: could not be verified.
F:\325 - Talking Heads - 1980 - Remain In Light\1980 - Remain In Light (2006 Expanded Edition)\01 - Born Under Punches (The Heat Goes On).flac: AR: rip accurate (163/179), CTDB: verified OK, confidence 119.
F:\327 - Queen - 1989 - The Miracle\1989 - The Miracle\01 - Party.flac: AR: rip accurate (1/1), CTDB: disk not present in database.
F:\328 - Men At Work - 1997 - Definitive Collection\1997 - Definitive Collection (2003 Remaster) {Anthology}\01 - Down Under.flac: AR: disk not present in database, CTDB: disk not present in database.
F:\329 - Tracy Chapman - 1988 - Tracy Chapman\1988 - Tracy Chapman\01 - Talkin' Bout A Revolution.flac: AR: rip accurate (600/650), CTDB: disk not present in database.

I would like this:
AR: rip not accurate (0/1), CTDB: could not be verified. F:\325 - Talking Heads - 1980 - Remain In Light\1980 - Remain In Light\01 - Born Under Punches (The Heat Goes On).flac
AR: rip accurate (163/179), CTDB: verified OK, confidence 119. F:\325 - Talking Heads - 1980 - Remain In Light\1980 - Remain In Light (2006 Expanded Edition)\01 - Born Under Punches (The Heat Goes On).flac
AR: rip accurate (1/1), CTDB: disk not present in database. F:\327 - Queen - 1989 - The Miracle\1989 - The Miracle\01 - Party.flac
AR: disk not present in database, CTDB: disk not present in database. F:\328 - Men At Work - 1997 - Definitive Collection\1997 - Definitive Collection (2003 Remaster) {Anthology}\01 - Down Under.flac
AR: rip accurate (600/650), CTDB: disk not present in database. F:\329 - Tracy Chapman - 1988 - Tracy Chapman\1988 - Tracy Chapman\01 - Talkin' Bout A Revolution.flac

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1329
I have a question regarding local database. Is there a way to remove old entries - for example I moved some albums to different folders and after rechecking cuetools shows them as multiple clones, but I MOVED them, not copied.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1330
There will be. In current version you can only delete the whole database ("C:\Users\<username>\AppData\Roaming\CUE Tools\LocalDB.xml.z")
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1331
There will be. In current version you can only delete the whole database ("C:\Users\<username>\AppData\Roaming\CUE Tools\LocalDB.xml.z")


Glad to hear that you´re planning this option, beacause rebuilding my database from scratch would be a three days worth of work at least.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1332
I´m increasingly fond of this local database idea,  its´very useful for me. It would be nice to have more features - like search option, sorting by CTDB confidence etc. Can we have a glimpse at what is the author working on? And what is the release schedule?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1333
Here are some of the major features planned for next release:
1) Updates to CTDB protocol that become necessary due to the database growth, especially because CTDB will hopefully soon be more widely supported
2) Support of musicbrainz NGS metadata via CTDB, providing a fast and convenient access to it.
3) Considerable CTDB verification speed improvement
4) AR v2 support, although in my opinion AR v2 was a huge mistake - this new 'CRC' is not better in any way than the previous one, and it doesn't support offset detection the way the old one did.

I will also try to improve local DB functionality if i have time before the planned release at the end of the month.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1334
>4) AR v2 support, although in my opinion AR v2 was a huge mistake - this new 'CRC' is not better in any way than the previous one,
>and it doesn't support offset detection the way the old one did.

AR v2 was AR v1 with the calculation hole fixed, nothing more, nothing less - the offset detection is the same for both.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1335
AR v2 was AR v1 with the calculation hole fixed, nothing more, nothing less - the offset detection is the same for both.

As i have tried to explain to you earlier, it doesn't fix any holes and it destroys the method of offset detection used by CUETools.

Yes, AR v1 was bad, it could even fail to detect a single-bit error, when a good 32-bit crc should be able to reliably detect a 32-bit burst error. Even basic XOR operation does that.

But who says AR v2 is immune to even single-bit errors? I'm pretty sure it's not. It's just a bit more obscure exactly which bits it fails to detect, because it now depends on the audio data, where in previous version those positions were fixed.

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.

But in case you absolutely had to, my advice was to use CRC32, which is proven to be immune against burst 32-bit errors, random 2-bit errors and most 3-bit errors AND allows offset calculations.

Or you could use Fletcher-32, which is exactly what you in fact tried to do, but done right.

Some useful discussion of checksum properties
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1336
Quote
And when verifying with AR v2 you can only use CRCs from the same pressing as yours.

That doesn't sound good, specially when the first thing I learned from accuraterip is the incredible number of offseted clones, which is far beyond what I would have imagined.
Presented this way, it sounds like a truncated AR for no gain. I don't know why you're even wasting time implementing it if you're convinced it's not done correctly.

It would be nice if you could agree together, cauz from an external point of view it seems AR2 will be a source of conflict. I think I have already seen Greynol vs Spoon, I don't want to see Gregory vs Spoon. It sounds dumb to me as from a technical point of view, all of you are way above the average HA user like me which don't understand much... I fell like I am counting stars waiting for the battle to end.

Is there a chance that the implementation of AR v2 in cuetool will actually prove who is right & who is wrong ? I mean if a rip is accurate with v1 & not with v2 (or the contrary) or some kind of unexpected behavior like this. [I mean if you consider it bad & you still implement it, I suspect you only implement it to prove that v2 is wrong]

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1337
I only implement it because it's very likely that new CDs will only have ARv2 CRCs in database when EAC 1.0 will be officially released, and people will still want to be able to verify their rips.

I need not prove anything. It's the claim that ARv2 is at least in some sense better than ARv1 that needs proof.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1338
How do I turn off this checking?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1339
Click this icon:
I know, it's annoying, was a mistake.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1340
Quote
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.


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


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


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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1341
>That doesn't sound good, specially when the first thing I learned from accuraterip is the incredible number of offseted clones, which is far beyond what I would have imagined.

AccurateRip v2 does detect across pressings

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1342
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

CUETools doesn't rip, and currently it's AR verification speed is limited only by flac decoding or HDD speed. That wouldn't be so when doing 10-20 calculations. Also that would also require a needless preparatory stage involving a lot of seeking to find 11 magic frames in each track. That's just bad design. And ARv2 CRC is also a bad design. It's just a broken version of higher bits of Fletcher-64, which has more collisions due to overflows than real Fletcher-64.

The detection is not in any way weakened by using the linear properties of ARv1 CRC (or CRC32 or Fletcher-32). It is mathematically equivalent to do a lot of calculations or one smart calculation, but the latter is much faster. I can always limit the output to offsets indicated by frame450, but i prefer not to do it.

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.

I didn't say anything about C2 pointers. I was talking about C2 error correction. When it lets the error through, it's never a single bit error. That's just how Reed-Solomon coding works. So in practice, weakness of ARv1 didn't matter much.

AccurateRip v2 does detect across pressings

In DbPoweramp i assume. As far as i know, not in EAC, not in fb2k and probably won't be in CUETools.

You already made a mistake once by inventing a bad CRC instead of taking 5 minutes to read on the subject. That's understandable, we all make mistakes. But why do the same mistake the second time, ignoring any advice?
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1343
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.

I also have never seen a false positive from AccurateRip based on real ripped data (and how many millions of CDs do these respective programs rip?), it should be obvious if the 'crc' was weak, a T&C in EAC (or similar in dBpoweramp) would give different overall CRC32s yet report a static AR CRC **.

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.



** the above does happen for tracks where the 5 frames are not taken into account for first or last track, this has been spotted many times and is to be expected.

(note this thread should split as discussions are not overly Cuetools related).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1344
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.

In fact, you can. Simple table implementation of CRC32 has approximately the same speed as ARv2 CRC. CRC32 on modern processors with SSE4.2 is way faster than ARv2 CRC (the special crc32 instruction introduced by Intel can process up to 64 bit per clock cycle (i.e. 3Ghz processor can process audio data at 146087x ripping speed)  - see here). And Fletcher-32 is about as fast as you can get without the special instruction.

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.

AR is great. I'm not bashing it. I just think a decision to introduce a new CRC didn't improve it, and the particular choice of a new CRC was very poor.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1345
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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1346
I hate to see this break down into a flame war instead of being a productive discussion. Maybe a completely open standard and protocol would be more helpful?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1347
"Bashing" wouldn't be the "current craze" if the developer were actually receptive to legitimate criticism and interested in improvement.


So you are saying I have an obligation to do this?, improve the CRC (although I have never seen a false positive) and all the other waste of time demands (such as detecting the insignificant number of drives which have buggy firmwares).

Ever wondered why projects such as CDex end up left by the wayside? because people are so ungrateful, if you had developed CDex and there have been 80 million downloads, you can expect on a monthly basis to get:

A) Abusive emails,
B) The occasional suing threat / threat of violence (because program XYZ broke my mouse!), expect three or four a year of these,
C) People who assume that because you have spent 1000's of hours writing something, that somehow implies you must spend a few hours helping that individual on a one to one basis, when this does not happen (A above),

The world is made up of many different people, a small % of these people are lets just say, not nice, inconsiderate, creating anything which has wide appeal will bring you into direct contact with those people. The saying goes "if you give a dog a bone, you do not want to hear from the dog if it does not taste nice".





CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1348
improve the CRC (although I have never seen a false positive)


I am falling off the line of argument here, in more ways:

- Wasn't AR2 (an attempt at) improving the CRC?
- Would you actually be able to detect a false positive, if there were/is such one?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1349
>Would you actually be able to detect a false positive, if there were/is such one?

If people are doing multiple tries on a damaged disc yes, they would show.