CUETools versions 1.9.5 through 2.1.4 (current), AccurateRip support & more Options

[sauvage78]

Welcome to the machine

[drfr]

Old changelog is displaying

[Anakunda]

Hi !

Give a try but can't get it working (crash on transformation), tried other combinations also and crash too.
I think I setup paths to encoder exactly, why the error?
Exception: No process assigned to this object.
See the picture:

[Gregory S. Chudo...]

Old changelog is displaying

You're getting the old changelog from cache, which should expire in a day or two. I keep forgetting to make it purge the cache when switching to a new version.

Exception: No process assigned to this object.

Most likely takc.exe doesn't like the command line arguments and exits immediately.

[sauvage78]

First impressions: I still miss the old ability to detect HDCD (even just to tag their folder as HDCD) & also the ability to nuke the whole database from within CT (Why not something like right click the green "Local DB" icon in the "Folder browser", to "Clear the Local DB".) It happened several times to me that I had to close CT & relaunch CT just because I forgot to erease the local database, considering how slow CT is on startup with a Sempron 3000+, this is annoying.

Currently I am still testing & specially I am keeping an eye on how AR V2 results compares against AR V1 results, as of now I noticed that a small amount of AR(1) rips in AR V2 are simultaneously AR(No match but offset/1) in AR V1 (around 25 rips) ... I don't know if it has any meaning or if it's just random.

These rips looks like this:

[CUETools log; Date: 14/06/2011 02:53:21; Version: 2.1.2]
[CTDB TOCID: nxnT8rnGFSQh5rqdD5eaD9845y8-] disk not present in database.
[AccurateRip ID: 001478f1-00be6205-a70aa80c] found.
Track [ CRC ] Status
01 [d48a93b6] (0/1) No match but offset
02 [58465981] (0/1) No match but offset
03 [7fcb705d] (0/1) No match but offset
04 [7a3bea39] (0/1) No match but offset
05 [e8de3d53] (0/1) No match but offset
06 [9c0a8f87] (0/1) No match but offset
07 [dc4e6f68] (0/1) No match but offset
08 [f654d376] (0/1) No match but offset
09 [39c976cb] (0/1) No match but offset
10 [1f74f692] (0/1) No match but offset
11 [b72b7bec] (0/1) No match but offset
12 [a5de0adc] (0/1) No match but offset
AccurateRip v2:
01 [eeae9727] (1/1) Accurately ripped
02 [eddfa49f] (1/1) Accurately ripped
03 [8ebbbac1] (1/1) Accurately ripped
04 [ef34e2a4] (1/1) Accurately ripped
05 [1a591d8e] (1/1) Accurately ripped
06 [3a29e0cb] (1/1) Accurately ripped
07 [07aa6aba] (1/1) Accurately ripped
08 [28eb3df6] (1/1) Accurately ripped
09 [799aa6fa] (1/1) Accurately ripped
10 [422877c5] (1/1) Accurately ripped
11 [7e14f5b4] (1/1) Accurately ripped
12 [ae742ef0] (1/1) Accurately ripped

Track Peak [ CRC32 ] [W/O NULL]
-- 97,7 [520F4152] [27D503BE]
01 97,7 [331C4236] [FD0E301A]
02 97,6 [6B8D6665] [44C65F75]
03 97,5 [00837037] [23716875]
04 97,6 [FC21450A] [81952DA9]
05 97,5 [FA6CBD21] [35F5DBB2]
06 97,6 [8B648735] [F6AFEEE6]
07 97,5 [D24F5766] [B454C535]
08 97,5 [E22C79CF] [D8BBC5FC]
09 97,6 [16ECD255] [F80F8B67]
10 97,7 [76B19F70] [3352F99A]
11 97,5 [9917118D] [C77B975C]
12 97,5 [00656567] [32B35828]

Not that it is necessarily suspect, but it feels strange to have the same confidence level with different results on two different databases & on around 25 rips.
Maybe the low confidence itself explains this & it's just a question of habbit. I will see how it behaves on rips with higher confidence later.

Also AR V2 bring a lot of sorting question: should I consider an AR(1) on AR V1 + AR(1) on AR V2 rip as an overall AR(2) on AR V1+V2 ??? Obviously Edit: maybe yes, but then the whole way of sorting results from the local database is broken as the above rip is sorted as AR(0) while it is AR(1) in AR V2. [Edit: Well afterall, maybe not, if the same rip is submitted to AR V1 & AR V2 at the same time ... is it the case ???]

This is a real headeache, I hope there will not be an AR V3, V4, V5 ... cauz the .accurip logs will grow exponential. You already need a degree in archeology to dig thru a 57 pages thread but soon you'll need a degree in cryptography to understand .accurip logs ...

Anyway thks [Edit: A lot] for CT.

This post has been edited by sauvage78: Jun 14 2011, 14:53

[Gregory S. Chudo...]

I still miss the old ability to detect HDCD

Are you sure it's still broken? Should have been fixed.

Why not something like right click the green "Local DB" icon in the "Folder browser", to "Clear the Local DB".

You can do it in a couple of clicks, e.g. by right-clicking on "Local DB"->"by Verification Date"->"Today", etc.

but it feels strange to have the same confidence level with different results on two different databases & on around 25 rips.

Those are not different databases. Those are different CRCs within one database actually. My guess is, that old CRC is still used for offset detection CRCs. So EAC submits ARv1 offset detection CRC and ARv2 full CRC for each track.

I probably should just remove the first (ARv1) part of the log if it doesn't contain any matches and just show ARv2 part.

This post has been edited by Gregory S. Chudov: Jun 14 2011, 14:55

[sauvage78]

I re-tested HDCD detection on another rip & it worked. Sorry dunno why it didn't work the first time, it's likely my misstake (I must have compared a V2.1.1 .accurip against the same V2.1.1 log by opening it twice instead of opening the new V2.1.2 log, stupid me). Anyway thks for the fix.

Edit: Also the above rip is sorted as AR(1) not AR(0), so it is in the right category ... sorry lots lots of bullshits is coming out of my mouth today.

This post has been edited by sauvage78: Jun 14 2011, 15:48

[korth]

I still miss the old ability to detect HDCD

Are you sure it's still broken? Should have been fixed.

HDCD detection working here so far. Tested on 10+ rips.

[Marc27]

Welcome to the machine

Agree.
Thanks for the improved skip as well.

[marc2003]

nice update. i'm really liking the ability to remove individual entries from the local database.

[sauvage78]

Some feedback:
I don't know if AR V2 is really usefull (in term of robustness) but I like that AR V2 results are now displayed. It makes clearer where were those hidden results which I think (IIRC) were only displayed in the total sum of all AR (V1+V2) results so far. So thks for AR V2 support. I didn't found any major clash between AR V1 & AR V2 yet, but I did found several newly accurate rips in my collection thks to AR V2 results

For someone like me, who fix offset to highest, the way AR V2 results are displayed makes it hard to differenciate between rips that need fix & rip that are already with corrected offset ... the first time I tried to "fix" an AR(2) V2 with offset=0 rip because with AR V1 it was "no match but offset" with offset=0, so I was visually tricked by the force of habbit & thought it needed fixing ... It is missleading at first, but I have no suggestion to make it clearer (except different colors between AR V1 & V2 results). I first thought of completly separating AR V1 & AR V2 results, but I don't like the idea as if would make direct comparison between AR V1 & AR V2 results harder, so colors would be more suited IMHO, but I think it would maybe require a more complex .accurip format than text. No easy solution, but this is only a minor issue, specially if you don't fix offsets. With time I will get used to it.

Rips with silent tracks are still not reported as accurate in the batchlog, even if sorted as accurate in the local database. That is annoying as it forces me to use a separate folder for rips with [00000000] tracks. I hope it will be solved at some point so that I can once for good merge my collection.

Also rips with all tracks accurate somewhere (on different pressings) but not within the same offset are sorted as accurate in the local database, even if reported as not accurate in the batchlog.

Exemple: The local database sort this as AR(2) while the batchlog detects that it is not accurate.

CODE

[CUETools log; Date: 17/06/2011 20:00:07; Version: 2.1.2]
[CTDB TOCID: kBfKSyiTi83oBqEbpS6maqCrCqA-] disk not present in database.
[AccurateRip ID: 0016aaad-00decabe-be0b000d] found.
Track   [ CRC    ] Status
01     [f30e04e0] (0/4) No match
02     [e072886c] (0/4) No match
03     [4018f358] (0/4) No match
04     [6369d2ab] (0/4) No match
05     [8c3c17fe] (0/4) No match
06     [aede529f] (0/4) No match
07     [d8cfdd45] (0/4) No match
08     [7d6a5564] (0/2) No match
09     [0bff9354] (0/4) No match
10     [01fb4662] (0/4) No match
11     [efd8b57c] (0/4) No match
12     [90e6823c] (0/2) No match
13     [c8706114] (0/4) No match
Offsetted by -562:
01     [20ff9cd4] (2/4) Accurately ripped
02     [3319b5e4] (2/4) Accurately ripped
03     [96774600] (2/4) Accurately ripped
04     [df230673] (2/4) Accurately ripped
05     [3c243cf8] (2/4) Accurately ripped
06     [68dc8b9f] (2/4) Accurately ripped
07     [b6c666f1] (2/4) Accurately ripped
08     [64e6347a] (0/2) No match but offset
09     [954b801a] (2/4) Accurately ripped
10     [971f35c0] (2/4) Accurately ripped
11     [66e9b576] (2/4) Accurately ripped
12     [d81027ce] (2/2) Accurately ripped
13     [751e2c02] (2/4) Accurately ripped
Offsetted by 36:
01     [17493f78] (2/4) Accurately ripped
02     [f592a47c] (2/4) Accurately ripped
03     [0214bb08] (2/4) Accurately ripped
04     [05d9dc1b] (2/4) Accurately ripped
05     [1a05234a] (2/4) Accurately ripped
06     [4c68009f] (2/4) Accurately ripped
07     [ba31f36d] (2/4) Accurately ripped
08     [353133f8] (2/2) Accurately ripped
09     [c540dc88] (2/4) Accurately ripped
10     [414f8566] (2/4) Accurately ripped
11     [1df86ac8] (2/4) Accurately ripped
12     [46314758] (0/2) No match but offset
13     [9f504af8] (2/4) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--  100,0 [DDD04840] [022FCAD7]          
01  100,0 [42F0161D] [3C469549]          
02   97,6 [698FEA12] [82548A2F]          
03   97,6 [400BABDA] [8F8A082D]          
04   50,3 [242F015B] [14CA512E]          
05   97,6 [8646E8D0] [618049AB]          
06   97,6 [7A0A51AF] [23ECABEA]          
07   97,6 [6AA93766] [31CD105D]          
08   97,6 [06B05B5D] [F5ABD106]          
09   97,6 [44CCA0E3] [B17A8FBF]          
10   97,6 [D2F0761E] [F25C4E32]          
11   97,6 [34377520] [AC8F9514]          
12   97,6 [84B6BD90] [53073C6A]          
13   97,6 [F2CC8154] [D8E78A67]

Edit:
Also, it would be nice if there would be an option to keep the "Desktop" tree always unexpended because when you switch from "Drag&Drop mode" to "File browser mode" after a verification, it is always expended (to the last tested rip IIRC) & it is annoying as if you use "Drag&Drop mode" to add files/folders then you don't use the "File browser mode", this is an annoying side effect of merging "local database" with "File browser mode" ... I always have to click "desktop" to unexpend/hide it & this is annoying as hell.

This post has been edited by sauvage78: Jun 18 2011, 02:30

[sauvage78]

Even better than a don't expend "desktop" option: why not just display the "local database" in "drag & drop mode" too, just like you did for the "File browser mode", this way I wouldn't even have to always switch between the two view styles & would save 2 clicks after each verification.

The "drag & drop mode" only take 1 line so there is plenty of room to display the "local database" there. Nothing said the "local database" has to be attached to 1 view style/mode only.

This post has been edited by sauvage78: Jun 18 2011, 09:47

[Galsia]

Thanks for this new version, something about it is bothering me though.

In previous versions after choosing the "encode" action, it was possible to select a tracklist coming from a cue sheet or online databases and to edit it along with album data (artist, album, date, etc.). It was then saved to tags and locally, so it was possible encode the same album again without re-editing metadata. In this version there are more fields (which is nice since I use most of them), but edits aren't saved in tags or locally anymore. Is it intended, or am I missing something?

Also it would be nice to have the catalogue number in a different field than the label.

Anyway, thanks again for your work.

This post has been edited by Galsia: Jun 18 2011, 14:44

[Balleklorin]

Thanks for this new version, something about it is bothering me though.

In previous versions after choosing the "encode" action, it was possible to select a tracklist coming from a cue sheet or online databases and to edit it along with album data (artist, album, date, etc.). It was then saved to tags and locally, so it was possible encode the same album again without re-editing metadata. In this version there are more fields (which is nice since I use most of them), but edits aren't saved in tags or locally anymore. Is it intended, or am I missing something?

Also it would be nice to have the catalogue number in a different field than the label.

Anyway, thanks again for your work.

Same problem here. Hope it will be fixed soon.

[thescribbler]

Hi,

First off, thanks for such a great tool!

I have a weird problem that has only appeared since I did a fresh install of XP.

I have been going through my music library and using Cuetools to correct file/track names and split my single file rips into multiple files. Normally, when I want to correct file/track names, I create a new folder and re-encode the album into that. When I click 'Go' and Cuetools asks me to choose the best option from Freedb etc., I choose the closest entry and then manually edit/correct tracknames, genre etc and then click 'OK.' Cuetools used to accept my changes and encode the new files with my changes, but now it seems to ignore any changes I make and simply uses the Freedb entry (or whichever other option I chose) in its original state, ignoring my input.

It's probably something stupid I'm doing but I can't figure it out at all and I can't seem to find anyone with a similar problem. Any help would be greatly appreciated!

Edit: Just saw the previous two posts which I think are alluding to the same problem.

This post has been edited by thescribbler: Jun 19 2011, 12:26

[Fandango]

Why not something like right click the green "Local DB" icon in the "Folder browser", to "Clear the Local DB".

You can do it in a couple of clicks, e.g. by right-clicking on "Local DB"->"by Verification Date"->"Today", etc.

Huh? Nothing happen when I right-click on that green icon. And there's no "Local DB" anywhere else...

[sauvage78]

Actually you need to right click on the sub-sub-category, not the green icon itself.

This post has been edited by sauvage78: Jun 19 2011, 14:43

[Gregory S. Chudo...]

Why not something like right click the green "Local DB" icon in the "Folder browser", to "Clear the Local DB".

You can do it in a couple of clicks, e.g. by right-clicking on "Local DB"->"by Verification Date"->"Today", etc.

Huh? Nothing happen when I right-click on that green icon. And there's no "Local DB" anywhere else...

[Gregory S. Chudo...]

Rips with silent tracks are still not reported as accurate in the batchlog
Also rips with all tracks accurate somewhere (on different pressings) but not within the same offset are sorted as accurate in the local database, even if reported as not accurate in the batchlog.

edits aren't saved in tags or locally anymore.

A hot-fix for some of those issues: http://www.cuetools.net/install/CUETools_2.1.2a.rar
It's still not a complete fix, for example new metadata fields are still not saved to tags, i'll have to work out some tag mapping scheme for this, probably configurable as in fb2k, but that will have to wait till the next version.

[Fandango]

Where do I click to see that tree? I have looked everywhere I can't find it.

[Gregory S. Chudo...]

You have to switch to Folder Browser mode:

[Fandango]

Oh dang, I totally forgot about that mode! Thanks!

[sauvage78]

I just found this in my collection & I wonder if this is normal ??? At first I thought AR V2 was conflicting with AR V1 but it doesn't as when AR V2 seems to disagree all entries are in fact in AR V1, but what I don't really understand is why AR V2 reports "No match but offset" instead of simply "No match" because I thought AR V2 was still using AR V1 to find offset. Maybe it is perfectly normal & my knowledge is partial. (Sorry if the question is dumb, but I don't feel like digging all the thread to find if I missed something... So thks a lot if you can light my lantern!)

[CUETools log; Date: 18/06/2011 08:52:22; Version: 2.1.2]
[CTDB TOCID: qY2dAI_n3ZMGjPFnnLiRqOBK8cg-] disk not present in database.
[AccurateRip ID: 0038a45c-0365a3e7-21119115] found.
Track [ CRC ] Status
01 [0e2ddf38] (3/5) Accurately ripped
02 [14edaa99] (3/5) Accurately ripped
03 [8655448d] (3/5) Accurately ripped
04 [d0c5eaaa] (3/5) Accurately ripped
05 [071cfb94] (3/5) Accurately ripped
06 [cf6b6325] (3/5) Accurately ripped
07 [b4f969a5] (4/4) Accurately ripped
08 [2c45475e] (4/4) Accurately ripped
09 [66ffcf01] (3/5) Accurately ripped
10 [838a43f5] (3/5) Accurately ripped
11 [cc173105] (3/5) Accurately ripped
12 [92c8789b] (3/5) Accurately ripped
13 [6c8f0970] (3/5) Accurately ripped
14 [a84a6937] (3/5) Accurately ripped
15 [5263512e] (3/5) Accurately ripped
16 [9e513207] (3/5) Accurately ripped
17 [6337b5eb] (3/5) Accurately ripped
18 [bef1e9d7] (3/3) Accurately ripped
19 [94f9274f] (3/3) Accurately ripped
20 [9f69423e] (3/3) Accurately ripped
21 [f6720d66] (3/3) Accurately ripped
AccurateRip v2:
01 [ebf2a53a] (2/5) Accurately ripped
02 [4bf8a27a] (2/5) Accurately ripped
03 [58b70fae] (2/5) Accurately ripped
04 [8c3c500d] (2/5) Accurately ripped
05 [87f9de6b] (2/5) Accurately ripped
06 [c373159d] (2/5) Accurately ripped
07 [86ceab88] (0/4) No match but offset
08 [577e6a52] (0/4) No match but offset
09 [1513cd84] (2/5) Accurately ripped
10 [08c49dc7] (2/5) Accurately ripped
11 [09d48d38] (2/5) Accurately ripped
12 [46c46ea2] (2/5) Accurately ripped
13 [6e962e45] (2/5) Accurately ripped
14 [6004ea77] (2/5) Accurately ripped
15 [f531aa1b] (2/5) Accurately ripped
16 [02c82794] (2/5) Accurately ripped
17 [a6c8e4d3] (2/5) Accurately ripped
18 [c99751e2] (0/3) No match but offset
19 [331ece41] (0/3) No match but offset
20 [95d5899a] (0/3) No match but offset
21 [07bbe596] (0/3) No match but offset

Track Peak [ CRC32 ] [W/O NULL]
-- 96,6 [0A97FFC0] [52EBC20D]
01 95,0 [75D86578] [74EFD87D]
02 96,6 [554E360B] [EB980182]
03 82,3 [9CE89340] [39799E39]
04 96,6 [1E845856] [ECD213C8]
05 96,6 [12C194D7] [08367722]
06 96,6 [39922703] [0EB9675B]
07 94,9 [2AF77C45] [678F49A7]
08 77,2 [FC6CA213] [51A5D20B]
09 96,6 [B806E427] [70CE5D54]
10 94,6 [73FC443E] [CCA4B237]
11 93,1 [48079EA7] [5786374A]
12 74,9 [43F13B2F] [0E5CFAF5]
13 74,7 [093D05F7] [FDA46E73]
14 93,2 [D9770915] [5121B56D]
15 86,5 [A76EE30E] [5EC1C47C]
16 93,8 [814591D1] [360EF1FA]
17 88,8 [2772D010] [840EAAC2]
18 96,6 [1C9BD08D] [3694EB1F]
19 96,6 [C12AFF99] [40454BED]
20 96,6 [18C517BF] [077131F0]
21 96,6 [2078D354] [0732A98C]

This post has been edited by sauvage78: Jun 20 2011, 02:44

[Gregory S. Chudo...]

It is confusing to think of ARv1 and ARv2 as separate databases. There are not. In fact, when looking at a database entry, there's no way to determine which CRC was computed using ARv1 and which using ARv2. You can only guess that it's a V2 CRC when it matches your local CRC that you know you computed using V2. And all offset-detection CRCs are computed using ARv1, but this doesn't affect anything. It doesn't matter how offsets are detected.

So the first part of this log compares your V1 CRCs against a database entry. And the second part of this log compares your V2 CRCs against the same database entry. Those comparisons are currently done independently. This log is a mirror image of the log you quoted earlier, where the first part said 'No match but offset' and the second part said 'Accurately ripped'.

Would it be more intuitive if CUETools would have merged those two parts of log into somethings like follows?

CODE

Track [ CRC ,  CRCv2 ] Status
05 [071cfb94,87f9de6b] (3,2/5) Accurately ripped
06 [cf6b6325,c373159d] (3,2/5) Accurately ripped
07 [b4f969a5,86ceab88] (4,0/4) Accurately ripped
08 [2c45475e,577e6a52] (4,0/4) Accurately ripped

And your previous log from a CD that was submitted only using ARv2 would look like this:

CODE

01 [d48a93b6,eeae9727] (0,1/1) Accurately ripped
02 [58465981,eddfa49f] (0,1/1) Accurately ripped

This post has been edited by Gregory S. Chudov: Jun 20 2011, 03:35

[sauvage78]

So the answer is that offset finding is not really tied to AR V1 or AR V2 as database, which they are not. But only loosely tied to AR V1 as the way the offset finding CRC is calculated is closer to the algorythm used in AR V1, right ? Saying that AR V1 is used to find offset is a kind of word abuse, cauz there is two AR V1 CRC in fact (offset finding+verification).

Concerning your displaying proposal, well I like it as long as all is accurate on both AR V1 & V2 as it would be shorter, but it doesn't seems suited to display when all is not perfect, cauz in these cases, I think you'll need additionnal text to explain clashes.

Edit:
Well it seems you've edited your display so it's a moving target.
I would like it better if all was doubled vertically, even the explanation:

CODE

Track [ CRCv1-CRCv2 ] Status
05 [071cfb94-87f9de6b] (3+2=5) Accurately ripped/Accurately ripped
06 [cf6b6325-c373159d] (3+2=5) Accurately ripped/Accurately ripped
07 [b4f969a5-86ceab88] (4+0=4) Accurately ripped/No Match
08 [2c45475e-577e6a52] (4+0=4) Accurately ripped/No Match

Edit: /code instead of /quote ...

This post has been edited by sauvage78: Jun 20 2011, 04:12