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 1893890 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1250
wow, thank you very much!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1251
Quote
* Added 'Silent track' diagnostics in AR log


[00000000] (0/0) Silent track = CDImage.cue: AR: rip not accurate

Reporting [00000000] as Silent track is ok, but it's useless if the bachlog still report "rip not accurate" just because of a silent track.

The problem was with the bachlog which gives you a false report, not with the .accurip log. I still have to sort my rip with [00000000] in a separate folder if I don't want them to be mixed with rips which are really not accurate, so it's more self-speaking for new users but it's useless for me.

That was just my very first impression. I am still trying to understand what is that green puzzle icon (seems it's a local database that recall what you already tested, right?) & that clock icon (no clue). It's likely that I will complain some more soon

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1252
Waiting with anticipation for your complaints 

Yep, the green puzzle icon means local database, which stores your logs for you and lets you browse verified library in certain useful ways.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1253
At first I was septikal about this database thing but I like the local database ability to automatically find dupe & not accurate & AR(1) rips, if I can use it as I like, it will be a time saver for me.

So my first question is how do I nuke the database ? cauz as of my actual understanding of how it works I will only use it to sort my folders by AR results after each verification pass. So I don't need it to contain all my past verifications results unless I can sort by multi-criteria, like first by date of verification & then by AR results. It seems actually it's sorted by one or the other but not both, hence the reason why I think I will need to nuke the database regulary.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1254
A bug that is not specific to the new version, but that I don't recall I reported so far: often the information bar at the buttom is completely blackened except the green progress bar. I dunno why it happens but it may be linked to how the window is resized/reduced/enlarged as it happens often (more than 50% of time) but not at startup IIRC, maybe it is also linked to the fact that I use 125% fonts, I dunno. (I use Win7 32bits SP1)

A screenshot of the bug:


Edit1:
Also if the new local database is going to be used as a way to automatically sort the batchlog, it would be interesting to have a NPID (not present in database) entry in Localdatabase/Sort by Accuraterip Confidence, because without this I will still have to copy/paste the batchlog in a .txt & search within it manually.
So IMHO it's either all or nothing, the localdatabase must completely take over the batchlog without leaving result outside, even if not in database.

The idea of a local database is good but personnaly I quickly started to think that it should completely replace the batchlog if done correctly.

Edit2:
This is just my personnal opinion but if I were to sort result according to AR, I would sort it like that:

AR(1)
AR(2)-AR(10)
AR(10+)
nAR-NM (not accurate with only "no match", reasonnable probability of being incomplete in database without being necessarily scratched)
nAR-NMBO (not accurate with "no match but offset", high probability of being scratched)
NPID (Not present in database)

+ special categories for
Silent Track [00000000]
Data Track (ECD)
CDDBId Mismatch
Doublons

Actually I think the difference between the AR(2), AR(3) & AR(below 5) categories is meaningless, as well as the difference between the AR(below 10) & AR(below 20) categories.
It's way too much categories for me, personnaly I only need two: AR(with low confidence) & AR(with high confidence). My personnal limit between high & low is AR(10) & it is completely arbitrary.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1255
I cannot edit anymore  & I am not sure that the word "categorie" exist in english so plz read: categorie=class

Edit: Thks Greynol.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1256
Category is the correct singular form of the plural word categories.

I can understand why this might be difficult for a non-native English speaker.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1257
Another bug that is not specific to the last version, when you use the Windows Snap feature from Windows 7 which automatically resize a window to half the size of your screen in order that you can see two windows on your screen (left/right), cuetools is always resized a little larger than half the screen which is annoying.

Bug screenshot:


I report it now because with the new local database it is easy now to browse the local database on the left window & sort your folders according to the results of the database on the right window, so it is more annoying now than it was previously.

Also as a suggestion, adding in parenthesis the sum of the number of rips in each category & each sub-category would maybe be interesting.

Edit:
I wanted to underline that the fact that you left out "not present in database" results from the local database as the side effect that finding dupes within rips that are not in AR database doesn't work, while I think technically CT could be used to find dupes within those rips, even just by comparing CTDB TOCID, if sums are not calculated (when using "verify only if found").

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1258
I still don't understand, how CUERipper handles C2 pointers. I didn't find any settings or options related to CUERipper. Doesn't matter if Burst or Secure mode is used, in final log, there is always  Make use of C2 pointers : No, though according to Gregory (http://wiki.hydrogenaudio.org/index.php?title=Comparison_of_CD_rippers) it is supported.
Second, i've total chaos from many explanations related to defeating cache with or without FUA support, they are offen contradictory. I suppose, CUERipper doesn't have FUA implemented, maybe in the future, or it isn't necessary at all (of course it must be firstly supported by the drive itself).

Simply i'm interested how CUERipper works, because objectivelly in my case (W7 x32, LG 4167B) it gives me consistently the most correct results from the other two well known rippers (EAC, dBP Ripper, with all ripping modes checked out). Tested on o scratched CDs and compared with the rips from other drive that was able to read them without a single problem, the possible reported suspicious positions on LG were in the case of CUERipper always correct (amount and position), unlike the other two (e.g. EAC, in Burst mode or Secure mode with (here it could be obvious) but also without C2). Moreover, CUETools was able to repair CUERipper rips into AR compliant state, perfect.

I appreciate Gregory's good work here, because it is the only ripper that could pull from my old drive really maximum, in that it can correctly interprete the readed samples. interesting if also others with relatively older drives, have a similar experience.
I use CUERipper mostly in Burst mode, according to log no C2s are used. When are they in use, if at all?. So how it is?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1259
On start, a message "CUETools 2.0.9 is out!" appears.
Is the bug with the de-DE.dll fixed BTW?
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1260
I still don't understand, how CUERipper handles C2 pointers.

It does use C2 pointers even in burst mode, if the drive supports them.

But not in the same sense that EAC does. I'm speculating here, because EAC is not open source and i can only repeat what i've read about it on some forum, but it seems that EACs "Use C2 pointers" option can decrease the number of retries the ripper makes if the drive reports that data is ok (correct me if i'm wrong), while CUERipper only uses C2 to increase the number of retries if the drive reports that data is not ok. In other words, CUERipper uses C2 pointers while EAC relies on C2 pointers.

Second, i've total chaos from many explanations related to defeating cache with or without FUA support, they are offen contradictory. I suppose, CUERipper doesn't have FUA implemented, maybe in the future, or it isn't necessary at all (of course it must be firstly supported by the drive itself).

CUERipper doesn't use FUA bit, but instead works under assumption that drive has no more than 8 megabytes of cache, and invalidates this cache in only reliable way - by reading in large non-overlapping chunks, which forces the cache invalidation.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1261
On start, a message "CUETools 2.0.9 is out!" appears.
Is the bug with the de-DE.dll fixed BTW?

That message will probably go away soon. It is cached for one day. You downloaded new version before CUETools found out there's a new version
Thank you for reminding me, I just fixed the crash with de-DE locale. Just download it again.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1262
I wanted to underline that the fact that you left out "not present in database" results from the local database as the side effect that finding dupes within rips that are not in AR database doesn't work, while I think technically CT could be used to find dupes within those rips, even just by comparing CTDB TOCID, if sums are not calculated (when using "verify only if found").

Rips that aren't in AR database still go to local database. If you use "Add folder to local database", AR is not contacted at all. And dupes are also found regardless of AR, just make sure you are not verifying in "only if found" mode.
CUETools 2.1.6


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1264
Thks for answers. I am slowly starting to like this local database thing even if not perfect yet.

Quote
Just delete the file "C:\Users\<username>\AppData\Roaming\CUE Tools\LocalDB.xml.z"

I had the idea but I was afraid to break something, it'll do the trick for now but I think a button within the GUI would be more practical in the future.

Quote
just make sure you are not verifying in "only if found" mode.

Well with my slow sempron 3000+ I was always using "only if found" mode so far, hence it didn't work.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1265
Then use the method i described earlier to find dupes. It should be fast.

* In Folder Browser, right-click on the folder with your rips and choose "Add folder to local database".
* Under "By Uniqueness" select "Not yet verified clones" and batch-verify them.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1266
Thks worked great, but what is this new CRC in batchlog, like:
Code: [Select]
cdimage.cue: CRC 2C2822C4

How is it calculated & what does it mean?

What is used to detect clones using this fast method, specially compared to a full scan with sums?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1267
That's CRC32 of the audio data without the few leading and trailing samples.
That's because drives with different offsets and no overread capability will produce different data in those areas.
Actually, several such CRCs with different offsets are stored in DB, which also allows to detect offset-corrected dupes or different pressings ("Offsetted clones" category)

Those CRCs are computed when verifying, so before verification DB doesn't know if the dupes have the same audio data, and places them in "Not yet verified clones" category.
Clones by definition are discs with the same DiscIds/TOCs (ignoring pregap/data track). Only DiscIds are calculated when adding folder to database without verification.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1268
So DiscIds/TOCs are not Edit:AccurateRip ID CTDB TOCID, which explains why it is faster than calculating audio data sums but slower than just comparing Edit:AccurateRip ID CTDB TOCID (which should be almost instant fast if it was already calculated in the .accurip)

As far as I understund it has the advantage of being able to find dupe between 2 identical rips with different Edit:AccurateRip ID CTDB TOCID due to a pregap/datatrack difference only, that's it? First pass DiscIds/TOCs (without pregap/datatrack), 2nd pass CRC32 (without leading & trailing samples) ... sounds very efficient.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1269
CTDB and local database have much in common. They both use two IDs - one for TOC, one for audio data. DiscID/TOCId is the same as in CTDB.  Data CRCs are slightly different, because when i was developing CTDB i didn't invent this new way of detecting offsets yet.

So you are mostly right, but dupes always have the same CTDB TOCID.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1270
Sounds like I am missing something there because I thought Edit:AccurateRip ID CTDB TOCID was calculated with pregap/datatrack & you tell me DiscIds/TOCs is not but at the same time that "DiscID is the same as in CTDB", so now I am lost within all these ID ... sorry if I am dumb.

Edit: Sorry I just realized I mixed AccurateRip ID with CTDB TOCID in post #1269, so now it's a mess, much sorry, I edited all that

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1271
Quote
EACs "Use C2 pointers" option can decrease the number of retries the ripper makes if the drive reports that data is ok (correct me if i'm wrong), while CUERipper only uses C2 to increase the number of retries if the drive reports that data is not ok. In other words, CUERipper uses C2 pointers while EAC relies on C2 pointers.

You gave a little bit more light to that, however i still think "decreasing the number of retries if the drive reports that data is ok" and "increase the number of retries if the drive reports that data is not ok" are two different approaches but with the same resulting effect. EAC secure with C2 and CUERipper in burst mode, both will do multiple readings only if get error report from the drive, unless CUERipper in burst mode reads every chunk twice (from the speed indicator it doesn't seem so) , i don't think so, its the case only for secure mode.
Ah what, just doesn't matter, CUERipper simply works much better for me. 

Quote
drive has no more than 8 megabytes of cache, and invalidates this cache by reading in large non-overlapping chunks, which forces the cache invalidation.

At least i shouldn't buy a drive with bigger that 8MB cache, if i find one  anyway, a clever idea.
Thanks for explanation and hard work.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1272
Quote
dupes always have the same CTDB TOCID

So CTDB TOCID from .accurip using "only if found" could be used to find possible dupe before further CRC examination, right ? It would be even faster than re-calculating DiscIds/TOCs, no ??? Not that I really care, the method you pointed me is already fast enougth anyway. I am just curious as is was the way I expected it to be done.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1273
So CTDB TOCID from .accurip using "only if found" could be used to find possible dupe before further CRC examination, right ? It would be even faster than re-calculating DiscIds/TOCs, no ???

If you already have the logs - in theory, yes. But CUETools doesn't parse logs when it creates the database. Logs are there only for your convenience. TOCs are calculated fast enough, because you only have to parse .cue file and look at the headers of audio files to find out their length. No audio is decompressed at this stage.
CUETools 2.1.6