IPB

Welcome Guest ( Log In | Register )

105 Pages V  « < 50 51 52 53 54 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
sauvage78
post Mar 9 2011, 13:03
Post #1276





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



My guess is that you already intend to do it as it is an evidence, but sorting result in the local database according to CTDB would be usefull too, now the problem is how to sort rip that are OK & differs at the same time.

I think it can be done in 3 categories:
-CTDB NPID (Not Present in Database) ==> Unknown
-CTDB Present in Database (No Matter If OK or differs)+AR(No Matter Condidence) ==> Accurate So CTDB Is Likely Useless
-CTDB Present in Database (Differs)+Not Accurate ==> Likely Scratched & Fixable

Also you said you intended to add .toc support for ECD with old EAC log that don't include .toc & miss the datatrack length, did you ever wonder about supporting it in .cue sheet via the REM command, I mean if you parse a .cue for
REM COMMENT "CUETools CD-Extra data track length 09:26:06." or maybe just
REM DATA "CD-Extra data track length 09:26:06." (I prefer the second one as it is easier to edit)
It would do the trick IMHO.

I mean the pregap length & the track number (incl. the data track via the DISCID) are already in the cue sheet, so IMHO it's far from illogical to store it there.

This post has been edited by sauvage78: Mar 9 2011, 13:39


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
chapa
post Mar 12 2011, 23:17
Post #1277





Group: Members
Posts: 1
Joined: 12-March 11
Member No.: 88954



Gregory S. Chudov
Thanks for CUE Tools 2.1.1. This great prog is most helpful for me with .wv.

Vertical? She drowned.

We Shall Overcome!
Make Love, Not War.
Go to the top of the page
+Quote Post
korth
post Mar 13 2011, 17:54
Post #1278





Group: Members
Posts: 479
Joined: 13-March 11
Member No.: 88969



HDCD detection changes in 2.1.1? No longer seeing HDCD in Batch Log, AccurateRip Log and not in Local Database on rips where 2.0.9 detected HDCD.

headbang.gif


--------------------
korth
Go to the top of the page
+Quote Post
sauvage78
post Mar 13 2011, 19:01
Post #1279





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



As a suggestion, as I don't merge my folder with AR(1) results with my folder with AR(>=2) results even if I have the CD, a script that would "test only if AR confidence is different from AR(1) in AR database" would be usefull for me. Just like "test only if found", it would be a CPU time saver for me as it would help skip AR(1) results when I re-test my folder with only AR(1) results. Doing so it would only test results which are not AR(1) anymore in AR database either because the result was dismissed: [AR(0) or "not present anymore in AR database"], or because it is now AR(>=2) [so I don't need to re-test them anytime soon]. Re-testing each months AR(1) results which are still AR(1) in database is a waste of ressource IMHO (specially with my weak CPU). I know some netpicking people might argue that re-testing AR(1) rip is useless if you have the CD anyway, thks I know it, keep your opinion cauz I'll keep mine & such a script would be usefull for me. (In ten years from now I don't know if I will still have the CD & I don't know if I will remember that I did have the CD one day for each of my rip, so like it or not, personnaly I never consider AR(1) safe)

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


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
sauvage78
post Mar 13 2011, 20:55
Post #1280





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



I confirm that CD previously detected as HDCD are not detected as HDCD anymore (Tested on 6 HDCD).

This post has been edited by sauvage78: Mar 13 2011, 20:58


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
GreenDrazi
post Mar 15 2011, 07:08
Post #1281





Group: Members
Posts: 3
Joined: 4-January 09
Member No.: 65188



Another item that seems to be missing in CUETools v2.1.1:

When verifying tracks that need an un-known pre-gap number, you now have to allow the program to proceed with verifying and overwriting an existing log file to know if the number you are trying is the correct number in the database. This is fine if you know the correct number.

Previously, you would get the request to overwrite the existing log file along with the Accuraterip icon highlighted to let you know that you’ve chosen the correct pre-gap number. If it wasn’t the correct pre-gap number, the Accuraterip icon was not highlighted and you could just select “no” to not over-write and move onto the next pre-gap number. This made it much quicker to get to a correct pre-gap number.

If there is a better way or quicker way to get correct pre-gap numbers, please let me know.


Otherwise, thanks for the update and a great program.

This post has been edited by GreenDrazi: Mar 15 2011, 07:26
Go to the top of the page
+Quote Post
amalone
post Mar 15 2011, 07:53
Post #1282





Group: Members
Posts: 29
Joined: 22-February 10
Member No.: 78388



I can convert Flac files to Ogg Vorbis image files with the track information embedded using Foobar2000. If I use CueTools, the track info is not there. Is it just command line parameters that need to be changed. If so, can someone tell me what they should be? With both Foobar and CueTools I am using the latest AoTuv encoder (6.02).

When ripping a CD to Flac with Foobar, I can easily delete tracks that I do not want included. I do not see an option in CueRipper to do this. Am I overlooking something?

Many thanks for this great software.
Go to the top of the page
+Quote Post
sidjames
post Mar 15 2011, 16:54
Post #1283





Group: Members
Posts: 10
Joined: 1-December 05
Member No.: 26144



QUOTE (GreenDrazi @ Mar 15 2011, 00:08) *
Another item that seems to be missing in CUETools v2.1.1:

When verifying tracks that need an un-known pre-gap number, you now have to allow the program to proceed with verifying and overwriting an existing log file to know if the number you are trying is the correct number in the database. This is fine if you know the correct number.

Previously, you would get the request to overwrite the existing log file along with the Accuraterip icon highlighted to let you know that you’ve chosen the correct pre-gap number. If it wasn’t the correct pre-gap number, the Accuraterip icon was not highlighted and you could just select “no” to not over-write and move onto the next pre-gap number. This made it much quicker to get to a correct pre-gap number.

If there is a better way or quicker way to get correct pre-gap numbers, please let me know.


Otherwise, thanks for the update and a great program.


i think it worked better the old way too, it was a good way to check a few different possibilities quickly for older eac rips without gap detection. for what its worth though, if you press stop before the verification is completed the log doesnt appear to be overwritten.
Go to the top of the page
+Quote Post
sidjames
post Mar 15 2011, 18:17
Post #1284





Group: Members
Posts: 10
Joined: 1-December 05
Member No.: 26144



thanks for the update, im totally indebted to cuetools.. one quick question thats been bugging me if i may.. this one has been bugging me for a couple of days. here are two reports from the same rip, one with a cue file and one without. please note that one is "accurate" and one not, the crcs for track 1 have different values for the same track! is there a reason for this?

with cue

[CUETools log; Date: 15/03/2011 17:24:00; Version: 2.1.1]
Pregap length 00:00:33.
[CTDB TOCID: Vuf8OxYpGA1WPTZiSMPGXcsCza4-] found.
[ CTDBID ] Status
[79bc561b] (72/72) Accurately ripped
[AccurateRip ID: 000aae9c-00488545-69091008] found.
Track [ CRC ] Status
01 [7ff67560] (023/095) Accurately ripped
02 [53ff39a0] (026/099) Accurately ripped
03 [4269846f] (025/099) Accurately ripped
04 [e78babb6] (024/096) Accurately ripped
05 [63aa7ee4] (026/100) Accurately ripped
06 [d90c3a31] (025/098) Accurately ripped
07 [56ac3dc9] (024/097) Accurately ripped
08 [94e3cb88] (026/096) Accurately ripped
Offsetted by -1187:
01 [14e12e73] (012/095) Accurately ripped
02 [e348df57] (012/099) Accurately ripped
03 [a4e0fe5e] (013/099) Accurately ripped
04 [88c4099b] (013/096) Accurately ripped
05 [abb5dca8] (013/100) Accurately ripped
06 [88ac357e] (013/098) Accurately ripped
07 [076dfa13] (013/097) Accurately ripped
08 [97fe8420] (013/096) Accurately ripped

(edited)....

Track Peak [ CRC32 ] [W/O NULL]
-- 93.8 [69D28992] [4F9382CA]
01 87.9 [3A958896] [38EE23BC]
02 93.8 [98852A53] [6F75C85C]
03 91.7 [BAC2FC05] [76E8E3E3]
04 64.7 [C8DC7D44] [3DCC4E18]
05 87.6 [067ADAF0] [83DA9F5E]
06 89.2 [5AD30B16] [B57A34EB]
07 82.6 [FC1B168A] [D753063A]
08 87.5 [468FAF05] [3EBF666F]


without cue

[CUETools log; Date: 15/03/2011 16:51:34; Version: 2.1.1]
Pregap length 00:00:33.
Using preserved id, actual id is 000aafa4-00488af1-6c091108.
[CTDB TOCID: MIBr0Co..lcDgLO_bhdFOXYGGkw-] disk not present in database.
[AccurateRip ID: 000aae9c-00488545-69091008] found.
Track [ CRC ] Status
01 [db4a22d0] (000/095) No match
02 [53ff39a0] (026/099) Accurately ripped
03 [4269846f] (025/099) Accurately ripped
04 [e78babb6] (024/096) Accurately ripped
05 [63aa7ee4] (026/100) Accurately ripped
06 [d90c3a31] (025/098) Accurately ripped
07 [56ac3dc9] (024/097) Accurately ripped
08 [94e3cb88] (026/096) Accurately ripped
Offsetted by -1187:
01 [ea73d4df] (000/095) No match
02 [e348df57] (012/099) Accurately ripped
03 [a4e0fe5e] (013/099) Accurately ripped
04 [88c4099b] (013/096) Accurately ripped
05 [abb5dca8] (013/100) Accurately ripped
06 [88ac357e] (013/098) Accurately ripped
07 [076dfa13] (013/097) Accurately ripped
08 [97fe8420] (013/096) Accurately ripped

(edited)

Track Peak [ CRC32 ] [W/O NULL]
-- 93.8 [8CF6F2CF] [4F9382CA]
01 87.9 [94FF746C] [38EE23BC]
02 93.8 [98852A53] [6F75C85C]
03 91.7 [BAC2FC05] [76E8E3E3]
04 64.7 [C8DC7D44] [3DCC4E18]
05 87.6 [067ADAF0] [83DA9F5E]
06 89.2 [5AD30B16] [B57A34EB]
07 82.6 [FC1B168A] [D753063A]
08 87.5 [468FAF05] [3EBF666F]
Go to the top of the page
+Quote Post
Nowings69
post Mar 16 2011, 06:20
Post #1285





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



Please rip it with latest EAC again
dont forget LOG is in English
and let me see here your LOG
Go to the top of the page
+Quote Post
Tigerman
post Mar 16 2011, 12:38
Post #1286





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



The crcs without zero are the same. Probably without the cuesheet the pregap of 33 is within the calculated crc with zeros

This post has been edited by Tigerman: Mar 16 2011, 12:39
Go to the top of the page
+Quote Post
sidjames
post Mar 16 2011, 13:01
Post #1287





Group: Members
Posts: 10
Joined: 1-December 05
Member No.: 26144



QUOTE (Nowings69 @ Mar 15 2011, 23:20) *
Please rip it with latest EAC again
dont forget LOG is in English
and let me see here your LOG


it was ripped with XLD, which id hazard a pretty strong guess is central to the problem. unfortunately i no longer have the cd. track 1 looks like this.. the files havent been altered other than for tagging so i would imagine its very likely "AccurateRip signature : 7FF67560" is correct for this track. im just curious as to why cuetools gives a different value based on whether the cue file is present or not.

Track gain : -3.71 dB
Peak : 0.879486
CRC32 hash (test run) : 3A958896
CRC32 hash : 3A958896
CRC32 hash (skip zero) : 38EE23BC
AccurateRip signature : 7FF67560
->Accurately ripped! (confidence 21)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 16 2011, 13:47
Post #1288





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



Note that without CUE sheet AccurateRip ID changes, that means that CUETools wasn't able to determine track lengths correctly.

My guess is that your track 1 also contained HTOA (track 0) prepended to it.

You should trust verification result with CUE Sheet. Without it CUETools is not always able to correctly guess the track lengths. It assumes that rip was done in gaps appended (noncompliant) mode, and yours is slightly different due to the way pregap was handled.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Darfo9
post Mar 17 2011, 01:20
Post #1289





Group: Members
Posts: 1
Joined: 17-March 11
Member No.: 89051



The local db is a very nice feature.
I request that you write to the db after every verification.
It would also be nice if multiple instances could write the db correctly, for one.
More significantly, my first 48 hours of verification were lost due to crash, corrupt db.
Unfortunately I do not have any information on that crash.
Also, as was mentioned previously, writing the application log to disc after each verification would be very helpful.
It would help me find some rips where I saved the wrong cuesheet, for one thing.

I have used ArCueTool with mono for verification for a long while.
No success with the full CUETools after version 1.9.5.
This version was closer to functional with mono... I gave in and tried in a Win7x64 VirtualBox VM.
This could be part of the reason for my second issue (the filesystem is shared from the host in VBox).
Two directories (the largest ones) will not add to local db, or open in multiselect.
Instead, the name changes in the tree, and an error is reported, different for each dir:
'Illegal characters in path..'
'Second path fragment must not be a drive or UNC name.
Parameter name: path2.'
I will try sharing the drive with samba instead. I expect it can avoid presenting characters windows dislikes.

I would be happy to help identify any mono problems also.
Currently there is a crash if settings is opened more than one time.
Also the 'Array Index is out of range." issue others mentioned.
Got external decoders working for the first time though, so it is looking close to usable on linux by now.

Great program. I appreciate it a lot.
If I can scan my archive into local db, that will be very helpful in pruning out some old duplicates, with good knowledge that I am keeping the right version at a glance.
Go to the top of the page
+Quote Post
sauvage78
post Mar 17 2011, 09:16
Post #1290





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



Bug (or maybe just a bad behavior):
The new database report as AR(1) rips that are not AR(1) within the same offset for all tracks:

Exemples:
CODE
[CUETools log; Date: 17/03/2011 01:54:50; Version: 2.1.1]
[CTDB TOCID: b6gm9OlJdrcf4Tg_8v0zf4blTzI-] disk not present in database.
[AccurateRip ID: 0017ec1c-00c283cb-7d0fc30a] found.
Track   [ CRC    ] Status
01     [ee75877b] (0/1) No match
02     [a42162d5] (0/1) No match
03     [2c9b2173] (0/1) No match
04     [9d6dde86] (0/1) No match
05     [01e28cbd] (0/1) No match
06     [086d5cd8] (0/1) No match
07     [beacb897] (0/1) No match
08     [771e0e75] (0/1) No match
09     [88b4d0ec] (0/1) No match
10     [10dbdb63] (0/1) No match
Offsetted by -30:
01     [248faa5b] (1/1) Accurately ripped
02     [e20bdec7] (1/1) Accurately ripped
03     [82a5426f] (1/1) Accurately ripped
04     [8c418997] (1/1) Accurately ripped
05     [a9728e8d] (1/1) Accurately ripped
06     [8846b6ca] (1/1) Accurately ripped
07     [0f09d762] (1/1) Accurately ripped
08     [7669c547] (1/1) Accurately ripped
09     [3298a756] (0/1) No match
10     [7b9740c7] (1/1) Accurately ripped
Offsetted by -24:
01     [66c6e8ea] (0/1) No match
02     [da8ab2d0] (0/1) No match
03     [714c6f08] (0/1) No match
04     [648edaac] (0/1) No match
05     [28ce489a] (0/1) No match
06     [f8ee815b] (0/1) No match
07     [fedcd139] (0/1) No match
08     [a9c1071d] (0/1) No match
09     [43d17c74] (1/1) Accurately ripped
10     [330b5fb3] (0/1) No match

Track Peak [ CRC32  ] [W/O NULL]
--  100,0 [3F152733] [3705D836]          
01  100,0 [D59F28F5] [3133D51F]          
02  100,0 [F2992133] [753725E0]          
03  100,0 [5947389A] [C7567C3A]          
04  100,0 [8769CA2F] [064C83B1]          
05  100,0 [FBEC632D] [32BE3824]          
06  100,0 [7A956A4D] [94BE15FB]          
07  100,0 [5326ACC9] [2D0DECF0]          
08  100,0 [A7D889D3] [FF0A9321]          
09  100,0 [F414995E] [7809B389]          
10   95,0 [F21F2CFC] [4E510C8B]


CODE
[CUETools log; Date: 17/03/2011 02:51:31; Version: 2.1.1]
[CTDB TOCID: h7JhPbXF2hMv1zdpHSVjhU2.AoI-] disk not present in database.
[AccurateRip ID: 0002e749-000bf24c-1e045e04] found.
Track   [ CRC    ] Status
01     [76d91483] (0/2) No match
02     [dc6a953e] (1/1) Accurately ripped
03     [172d3cec] (1/1) Accurately ripped
04     [596ac875] (1/1) Accurately ripped
Offsetted by -2031:
01     [492fd62c] (2/2) Accurately ripped
02     [35a43578] (0/1) No match
03     [f7aef392] (0/1) No match
04     [89de802f] (0/1) No match

Track Peak [ CRC32  ] [W/O NULL]
--   95,4 [490CDC9E] [E90C5853]          
01   75,7 [CB9EA3B1] [650B95EC]          
02   95,4 [3F5C2ADD] [0FF12F32]          
03   73,4 [36161983] [F4EC209D]          
04   75,8 [C53DE965] [6832AA53]


Shouldn't those be just not accurate? (Well not yet, even if a match is a match) cauz if the database behavior is the normal one, then the problem is with the batchlog which report those as "rip not accurate (1/1)", there is a consistency problem somewhere. Either it's AR(1) or it's not AR(1), it cannot be both at same time (even at two different place within CT).

By the way, if there is not a quick fix soon for the HDCD non-detection bug, personnaly I think I will go back to V2.0.9. I think the new database is nice but not polished & in the same time the HDCD non-detection annoys me. Actually I still prefer copy/pasting the batchlog & do manual sorting (using a TXT search engine) as AR(1) report is partially erroneous & the database miss "not present in database" results anyway. So V2.1.1 brings me no-gain for a loss.

Gregory S. Chudov:
QUOTE
Waiting with anticipation for your complaints wink.gif

I hope I complained enough for your taste wink.gif I am done for V2.1.1 !

This post has been edited by sauvage78: Mar 17 2011, 10:14


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
greynol
post Mar 17 2011, 18:36
Post #1291





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



QUOTE (sauvage78 @ Mar 17 2011, 01:16) *
Either it's AR(1) or it's not AR(1), it cannot be both at same time (even at two different place within CT).

None of the logs you posted show both at the same time.


--------------------
Breath is found in plots and DR figures.
Go to the top of the page
+Quote Post
sauvage78
post Mar 17 2011, 23:13
Post #1292





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



Sorry if it wasn't clear, the problem is not within the logs, it's the database vs. the batchlog, the database sort those results within the "accuraterip confidence 1" folder while the batchlog report those as "not accurate". So for the database it's AR(1) & for the batchlog it's AR(0) [if you consider that an overall AR(1) result where all AR(1) results are spreaded among several offsets/pressings is in fact not accurate, no matter if a match is a match which was the default behavior so far]

This post has been edited by sauvage78: Mar 17 2011, 23:13


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





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



I just noticed that the "problem" seems generalized as it also affects rips with a higher accuraccy than just AR(1):

The two following logs are sorted in accurate folders (with mid/high level) in the database while reported as not accurate in the batchlog.

Note: Those two rips are really strange anyway as the pressings only differs by offset+1 & at the same time the accuracy level is nearly the same among the two "different" pressings. So it looks as if it was the same pressing splitted by a +1 offset. Any idea why this happens ?

CODE
[CUETools log; Date: 17/03/2011 13:54:05; Version: 2.1.1]
[AccurateRip ID: 000c10fa-00564dc5-59075109] found.
Track   [ CRC    ] Status
01     [27f8cb35] (00/15) No match
02     [33349032] (00/15) No match
03     [db805bf9] (00/15) No match
04     [b564b571] (00/15) No match
05     [54494d7c] (00/15) No match
06     [7bc575f5] (00/15) No match
07     [a030f16b] (00/15) No match
08     [0b7d1c2b] (00/15) No match
09     [15324d80] (00/15) No match
Offsetted by 1360:
01     [77b82b05] (00/15) No match
02     [991c04b2] (00/15) No match
03     [55238589] (00/15) No match
04     [c3298571] (15/15) Accurately ripped
05     [ff0e9f5c] (15/15) Accurately ripped
06     [2de9acd5] (15/15) Accurately ripped
07     [474ccacb] (15/15) Accurately ripped
08     [e8322ff7] (15/15) Accurately ripped
09     [1752a2b1] (15/15) Accurately ripped
Offsetted by 1361:
01     [cbeb520e] (15/15) Accurately ripped
02     [bcc2c6da] (15/15) Accurately ripped
03     [3cf222be] (15/15) Accurately ripped
04     [c4ad9e71] (00/15) No match
05     [60b04602] (00/15) No match
06     [a16e988b] (00/15) No match
07     [27fcd009] (00/15) No match
08     [98b50f8a] (00/15) No match
09     [0f7d89db] (00/15) No match

Track Peak [ CRC32  ] [W/O NULL]
--   99,9 [3E2034F7] [454DA1E4]          
01   74,5 [CC146E29] [C3A675C9]          
02   73,9 [C0263C1A] [FD4311C2]          
03   82,7 [FD7A83F8] [84020FA1]          
04   81,1 [2F855D52] [33DDBA90]          
05   87,5 [B1ECE243] [CAE1DCB2]          
06   89,3 [39B10FE7] [6FE6A47E]          
07   99,9 [3800A228] [475E2E8F]          
08   99,8 [E5FCC4DB] [474DA738]          
09   95,9 [B5AD0324] [16862305]



CODE
[CUETools log; Date: 17/03/2011 13:50:08; Version: 2.1.1]
[AccurateRip ID: 0017b795-00cc6faa-850d110b] found.
Track   [ CRC    ] Status
01     [fdb6fd32] (00/72) No match
02     [ef20570e] (00/73) No match
03     [6adb4a5e] (00/72) No match
04     [64fb2a8c] (00/71) No match
05     [3c3f5b2f] (00/70) No match
06     [c5cfb392] (00/71) No match
07     [57bec47a] (00/71) No match
08     [e11727d9] (00/71) No match
09     [cf4c17dc] (00/72) No match
10     [e23a5f7e] (00/71) No match
11     [6a143907] (00/66) No match
Offsetted by 5:
01     [4509d1f6] (00/72) No match
02     [c02e4492] (13/73) Accurately ripped
03     [924f2fa3] (00/72) No match
04     [46b863b0] (00/71) No match
05     [00221419] (00/70) No match
06     [fda88900] (00/71) No match
07     [648501ab] (00/71) No match
08     [601f5741] (00/71) No match
09     [c4776133] (00/72) No match
10     [d491ef21] (00/71) No match
11     [4527317d] (00/66) No match
Offsetted by 6:
01     [201a62ea] (13/72) Accurately ripped
02     [b6caa746] (00/73) No match
03     [44783bde] (13/72) Accurately ripped
04     [40ab08b6] (13/71) Accurately ripped
05     [5a829f7b] (13/70) Accurately ripped
06     [3c071a16] (12/71) Accurately ripped
07     [67130de8] (12/71) Accurately ripped
08     [46542d89] (12/71) Accurately ripped
09     [5be66fde] (12/72) Accurately ripped
10     [0509d8a8] (12/71) Accurately ripped
11     [a9c82d5a] (11/66) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--   99,9 [527629B7] [E560279D]          
01   87,0 [426441B0] [C18F2AC9]          
02   86,8 [0ADC0ABA] [A7A7A3FE]          
03   99,9 [9BAF25F8] [16C545C9]          
04   86,8 [B6F1956D] [7027D37B]          
05   99,9 [0178F0E4] [78B8C4D2]          
06   99,9 [34C23BFC] [6FD77973]          
07   99,9 [EFC4282B] [976B1599]          
08   86,6 [9833FDBC] [42AF91F7]          
09   87,2 [314FA6FC] [5801148C]          
10   87,7 [C06D17DF] [4B9E5298]          
11   86,5 [826C7ACB] [8B089D49]


This post has been edited by sauvage78: Mar 18 2011, 00:05


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
liquefied
post Mar 18 2011, 00:32
Post #1294





Group: Members
Posts: 9
Joined: 17-March 11
Member No.: 89083



I love this program but found some sticky things.

Look at the logs below (I've edited to only the problem area). 2.1.1 log shows no match yet in the bottom right corner while processing it, it clearly said "AccurateRip: found" (2). So does that mean that 2.0.9 was correct, but if so, why does it say no match too, but 2/2? Or is 2.1.1 correct in this case?

CODE
[CUETools log; Date: 3/17/2011 6:46:05 PM; Version: 2.1.1]
Offsetted by -646:
01     [cc71dedb] (0/2) No match but offset
02     [25fdfe05] (0/2) No match but offset
03     [81a2ed11] (0/2) No match but offset
04     [cd0713ed] (0/2) No match but offset
05     [a010b224] (0/2) No match but offset
06     [f0393be7] (0/2) No match but offset
07     [d1401d51] (0/2) No match but offset
08     [89d05b18] (0/2) No match but offset
09     [2fc9c665] (0/2) No match but offset
10     [ce850037] (0/2) No match but offset
11     [5063e83e] (0/2) No match but offset


CODE
[CUETools log; Date: 3/17/2011 6:49:01 PM; Version: 2.0.9]
Offsetted by -646:
01     [cc71dedb] (2/2) No match but offset
02     [25fdfe05] (2/2) No match but offset
03     [81a2ed11] (2/2) No match but offset
04     [cd0713ed] (2/2) No match but offset
05     [a010b224] (2/2) No match but offset
06     [f0393be7] (2/2) No match but offset
07     [d1401d51] (2/2) No match but offset
08     [89d05b18] (2/2) No match but offset
09     [2fc9c665] (2/2) No match but offset
10     [ce850037] (2/2) No match but offset
11     [5063e83e] (2/2) No match but offset


Also "Write AccurateRip log" > "In source folder" does not work at all. I have tried it many times. It only writes into the the target output folder. So maybe that should be have a tooltip over it that it really doesn't work currently.

Suggestion for the website: it still shows screenshots of version 2.0.3 and I see artifacts on them too too. So replace them with PNG screenshots of 2.1.1?

Is there an official help file for CueTools? I would love to write one, but I probably wouldn't be really useful for that. It might be useful though. That way you know what the custom scripts under the main "Action" box do (Encode/Verify/etc). I love how Sonar X1's has a help button on each page of options and when you click it, it's about the page you were on. Useful!

The template box is totally frozen and greyed out if you switch to Verify under actions when using the Default profile. However if you go to Encode first, change it there, then go back, that new template will be used, but its' greyed out again under verify. But if you choose the verify PROFILE then you can change it while under Verify. Another minor bug.
Go to the top of the page
+Quote Post
sauvage78
post Mar 18 2011, 00:58
Post #1295





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



liquefied:
In your case there is a result in the database with a confidence 2, but you just don't match maybe because you have another pressing. Providing you corrected offset while ripping, you shoudn't correct offset when you don't match (I see it's Offsetted by -646), because then you obviously try to match a pressing that is not yours. Just wait for your pressing to appear. As for (0/2) vs. (2/2), I think (0/2) is a better way of displaying as it doesn't match, but what matters anyway is the "No match but offset" line.

QUOTE
Also "Write AccurateRip log" > "In source folder" does not work at all.

It works for me, maybe this is related to the way you outputs results (I dunno)
I use [%directoryname%\]%filename%-new[%unique%].cue & with the right ticked options, it does create an CDImage-new.accurip in each folder.

Be sure "Write AccurateRip log" is ticked for both "verify" & "encode & verify", not just "verify" if you encode.

This post has been edited by sauvage78: Mar 18 2011, 01:03


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





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



Suggestion:
Could the "drag & drop mode" be always be visible on the left & on top of the "local database". (unless you "hide browser" indeed)

The "drag & drop mode" only take 1 line so it is boring to always have to switch between "drag & drop mode" & "local database" when both could be displayed at the same time.

IMHO, there should only be 4 inputs display:
-Folder browser
-Multiselect browser
-Drag & drop+Local database
-Hide browser

This post has been edited by sauvage78: Mar 18 2011, 09:27


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
Alex B
post Mar 18 2011, 12:44
Post #1297





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



QUOTE (liquefied @ Mar 18 2011, 01:32) *
... Also "Write AccurateRip log" > "In source folder" does not work at all. I have tried it many times. It only writes into the the target output folder. So maybe that should be have a tooltip over it that it really doesn't work currently. ...

It works for me too.

It is an option only for verifying. When it is not enabled the destination folder will be created according to the templete.

If you also convert the log will always be saved in the output folder. ("Encode and verify > Write Accurate Rip log" does not have this option.)


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
420 MuNkEy
post Mar 18 2011, 12:58
Post #1298





Group: Members
Posts: 2
Joined: 16-November 08
Member No.: 62546



FLACCL is unable to write mono files.

stereo test:
CODE
CUETools_2.1.1>CUETools.FLACCL.cmd.exe -8 -o test-stereo.flac test-stereo.wav
FLACCL#0.4, Copyright (C) 2010 Gregory S. Chudov.
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename  : test-stereo.wav
File Info : 44100kHz; 2 channel; 16 bit; 00:03:58.0270000
Results   : 192.11x; 30975986 bytes in 00:00:01.2390000 seconds;


mono test:
CODE
CUETools_2.1.1>CUETools.FLACCL.cmd.exe -8 -o test-mono.flac test-mono.wav
FLACCL#0.4, Copyright (C) 2010 Gregory S. Chudov.
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename  : test-mono.wav
File Info : 44100kHz; 1 channel; 16 bit; 00:03:58.0270000
Error     : EnqueueWriteBuffer failed with error code INVALID_VALUE

I tried with other mono wavs with the same results.
I know mono is kind of rare on CDs, but I'd really love to see support added if it's not much trouble
Go to the top of the page
+Quote Post
Chinch
post Mar 19 2011, 18:35
Post #1299





Group: Members
Posts: 98
Joined: 22-July 09
Member No.: 71664



QUOTE (sauvage78 @ Mar 18 2011, 03:21) *
Suggestion:
Could the "drag & drop mode" be always be visible on the left & on top of the "local database". (unless you "hide browser" indeed)

The "drag & drop mode" only take 1 line so it is boring to always have to switch between "drag & drop mode" & "local database" when both could be displayed at the same time.

IMHO, there should only be 4 inputs display:
-Folder browser
-Multiselect browser
-Drag & drop+Local database
-Hide browser


I think this is an excellent idea. It is a bit of extra clicking that gets tiresome after a bit... clicking to change over to see the local database view. While I haven't had a chance to read the documentation to see exactly how the local database works (other than obviously a database/logging of what you've scanned and the results)... I don't know if it's used as a cache or anything, but regardless... I think it's a smart idea, since I like to take a look at the local DB often... and i agree with sauvage, in drag and drop mode, could we show the local database in a side pane (or have the option too) in drag and drop mode have your left pane, and have a horizontal splitter, top (or bottom) would show the local database, while the other portion would act as a "drop pad" for the files to be dropped on, as he does have a good point in that the drop area doesn't have to be that big. So i just wanted to +1 to his suggestion.



While we're at it, I have one very small suggestion -- can the queue log/output window do a simple word wrap? I don't know what it's written in, but in most of the Visual languages it's a simple property you set for that text box, for word wrap (like I'm telling you something new, haha). that would allow one to see the entire output of the process without having to have the unsightly horizontal scrollbar or having the window wide as the whole screen. it'd be a great space saver for those wanting to resize the window smaller. or, as said, if not the default, at least could it be an option? maybe double click the text area to toggle it on or off or a little icon next to the progress bar/status icons? Right now, I'm using a 1080p monitor, so with 1920 horizontal pixels, for me to get the horizontal scrollbar to disappear and for me to see the full output line at once, i have to resize the window to approximately 60% of my screen's width. It's not a huge deal, but it does make it more cumbersome when I have an explorer window up for my files, and then maybe another accurip log up for comparison, etc.... I have to constantly keep minimizing CueTools out of the way to see everything. [EDIT: I just realized that this only is a problem in non-verbose mode, where the single output line is very long, the problem is solved it seems to me, by cutting on verbose logging, which gives it the look that is seen in my beautiful design artwork. "Paint" doesn't intimidate this guy....]

I don't want to leave with a bad impression, so I want to say that I am very pleased to see a new version after all this time, from what I really began to think was an abandoned project and I felt that CueTools was dead in the water. I hope to see more versions and further ideas and progress in the future! You're doing a great job! Hopefully we can see more frequent updates, even if they only introduce a few small features or fixes at a time... you had me worried! wink.gif

Imagine... you have the "hide browser" option on... the side is hidden. Now your window is quite small, though with a lot of scrolling to do for the output. If we had it wrap, we could see
the whole output, without scrolling sideways, even in this collapsed view. Now, looking at this view on my computer, we have two perfectly good, but unused spaces. the area directly below the "Action" area and to the left of the "Extra" area. Perfect drop pad for drag and drop mode! The other is directly below the three checkbox options for CTDB, LDB, and skip recent. That's another pefectly good size of a blank area to drop files into. Possibly just put a little icon indicator there, or text to show "hey this is your drop area for files" -- I think that's an amazing idea, if I even say so, myself, haha...

In Windows 7, they could use this view and use the whatever it is... Snap feature or whatever, so it docks to 25% of the screen or whatever it is... and how I can see a long vertical listing, if i'm doing recursive or a lot of queued work.

If it lets me attach my image correctly (maybe you have to open the attached jpg), reference that for a visual mock-up. Note that I made things as small as I could, but the two windows are both docked to the side of the screen, and this display that you see only takes up 50% of my screen's width. I could have up to 4 windows tiled vertically and talk about doing some multitasking.... The dealbreaking problem of this was that I had to undock the window, and hit "Drag and drop mode", which popped out an entire, unnecessary left column... then I dragged my file onto it, then hid it again, and redocked. What a pain. That could be eliminated by using the design I show here:

Attached Image



If anyone agrees or disagrees with this suggestion, please post about it, so we can see if other people would be interested in the same idea. So maybe have 5 options... the 4 sauvage offered, and a fifth -- collapsed view or minimal DND view.

Thanks for considering/reading my ideas... and if you're impressed by my art -- I'm available for hire. Just let me know... wink.gif

This post has been edited by Chinch: Mar 19 2011, 18:40
Go to the top of the page
+Quote Post
Eli
post Mar 19 2011, 19:38
Post #1300





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



Still hoping cuetools will be able to read TOC from vorbis/flac tags.

http://forum.dbpoweramp.com/showthread.php?t=16705

I have thousands of albums I would like to scan and update the CTDB with and they all have the TOC in the meta-data as above and many are not added because cuetools cannot currently read these tags.


--------------------
http://forum.dbpoweramp.com/showthread.php?t=21072
Go to the top of the page
+Quote Post

105 Pages V  « < 50 51 52 53 54 > » 
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: 29th December 2014 - 07:58