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 1911473 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 #1000 –
Well, sometimes connection can break during uploading, but according to log the only time this happened last week was 11/May/2010:21:59:29 +0400
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1001 –
I guess it's the same issue sauvage78 reported:

Code: [Select]
[AccurateRip ID: 000cef35-004de6cd-540bec08] disk not present in database.
CD-Extra data track length 18:23:00 - 18:23:74.
[CTDB TOCID: zj_rMxHuJN5Oerzcxqxr2bsS22A-] found.
        [ CTDBID ] Status
        [400e759b] (12/12) Is an Enhanced CD, data track length 18:23:25, Accurately ripped      <--------
Disk not present in database.


It's not clear whether the disk is accuratly ripped or not in the database.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1002 –
onkl:
With this log you actually cannot say if the rip is accurate or not because your EAC log is missing the exact data track length ... so cuetools only guess a range of possible lengths:
Code: [Select]
CD-Extra data track length 18:23:00 - 18:23:74.

but you're lucky because CTDB includes your CD & gives you  a big hint of this exact data track length:
Code: [Select]
data track length 18:23:25


Just put this number in Cuetools data track length's box & re-check, if the rip is in the AR database then you will know if it is accurate or not.

CTDB is great for reparing but it is also great to get the exact data track length.

My personnal issue was that I didn't knew which one to trust in case cuetools doesn't detect a range but CTDB detect an enhanced CD, I have tried to get an answer by experimentation, obviously in this case cuetools is right & you just happen to have a non-enhanced pressing of the enhanced CD which is in the database. So in this case, if cuetools doesn't detect a range, it seems that you should just ignore the CTDB enhanced information.

Edit: lot of typos.

The mandatory way of storing (& parsing) the exact data track length in an external file that I was asking for earlier (I use .nfo actually) or the ability of cuetools to parse .accurip for this information (in case you delete the EAC log after checking AR with cuetools) would be usefull for guys like me in order to submit to CTDB. Because as I don't use logs, if I actually submit my enhanced CD to CTDB I fear that it will not work as it should as there will be no data track length.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1003 –
Hey that did the trick! With the data track info AR could verify the rip. Thanks for the advice. Now I wonder why CUETools doesn't recheck by itself.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1004 –
I'm re-ripping with CUETools few CDs that are not in any DB (musicbrainz, freedb, AMG, ...).

Feature request :
Could you import tags from files (in this case , *.flac , individual tracks) ?

I failed to rip a bonus track (#21).
TOC :
      20  | 64:12.56 |  4:02.60 |    288956    |  307165 
      21  | 70:47.41 |  6:38.34 |    318566    |  348449 
Drive used : HL-DT-ST DVDRAM GSA-T40N
[Copy range didn't work in EAC either]

Is it a drive limitation ? Should i try with another drive ?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1005 –
Quote from: Thundik81 on
I'm re-ripping with CUETools few CDs that are not in any DB (musicbrainz, freedb, AMG, ...).

You can also scan the old rips with CUE Tools, and if the AR confidence is greater than 2 the CTDB hashes can be submitted to the database. That should be a timesaver.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1006 –
Quote from: Fandango on
You can also scan the old rips with CUE Tools, and if the AR confidence is greater than 2 the CTDB hashes can be submitted to the database. That should be a timesaver.


As i said : AccurateRip: disk not present in database.

Edit: however how to update cue files created by EAC without re-ripping ? (i want to add ACCURATERIPID, CATALOG and ISRC)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1007 –
Quote from: sauvage78 on
The mandatory way of storing (& parsing) the exact data track length in an external file that I was asking for earlier (I use .nfo actually) or the ability of cuetools to parse .accurip for this information (in case you delete the EAC log after checking AR with cuetools) would be usefull for guys like me in order to submit to CTDB. Because as I don't use logs, if I actually submit my enhanced CD to CTDB I fear that it will not work as it should as there will be no data track length.

There are too many ways to organize your rips, CUETools cannot possibly be 'smart' enough to guess it in each case. Keeping the log file is the most common and reliable way. You can at least keep the TOC portion of the log at least for enhanced CDs. It seems somehow wrong to use .accurip files for verification when they are the result of verification. Besides, .accurip format is changing frequently, many people store .accurip files not in the same folder as the rip, it also often has a different extension.

Quote from: onkl on
Hey that did the trick! With the data track info AR could verify the rip. Thanks for the advice. Now I wonder why CUETools doesn't recheck by itself.

As sauvage78 pointed out, data track length from CTDB is not always relevant (you can have a non-enhanced pressing of the enhanced CD which is in the database). But in this particular case when CUETools knows that there is a data track but doesn't know it's exact length, i suppose it makes sense to use CTDB info. I'll probably implement it.

Quote from: Thundik81 on
Could you import tags from files (in this case , *.flac , individual tracks) ?

The best solution would probably be to submit metadata from flac rip to freedb or musicbrainz, i'm sure it's possible with some software. CUETools will probably soon be able to submit to freedb. You could then import those tags when reripping.

Quote from: Thundik81 on
I failed to rip a bonus track (#21).
TOC :
      20  | 64:12.56 |  4:02.60 |    288956    |  307165 
      21  | 70:47.41 |  6:38.34 |    318566    |  348449

It's not a bonus audio track, it's a data track. It contains files, and it can be copied using explorer.

Quote from: Thundik81 on
Edit: however how to update cue files created by EAC without re-ripping ? (i want to add ACCURATERIPID, CATALOG and ISRC)

One of the awkward ways to do this is to start ripping and abort after gaps are detected. CUERipper has already written .cue at this point. You could then just replace old .cue with new. It should be compatible with old files, if you used the same mode (image or tracks).
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1008 –
Quote from: Gregory S. Chudov on
Quote from: Thundik81 on
Could you import tags from files (in this case , *.flac , individual tracks) ?

The best solution would probably be to submit metadata from flac rip to freedb or musicbrainz, i'm sure it's possible with some software. CUETools will probably soon be able to submit to freedb. You could then import those tags when reripping.


thanks. Nice forthcoming feature.

Quote from: Gregory S. Chudov on
Quote from: Thundik81 on
I failed to rip a bonus track (#21).
TOC :
      20  | 64:12.56 |  4:02.60 |    288956    |  307165 
      21  | 70:47.41 |  6:38.34 |    318566    |  348449

It's not a bonus audio track, it's a data track. It contains files, and it can be copied using explorer.


That's what i assumed for this "bonus" track. I thought that audio ripping tool could retrieve that kind of data... no problem i'll use Isobuster or such a software.

Quote from: Gregory S. Chudov on
Quote from: Thundik81 on
Edit: however how to update cue files created by EAC without re-ripping ? (i want to add ACCURATERIPID, CATALOG and ISRC)

One of the awkward ways to do this is to start ripping and abort after gaps are detected. CUERipper has already written .cue at this point. You could then just replace old .cue with new. It should be compatible with old files, if you used the same mode (image or tracks).


I would love an update cue function (like the Correct extension / filenames) 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1009 –
Gregory S. Chudov:
Quote
There are too many ways to organize your rips


Well you're forgetting that you can have an EAC log & still miss the exact data track length, the TOC & data track length is only included in rips with recent EAC log ... I have plenty of rips with old EAC log which don't inludes the data track length ... these rips are perfectly valid & I haven't done any misstake.

There must be a mandatory way to store the exact data lengtht for rip with old EAC log (or no log at all which in the end is the same) ... you cannot just tell me "hey, it's you're fault, just use EAC log!" This is not true. 80% of my logs didn't have a TOC, so it would have been the same if I would have keept those logs.

I understand that parsing a .accurip might sound weird to you if you only have logs with TOC & don't miss any exact data track length ... but for old EAC rips with the old EAC log formatting this is [Edit: maybe] where it belongs [Edit: In fact I don't think so, see below]... I mean you cannot store it in the log unless you heavily edit it & it is never a good idea to edit a log.

(Long off-topic parenthesis about my position on logs:
I delete logs specially for this reason: my logs are perfect so those are of no use for me, & I know I cannot trust any logs from anyone except me so why would I keep those logs too? Keeping EAC logs is IMHO just a FUD from zealots which don't understand the information included inside, & specially that don't admit that a rip with "no error" in the EAC log can be scratched. Don't get me wrong I don't think logs are useless, I think that logs are only usefull when something is wrong & I have checked all my logs for anything wrong before deleting them, so my logs are not useless, those are just not usefull to me anymore. IMHO, the people who only swear by EAC logs are P2P irrationnal teenagers sectarians, the same kind so-called audiophile which were enforcing the use of Musepack a few years ago. It's not that keeping logs would be stupid, if I would not verify my logs instantly I would keep those untill I would check them. So even if I don't keep those I do create them, I wouldn't even create those if I would think those would be completely useless. I have keept my logs for years before experience told me that those files weren't as precious as I was told.)

Back on the topic:
So as the exact data track length is not included in old EAC logs & as you cannot store the exact data length in .log without editing (& as furthermore editing would be a painfull waste of time) ... you have to find an official simple yet efficient way to store this information ... you cannot say : "You don't organize your collection like me, it's your fault" ... It is not my fault if early EAC logs don't work well with AR & Cuetools, I am only asking for a simple solution.

I admit that, for the same reason as editing an EAC log, editing a .accurip is not a good idea, manually editing a .accurip for parsing is strange ... still manually adding  the line "CD-Extra data track length XX:XX:XX." & re-checking with a Cuetools version that would parse this info before any calculation, is one of the two easiest solutions I found.

In the end the conlusion is simple:
If you admit that you must find a solution for enhanced CD with early EAC log, I only see 2 choices ...
1- You don't want to store this info outside the .accurip, then you have to accept the idea of . accurip editing in this special case & parse . accurip for this info.
2- You don't want people to edit .accurip even in this special case, then you have to admit the idea of parsing an external file with this information to simulate the .log. This .txt can be a .nfo, a .accudata or a .whatever-you-want ... it doesn't matter to me but I think it would be better to have a new extension reserved for this use ... because some people might already use .log/.txt/.nfo for other purposes.

I understand that this is boring & annoying for you ... you have to code something you obviously don't use & both solutions have flaws (additionnal parsing, editing or additionnal file) ... but you cannot tell that the problem doesn't exist, it just doesn't exist for you. Personnaly I already use .nfo, so I think the second solution with the parsing of an external .accudata file is the best solution. I don't like the idea of editing . accurip from the first solution.

Now you may ask why am I asking for this if I already use .nfo ? The reason is simple, if you don't automaticaly parse an external file for the exact data track lenght then you force people to manually add this length ... with only a few enhanced CD, in the beginning it was not an issue ... but I have realized that I had ~100 enhanced rips so this has became an issue for me ... worse now I don't know if I can upload those ECD to CTDB as I don't know how it will react (Will it create a non enhanced pressing that don't exist in real life? It is an issue at all?).

I understand that you must have plenty of more important stuff to code first, but I disagree with the denial of the problem for enhanced CD with old EAC logs.

Edit:
Think of it as wavpack lossy+correction file (.wv+.wvc) ... (.accurip+.accudata) ... simple & efficient.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1010 –
After you added CD to CTDB, CUETools will always be able to get data track length from there. I just added this feature. So in this case it becomes unnecessary to store it in any file. And when you don't use CTDB, stored ACCURATERIPID tag is enough.

There remains only one exotic case where you might want to store data track length - when you have an old rip which cannot be submitted to CTDB at this time (inaccurate/not in AR database), but you want to be able to try again later. Personally i think this case is unimportant. But just in case i will add support for .toc files, which contain TOC portion of EAC log. I'll even add an option to create such files.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1011 –
Well I'll wait to see how this get implemented to comment, but if you can create a .toc which includes the data track length (manually added but once for good at .toc creation this time) & if Cuetools can parse it instead of .log when the log is missing then I guess it should perfectly fit my needs ... if this works that way then I will instantly creates .toc for all my ECD for which I know the data track length ... I may even start to search manually some of those I miss ... actually the most annoying thing about my ECD is that I have to manage them in a seperate folders as some of them have a data track length & some don't, & even for those which have an exact data length but no log, I cannot update the AR count as I have no way to automatically parse the information.

It might sound exotic to you, but it highly depends on how many ECD you ripped before EAC log included the TOC ... this is a must have feature for me as each special AR case is splitting my collection in different folders actually.

It's true that creating an additionnal separate file just for one line "CD-Extra data track length XX:XX:XX." creates files that are almost empty, I have nothing against adding the TOC, I just didn't thought about it. Afterall that's the only part of EAC logs that I am truly missing ... in fact I didn't thought about this option as I thought that creating a complete TOC would have useless work for you when a simple copy/paste can do the trick, but if you're willing to add it that way because it sound more logic to you ... I am all in.

To a lesser extand I have the same problem with rips with silent track:
as Cuetools doesn't detect an accurate rip with confidency 3 as accurate if it includes a [00000000] silent track, it rejects those rips from CTDB ...
Code: [Select]
CDImage.cue: AccurateRip: confidence too low.
Those rips are perfectly AR3.
Code: [Select]
[Verification date: 05/05/2010 23:02:52]
[AccurateRip ID: 0018549a-00e1dd40-aa0cfc0c] found.
[CTDB TOCID: QZ8He3MyR7ifg.FPwQlph_aAmL8-] disk not present in database.
Track	[ CRC    ] Status
 01	[9a81e41e] (05/05) Accurately ripped
 02	[60fc2f70] (05/05) Accurately ripped
 03	[18200767] (05/05) Accurately ripped
 04	[d72a42f2] (05/05) Accurately ripped
 05	[6ebb67af] (05/05) Accurately ripped
 06	[1c245330] (05/05) Accurately ripped
 07	[00000000] (00/00) No match
 08	[a6096bc8] (05/05) Accurately ripped
 09	[a647b5ab] (05/05) Accurately ripped
 10	[919a1bc5] (05/05) Accurately ripped
 11	[94611876] (05/05) Accurately ripped
 12	[1121b507] (05/05) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] 
 --   98,8 [7255B76C] [CF9A3606]           
 01   98,8 [5A6F00EA] [BF508009]           
 02   98,5 [54ACC1C8] [5A96293A]           
 03   98,8 [1591BC51] [7AD4DC9B]           
 04   98,8 [4D09A800] [361B02A7]           
 05   98,8 [C250DD50] [049BD2DA]           
 06   98,8 [8B532B12] [406D5C1D]           
 07    0,0 [02864C0E] [00000000]           
 08   98,8 [915367D2] [4DE0C500]           
 09   98,8 [CFB8B562] [316B64D9]           
 10   98,8 [C48522CC] [FBE5E4CE]           
 11   98,8 [5640892A] [A0A973E7]           
 12   98,8 [3C7DB066] [15D83CA3]         

 At some point, (after Sandy Bridge CPU are released, so around 2011) I plan to submit all my collection to CTDB. I hope those rips could be submitted, even if those "exotic cases" are "unimportant" ... I'll keep those in a separate folder too till then ...

Here is a list of "unimportant" rips that I actually cannot submit to CTDB even if I wanted to
Code: [Select]
Danzig - 1994 - Danzig 4
Edge Of Sanity - 1994 - Purgatory Afterglow
John Lennon - 1973 - Mind Games
Korn - 1998 - Follow The Leader
Marilyn Manson - 1996 - Antichrist Superstar
Mayhem - 2000 - Grand Declaration Of War
Ministry - 1999 - Dark Side Of The Spoon
Morbid Angel - 2003 - Heretic
Nine Inch Nails - 1992 - Broken (EP, Digipack)
Overkill - 1994 - W.F.O.
Tool - 1993 - Undertow
Louis Armstrong - 2008 - The Hot Five & Hot Seven Recordings (1925-29) (4CD)
Marillion - 2008 - Happiness Is The Road (2CD, Deluxe Ed)

I could post twice more but I am bored of copy pasting

I may look constantly complaining ... but don't get me wrong I am already very thanksfull for all you achieved with Cuetools, in fact I am addicted to it ... it's just that it could be even better !!!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1012 –
Quote from: sauvage78 on
To a lesser extand I have the same problem with rips with silent track:
as Cuetools doesn't detect an accurate rip with confidency 3 as accurate if it includes a [00000000] silent track, it rejects those rips from CTDB ...

Thanks, fixed in 2.0.9
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1013 –
Thanks

Honestly I wish that rips with [00000000] would not only be accepted as submissions but also that those rips would be reported as accurate in the bach log because actually when I "fix" my rips according to the offset with the highest AR confidence  in database+only if 100% tracks are AR2+only if all tracks match the same offset ... cuetools doesn't "fix" the offset too (as so far a rip with [00000000] couldn't be accurate no matter the result of the others non-silent tracks) [Edit: I guess I can lower the required confidence but it forces me to do 2 pass]

In fact I wish that [00000000] tracks would be simply ignored no matter the action. Both when you set an AR confidence parameter as a filter & when cuetools draw a conclusion about the accuracy of the whole disk.

Edit: My personnal assistant Greynol just told me that the word "confidency" didn't exist  Fixed to "confidence", thks !!!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1014 –
I just saw that V2.09 was actually released so I tested it ... I succesfully submitted a rip with an empty track to CTDB so that part worked ... but after that I tried to "fix" another rip & I had a strange result: all tracks are now reported as accurate in the .accurip log but the batch log still concludes that the whole rip is not accurate & so the whole offset fixing didn't start, then I tried to upload that "bad" rip ... & it was accepted (Edit: The first time I didn't check if the whole rip was accurate in the batch log before being accepted, despite being accepted it "wasn't accurate" in batch log too I just re-checked):

Batch log: Bad hence "offset not fixable" with my filter
Code: [Select]
CDImage.cue: AR: rip not accurate (16/16).

Bad but submitted ???
Code: [Select]
CDImage.cue: AR: rip not accurate (16/16), CTDB: disk not present in database, zImXwBUC_ZGAOhJghadou315CbE- has been uploaded.

.accurip log: Good but should have been "fixed" by +66 if [00000000] tracks would have been ignored.
Code: [Select]
[CUETools log; Date: 18/05/2010 20:23:30; Version: 2.0.9]
[AccurateRip ID: 0032ca87-03021fa3-4909bb17] found.
Track   [ CRC    ] Status
 01     [25b0fccd] (05/19) Accurately ripped
 02     [f926c883] (05/19) Accurately ripped
 03     [3220d10e] (05/19) Accurately ripped
 04     [0b9512be] (05/19) Accurately ripped
 05     [0bd9f5a4] (05/19) Accurately ripped
 06     [b695892c] (05/19) Accurately ripped
 07     [59d33144] (05/19) Accurately ripped
 08     [9ef4928e] (05/19) Accurately ripped
 09     [beee4d2c] (05/19) Accurately ripped
 10     [a82efa2d] (05/19) Accurately ripped
 11     [4b5fb83b] (06/20) Accurately ripped
 12     [00000000] (00/00) Accurately ripped
 13     [00000000] (00/00) Accurately ripped
 14     [00000000] (00/00) Accurately ripped
 15     [00000000] (00/00) Accurately ripped
 16     [00000000] (00/00) Accurately ripped
 17     [00000000] (00/00) Accurately ripped
 18     [00000000] (00/00) Accurately ripped
 19     [00000000] (00/00) Accurately ripped
 20     [00000000] (00/00) Accurately ripped
 21     [00000000] (00/00) Accurately ripped
 22     [00000000] (00/00) Accurately ripped
 23     [09c3e978] (05/16) Accurately ripped
Offsetted by 66:
 01     [4c7144a7] (14/19) Accurately ripped
 02     [6999bd94] (14/19) Accurately ripped
 03     [efc0b09a] (14/19) Accurately ripped
 04     [a3b20f25] (14/19) Accurately ripped
 05     [b62a4303] (14/19) Accurately ripped
 06     [131b76eb] (14/19) Accurately ripped
 07     [2716707c] (14/19) Accurately ripped
 08     [5122279f] (14/19) Accurately ripped
 09     [bcefe72c] (14/19) Accurately ripped
 10     [183f759e] (14/19) Accurately ripped
 11     [469135c7] (14/20) Accurately ripped
 12     [00000000] (00/00) Accurately ripped
 13     [00000000] (00/00) Accurately ripped
 14     [00000000] (00/00) Accurately ripped
 15     [00000000] (00/00) Accurately ripped
 16     [00000000] (00/00) Accurately ripped
 17     [00000000] (00/00) Accurately ripped
 18     [00000000] (00/00) Accurately ripped
 19     [00000000] (00/00) Accurately ripped
 20     [00000000] (00/00) Accurately ripped
 21     [00000000] (00/00) Accurately ripped
 22     [00000000] (00/00) Accurately ripped
 23     [ea572e0b] (11/16) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] 
 --  100,0 [02D97771] [08042A49]           
 01  100,0 [1D2F1FB9] [F51F0F51]           
 02  100,0 [2553F3A4] [523834A1]           
 03  100,0 [A7A5FC78] [4912C60B]           
 04  100,0 [5E7313D1] [92089105]           
 05  100,0 [2E581386] [E97B4DCA]           
 06  100,0 [B05D8912] [796EE265]           
 07  100,0 [C1AF8AA1] [3FE268F4]           
 08  100,0 [D9805A37] [8FD46487]           
 09  100,0 [97FB0799] [DFB237D8]           
 10  100,0 [CDAEDC9F] [E7A1BCEC]           
 11  100,0 [790C0F58] [9E32BA87]           
 12    0,0 [6E375D99] [00000000]           
 13    0,0 [6E375D99] [00000000]           
 14    0,0 [6E375D99] [00000000]           
 15    0,0 [6E375D99] [00000000]           
 16    0,0 [6E375D99] [00000000]           
 17    0,0 [6E375D99] [00000000]           
 18    0,0 [6E375D99] [00000000]           
 19    0,0 [6E375D99] [00000000]           
 20    0,0 [6E375D99] [00000000]           
 21    0,0 [6E375D99] [00000000]           
 22    0,0 [6E375D99] [00000000]           
 23   73,3 [AE335FE7] [ED630E95]         


... there is actually a problem of logic in the way things are reported IMHO

Edit: Also instead of "Accurately ripped" reporting as "Silent track" would IMHO be better for newbies which doesn't understand what [00000000] means.
Edit2: If you want to be even more precise & make a difference between silent track with data (not empty) & silent track without data (empty), maybe someting like "Empty track" or "No data" would work too. I don't know if the precision is really usefull.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1015 –
CUETools 2.0.8 and 2.0.9 are not working for me under mono.


~/smb/CUETools_2.0.9$ mono ArCueDotNet.exe /tmp/Estatic\ Fear\ -\ Somnium\ Obmutum.flac.cue
Error: Access to the path "/tmp/orbit-root" is denied.

For some reason it needs to scan every file in that directory....

~/smb/CUETools_2.0.9$ mono ArCueDotNet.exe /tmp/arcue/Estatic\ Fear\ -\ A\ Sombre\ Dance.flac.cue
Error: Array index is out of range.


~/smb/CUETools_2.0.4a_x86$ mono ArCueDotNet.exe /tmp/Estatic\ Fear\ -\ Somnium\ Obmutum.flac.cue
[Verification date: 5/18/2010 3:59:15 PM]
[Disc ID: 000901b5-00255800-1b0d5604]
.....

I'm not sure what version broke it for mono. Any chance someone can look into this? Thanks!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1016 –
I'll try...
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1017 –
I used to be able to associate .cue files with cuetools but since upgrading to 2.0.9 I can't anymore.  Anybody else having this problem?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1018 –
Me not. Check the path. I have the following in my registry and it works:

[HKEY_CLASSES_ROOT\Folder\shell\cue tools]
"" = "Browse with CUETools"

[HKEY_CLASSES_ROOT\Folder\shell\cue tools\command]
"" = "C:\Work\cuetoolsnet\bin\Release\CUETools.exe" "%1"
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1019 –
I found a CD in my collection where CUE Ripper cannot detect pre-gaps. What I do?

Code: [Select]
REM ACCURATERIPID 00211583-01624bb2-c70ed90e
REM DISCID C70ED90E
REM COMMENT "CUERipper v2.0.9 Copyright © 2008-10 Gregory S. Chudov"
REM DATE 1991
REM GENRE "Industrial"
PERFORMER "Die Warzau"
TITLE "Big Electric Metal Bass Face"
FILE "01. Crack Radio.wv" WAVE
  TRACK 01 AUDIO
    TITLE "Crack Radio"
    PERFORMER "Die Warzau"
    PREGAP 00:00:33
    INDEX 01 00:00:00
FILE "02. Funkopolis.wv" WAVE
  TRACK 02 AUDIO
    TITLE "Funkopolis"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "03. Never Again.wv" WAVE
  TRACK 03 AUDIO
    TITLE "Never Again"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "04. Shock Box.wv" WAVE
  TRACK 04 AUDIO
    TITLE "Shock Box"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "05. Brand New Convertible Car.wv" WAVE
  TRACK 05 AUDIO
    TITLE "Brand New Convertible Car"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "06. Burning.wv" WAVE
  TRACK 06 AUDIO
    TITLE "Burning"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "07. All Cut Up.wv" WAVE
  TRACK 07 AUDIO
    TITLE "All Cut Up"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "08. Coming Down (Live).wv" WAVE
  TRACK 08 AUDIO
    TITLE "Coming Down (Live)"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "09. My Pretty Little Girlfriend.wv" WAVE
  TRACK 09 AUDIO
    TITLE "My Pretty Little Girlfriend"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "10. Red All Over.wv" WAVE
  TRACK 10 AUDIO
    TITLE "Red All Over"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "11. Pig City.wv" WAVE
  TRACK 11 AUDIO
    TITLE "Pig City"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "12. Dying in Paradise.wv" WAVE
  TRACK 12 AUDIO
    TITLE "Dying in Paradise"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "13. Suck It Up.wv" WAVE
  TRACK 13 AUDIO
    TITLE "Suck It Up"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "14. Head.wv" WAVE
  TRACK 14 AUDIO
    TITLE "Head"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00

Code: [Select]
REM GENRE rock
REM DATE 1991
REM DISCID C70ED90E
REM COMMENT "ExactAudioCopy v0.99pb5"
CATALOG 0731451198823
PERFORMER "Die Warzau"
TITLE "Big Electric Metal Bass Face"
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\01. Crack Radio.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Crack Radio"
    PERFORMER "Die Warzau"
    PREGAP 00:00:33
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\02. Funkopolis.wav" WAVE
  TRACK 02 AUDIO
    TITLE "Funkopolis"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\03. Never Again.wav" WAVE
  TRACK 03 AUDIO
    TITLE "Never Again"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\04. Shock Box.wav" WAVE
  TRACK 04 AUDIO
    TITLE "Shock Box"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
  TRACK 05 AUDIO
    TITLE "Brand New Convertible Car"
    PERFORMER "Die Warzau"
    INDEX 00 03:26:58
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\05. Brand New Convertible Car.wav" WAVE
    INDEX 01 00:00:00
  TRACK 06 AUDIO
    TITLE "Burning"
    PERFORMER "Die Warzau"
    INDEX 00 06:25:07
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\06. Burning.wav" WAVE
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\07. All Cut Up.wav" WAVE
  TRACK 07 AUDIO
    TITLE "All Cut Up"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\08. Coming Down (Live).wav" WAVE
  TRACK 08 AUDIO
    TITLE "Coming Down (Live)"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\09. My Pretty Little Girlfriend.wav" WAVE
  TRACK 09 AUDIO
    TITLE "My Pretty Little Girlfriend"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\10. Red All Over.wav" WAVE
  TRACK 10 AUDIO
    TITLE "Red All Over"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\11. Pig City.wav" WAVE
  TRACK 11 AUDIO
    TITLE "Pig City"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\12. Dying in Paradise.wav" WAVE
  TRACK 12 AUDIO
    TITLE "Dying in Paradise"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\13. Suck It Up.wav" WAVE
  TRACK 13 AUDIO
    TITLE "Suck It Up"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\14. Head.wav" WAVE
  TRACK 14 AUDIO
    TITLE "Head"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1020 –
Quote from: Fandango on
I found a CD in my collection where CUE Ripper cannot detect pre-gaps. What I do?


how did you do it? 
for me makes: 01.00 - (HTOA)

CUEripper rip:
Code: [Select]
REM ACCURATERIPID 0025fbfa-0205f0ea-ec0edf12
REM DISCID EC0EDF12
REM COMMENT "ExactAudioCopy v0.99pb4"
REM DATE 2002
PERFORMER "Buzzcocks"
TITLE "Ever Fallen in Love? Buzzcocks Finest"
CATALOG 0724385623820
FILE "01.00 - (HTOA).flac" WAVE
  TRACK 01 AUDIO
    TITLE "I Don't Mind"
    PERFORMER "Buzzcocks"
    INDEX 00 00:00:00
FILE "01 - I Don't Mind.flac" WAVE
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Whatever Happened to...?"
    PERFORMER "Buzzcocks"
    INDEX 00 02:19:28
.
.


EAC rip:
Code: [Select]
REM GENRE Punk
REM DATE 1997
REM DISCID EC0EDF12
REM COMMENT "ExactAudioCopy v0.99pb5"
PERFORMER "Buzzcocks"
TITLE "Ever Fallen In Love? - BUZZCOCKS FINEST"
FILE "01 - I Don't Mind.wav" WAVE
  TRACK 01 AUDIO
    TITLE "I Don't Mind"
    PERFORMER "Buzzcocks"
    PREGAP 00:00:32
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Whatever Happened To?"
    PERFORMER "Buzzcocks"
    INDEX 00 02:19:28
FILE "02 - Whatever Happened To .wav" WAVE
.
.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1022 –
Quote from: Gregory S. Chudov on
Me not. Check the path. I have the following in my registry and it works:

[HKEY_CLASSES_ROOT\Folder\shell\cue tools]
"" = "Browse with CUETools"

[HKEY_CLASSES_ROOT\Folder\shell\cue tools\command]
"" = "C:\Work\cuetoolsnet\bin\Release\CUETools.exe" "%1"


Thank you for the reply.  I figured it out, but your post led me to a little digging through the registry.  It turns out that cuetools wasn't properly registered.  It was pointing to an obsolete .exe.  Just in case this happens to anyone else make sure that cuetools is  pointing to the right .exe location at the following registry key HKEY_CLASSES_ROOT\Applications\CUETools.exe\shell\open\command

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1023 –
Still no multi-core support?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1024 –
If you are expecting multicore support in fb2k style, no, and i don't intend to implement it.

It's a bad idea to write several files in parallel. It's bad for your HDD and performance gains are too small.
It also doesn't help when using one-file disc images.

If you want fast compression, use FlaCuda, which uses many CPU cores and GPU. Assuming you have a compatible GPU, of course.
If you don't, then use libFlake, which is about twice as fast as standard FLAC when using similar compression ratios.
And try using lower compression levels like libFlake -3, extra 1% of used disc space won't kill you.
Also recent versions of CUETools do use at least two cores, with separate decoding thread.
CUETools 2.1.6