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 1907342 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #975
Hi, Gregory.
This time it's not really questions but some suggestions for the log formatting.

Would it be possible to change the wording for "disk not present in database." to "disk not present in the AR database." & "disk not present in the CTDB database.", the reason why I am asking for this is because I do text based search within my .accurip log & then I sort my collection according to AR results in order to know what I neeed to re-check later.
With the new CTDB database results, now I got "false positive" mixing AR & CTDB results when I search for "disk not present in database." only.

Another possibility that would work for me too would be to add the possibilty to create two logs for the two database in order to not mix apples with oranges, one would be the old .accurip & the other a new .ctdb. It would be usefull to update logs against only 1 database if for exemple you know the other has not been updated. (How often is the CTDB updated ? Would be nice to have a page where you indicate when the database is updated.)

I think that I would also prefer to have the CTDB information displayed separatly at the end of the log instead of mixed within the AR information. I think it would be easier to read as the CTDBID is a useless information if the rip is not found which actually happen very often. Displaying first an information that is 99% of time useless is not really interesting IMHO, even if I understand that you want to promote your work.

Something like this: (with the ability to split the second part in a .ctdb, with the first line (date) duplicated in front of the .ctdb)
Code: [Select]
[Verification date: 30/04/2010 21:16:06]
[AccurateRip ID: 001e9b90-012dadbd-c80e170d] found.
Track [ CRC ] Status
 01 [e3912c21] (00/35) No match
 02 [f95bc3ed] (00/35) No match
 03 [273d76b9] (00/36) No match
 04 [51f86c5b] (00/36) No match
 05 [8731ef1d] (00/34) No match
 06 [c549489b] (00/34) No match
 07 [fe71fe3d] (00/35) No match
 08 [f02797bf] (00/34) No match
 09 [9a3de21a] (00/34) No match
 10 [49c5b587] (00/35) No match
 11 [b5d6e85b] (00/36) No match
 12 [6c615e51] (00/36) No match
 13 [5a17d925] (00/35) No match
Offsetted by -550:
 01 [f211be23] (04/35) Accurately ripped
 02 [0c8d5573] (04/35) Accurately ripped
 03 [cfe92cf7] (04/36) Accurately ripped
 04 [9d5d242f] (04/36) Accurately ripped
 05 [c62ad5cf] (04/34) Accurately ripped
 06 [623cc3c1] (04/34) Accurately ripped
 07 [b8ede7eb] (04/35) Accurately ripped
 08 [f68b20fd] (04/34) Accurately ripped
 09 [a6fa775e] (04/34) Accurately ripped
 10 [cd84208b] (04/35) Accurately ripped
 11 [e2d32ebd] (04/36) Accurately ripped
 12 [583c6daf] (04/36) Accurately ripped
 13 [ea63f575] (04/35) Accurately ripped
Offsetted by 126:
 01 [cda066d7] (31/35) Accurately ripped
 02 [d54f7a8f] (31/35) Accurately ripped
 03 [86a66ac3] (32/36) Accurately ripped
 04 [2e148cb7] (32/36) Accurately ripped
 05 [3b542463] (30/34) Accurately ripped
 06 [d92f4b1d] (30/34) Accurately ripped
 07 [1c559b17] (31/35) Accurately ripped
 08 [3b068cc9] (30/34) Accurately ripped
 09 [8ef21946] (30/34) Accurately ripped
 10 [f95267f3] (31/35) Accurately ripped
 11 [9ac70131] (32/36) Accurately ripped
 12 [102e40bb] (32/36) Accurately ripped
 13 [8be30995] (31/35) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  98,3 [FB108FEE] [75CAFA3E]  
 01  98,3 [D75029BF] [66D74C6D]  
 02  98,0 [37ECA16C] [9269CE21]  
 03  92,5 [8A74C440] [9E42D327]  
 04  87,3 [0565D5DC] [36D6C0F5]  
 05  97,9 [A9FFE428] [E036EDD0]  
 06  97,9 [EDAEBB82] [F2AFD165]  
 07  93,7 [5711A02B] [136BFDDC]  
 08  87,3 [68B120D4] [CCE2F437]  
 09  88,2 [852FCA85] [6CD535D9]  
 10  98,0 [187CF52E] [385EAD54]  
 11  77,8 [0EB10F46] [699F23CA]  
 12  82,7 [3CB01ED5] [EB0A236E]  
 13  98,0 [5BD83527] [3DA8DD04]  

[CTDB TOCID: 0b_NoO0nHCBx3gDaIRQrUv.T_.U-] found.
[ CTDBID ] Status
[5323d943] (32/32) Accurately ripped

An exemple of .ctdb log:
Code: [Select]
[Verification date: 30/04/2010 21:16:06]
[CTDB TOCID: 0b_NoO0nHCBx3gDaIRQrUv.T_.U-] found.
[ CTDBID ] Status
[5323d943] (32/32) Accurately ripped

Also I think it's a bug when you repair a damaged rip, the created log reports how many error was fixed but then doesn't display the CTDBID anymore.
Code: [Select]
CUETools DB: corrected 1 errors.
<== no ID
should be
Code: [Select]
[CTDB TOCID: 0b_NoO0nHCBx3gDaIRQrUv.T_.U-] found. CUETools DB: corrected 1 errors.
        [ CTDBID ] Status
        [5323d943] (32/32) Accurately ripped

I corrected 12 rips so far it worked perfectly  Thanks!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #976
Maybe a bit late, but I just found the pregap 32, 33, 37 script: Thank you very much!!! 
I was curious about this and I have just tried on some files for which I had no CUE. It worked perfectly but I do not understand the result  . Since tracks 05 and 07 are accurately ripped with different offsets does this mean that the disk is accurately ripped ? Cheers.

Code: [Select]
[Verification date: 30.04.2010 21:12:31]
[AccurateRip ID: 00076572-002d3751-3c07a607] found.
Pregap length 00:00:33.
[CTDB TOCID: oe4Ur4VJ7xasTehb4QAJ5UzqGt0-] disk not present in database.
Track [ CRC ] Status
 01 [a96c48e0] (00/07) No match
 02 [028aebd8] (00/07) No match
 03 [85333568] (00/07) No match
 04 [599878db] (00/07) No match
 05 [56871c1a] (00/05) No match
 06 [77e9e338] (00/07) No match
 07 [049368f6] (00/07) No match
Offsetted by 6:
 01 [ec537bdf] (02/07) Accurately ripped
 02 [2e619264] (02/07) Accurately ripped
 03 [002691f3] (02/07) Accurately ripped
 04 [0c658b53] (02/07) Accurately ripped
 05 [f0629f1b] (00/05) No match
 06 [6ec5afe6] (02/07) Accurately ripped
 07 [36021af9] (02/07) Accurately ripped
Offsetted by 241:
 01 [b2d1c890] (05/07) Accurately ripped
 02 [10042ad8] (05/07) Accurately ripped
 03 [7a3724c0] (05/07) Accurately ripped
 04 [87c7fc7e] (05/07) Accurately ripped
 05 [f1647f91] (05/05) Accurately ripped
 06 [aef1fb70] (05/07) Accurately ripped
 07 [e2aa1c12] (05/07) No match but offset

Track Peak [ CRC32  ] [W/O NULL]
 --  59.1 [8CC66DE2] [12FF055A]  
 01  42.2 [6696F548] [F82756C3]  
 02  54.4 [C7A02353] [12AB9CD4]  
 03  32.7 [20A03151] [C4936B48]  
 04  57.3 [72ADE489] [EFA85717]  
 05  57.1 [F0526CF6] [1F2EB36F]  
 06  37.0 [8A7CF8A2] [377CA91C]  
 07  59.1 [47895623] [F0BD1265]

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #977
prefab:
As far as I understand, as a whole your rip cannot actually be said as Accurate as there is no pressing in the database that matches yours, but it is likely that you have a 3 third pressing & it is likely to be accurate when it will be included in the database. Your rip is not accurate yet but is unlikely to be scratched.


See the two logs below: same rip with 5 months interval, it was the same case as yours (not AR) but is now perfectly AR.
Code: [Select]
[Verification date: 16/11/2009 02:21:59]
[Disc ID: 00210f7e-02fdcc77-9b0c8720]
Track [ CRC ] Status
 01 [a7fb1eab] (02/04) Accurately ripped
 02 [b3a7c02a] (02/04) Accurately ripped
 03 [5043d64c] (02/04) Accurately ripped
 04 [d49735a4] (03/05) Accurately ripped
 05 [d86d3c18] (02/04) Accurately ripped
 06 [830e3ecc] (02/04) Accurately ripped
 07 [3da68be2] (02/04) Accurately ripped
 08 [80f91339] (02/04) Accurately ripped
 09 [ce487b6b] (02/04) Accurately ripped
 10 [4fdec324] (02/04) Accurately ripped
 11 [09cb09e7] (03/05) Accurately ripped
 12 [353ad669] (02/04) Accurately ripped
 13 [0aa9af4a] (02/04) Accurately ripped
 14 [452a355d] (02/04) Accurately ripped
 15 [dbb8b038] (02/04) Accurately ripped
 16 [bf92d5d2] (02/04) Accurately ripped
 17 [ddcb7c85] (02/04) Accurately ripped
 18 [6498ac4f] (02/04) Accurately ripped
 19 [3c898673] (02/02) Accurately ripped
 20 [6219ee4d] (02/04) Accurately ripped
 21 [3afc3bf3] (02/04) Accurately ripped
 22 [035f9674] (03/05) Accurately ripped
 23 [7dd15b3c] (02/04) Accurately ripped
 24 [0ad44af9] (02/04) Accurately ripped
 25 [592216bd] (02/04) Accurately ripped
 26 [64f127a6] (03/05) Accurately ripped
 27 [7b21c891] (02/04) Accurately ripped
 28 [baac2520] (02/04) Accurately ripped
 29 [6a1d067b] (02/04) Accurately ripped
 30 [4e4a4b29] (02/04) Accurately ripped
 31 [ed07232f] (02/04) Accurately ripped
 32 [57c3acfe] (02/02) Partial match
Offsetted by 1337:
 01 [b07c04c3] (02/04) Accurately ripped
 02 [15670431] (02/04) Accurately ripped
 03 [eee23ab4] (02/04) Accurately ripped
 04 [9bce3150] (02/05) Accurately ripped
 05 [9e59570f] (02/04) Accurately ripped
 06 [bf225a54] (02/04) Accurately ripped
 07 [d02321ee] (02/04) Accurately ripped
 08 [b33b4da5] (02/04) Accurately ripped
 09 [316f8a8c] (02/04) Accurately ripped
 10 [b5cd62db] (02/04) Accurately ripped
 11 [502bf103] (02/05) Accurately ripped
 12 [9e99f224] (02/04) Accurately ripped
 13 [afb5b33c] (02/04) Accurately ripped
 14 [5e3566e3] (02/04) Accurately ripped
 15 [87ec3019] (02/04) Accurately ripped
 16 [0fa2f5fa] (02/04) Accurately ripped
 17 [edbfd7a8] (02/04) Accurately ripped
 18 [7273eb07] (02/04) Accurately ripped
 19 [924474f7] (02/02) Partial match
 20 [e199cb23] (02/04) Accurately ripped
 21 [46f555fa] (02/04) Accurately ripped
 22 [3917dd66] (02/05) Accurately ripped
 23 [4527442a] (02/04) Accurately ripped
 24 [0064ab68] (02/04) Accurately ripped
 25 [de698c32] (02/04) Accurately ripped
 26 [55177f15] (02/05) Accurately ripped
 27 [6c1af3ec] (02/04) Accurately ripped
 28 [7c14ab5c] (02/04) Accurately ripped
 29 [a747ed0b] (02/04) Accurately ripped
 30 [99c1fab6] (02/04) Accurately ripped
 31 [507e5332] (02/04) Accurately ripped
 32 [a98ed15c] (02/02) Accurately ripped

Track [ CRC32  ] [W/O NULL]
 -- [E9A1C36C] [8F80EB50]
 01 [0E63E3DF] [64292950]
 02 [3EF5E1E6] [06454285]
 03 [0AAFDC73] [452969AF]
 04 [AB3F266A] [43CAE9E5]
 05 [2E2F2E1F] [72C36F69]
 06 [FD6C316D] [374C2E26]
 07 [B959EF2A] [79413473]
 08 [E5A1F0AF] [DD67566F]
 09 [D3133F07] [17BC30F1]
 10 [72781844] [2D8D81A3]
 11 [EAB20437] [467D885D]
 12 [44582A2C] [1CABC0DB]
 13 [FD482702] [37FF1385]
 14 [43100C34] [F7E821E3]
 15 [228190DD] [B5482DE4]
 16 [0320E350] [C31BBB93]
 17 [F732E6B1] [E1D4176A]
 18 [D32877A5] [7BD25F05]
 19 [6C475E87] [EB2BDA3D]
 20 [FA744D71] [A75EEE42]
 21 [76FAC36C] [AFB60702]
 22 [BAA7D354] [D5315C52]
 23 [E56DBB4F] [2B80D237]
 24 [3B7A20FD] [6A1A4FC0]
 25 [E331A23C] [71F0DC49]
 26 [A9DBB386] [FF2C0DAF]
 27 [C9C9B4B5] [75CA6331]
 28 [C51F24D4] [13BEE4A3]
 29 [DDC96944] [BB7144E4]
 30 [8FC5FBB9] [480B07AE]
 31 [02E5D1CA] [C49E0F21]
 32 [BF54BE9D] [6C242209]

[Verification date: 28/04/2010 14:51:28]
[AccurateRip ID: 00210f7e-02fdcc77-9b0c8720] found.
[CTDB TOCID: EkbCkFeMtEGBT3wexy0BJdDsZMo-] disk not present in database.
Track [ CRC ] Status
 01 [a7fb1eab] (02/05) Accurately ripped
 02 [b3a7c02a] (02/05) Accurately ripped
 03 [5043d64c] (02/05) Accurately ripped
 04 [d49735a4] (03/06) Accurately ripped
 05 [d86d3c18] (02/05) Accurately ripped
 06 [830e3ecc] (02/05) Accurately ripped
 07 [3da68be2] (02/05) Accurately ripped
 08 [80f91339] (02/05) Accurately ripped
 09 [ce487b6b] (02/05) Accurately ripped
 10 [4fdec324] (02/05) Accurately ripped
 11 [09cb09e7] (03/06) Accurately ripped
 12 [353ad669] (02/05) Accurately ripped
 13 [0aa9af4a] (02/05) Accurately ripped
 14 [452a355d] (02/05) Accurately ripped
 15 [dbb8b038] (02/05) Accurately ripped
 16 [bf92d5d2] (02/05) Accurately ripped
 17 [ddcb7c85] (02/05) Accurately ripped
 18 [6498ac4f] (02/05) Accurately ripped
 19 [3c898673] (02/04) Accurately ripped
 20 [6219ee4d] (02/05) Accurately ripped
 21 [3afc3bf3] (02/05) Accurately ripped
 22 [035f9674] (03/06) Accurately ripped
 23 [7dd15b3c] (02/05) Accurately ripped
 24 [0ad44af9] (02/05) Accurately ripped
 25 [592216bd] (02/05) Accurately ripped
 26 [64f127a6] (03/06) Accurately ripped
 27 [7b21c891] (02/05) Accurately ripped
 28 [baac2520] (02/05) Accurately ripped
 29 [6a1d067b] (02/05) Accurately ripped
 30 [4e4a4b29] (02/05) Accurately ripped
 31 [ed07232f] (02/05) Accurately ripped
 32 [57c3acfe] (00/02) No match
Offsetted by 1337:
 01 [b07c04c3] (03/05) Accurately ripped
 02 [15670431] (03/05) Accurately ripped
 03 [eee23ab4] (03/05) Accurately ripped
 04 [9bce3150] (03/06) Accurately ripped
 05 [9e59570f] (03/05) Accurately ripped
 06 [bf225a54] (03/05) Accurately ripped
 07 [d02321ee] (03/05) Accurately ripped
 08 [b33b4da5] (03/05) Accurately ripped
 09 [316f8a8c] (03/05) Accurately ripped
 10 [b5cd62db] (03/05) Accurately ripped
 11 [502bf103] (03/06) Accurately ripped
 12 [9e99f224] (03/05) Accurately ripped
 13 [afb5b33c] (03/05) Accurately ripped
 14 [5e3566e3] (03/05) Accurately ripped
 15 [87ec3019] (03/05) Accurately ripped
 16 [0fa2f5fa] (03/05) Accurately ripped
 17 [edbfd7a8] (03/05) Accurately ripped
 18 [7273eb07] (03/05) Accurately ripped
 19 [924474f7] (02/04) Accurately ripped
 20 [e199cb23] (03/05) Accurately ripped
 21 [46f555fa] (03/05) Accurately ripped
 22 [3917dd66] (03/06) Accurately ripped
 23 [4527442a] (03/05) Accurately ripped
 24 [0064ab68] (03/05) Accurately ripped
 25 [de698c32] (03/05) Accurately ripped
 26 [55177f15] (03/06) Accurately ripped
 27 [6c1af3ec] (03/05) Accurately ripped
 28 [7c14ab5c] (03/05) Accurately ripped
 29 [a747ed0b] (03/05) Accurately ripped
 30 [99c1fab6] (03/05) Accurately ripped
 31 [507e5332] (03/05) Accurately ripped
 32 [a98ed15c] (02/02) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  98,9 [E9A1C36C] [8F80EB50]  
 01  97,9 [0E63E3DF] [64292950]  
 02  97,9 [3EF5E1E6] [06454285]  
 03  97,9 [0AAFDC73] [452969AF]  
 04  97,9 [AB3F266A] [43CAE9E5]  
 05  97,9 [2E2F2E1F] [72C36F69]  
 06  97,9 [FD6C316D] [374C2E26]  
 07  97,9 [B959EF2A] [79413473]  
 08  97,9 [E5A1F0AF] [DD67566F]  
 09  97,9 [D3133F07] [17BC30F1]  
 10  57,8 [72781844] [2D8D81A3]  
 11  97,9 [EAB20437] [467D885D]  
 12  97,9 [44582A2C] [1CABC0DB]  
 13  97,9 [FD482702] [37FF1385]  
 14  97,9 [43100C34] [F7E821E3]  
 15  97,9 [228190DD] [B5482DE4]  
 16  97,9 [0320E350] [C31BBB93]  
 17  97,9 [F732E6B1] [E1D4176A]  
 18  97,9 [D32877A5] [7BD25F05]  
 19  97,9 [6C475E87] [EB2BDA3D]  
 20  97,9 [FA744D71] [A75EEE42]  
 21  97,8 [76FAC36C] [AFB60702]  
 22  98,9 [BAA7D354] [D5315C52]  
 23  96,5 [E56DBB4F] [2B80D237]  
 24  98,9 [3B7A20FD] [6A1A4FC0]  
 25  98,9 [E331A23C] [71F0DC49]  
 26  98,9 [A9DBB386] [FF2C0DAF]  
 27  98,9 [C9C9B4B5] [75CA6331]  
 28  98,9 [C51F24D4] [13BEE4A3]  
 29  98,9 [DDC96944] [BB7144E4]  
 30  98,9 [8FC5FBB9] [480B07AE]  
 31  98,9 [02E5D1CA] [C49E0F21]  
 32  98,6 [BF54BE9D] [6C242209]

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #978
prefab:
As far as I understand, as a whole your rip cannot actually be said as Accurate as there is no pressing in the database that matches yours, but it is likely that you have a 3 third pressing & it is likely to be accurate when it will be included in the database. Your rip is not accurate yet but is unlikely to be scratched.
sauvage78, that was exactly what I was trying to figure out  Thanks.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #979
Hello Gregory !
For FLAC encoder appears two of FLAKE - libFlake & flake with a different compression levels. What is a difference ?
Which of them (libFLAC, libFlake, flake) to prefer ?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #980
Another option to make the log easily searchable is to do inside the log the same thing as you're aleady doing in the batch log:
Code: [Select]
AR: : disk not present in database, CTDB: disk not present in database.

The batch log already specify to which database belongs the results, applied inside the log it would give something like this:
Code: [Select]
[Verification date: 29/04/2010 18:10:16]
[AccurateRip ID: 000c38f1-005434a4-610a4608] AR: disk not present in database.
[CTDB TOCID: FEKJkkZuSGXzJ9XOczjF7rznBrg-] CTDB: disk not present in database.


Also an option to limit the date only to month/year would be nice, because displaying day/hours prevents you from searching .accurip doublon while displaying day/hour is not really usefull when the AR database is only updated monthly.
Code: [Select]
[Verification date: XX/04/2010 XX:XX:XX]
would be enougth for me
If you use CDImage+"fix offset to highest in database" searching doublons with .accurip is more efficient than with CDImage.flac as the same album encoded with the same setting with F2K & Cuetools is likely to not have the same checksum, despite being identical. Also being much smaller than a CDImage.flac, a .accurip is much faster to process.
I agree this is a very particular way of using .accurip but it would be nice to have the option.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #981
Gregory
Regarding "find pregap script"...
For the case when no enumerated pregaps yield a match against AR DB I'd like to have in the end a log with IDs for zero pregap and calculated CRCs.
I can't figure out how to do it 'cause for now the header always contains info about the last enumerated pregap, even if I set it to zero before calling processor.Go(). Maybe it is related to the fact that when I break pregaps' sort order I get "can't set negative offset" or something.
Also it would be helpful if the log could contain a list of tested pregaps.
Is it possible?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #982
Is there a way to use CUETools to update the (separate) cue sheet using info from Freedb/musicbrainz without re-encoding the audio file itself?
I also would like to be able to do this. Cheers.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #983
Is there a way to use CUETools to update the (separate) cue sheet using info from Freedb/musicbrainz without re-encoding the audio file itself?
I also would like to be able to do this. Cheers.

I think what you're after is achieved when setting "Audio Output" to "None"

-- L. Ipsum

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #984
Is there a way to use CUETools to update the (separate) cue sheet using info from Freedb/musicbrainz without re-encoding the audio file itself?
I also would like to be able to do this. Cheers.

I think what you're after is achieved when setting "Audio Output" to "None"

-- L. Ipsum


Yes, that works, sort of, as long as you leave the combo box under action to "default", use "encode" for action, "image+cue" for mode, and output to "none" as indicated above. It won't update the cue file in place, but will create a new one in the destination directory.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #985
Hello! My question is:

What files CUERipper requires to work separetly from CUETools???
🇺🇦 Glory to Ukraine!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #986
A few thoughts:

In some case "disk not present in database." is repeated twice without real use.
Worst, it is confusing as the second time is repeated in the middle of CTDB information while it is an AR information. IMHO, this is not really clear. As no CRC is displayed because the rip is not in the AR database, "disk not present in database." is still displayed next to CTDB information without pointing out that it is not belonging to the CTDB informations. At first I was confused personnaly .

Exemple:
Code: [Select]
[Verification date: 06/05/2010 04:54:04]
[AccurateRip ID: 00100325-008d29b0-a809970c] disk not present in database.
CD-Extra data track length 02:37:15 - 02:38:14.
[CTDB TOCID: iV0EDyEDBUTK5m1qP1duC.QkPfY-] found.
        [ CTDBID ] Status
        [b90da38a] (39/39) , Accurately ripped
Disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
--   97,8 [D7CE63F7] [D53620F4]          
01   84,0 [B6E48353] [51481335]          
02   90,8 [6AF45844] [79640A06]          
03   97,8 [60FC355C] [9D941685]          
04   87,6 [A97E2DBC] [B9DD6683]          
05   89,3 [E491D56E] [62468787]          
06   91,6 [B9CA1D1C] [1AA62050]          
07   89,8 [454B37CA] [EFACBDA6]          
08   95,0 [2948647D] [E0A78584]          
09   87,6 [86E97FED] [9A1E4147]          
10   88,5 [21754A50] [E2C6BFEC]          
11   89,6 [7489D97C] [C619A96D]


Even if not perfect, it would have been clearer if
"Track   [ CRC    ] Status" would have split CTDB & AR informations zone.
Example:
Code: [Select]
[Verification date: 06/05/2010 04:54:04]
[AccurateRip ID: 00100325-008d29b0-a809970c] disk not present in database.
CD-Extra data track length 02:37:15 - 02:38:14.
[CTDB TOCID: iV0EDyEDBUTK5m1qP1duC.QkPfY-] found.
        [ CTDBID ] Status
        [b90da38a] (39/39) , Accurately ripped
Track    [ CRC    ] Status
Disk not present in database.


But IMHO the best way to deal with this is to completely remove the second "Disk not present in database." which is now useless. All this is unexpected consequences of the introduction of CTDB informations in the middle of AR informations. That's why I would prefer to have it in the end with the possibility of splitting the log in two logs (.accurip .ctdb).
The only drawback of having the CTDB information at the end is that with CD with plenty of pressings it forces you to look at the bottom. If this is really an issue then display the CTDB information in absolute first place just after the first line (Date) because IMHO the actual way of splitting the AR information in two to artifially put the CTDB checksum next to the AR checksums is only making things harder to read IMHO. Specially as the CTDB database is actually very small.

Also I noticed an unoptimised behavior of Cuetools:
When you "Verify"+"only if found", cuetools doesn't display the possible data track length if one if found in the CTDB database, this is sub-obtimal because the reason why the CD is not found in the AR database might be that the data track length is missing. So in this case Cuetools doesn't display an important information for you. It's normal but it's paradoxal.

Example:
Verify+Only if found:
Code: [Select]
[Verification date: 06/05/2010 00:02:41]
[AccurateRip ID: 0016f8d6-00d48840-a50c040d] disk not present in database.
CD-Extra data track length 08:56:44 - 08:57:43.
[CTDB TOCID: jYPeHFZN6n2dunXqLH_YAlPVfIs-] found.

You wasted the exact data track length which is included in CTDB but not displayed.

Same Verify+Default:
Code: [Select]
[Verification date: 06/05/2010 04:49:01]
[AccurateRip ID: 0016f8d6-00d48840-a50c040d] disk not present in database.
CD-Extra data track length 08:56:44 - 08:57:43.
[CTDB TOCID: jYPeHFZN6n2dunXqLH_YAlPVfIs-] found.
        [ CTDBID ] Status
        [75314992] (40/78) Is an Enhanced CD, data track length 08:57:40, Accurately ripped
        [853a89a6] (38/78) Is an Enhanced CD, data track length 08:57:40, No match
Disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
--   99,4 [297DBA6E] [FB457C98]          
01   99,4 [55D2767C] [594EC380]          
02   99,4 [AE16827C] [4CECCE03]          
03   99,4 [89B41C5C] [3493DC21]          
04   99,4 [9DC6F91F] [DCE80902]          
05   99,4 [2AA3EF16] [E3749205]          
06   99,4 [124F5ADD] [2620D55A]          
07   99,4 [250BBA83] [982E88AE]          
08   99,4 [9EE7922B] [1CF6AAF0]          
09   99,4 [69DC48DF] [ACBE00DF]          
10   80,6 [E7AB247B] [57201234]          
11   99,4 [3B379612] [4EBC6F88]          
12   99,4 [5A324E99] [20437F56]


Conclusion:
In some case it might be usefull to display CTDB information even if the rip is not found in the AR database.
IMHO, it's either you always display the CTDB information by default or you introduce a new verify mode, something like "Verify+Only if found+Always display CTDB information no matter AR result".

Thx Greg.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #987
Gregory,

I just wanted to pop back in here to let you know how well CUETools worked to cure my "extra 4096 samples of silence" problem.  Everything has been modified appropriately, tagged and backed up.

Your program has really saved me lots of hours and frustration.  Thank you so much.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #988
Hi, Greg, I have a request.

Could you state a mandatory way of storing the data track lenght for people not using .log. This would be usefull in order to update the . accurip without being forced to enter manually the data track lenght.

The easiest way to achieve this without re-inventing the wheel would be to simply automatically parse any existing .accurip for the "CD-Extra data track length XX:XX:XX." string.

Personnaly, I also store this precious information separatly in a .nfo, because actually I fear that I would lost this information by misstake if I would update the . accurip without thinking that this would actually erase this information.

So I would enjoy if an external file with this data could be parsed too. I use .nfo because I rename my .accurip as . txt in order to make them searchable & .log is obviously reserved for EAC log. So no .log no .txt leaves me with .nfo. I understand that some people might reserve . nfo for another use ... so you just have to state an extension that would basically be a disguised .txt that would only be used to store the extra data track length. Think of it a little like the correction file of wavpack lossy. I dunno something like .accudata would do the trick.

exemple:
CDImage.accudata
Code: [Select]
CD-Extra data track length 21:10:30.


With such a file you can never lose the data track length, no matter what you do.

Indeed if you decide to simply parse any existing .accurip for the "CD-Extra data track length XX:XX:XX." string, storing this info in an external .nfo or .accudata becomes almost useless.

Storing the data length information in an external file is actually only a trick to avoid the bad behavior of cuetools which actually erase this information if you re-check a rip after deleting the EAC log.

Edit:
About the inconsistency of data track lenght between CTDB & the old TOC analysis, I think I have found myself the answer by testing. The old TOC based analysis is more reliable & the new CTDB suggested data length is only an additionnal hint about the possible length. So the right way of using this information is to only test the CTDB suggested length if you don't have the exact lenght given by the old TC analysis (but only a range due to the absence of log). That's the way I understand things right now. CTDB helped me found 8 data track length so far, so thks.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #989
I have a request, too. Regarding CUERipper. I think it should come with its own log layout and not emulate an EAC log. Time to emancipate!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #990
Perhaps something like this:

Code: [Select]
CUERipper v2.0.8 Copyright © 2008-10 Gregory S. Chudov
Extraction logfile from : 04/25/2010 22:38:06
Used drive              : TSSTcorp - CD/DVDW SH-W162C
Read offset correction  : 6
Read command            : BEh, 12h, BEh, 16 blocks at a time
Secure mode            : 1
Disk length            : 76:17:64
AccurateRip            : ok

TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  | 00:00:00 | 07:20:32 |        0    |    33031
        2  | 07:20:32 | 03:03:50 |    33032    |    46806
        3  | 10:24:07 | 03:55:14 |    46807    |    64445
        4  | 14:19:21 | 04:39:15 |    64446    |    85385
        5  | 18:58:36 | 05:08:50 |    85386    |  108535
        6  | 24:07:11 | 03:40:22 |    108536    |  125057
        7  | 27:47:33 | 04:52:47 |    125058    |  147004
        8  | 32:40:05 | 05:07:58 |    147005    |  170087
        9  | 37:47:63 | 04:09:64 |    170088    |  188826
      10  | 41:57:52 | 04:53:59 |    188827    |  210860
      11  | 46:51:36 | 05:23:17 |    210861    |  235102
      12  | 52:14:53 | 05:01:16 |    235103    |  257693
      13  | 57:15:69 | 06:22:02 |    257694    |  286345
      14  | 63:37:71 | 05:51:65 |    286346    |  312735
      15  | 69:29:61 | 06:48:03 |    312736    |  343338

    Track |  Pregap  | Indexes
    ---------------------------------------------------------
        1  | 00:02:00 |    1
        2  | 00:00:00 |    1
        3  | 00:00:00 |    1
        4  | 00:00:00 |    1
        5  | 00:00:00 |    1
        6  | 00:00:00 |    1
        7  | 00:00:00 |    1
        8  | 00:00:00 |    1
        9  | 00:00:00 |    1
      10  | 00:00:00 |    1
      11  | 00:00:00 |    1
      12  | 00:00:00 |    1
      13  | 00:00:00 |    1
      14  | 00:00:00 |    1
      15  | 00:00:00 |    1

Destination files
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\01. Spincycle _ Drug Games.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\02. Dj On _ Super Sexy Girl.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\03. Mazi _ Interplay.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\04. Timo Mass feat. Kelis _ Help Me (Locodice Dub).flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\05. Mickey Blue Eyes _ Keep Me Safe.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\06. Jef Dam _ Soundtrack (Apollo Kids remix).flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\07. Elijah _ Deep Soul Music.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\08. Funk Function _ Old Skool House Musik.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\09. Silver City _ 1969.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\10. O. C. B. _ Synchronicity.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\11. Briggs & Lievense _ Breakdown.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\12. Neruda _ Alliance (Club mix).flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\13. Moguai _ U Know Y (Starecase remix).flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\14. Ian Ossia & Marc Mitchell _ 4 Day Haze (We Like The Music).flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\15. Silk _ U Spin Me.flac

[CTDB TOCID: if_KJdER9AK3C8IMtLmzhYuKTro-] found.
        [ CTDBID ] Status
        [954194ef] (3/3) Accurately ripped

AccurateRip summary

Track [ CRC    ] Status
 01 [8854259e] (02/02) Accurately ripped
 02 [e2ea23a7] (02/02) Accurately ripped
 03 [965806cb] (02/02) Accurately ripped
 04 [4cb54a51] (02/02) Accurately ripped
 05 [3e294d1b] (02/02) Accurately ripped
 06 [7559a491] (02/02) Accurately ripped
 07 [d686dc8e] (02/02) Accurately ripped
 08 [3532a44c] (02/02) Accurately ripped
 09 [821b2e0f] (02/02) Accurately ripped
 10 [eb36048d] (02/02) Accurately ripped
 11 [c8fa8dc0] (02/02) Accurately ripped
 12 [fe45b79a] (02/02) Accurately ripped
 13 [5646bb50] (02/02) Accurately ripped
 14 [eea5b438] (02/02) Accurately ripped
 15 [ad5395b4] (02/02) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  98.5 [D3C8079D] [D38F0EA0]         
 01  97.0 [65287AEF] [B6C10FA7]         
 02  97.0 [CA853F6D] [88210CAA]         
 03  97.0 [DF17904F] [51641C76]         
 04  97.0 [3CC8C1E5] [94AFA0CB]         
 05  95.0 [F10E3B6C] [44DFA557]         
 06  95.0 [44BA1A2A] [B30C79D2]         
 07  97.0 [E886AE51] [DABC3CAC]         
 08  98.5 [96AF58F2] [776F7A86]         
 09  97.0 [33379FAF] [117E661D]         
 10  98.5 [8C5D0734] [71C07C76]         
 11  98.5 [577BD323] [4ED12F73]         
 12  97.0 [A7D78EB8] [436250EA]         
 13  97.9 [FE906FAF] [7B4F9BF5]         
 14  95.8 [BB82BD92] [92AF1297]         
 15  97.0 [FDCDE22A] [89F80092]         

End of status report


Hint: Untick the "EAC log" option. 

Personally I don't see a need for the EAC log option. Since CUERipper is different some of the "logged" settings are probably not even correct for CUERipper.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #991
Thank you very much for the updates Gregory!

Had an idea the other day, Do you think CueTools can be made to support generation of real EAC cuesheets from existing log files ?
(I assume it is possible if the gaps were detected & reported in the log file.)

PS: Still hoping for non system wide proxy support!

Thanks !

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #992
Hint: Untick the "EAC log" option. 

Damn! Never used CUE Ripper that much, but when I did a few days ago, I believed the "EAC log" option was the only way to get a log, any log.

Since CUERipper is different some of the "logged" settings are probably not even correct for CUERipper.

I compared the EAC log by CUERipper with one by EAC and noticed some differences. Of course, the read mode setting can be ignored, also that it fakes an outdated version of EAC. Adapter ID was different. Can be easily fixed, but why?

The most obvious and hard-to-fix difference it not having a clue about lead-in/out read capabilities... it's a dead give away that the log was faked. I think CUE Ripper tries too hard to fake an EAC log and I don't see the reason why it should in the first place, except maybe that it makes comparing a faked EAC log by CUE Ripper and an original EAC log easy in a compare tool like WinDiff or WinMerge. Could be helpful for analyzing problematic CDs... but then it would be enough to just use a CUE Ripper log header and a EAC log body, because this is the part where all the relevant data is to be found for comparing logs.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #993
Is there a way to get CueRipper to use different gap handling settings? I'd prefer to not have the HTOA file if there is a first track pre-gap. I know it can be fixed with CUETools, but it would be nice to have the option to do it the way you prefer while ripping.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #994
Would it be possible to add the actual peak value on top of the EAC-style "percentage" value? If you could include values for each channel and polarity for the peak (first sample of that value if there's more than one) that'd be even better.  It might make it clearer to people that the EAC values are just approximations...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #995
Just a suggestion:
Reporting the track length in the log would be usefull to understand why very short tracks (including non-null silent track) or non-silent special cases that are usually short (intro, interlude) often suddenly have a lower AR confidence. See this Topic. It would not make those tracks more accurate, but it would give you an hint of why the track has a lower confidence level. I guess that the peak level would do the trick to guess that with non-null silent track, but i don't think it would work well (never tried) with non silent special cases.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #997
I ripped a brand new CD, not in AR-database using CUERipper in secure (track) mode.

Why does it not appear in CTDB when I verify with CUETools?
Can't wait for a HD-AAC encoder :P

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #998
It should have, unless there were errors.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #999
It should have, unless there were errors.

Code: [Select]
Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 10. May 2010, 20:21

Unknown Artist / Unknown Title

Used drive  : HL-DT-ST DVDRAM GSA-T50L  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 667
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  3:39.16 |        0    |    16440 
        2  |  3:39.16 |  3:53.30 |    16441    |    33945 
        3  |  7:32.46 |  3:20.63 |    33946    |    49008 
        4  | 10:53.34 |  3:31.31 |    49009    |    64864 
        5  | 14:24.65 |  4:21.10 |    64865    |    84449 
        6  | 18:46.00 |  3:55.09 |    84450    |  102083 
        7  | 22:41.09 |  3:55.35 |    102084    |  119743 
        8  | 26:36.44 |  3:27.55 |    119744    |  135323 
        9  | 30:04.24 |  4:27.12 |    135324    |  155360 
      10  | 34:31.36 |  3:35.03 |    155361    |  171488 
      11  | 38:06.39 |  3:45.52 |    171489    |  188415 


Track  1

    Filename M:\Ripped\Unknown Artist - Unknown Title\01. Byens Bitreste Mand.wav

    Pre-gap length  0:00:02.00

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC D0F0AD80
    Copy CRC D0F0AD80
    Track not present in AccurateRip database
    Copy OK

Track  2

    Filename M:\Ripped\Unknown Artist - Unknown Title\02. Nitten.wav

    Peak level 100.0 %
    Track quality 100.0 %
    Test CRC C373B930
    Copy CRC C373B930
    Track not present in AccurateRip database
    Copy OK

Track  3

    Filename M:\Ripped\Unknown Artist - Unknown Title\03. Selvmord På Dansegulvet.wav

    Pre-gap length  0:00:01.36

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 2C5EF57A
    Copy CRC 2C5EF57A
    Track not present in AccurateRip database
    Copy OK

Track  4

    Filename M:\Ripped\Unknown Artist - Unknown Title\04. En Stivnet Smiler.wav

    Pre-gap length  0:00:01.40

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC D4DAAA5D
    Copy CRC D4DAAA5D
    Track not present in AccurateRip database
    Copy OK

Track  5

    Filename M:\Ripped\Unknown Artist - Unknown Title\05. Hvad Mere Vil Du Have.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 874356FF
    Copy CRC 874356FF
    Track not present in AccurateRip database
    Copy OK

Track  6

    Filename M:\Ripped\Unknown Artist - Unknown Title\06. Almindelige Mennesker.wav

    Pre-gap length  0:00:01.90

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC BF2E47D2
    Copy CRC BF2E47D2
    Track not present in AccurateRip database
    Copy OK

Track  7

    Filename M:\Ripped\Unknown Artist - Unknown Title\07. Lidt For Lidt.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 9AB4A9D2
    Copy CRC 9AB4A9D2
    Track not present in AccurateRip database
    Copy OK

Track  8

    Filename M:\Ripped\Unknown Artist - Unknown Title\08. Middelklassehelt.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 72EF1A85
    Copy CRC 72EF1A85
    Track not present in AccurateRip database
    Copy OK

Track  9

    Filename M:\Ripped\Unknown Artist - Unknown Title\09. Samtalekøkken.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 6EF0885D
    Copy CRC 6EF0885D
    Track not present in AccurateRip database
    Copy OK

Track 10

    Filename M:\Ripped\Unknown Artist - Unknown Title\10. Har Du Forstået.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 0CE2691C
    Copy CRC 0CE2691C
    Track not present in AccurateRip database
    Copy OK

Track 11

    Filename M:\Ripped\Unknown Artist - Unknown Title\11. Mere Endnu.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC A899E175
    Copy CRC A899E175
    Track not present in AccurateRip database
    Copy OK


None of the tracks are present in the AccurateRip database

No errors occurred

End of status report
Can't wait for a HD-AAC encoder :P