CUETools versions 1.9.5 through 2.1.6

Topic: CUETools versions 1.9.5 through 2.1.6 (Read 1925514 times) previous topic - next topic

0 Members and 2 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1150 – 2010-08-05 00:08:38

Quote from: greynol on 2010-08-04 17:19:12

Quote from: Akkurat on 2010-08-04 16:44:02
Quote from: fadsplat on 2010-08-04 14:29:19
The reverse situation also occurs: EAC reports "no errors", even though there are CRC mis-matches between Test and Copy on some tracks.

Mismatched CRC's are not "errors"! That only tells that the 2 subsequent reads of that track differed.

CRCs that don't match most certainly indicate that either the test pass or the copy pass was done in error at the very least.

Mismatched CRC's INDICATE something, but EAC doesn't report errors in the log when there's mismatched CRC's. Read the text which I was answering to (added that quote here).

Quote from: greynol on 2010-08-04 17:19:12

Quote from: Akkurat on 2010-08-04 16:44:02
The "Copy" part of the ripping is the only deciding factor when EAC decides whether the rip was good or not.

...and it is well documented that EAC can tell you a rip is good when it really isn't (and vice-versa, though not as well documented).

Both are correct. Was that just a complement or a try to refute what I wrote? Can't tell..

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1151 – 2010-08-05 00:46:48

I don't think that fadsplat was ever suggesting that EAC bases its error messages (or lack thereof) on whether checksums match.

Anyway, I'm just trying to tie up any loose ends so this thing can get back on topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1152 – 2010-08-05 01:12:46

My point was simply that when CRC values don't match, it at the very least raises the question as to whether or not the rip is accurate. But, since EAC reports "no errors", many people will read only that line and assume that everything is perfect.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1153 – 2010-08-05 11:09:24

Using Cuetools 2.0.9. I found a possible bug.
I have ticked "Detect HDCD encoding" which I think works (not sure yet, must find another HDCD rip)
But when I tick Decode HDCD to 20 bit and store as 16bit lossy wav or store as 24bit lossless, then normal cd's are not written anymore (it gives a message:HDCD not detected)
IMHO when I tick Decode HDCD to 20 bit then normal cd's should not be affected by this setting.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1154 – 2010-08-05 18:27:17

Quote from: Akkurat on 2010-07-18 18:23:13

For some odd reason, when starting CUETools, my firewall kicks in and says that "CUETools.exe" is trying to start "c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.exe" (Microsoft® Visual Studio® 2005 - Visual C# Command Line Compiler). It does this 8 times before CUETools window finally opens. And it happens EVERY time when starting CUETools. 2.0.4a never did this AFAIR (maybe the first time, can't remember..). I've ".NET Framework 2.0 SP2" & "Visual C++ 2008 runtime" installed. Recently I installed the ".NET Framework 4 Client Profile" from Windows updates (I've XP SP3), I wonder if that has something to do with this. Is it really required to run that csc.exe every time? CT starts very slowly.

It's the DLL files. Why was this changed so that csc.exe needs to compile (or whatever it does when it runs) the needed DLL's every time when running CUETools? Was this intended? Starting to really annoy. Especially when using the "/verify" cmdline feature. Hasn't anybody else noticed this "slowdown" starting CT?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1155 – 2010-08-06 14:01:14

Hello,

I'm new here.

I use CUERipper to encode my cds into FLAC files and I get the following error during the gap detection of Muse - Hullabaloo Soundtrack (disc 2) :

My cd have no scratch I can listen it without problem. I have ripped many cds with CUERipper and I never had this error. I also try to rip it with different cd players and have the same error.

Does my cd have a problem or it is a CUERipper bug?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1156 – 2010-08-07 15:02:39

Quote from: filou85 on 2010-08-06 14:01:14

Does my cd have a problem or it is a CUERipper bug?

The CD contains a HTOA-track (you know, a hidden track before track 1) which your CD-drive doesn't seem to be able to support. CUEtools crashes the same way on my drive, so I think it's safe to say that this is a bug. My other drive that are capable of ripping HTOA works fine.

Maybe CUEtools should be fixed to rip a CD normally without that track, but give the user a notification of the presence of HTOA.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1157 – 2010-08-07 15:06:51

Can someone explain this to me...

I ripped a scratched CD, obviously with errors. I use CUEtools to repair it using the known CTDB-entrys and receives the following output on the files. At first sight it seems like CTDB was not able to successfully repair the tracks, but apparently it was repaired to match all other offsetted releases:

Code: [Select]

[CUETools log; Date: 07-08-2010 15:56:52; Version: 2.0.9]
[CTDB TOCID: XTU4B7u6dvyQRuV9Lh992o1Udy8-] found.
		[ CTDBID ] Status
		[03e12bac] (336/336) Accurately ripped
[AccurateRip ID: 00144dd9-00d7a14c-b009520e] found.
Track   [ CRC	] Status
 01	 [be97907b] (200/634) Accurately ripped
 02	 [d18d8ea0] (200/630) Accurately ripped
 03	 [f3637334] (200/629) Accurately ripped
 04	 [b2430def] (200/629) Accurately ripped
 05	 [fff3a34c] (200/633) No match but offset
 06	 [9c6a5d54] (200/629) Accurately ripped
 07	 [e17941b1] (200/636) Accurately ripped
 08	 [7469e41b] (200/628) Accurately ripped
 09	 [85da3c52] (200/629) Accurately ripped
 10	 [c09b7265] (200/632) Accurately ripped
 11	 [de212959] (200/627) Accurately ripped
 12	 [ca7c1d6b] (200/628) Accurately ripped
 13	 [87f097c4] (200/630) Accurately ripped
 14	 [07abc8dd] (200/623) Accurately ripped
Offsetted by -1167:
 01	 [651978b4] (067/634) Accurately ripped
 02	 [5eb792bc] (066/630) Accurately ripped
 03	 [622e7bfa] (067/629) Accurately ripped
 04	 [1a1ef9a4] (067/629) Accurately ripped
 05	 [1383964a] (067/633) Accurately ripped
 06	 [78258c6b] (067/629) Accurately ripped
 07	 [3cda3725] (067/636) Accurately ripped
 08	 [a11fde9c] (067/628) Accurately ripped
 09	 [3d5db722] (067/629) Accurately ripped
 10	 [8ee75178] (067/632) Accurately ripped
 11	 [f55f0015] (067/627) Accurately ripped
 12	 [7477200d] (067/628) Accurately ripped
 13	 [41e96bc5] (066/630) Accurately ripped
 14	 [2bc5f796] (066/623) Accurately ripped
Offsetted by -503:
 01	 [bb44e503] (144/634) Accurately ripped
 02	 [d79a843b] (144/630) Accurately ripped
 03	 [7d72be6b] (143/629) Accurately ripped
 04	 [eb96d2ca] (144/629) Accurately ripped
 05	 [e58e2fa8] (145/633) Accurately ripped
 06	 [207e259d] (144/629) Accurately ripped
 07	 [03241b2c] (145/636) Accurately ripped
 08	 [7992c329] (145/628) Accurately ripped
 09	 [d22d1c46] (143/629) Accurately ripped
 10	 [3cead23d] (144/632) Accurately ripped
 11	 [5d4e3751] (140/627) Accurately ripped
 12	 [576e8f1a] (144/628) Accurately ripped
 13	 [8ab56485] (144/630) Accurately ripped
 14	 [9a18a194] (142/623) Accurately ripped
Offsetted by 166:
 01	 [c44269b0] (064/634) Accurately ripped
 02	 [9303797d] (063/630) Accurately ripped
 03	 [fed762b3] (063/629) Accurately ripped
 04	 [2a50612d] (061/629) Accurately ripped
 05	 [8815c208] (062/633) Accurately ripped
 06	 [e55bad13] (062/629) Accurately ripped
 07	 [514a2236] (063/636) Accurately ripped
 08	 [2a0e58b6] (062/628) Accurately ripped
 09	 [fbff9a71] (062/629) Accurately ripped
 10	 [27acb03b] (061/632) Accurately ripped
 11	 [bdd16fe7] (061/627) Accurately ripped
 12	 [88d50923] (061/628) Accurately ripped
 13	 [73a45a43] (061/630) Accurately ripped
 14	 [4cedf4be] (063/623) Accurately ripped
Offsetted by 278:
 01	 [4f1ab971] (060/634) Accurately ripped
 02	 [e2b5e515] (060/630) Accurately ripped
 03	 [65115c17] (059/629) Accurately ripped
 04	 [d402cdea] (060/629) Accurately ripped
 05	 [2a5ae0b2] (062/633) Accurately ripped
 06	 [300a8a9b] (059/629) Accurately ripped
 07	 [3aa21a50] (061/636) Accurately ripped
 08	 [d2bb4ed7] (061/628) Accurately ripped
 09	 [05aadede] (060/629) Accurately ripped
 10	 [8194c26f] (062/632) Accurately ripped
 11	 [eaaa62f0] (062/627) Accurately ripped
 12	 [665dbfc3] (060/628) Accurately ripped
 13	 [930bdbad] (061/630) Accurately ripped
 14	 [0a21c079] (057/623) Accurately ripped
Offsetted by -977:
 01	 [807af0a0] (004/634) Accurately ripped
 02	 [20b1f5d9] (004/630) Accurately ripped
 03	 [08a1cd52] (004/629) Accurately ripped
 04	 [550a4049] (004/629) Accurately ripped
 05	 [62d77c7c] (003/633) No match but offset
 06	 [6eced33c] (004/629) Accurately ripped
 07	 [25a797c8] (004/636) Accurately ripped
 08	 [3c37ee7c] (004/628) Accurately ripped
 09	 [b2ba0689] (004/629) Accurately ripped
 10	 [64ff866e] (004/632) Accurately ripped
 11	 [e81dfaf6] (004/627) Accurately ripped
 12	 [eaf0a728] (004/628) Accurately ripped
 13	 [38f381b0] (004/630) Accurately ripped
 14	 [43aa54ce] (004/623) Accurately ripped
Offsetted by -285:
 01	 [1128fac9] (024/634) Accurately ripped
 02	 [3a9b4950] (024/630) Accurately ripped
 03	 [14d2deaa] (024/629) Accurately ripped
 04	 [6bec140f] (024/629) Accurately ripped
 05	 [8a39ae6c] (024/633) No match but offset
 06	 [8a772c33] (024/629) Accurately ripped
 07	 [c3e5189d] (025/636) Accurately ripped
 08	 [0beb91d7] (021/628) Accurately ripped
 09	 [e50521a4] (024/629) Accurately ripped
 10	 [b59efd30] (025/632) Accurately ripped
 11	 [f77a0bfb] (024/627) Accurately ripped
 12	 [b8e90109] (023/628) Accurately ripped
 13	 [928d106e] (024/630) Accurately ripped
 14	 [d01d8cf2] (024/623) Accurately ripped
Offsetted by 379:
 01	 [caf9809d] (071/634) Accurately ripped
 02	 [3c1f37cf] (069/630) Accurately ripped
 03	 [a3fb6e97] (069/629) Accurately ripped
 04	 [a9af7b1a] (069/629) Accurately ripped
 05	 [d9a2723f] (070/633) No match but offset
 06	 [a06f11eb] (069/629) Accurately ripped
 07	 [fc8ad8a8] (071/636) Accurately ripped
 08	 [a67277b6] (068/628) Accurately ripped
 09	 [5b1bc9d0] (069/629) Accurately ripped
 10	 [321c3014] (069/632) Accurately ripped
 11	 [b7960faa] (069/627) Accurately ripped
 12	 [1a7d2de0] (069/628) Accurately ripped
 13	 [cd58b4fa] (070/630) Accurately ripped
 14	 [ad4d9913] (067/623) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --  100,0 [2FD7507D] [12032DE7] [E84B3A7D]
 01   97,7 [62C1C40C] [D578D2E8]		   
 02   97,7 [F385CEDE] [E7A3EDB0]		   
 03   97,7 [573ADCFF] [4112FC39]		   
 04   97,7 [ABE73EE9] [F6CE68FF]		   
 05   97,7 [300E75AF] [50D7AA68]		   
 06   97,7 [59CD56CA] [BEED7545]		   
 07   97,7 [80B92569] [70C11558]		   
 08   97,7 [B18A1D07] [ACE5A70F]		   
 09   97,7 [ACD0E700] [9D5E347B]		   
 10   99,9 [0F5C0D3B] [51500113]		   
 11   97,7 [7C6F9D97] [4A7E07AD]		   
 12  100,0 [66630ECC] [A6C60D95]		   
 13   97,7 [126A0B13] [82C0B378]		   
 14   97,7 [5798FA0C] [0862B8F3]

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1158 – 2010-08-07 18:28:13

Your pressing differs from the pressing that is in the CTDB by more than just an offset.

Of all the pressings listed in the log it seems that there are three others that are a possible match to yours (besides the difference due to offset).

While this might not seem to be exactly common, it does happen. If your copy of track 5 was previously verifiable against those other pressings you can locate the differences through subtracting the two and then determine which one is more correct.

I've tried to alert people to the possibility of this happening on more than one occasion in the past. Here is one such post:
http://www.hydrogenaudio.org/forums/index....st&p=698717

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1159 – 2010-08-07 19:01:22

Wouldn't it then be more likely that CTDB corrected track 5 to match the other pressings, making the rip by this exact offset inaccurate?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1160 – 2010-08-07 19:12:46

I don't know what you started with before the correction, but that's clearly what happened.

However, I don't see how that negates my explanation of the mechanism that caused the discrepancy. Barring the possibility that one of the databases was polluted by an errant rip that was propagated through a CD-R/RW or file sharing, there are pressings that exist in which the audio data in track five differs by more than just an offset. I identified such a situation in my collection just yesterday.

Are you able to get an error-free extraction of track five that can be verified by AR?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1161 – 2010-08-07 19:33:44

But I don't think it's a "pollution". As far as I can see, it looks like CTDB are capable of repairing rips independently of offset. If only a CTDB submission exists for all the other offsets (which are similar in data), CTDB, will (?) repair my rip according to one of those.

Anyway, I could just offset it, and it will match another pressing just perfectly, although it seems kind of hackish...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1162 – 2010-08-07 19:38:48

Quote from: odyssey on 2010-08-07 19:33:44

But I don't think it's a "pollution".

I just said barring the possibility of pollution. I have no compelling reason to believe that the different pressings were caused by pollution.

Quote from: odyssey on 2010-08-07 19:33:44

As far as I can see, it looks like CTDB are capable of repairing rips independently of offset. If only a CTDB submission exists for all the other offsets (which are similar in data), CTDB, will (?) repair my rip according to one of those.

That's correct.

Quote from: odyssey on 2010-08-07 19:33:44

Anyway, I could just offset it, and it will match another pressing just perfectly, although it seems kind of hackish...

Whatever floats your boat.

If you like, I can check my copy of Dookie to see which audio data I have for track 5.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1163 – 2010-08-07 20:53:36

I thought I'd play around with it anyway and managed to successfully convert my disc that has a different TOC into the one that you have, though I am not able to get CUETools to correct it using CTDB.

Code: [Select]

[CUETools log; Date: 8/7/2010 12:48:37 PM; Version: 2.0.9]
[CTDB TOCID: XTU4B7u6dvyQRuV9Lh992o1Udy8-] found.
        [ CTDBID ] Status
        [03e12bac] (336/336) No match
[AccurateRip ID: 00144dd9-00d7a14c-b009520e] found.
Track   [ CRC    ] Status
 01     [be97907b] (200/634) Accurately ripped
 02     [d18d8ea0] (200/630) Accurately ripped
 03     [f3637334] (200/629) Accurately ripped
 04     [b2430def] (200/629) Accurately ripped
 05     [627aac23] (200/633) Accurately ripped
 06     [9c6a5d54] (200/629) Accurately ripped
 07     [e17941b1] (200/636) Accurately ripped
 08     [7469e41b] (200/628) Accurately ripped
 09     [85da3c52] (200/629) Accurately ripped
 10     [c09b7265] (200/632) Accurately ripped
 11     [de212959] (200/627) Accurately ripped
 12     [ca7c1d6b] (200/628) Accurately ripped
 13     [87f097c4] (200/630) Accurately ripped
 14     [936cc134] (200/623) No match but offset
Offsetted by -1167:
 01     [1c52cb4a] (067/634) No match but offset
 02     [5eb792bc] (066/630) Accurately ripped
 03     [622e7bfa] (067/629) Accurately ripped
 04     [1a1ef9a4] (067/629) Accurately ripped
 05     [7a248e94] (067/633) No match but offset
 06     [78258c6b] (067/629) Accurately ripped
 07     [3cda3725] (067/636) Accurately ripped
 08     [a11fde9c] (067/628) Accurately ripped
 09     [3d5db722] (067/629) Accurately ripped
 10     [8ee75178] (067/632) Accurately ripped
 11     [f55f0015] (067/627) Accurately ripped
 12     [7477200d] (067/628) Accurately ripped
 13     [41e96bc5] (066/630) Accurately ripped
 14     [47035c89] (066/623) No match but offset
Offsetted by -977:
 01     [3127f0c6] (004/634) No match but offset
 02     [20b1f5d9] (004/630) Accurately ripped
 03     [08a1cd52] (004/629) Accurately ripped
 04     [550a4049] (004/629) Accurately ripped
 05     [a50bd0c0] (003/633) Accurately ripped
 06     [6eced33c] (004/629) Accurately ripped
 07     [25a797c8] (004/636) Accurately ripped
 08     [3c37ee7c] (004/628) Accurately ripped
 09     [b2ba0689] (004/629) Accurately ripped
 10     [64ff866e] (004/632) Accurately ripped
 11     [e81dfaf6] (004/627) Accurately ripped
 12     [eaf0a728] (004/628) Accurately ripped
 13     [38f381b0] (004/630) Accurately ripped
 14     [82c5de09] (004/623) No match but offset
Offsetted by -503:
 01     [13e8ace0] (144/634) No match but offset
 02     [d79a843b] (144/630) Accurately ripped
 03     [7d72be6b] (143/629) Accurately ripped
 04     [eb96d2ca] (144/629) Accurately ripped
 05     [4e3ceaba] (145/633) No match but offset
 06     [207e259d] (144/629) Accurately ripped
 07     [03241b2c] (145/636) Accurately ripped
 08     [7992c329] (145/628) Accurately ripped
 09     [d22d1c46] (143/629) Accurately ripped
 10     [3cead23d] (144/632) Accurately ripped
 11     [5d4e3751] (140/627) Accurately ripped
 12     [576e8f1a] (144/628) Accurately ripped
 13     [8ab56485] (144/630) Accurately ripped
 14     [40287527] (142/623) No match but offset
Offsetted by -285:
 01     [fb41f9d5] (024/634) No match but offset
 02     [3a9b4950] (024/630) Accurately ripped
 03     [14d2deaa] (024/629) Accurately ripped
 04     [6bec140f] (024/629) Accurately ripped
 05     [a363ad4c] (024/633) No match but offset
 06     [8a772c33] (024/629) Accurately ripped
 07     [c3e5189d] (025/636) Accurately ripped
 08     [0beb91d7] (021/628) Accurately ripped
 09     [e50521a4] (024/629) Accurately ripped
 10     [b59efd30] (025/632) Accurately ripped
 11     [f77a0bfb] (024/627) Accurately ripped
 12     [b8e90109] (023/628) Accurately ripped
 13     [928d106e] (024/630) Accurately ripped
 14     [26114edd] (024/623) No match but offset
Offsetted by 166:
 01     [c44269b0] (064/634) Accurately ripped
 02     [9303797d] (063/630) Accurately ripped
 03     [fed762b3] (063/629) Accurately ripped
 04     [2a50612d] (061/629) Accurately ripped
 05     [eb203b91] (062/633) No match but offset
 06     [e55bad13] (062/629) Accurately ripped
 07     [514a2236] (063/636) Accurately ripped
 08     [2a0e58b6] (062/628) Accurately ripped
 09     [fbff9a71] (062/629) Accurately ripped
 10     [27acb03b] (061/632) Accurately ripped
 11     [bdd16fe7] (061/627) Accurately ripped
 12     [88d50923] (061/628) Accurately ripped
 13     [73a45a43] (061/630) Accurately ripped
 14     [3b6388bd] (063/623) No match but offset
Offsetted by 278:
 01     [4f1ab971] (060/634) Accurately ripped
 02     [e2b5e515] (060/630) Accurately ripped
 03     [65115c17] (059/629) Accurately ripped
 04     [d402cdea] (060/629) Accurately ripped
 05     [e104f98b] (062/633) No match but offset
 06     [300a8a9b] (059/629) Accurately ripped
 07     [3aa21a50] (061/636) Accurately ripped
 08     [d2bb4ed7] (061/628) Accurately ripped
 09     [05aadede] (060/629) Accurately ripped
 10     [8194c26f] (062/632) Accurately ripped
 11     [eaaa62f0] (062/627) Accurately ripped
 12     [665dbfc3] (060/628) Accurately ripped
 13     [930bdbad] (061/630) Accurately ripped
 14     [28ae7cb8] (057/623) No match but offset
Offsetted by 379:
 01     [caf9809d] (071/634) Accurately ripped
 02     [3c1f37cf] (069/630) Accurately ripped
 03     [a3fb6e97] (069/629) Accurately ripped
 04     [a9af7b1a] (069/629) Accurately ripped
 05     [f4da33e7] (070/633) No match but offset
 06     [a06f11eb] (069/629) Accurately ripped
 07     [fc8ad8a8] (071/636) Accurately ripped
 08     [a67277b6] (068/628) Accurately ripped
 09     [5b1bc9d0] (069/629) Accurately ripped
 10     [321c3014] (069/632) Accurately ripped
 11     [b7960faa] (069/627) Accurately ripped
 12     [1a7d2de0] (069/628) Accurately ripped
 13     [cd58b4fa] (070/630) Accurately ripped
 14     [8e13c99e] (067/623) No match but offset

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --  100.0 [59354DB9] [196815AC]           
 01   97.7 [4B62A514] [9D18C343]   CRC32   
 02   97.7 [F385CEDE] [E7A3EDB0]   CRC32   
 03   97.7 [573ADCFF] [4112FC39]   CRC32   
 04   97.7 [ABE73EE9] [F6CE68FF]   CRC32   
 05   97.7 [02F9CDA8] [A12D2B6C]   CRC32   
 06   97.7 [59CD56CA] [BEED7545]   CRC32   
 07   97.7 [80B92569] [70C11558]   CRC32   
 08   97.7 [B18A1D07] [ACE5A70F]   CRC32   
 09   97.7 [ACD0E700] [9D5E347B]   CRC32   
 10   99.9 [0F5C0D3B] [51500113]   CRC32   
 11   97.7 [7C6F9D97] [4A7E07AD]   CRC32   
 12  100.0 [66630ECC] [A6C60D95]   CRC32   
 13   97.7 [126A0B13] [82C0B378]   CRC32   
 14   97.7 [E4F62D0D] [576D6E64]   CRC32

Any assistance would be appreciated.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1164 – 2010-08-07 21:21:12

When CUETools converts HDCD data to 24 bit lossless does it apply peak extend, transient filter and gain to sound data?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1165 – 2010-08-08 16:22:13

Quote from: tuxman on 2010-07-31 17:42:00

CUETools is constantly giving me an array index out of bound exception when trying to process any cue file ...

Quote from: tuxman on 2010-07-31 17:58:49

It happens with all CUE files I have, it didn't earlier.
Also, it happens before or after checking MusicBrainz, so I guess it's not related to the cue files at all.

Same here! It even happens with rips I made with CUERipper just minutes ago. My old EAC rips (a mixture of image + cue and individual files + cue) give the same error.

Interestingly, AR verification is possible. I just get that exception when trying to transcode. Sometimes before querying MusicBrainz, sometimes after. My previous version of CUETools (2.0.2a) didn't have that issue.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1166 – 2010-08-08 22:14:59

When I use this format with Cue-Tools

[%directoryname%\]%artist% - %album% '('%year%')'[%unique%]\%filename%.cue

how can I make it, that instead of this output (showing the variable %year%)

Rah Band - Rah (%year%)

nothing (instead of %year%) will be displayed, when the year is missing in the data:

Rah Band - Rah

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1167 – 2010-08-09 21:49:04

Hello:

I downloaded a rip made by someone else. There is no cue file, only an EAC log from an unspecified version. When I use EAChelper's log analyzer it says: "Incorrect read offset for LITE-ON LTR-52327S The read offset for LITE-ON LTR-52327S should be +6." The log shows that Read offset correction was 0.

When I use CueTools to verify the tracks, by dragging the first .wav file onto CueTools. the result is this:

Code: [Select]

[CUETools log; Date: 09/08/2010 4:20:35 PM; Version: 2.0.9]
[CTDB TOCID: _Aw5sadEbfyx850rLpfAssw1T2w-] found.
        [ CTDBID ] Status
        [19ddeccc] (5/5) Accurately ripped
[AccurateRip ID: 000dbd35-00706562-79091d0a] found.
Track   [ CRC    ] Status
 01     [49334af4] (02/09) Accurately ripped
 02     [fb9a597f] (02/08) Accurately ripped
 03     [97dc1da3] (02/09) Accurately ripped
 04     [12c2f36d] (02/09) Accurately ripped
 05     [b57fbdc2] (02/09) Accurately ripped
 06     [d4358d5e] (02/09) Accurately ripped
 07     [548953b8] (02/09) Accurately ripped
 08     [82848983] (02/09) Accurately ripped
 09     [a2fe8bf8] (03/10) Accurately ripped
 10     [b918da29] (02/09) Accurately ripped
Offsetted by 6:
 01     [abc59c3f] (07/09) Accurately ripped
 02     [f30a350d] (06/08) Accurately ripped
 03     [ac353f87] (07/09) Accurately ripped
 04     [377c760f] (07/09) Accurately ripped
 05     [c77d951b] (07/09) Accurately ripped
 06     [4ecad046] (07/09) Accurately ripped
 07     [fd29ebb1] (07/09) Accurately ripped
 08     [554e4742] (07/09) Accurately ripped
 09     [6f8b0943] (07/10) Accurately ripped
 10     [ed4db42f] (07/09) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --   87.9 [F0842CFA] [FE10AB4A]
 01   45.7 [8CAFE107] [5EEE4117]
 02   49.7 [F9501052] [3395475C]
 03   40.9 [240C3F17] [50F1D520]
 04   53.7 [65DB5693] [95856A3A]
 05   68.8 [9E85FD6B] [708E25E5]
 06   47.0 [63A61B38] [C5D11F6F]
 07   71.4 [18DD8958] [6D7E3DB0]
 08   87.9 [5EE0CB38] [430A092C]
 09   67.2 [B301B89E] [FC001F59]
 10   63.2 [1F292BD2] [B00BC890]

CueTools has a function called "fix offset", but I do not know exactly what it does or how to use it. Should I use it in this case? How would I do so, and what would the benefit be?

Thank you.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1168 – 2010-08-10 05:25:00

Is there a good guide online on how to use CUETools?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1169 – 2010-08-10 16:57:57

Quote from: g725s on 2010-08-10 05:25:00

Is there a good guide online on how to use CUETools?

A quick search would have found a guide on the previous page.

http://www.hydrogenaudio.org/forums/index....st&p=716848

It is a work in progress needs people to contribute.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1170 – 2010-08-11 01:58:28

Quote from: bilbo on 2010-08-10 16:57:57

Quote from: g725s on 2010-08-10 05:25:00
Is there a good guide online on how to use CUETools?

A quick search would have found a guide on the previous page.

http://www.hydrogenaudio.org/forums/index....st&p=716848

It is a work in progress needs people to contribute.

Are you calling this a guide / tutorial?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1171 – 2010-08-15 17:18:47

After starting to rip my CD's with CUEripper (in tracks mode), I noticed many albums, which gives me a HTOA-file usually only consisting of 18816 samles (some more). I suspect this is equivalent of PREGAP. They can of course contain audio, in which case they should surely be preserved, but what should I do with all those without audio?

It seems a bit odd to keep them, but deleting them will break the CUE-sheet. Maybe an option to convert them into PREGAP instead would be the best way to fix it?

Besides this, I have a few issues/requests:

1. Verifying albums in batch mode, if an album consists of short tracks that are not kept in the AR-database, it will report "AR inaccurate" even when the album says accurate when it's verified alone.
2. The log output is great, but could certainly be improved. How about a cell-matrix with columns instead of everything on one line?
3. CT can correct filenames in cue-files, but it would be great if you could also rename log+cue+accurip using a template.
4. CT can't distinguish multiple CD-albums with more than 9 albums in one folder?
5. "Output file already exists, Overwrite?" (.accurip) is quite annoying. Can we have an option to always overwrite at least this file?
6. Why are HTOA tracks not tagged? (Edit: This seems to be a problem if you want to rename an album with a HTOA-track)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1172 – 2010-08-16 15:05:43

Thx for your nice work!!!

Startet today with CueTools after rEACt making Problems with Win7 (x64) on my new computer.
And CueTools seems to work how I intend: Making simply exact Images as Flac with Cue-Sheet.

I tried several templates to achive the same Name-Structur as I did in Foobar2000 or rEACt before.
I thought while: "cuetools output path templates are based on foobar2000 title formatting syntax", I should be able to take my formating string from Foobar2000.
But it doesn´t work.

Here is my f2k formatting string:
%music%\$left(%album artist%,1)\%album artist%\['['%date%']' ]%album%\$if(%disc%,CD$num(%disc%,1)\,)[$if2(%vinyltrack%,%tracknumber%)] %title%

or for single image files
%music%\$left(%album artist%,1)\%album artist%\['['%date%']' ]%album%\$if(%disc%,CD$num(%disc%,1)\,)%album artist% - %album%

to make this structure:
music\A\Alex\[2009] Test\Alex - Test.flac

and if more than 1 disc:
music\A\Alex\[2009] Test\cd1\Alex - Test.flac
music\A\Alex\[2009] Test\cd2\Alex - Test.flac

Could you please help me doing this with CueTools?
It´s not such a big problem to "handmade" this later on, but it would be nice if CueTools could handle this too!!!

(Sorry for my bad english.)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1173 – 2010-08-18 02:06:45

I am new to Cuetools/Cueripper etc. Is there a way to make Cueripper eject a CD automatically after it is ripped? I'd like to automate the ripping process if possible.

Thanks

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1174 – 2010-08-18 11:33:43

Hi!
I really like the progress of the CUETools development

Currently I've got two problems/questions that I'd love to see a fix for:

1) It seems that CUERipper has a problem with UTF-8 in cue sheets:

CUETools are able to save Japanese artists in the CUE sheet,
but CUERipper only sets

?? as artist name.

I also think there should be an option to use Latin names (like the
option found in MusicBrainz Picard).

2) I've got a EAC rip of the Emperor: Battle for Dune soundtrack.
However since no one has added the disc id to MusicBrainz, CUETools
are not able to get the related metadata from MusicBrainz.

Is there a way I can force CUETools to use a specific metadata entry?

Notice