IPB

Welcome Guest ( Log In | Register )

100 Pages V  « < 52 53 54 55 56 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
Gregory S. Chudo...
post Apr 25 2011, 15:32
Post #1326





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (xz_kostyan @ Mar 20 2011, 01:24) *
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?

QUOTE (zsero @ Mar 21 2011, 07:13) *
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 sad.gif 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.

QUOTE (korth @ Apr 9 2011, 00:09) *
Already reported.

Thanks.

QUOTE (Miguk @ Apr 13 2011, 16:11) *
I've searched this topic but nothing found: is it planned to verify XLD extraction logfiles along with EAC logs?

I guess so smile.gif 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.

QUOTE (djray @ Apr 16 2011, 21:54) *
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.

QUOTE (Nino-kun @ Apr 24 2011, 07:58) *
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.

QUOTE (Tigerman @ Apr 25 2011, 11:45) *
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.

This post has been edited by Gregory S. Chudov: Apr 25 2011, 23:33


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Miguk
post Apr 26 2011, 20:52
Post #1327





Group: Members
Posts: 32
Joined: 24-November 08
Member No.: 63054



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?

This post has been edited by Miguk: Apr 26 2011, 20:53
Go to the top of the page
+Quote Post
Arbie
post Apr 27 2011, 18:19
Post #1328





Group: Members
Posts: 7
Joined: 4-January 04
Member No.: 10925



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
Go to the top of the page
+Quote Post
Tigerman
post Apr 28 2011, 19:28
Post #1329





Group: Members
Posts: 47
Joined: 15-June 07
From: Netherlands
Member No.: 44399



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
Go to the top of the page
+Quote Post
drfr
post May 10 2011, 11:34
Post #1330





Group: Members
Posts: 12
Joined: 31-May 10
Member No.: 81034



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.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post May 10 2011, 11:44
Post #1331





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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.4
Go to the top of the page
+Quote Post
drfr
post May 10 2011, 11:50
Post #1332





Group: Members
Posts: 12
Joined: 31-May 10
Member No.: 81034



QUOTE (Gregory S. Chudov @ May 10 2011, 12:44) *
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.
Go to the top of the page
+Quote Post
drfr
post May 16 2011, 09:02
Post #1333





Group: Members
Posts: 12
Joined: 31-May 10
Member No.: 81034



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?
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post May 16 2011, 10:19
Post #1334





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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.4
Go to the top of the page
+Quote Post
spoon
post May 16 2011, 12:47
Post #1335


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



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


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post May 16 2011, 13:46
Post #1336





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (spoon @ May 16 2011, 15:47) *
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

This post has been edited by Gregory S. Chudov: May 16 2011, 14:40


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
sauvage78
post May 16 2011, 18:51
Post #1337





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



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]

This post has been edited by sauvage78: May 16 2011, 18:55


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post May 16 2011, 19:46
Post #1338





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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.4
Go to the top of the page
+Quote Post
acmodeu
post May 17 2011, 06:48
Post #1339





Group: Members
Posts: 84
Joined: 28-September 07
From: Petrozavodsk
Member No.: 47418



How do I turn off this checking?
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post May 17 2011, 07:46
Post #1340





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



Click this icon:
I know, it's annoying, was a mistake.

This post has been edited by Gregory S. Chudov: May 17 2011, 07:47


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
spoon
post May 17 2011, 08:53
Post #1341


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



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.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
spoon
post May 17 2011, 08:56
Post #1342


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



>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


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post May 17 2011, 09:19
Post #1343





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (spoon @ May 17 2011, 11:53) *
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.

QUOTE (spoon @ May 17 2011, 11:53) *
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.

QUOTE (spoon @ May 17 2011, 11:53) *
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?

This post has been edited by Gregory S. Chudov: May 17 2011, 11:32


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
spoon
post May 17 2011, 11:02
Post #1344


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



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


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post May 17 2011, 12:04
Post #1345





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (spoon @ May 17 2011, 14:02) *
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.

QUOTE (spoon @ May 17 2011, 14:02) *
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.

This post has been edited by Gregory S. Chudov: May 17 2011, 12:26


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
greynol
post May 17 2011, 17:03
Post #1346





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (spoon @ May 17 2011, 14:02) *
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.

This post has been edited by greynol: May 17 2011, 22:03


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Eli
post May 17 2011, 19:49
Post #1347





Group: Members
Posts: 1055
Joined: 16-October 03
Member No.: 9337



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?


--------------------
http://forum.dbpoweramp.com/showthread.php?t=21072
Go to the top of the page
+Quote Post
spoon
post May 18 2011, 09:54
Post #1348


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



QUOTE (greynol @ May 17 2011, 17:03) *
"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".






--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Porcus
post May 18 2011, 12:32
Post #1349





Group: Members
Posts: 1779
Joined: 30-November 06
Member No.: 38207



QUOTE (spoon @ May 18 2011, 10:54) *
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?


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
spoon
post May 18 2011, 12:54
Post #1350


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



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


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post

100 Pages V  « < 52 53 54 55 56 > » 
Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 16th April 2014 - 18:21