IPB

Welcome Guest ( Log In | Register )

102 Pages V  « < 49 50 51 52 53 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
jaro1
post Mar 7 2011, 10:49
Post #1251





Group: Members
Posts: 77
Joined: 22-November 08
Member No.: 62952



wow, thank you very much!
Go to the top of the page
+Quote Post
sauvage78
post Mar 7 2011, 14:21
Post #1252





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



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


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 7 2011, 14:31
Post #1253





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



Waiting with anticipation for your complaints wink.gif

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.4
Go to the top of the page
+Quote Post
sauvage78
post Mar 7 2011, 15:12
Post #1254





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



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.

This post has been edited by sauvage78: Mar 7 2011, 15:15


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
sauvage78
post Mar 7 2011, 18:51
Post #1255





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



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.

This post has been edited by sauvage78: Mar 7 2011, 19:43


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
sauvage78
post Mar 7 2011, 19:53
Post #1256





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



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

Edit: Thks Greynol.

This post has been edited by sauvage78: Mar 7 2011, 20:06


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
greynol
post Mar 7 2011, 19:56
Post #1257





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



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

This post has been edited by greynol: Mar 7 2011, 19:59


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
sauvage78
post Mar 7 2011, 21:42
Post #1258





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



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

This post has been edited by sauvage78: Mar 7 2011, 22:34


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
jaro1
post Mar 8 2011, 12:02
Post #1259





Group: Members
Posts: 77
Joined: 22-November 08
Member No.: 62952



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?
Go to the top of the page
+Quote Post
tuxman
post Mar 8 2011, 12:12
Post #1260





Group: Members
Posts: 188
Joined: 24-April 07
From: Northern Germany
Member No.: 42855



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


--------------------
audiophile // FLAC and Vorbis user // Winamp addict
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 8 2011, 15:34
Post #1261





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



QUOTE (jaro1 @ Mar 8 2011, 14:02) *
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.

QUOTE (jaro1 @ Mar 8 2011, 14:02) *
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.

This post has been edited by Gregory S. Chudov: Mar 8 2011, 18:05


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 8 2011, 15:49
Post #1262





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



QUOTE (tuxman @ Mar 8 2011, 14:12) *
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 smile.gif
Thank you for reminding me, I just fixed the crash with de-DE locale. Just download it again.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 8 2011, 15:55
Post #1263





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



QUOTE (sauvage78 @ Mar 7 2011, 23:42) *
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.4
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 8 2011, 16:02
Post #1264





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



QUOTE (sauvage78 @ Mar 7 2011, 17:12) *
So my first question is how do I nuke the database ?

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


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
sauvage78
post Mar 8 2011, 16:11
Post #1265





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



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.

This post has been edited by sauvage78: Mar 8 2011, 16:17


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





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



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.

This post has been edited by Gregory S. Chudov: Mar 8 2011, 16:22


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
sauvage78
post Mar 8 2011, 16:49
Post #1267





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



Thks worked great, but what is this new CRC in batchlog, like:
CODE
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?

This post has been edited by sauvage78: Mar 8 2011, 16:53


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





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



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.

This post has been edited by Gregory S. Chudov: Mar 8 2011, 17:09


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
sauvage78
post Mar 8 2011, 17:12
Post #1269





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



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.

This post has been edited by sauvage78: Mar 8 2011, 17:31


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





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



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.

This post has been edited by Gregory S. Chudov: Mar 8 2011, 17:27


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
sauvage78
post Mar 8 2011, 17:23
Post #1271





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



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

This post has been edited by sauvage78: Mar 8 2011, 17:34


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
jaro1
post Mar 8 2011, 18:45
Post #1272





Group: Members
Posts: 77
Joined: 22-November 08
Member No.: 62952



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 laugh.gif anyway, a clever idea.
Thanks for explanation and hard work.

This post has been edited by jaro1: Mar 8 2011, 18:46
Go to the top of the page
+Quote Post
sauvage78
post Mar 8 2011, 19:44
Post #1273





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



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.

This post has been edited by sauvage78: Mar 8 2011, 19:45


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 8 2011, 21:03
Post #1274





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



QUOTE (sauvage78 @ Mar 8 2011, 21:44) *
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.4
Go to the top of the page
+Quote Post
Nowings69
post Mar 8 2011, 23:22
Post #1275





Group: Members
Posts: 95
Joined: 22-December 09
From: nicyoume
Member No.: 76223



Thanks for 2.1.1
Accuracy,Flaccl#0.3 was very pickey to only my legacy Nvidia's GPU(9600GT)
but Flaccl#0.4 works fine
You are the superior developer for OpenCL as far as I know it laugh.gif

Attached thumbnail(s)
Attached Image
 
Go to the top of the page
+Quote Post

102 Pages V  « < 49 50 51 52 53 > » 
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: 27th August 2014 - 22:28