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:

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.

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

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.

QUOTE (sauvage78 @ Jun 14 2011, 17:37)

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.

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.

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.

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.

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.

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.

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.

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.

Rips with silent tracks are still not reported as accurate in the batchlogAlso 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.

QUOTE (Galsia @ Jun 18 2011, 17:42)

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

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

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?

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: