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 1894937 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #175
Use the "Own format" textbox.
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #176
Is there a tutoral or any kind explanation of how to use Cuetools ?

Not really. Just a readme file and a small wiki page here, which i hope somebody will expand a bit - i'm not really good at this.

I would like to write my files to a different directory using "artist - album" as the folder name and "artist - album" as the name of my single file .wav .

Choose "Use custom format" for output path, and set it to something like "C:\Music\%D - %C\%D - %C.cue".
Make sure that in advanced settings "Single format" is set to %F and "Keep original filenames" is turned off. I think it's this way by default.

Your program is great !!!!

Actually, it's Moitah's program. I just added some new features.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #177
Does anyone know how to change CueTools language? It's a good idea to place this info to readme :-)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #178
AFAICS it is taken from the system?
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #179
Yep...
If your system's language is russian or german, CUETools will use the appropriate language files, unless you remove the deDE and ruRU folders.
No other language packs available currently. If you are willing to help creating one of them, let me know.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #180
If it hasn't been reported, yet: ALAC input does not work without cuesheets for 1.9.3. It displays the following message "Padded some input files to a frame boundary.", fails to detect the correct disc ID, and returns before verification. If I convert the same set of ALAC files to FLAC in Foobar and feed them into CUETools again everything works fine.

I tried the same in 1.9.4a. Here verification starts (I guess the disc ID has been detected then) but breaks when going from track 01 to track 02 with the following error: "Samples read != Samples expected".

Edit: ALAC files were created using XLD (Apple's Core Audio converter), so they should be conforming to specs.

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #181
In November last year I did a request for a drag & drop for the cue-sheet creator. A few days later I said I didn't need it any more.
But now I think it would be a nice feature.

Since the request of Fandango on Jan, 9 an update also calculates the crc's with and without zero's while only verifying.
Could this be made into a selectable feature?
I check many downloads without log, and now I have to wait until cuetools has calculated all crc's instead of telling me right away the disc is not in accurate rip database.

To finish a question about a log:
Code: [Select]
[Disc ID: 00376db3-03ea51a9-5f0f8019]
Track [ CRC    ] Status
 01 [41810bc1] (00/00) No matches
 02 [b38f9541] (00/02) No matches
 03 [f534d0a5] (00/02) No matches
 04 [70e38582] (00/02) No matches
 05 [b9ffa57c] (00/02) No matches
 06 [a4c21713] (00/02) No matches
 07 [a9e42b24] (00/02) No matches
 08 [2ce3ec1f] (00/02) No matches
 09 [691da940] (00/02) No matches
 10 [653ff6e2] (00/02) No matches
 11 [8a6e4f7c] (00/02) No matches
 12 [28bb673f] (00/00) No matches
 13 [67633e1d] (00/02) No matches
 14 [543b0503] (00/02) No matches
 15 [e08a56d5] (00/02) No matches
 16 [ab61a706] (00/00) No matches
 17 [27fd191b] (00/02) No matches
 18 [47a1b9a8] (00/02) No matches
 19 [875f8b51] (00/02) No matches
 20 [984f5c0a] (00/02) No matches
 21 [c1d8633a] (00/02) No matches
 22 [ca8cc11e] (00/02) No matches
 23 [3bb02914] (00/02) No matches
 24 [d7980cae] (00/02) No matches
 25 [04d0fc4c] (00/02) No matches
Offsetted by 450:
 01 [eae7aa77] (00/00) No matches
 02 [190770ed] (02/02) Accurately ripped as in pressing(s) #1
 03 [3de8c8b7] (02/02) Accurately ripped as in pressing(s) #1
 04 [8db62dac] (02/02) Accurately ripped as in pressing(s) #1
 05 [8215c9da] (02/02) Accurately ripped as in pressing(s) #1
 06 [331c07eb] (02/02) Accurately ripped as in pressing(s) #1
 07 [9a6d6c68] (02/02) Accurately ripped as in pressing(s) #1
 08 [97a0f8eb] (02/02) Accurately ripped as in pressing(s) #1
 09 [a1f2a00c] (02/02) Accurately ripped as in pressing(s) #1
 10 [50af46dc] (02/02) Accurately ripped as in pressing(s) #1
 11 [6499de26] (02/02) Accurately ripped as in pressing(s) #1
 12 [8aca015d] (00/00) No matches
 13 [02e24079] (02/02) Accurately ripped as in pressing(s) #1
 14 [f10f0f87] (02/02) Accurately ripped as in pressing(s) #1
 15 [3fceacb1] (02/02) Accurately ripped as in pressing(s) #1
 16 [29c0ff10] (00/00) No matches
 17 [b9bf2dd9] (02/02) Accurately ripped as in pressing(s) #1
 18 [3d7cde7c] (02/02) Accurately ripped as in pressing(s) #1
 19 [019b2343] (02/02) Accurately ripped as in pressing(s) #1
 20 [57d3d30c] (02/02) Accurately ripped as in pressing(s) #1
 21 [fee1fed6] (02/02) Accurately ripped as in pressing(s) #1
 22 [1731c90a] (02/02) Accurately ripped as in pressing(s) #1
 23 [dcd59316] (02/02) Accurately ripped as in pressing(s) #1
 24 [f286eafc] (02/02) Accurately ripped as in pressing(s) #1
 25 [a764d748] (02/02) Accurately ripped as in pressing(s) #1

Am I correct when I conclude that tracks 1, 12 & 16 haven't been ripped by both contributors?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #182
Since the request of Fandango on Jan, 9 an update also calculates the crc's with and without zero's while only verifying.
Could this be made into a selectable feature?
I check many downloads without log, and now I have to wait until cuetools has calculated all crc's instead of telling me right away the disc is not in accurate rip database.

To finish a question about a log:
...
Am I correct when I conclude that tracks 1, 12 & 16 haven't been ripped by both contributors?


I have the same problem with log files. I don't see any value in wasting time calculating CRC values only to eventually be told that the CD does not exist in the AccurateRip database.

Tigerman, are those three tracks really short tracks? I've seen 00/00 with tracks that are just a few seconds long.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #183


To finish a question about a log:
...
Am I correct when I conclude that tracks 1, 12 & 16 haven't been ripped by both contributors?


Tigerman, are those three tracks really short tracks? I've seen 00/00 with tracks that are just a few seconds long.


All 3 tracks are more than 2:30 minutes long.  I also think it's a bit strange that 2 persons rip all tracks but 3 and on top pf that, the same 3.
But I don't know another explanation for this log.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #184
Since the request of Fandango on Jan, 9 an update also calculates the crc's with and without zero's while only verifying.
Could this be made into a selectable feature?

+1, please add a checkbox to disable this feature of 1.9.4a.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #185
What's ru-RU\CUETools.resources.dll for? If it is a localization, how can I enable it?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #186
If your system language is ru-RU, it is enabled automatically.
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #187
How can I save the log with summary results including information how many tracks are accuratly ripped???
I have flac files + cue and cue tools shows me this:

Code: [Select]
[Verification date: 17.02.2009 18:48:00]
[Disc ID: 00236e9b-0148dca1-be129a0c]
Track [ CRC    ] Status
 01 [900ed963] (04/08) Accurately ripped as in pressing(s) #1
 02 [fe14ff5a] (04/08) Accurately ripped as in pressing(s) #1
 03 [3251d1ea] (04/08) Accurately ripped as in pressing(s) #1
 04 [1ed5ba05] (04/08) Accurately ripped as in pressing(s) #1
 05 [6988026b] (04/08) Accurately ripped as in pressing(s) #1
 06 [63c0c74c] (04/06) Accurately ripped as in pressing(s) #1
 07 [502fbf53] (04/06) Accurately ripped as in pressing(s) #1
 08 [a1134504] (04/08) Accurately ripped as in pressing(s) #1
 09 [2a2a7ca5] (04/08) Accurately ripped as in pressing(s) #1
 10 [af9ffc79] (04/08) Accurately ripped as in pressing(s) #1
 11 [6e81ef45] (04/08) Accurately ripped as in pressing(s) #1
 12 [a096748a] (04/08) Accurately ripped as in pressing(s) #1
Offsetted by 658:
 01 [16bda481] (04/08) Accurately ripped as in pressing(s) #2
 02 [b4e5f384] (04/08) Accurately ripped as in pressing(s) #2
 03 [e91b7a6a] (04/08) Accurately ripped as in pressing(s) #2
 04 [e06ef381] (04/08) Accurately ripped as in pressing(s) #2
 05 [b948c587] (04/08) Accurately ripped as in pressing(s) #2
 06 [f3b8c9bc] (02/06) Accurately ripped as in pressing(s) #2
 07 [4b9e0fa3] (02/06) Accurately ripped as in pressing(s) #2
 08 [f4d7469e] (04/08) Accurately ripped as in pressing(s) #2
 09 [0eff3567] (04/08) Accurately ripped as in pressing(s) #2
 10 [a62f7475] (04/08) Accurately ripped as in pressing(s) #2
 11 [8df9bdff] (04/08) Accurately ripped as in pressing(s) #2
 12 [396b5720] (04/08) Accurately ripped as in pressing(s) #2

Track [ CRC32  ] [W/O NULL] [  LOG  ]
 -- [5BA4C51E] [69837F15]
 01 [ED14D67F] [0524FE8D] W/O NULL
 02 [9FFC6177] [A4439958] W/O NULL
 03 [84459ABA] [165623DE] W/O NULL
 04 [65AF8CCC] [6D42D10C] W/O NULL
 05 [2FE0C888] [E04A22A1] W/O NULL
 06 [9DA30EA6] [A38AB19E] W/O NULL
 07 [D651B2BB] [8F25F247] W/O NULL
 08 [5E96E749] [4AA61D43] W/O NULL
 09 [DC12FE56] [F67A5A90] W/O NULL
 10 [9C620694] [ACCAF361] W/O NULL
 11 [099A2D28] [69AB621E] W/O NULL
 12 [361F538B] [573BDEDA] W/O NULL
W/O NULL - what does it mean????

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Codebox.[/size]
🇺🇦 Glory to Ukraine!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #188
Without nullsamples, I guess?
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #189
it means that file not contain null samples??? or there must by CRC for this tracks without nullsamples??? I don't undderstand
🇺🇦 Glory to Ukraine!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #190
There are two ways in which EAC can calculate CRCs.  This has no effect on the data that is ripped.

I take it the first pair listed is for the data as a single-file image?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #191
I take it the first pair listed is for the data as a single-file image?

Exactly.

Also, in the first column are CRCs from the audio with the null samples. In the second column are CRCs of the audio without the null samples.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #192
Thanks.

The null samples for CRC calculations applies to null samples (as a stereo pair) anywhere within the track, not just at the beginning or end.

Personally, I don't see the need to show the fourth column which I assume is a comparison against the log.  However, I'm curious to see what gets displayed if the checksums don't match at all or if they match a test CRC which may be different from a copy CRC.  I can pretty much figure this out for myself, but if you or anyone else can save me the trouble, I'd love to know.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #193
The null samples for CRC calculations applies to null samples (as a stereo pair) anywhere within the track, not just at the beginning or end.
Really? I wouldn't have thought so. It's a bit weird, does it have any practical advantage?

Personally, I don't see the need to show the fourth column which I assume is a comparison against the log.  However, I'm curious to see what gets displayed if the checksums don't match at all or if they match a test CRC which may be different from a copy CRC.  I can pretty much figure this out for myself, but if you or anyone else can save me the trouble, I'd love to know.
It doesn't compare the against the CRC in EAC's log, but maybe it is planned? Would be a nice feature to make an event from it that triggers something useful.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #194
Oh, I guess it just checks for that setting in the log?  That's even less useful.

Re: practical advantage
I can't think of any.  I despise the idea of leaving out null samples in CRC calculations.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #195
Why CUETools don't shows the summary information like "9 tracks is accuratley riped. 1 track is not in database" ???
🇺🇦 Glory to Ukraine!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #196
Oh, I guess it just checks for that setting in the log?  That's even less useful.

AFAIK it doesn't analyze the EAC log at all.

But I think this would be a great way of improving CUE Tools' performance... for example: only check rips where the log says the read offset correction was "0", in case you want to quickly "correct" all your older rips, only those without offset correction would be analyzed and if possible they'd be corrected. Utilizing the AR drive offset database for cross-reference would be nice, too, by using the drive model's string.

Then a EAC-log-rewrite feature... after correcting a rip's offset the EAC log gets rewritten to match the CRC/AR-CRCs, change the "no use of null samples" line if desired and of course change the offset correction line...

Rips where the CRC in the log doesn't match both CRCs calculated by CUE Tools, could be marked as suspicious, and so on. This could be useful for example after you've had an incident of data corruption due to hardware failure.

See, there's so much more that could be implemented in this tool just by integrating EAC log analyzing... so much work.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #197
AFAIK it doesn't analyze the EAC log at all.


Yes, the EAC log file is analyzed now in 1.9.4 update 1. There is a pop-up window making you choose a log file -- even if there is only one EAC log file in the directory.

CUE Tools now always computes CRC values for all tracks and compares them to the EAC log file. It also computes CRC values for the entire CD. Here's an example:

[Verification date: 02/06/2009 8:09:59 PM]
[Disc ID: 001426c9-00bb266b-910a740c]
Disk not present in database.

Track    [ CRC32  ]   [W/O NULL]   [  LOG  ]
--      [D4B3D468]   [0941D83E]   
01      [90C6CBFC]   [E10369D8]     CRC32 
02      [03D82245]   [1B9DDD67]     CRC32 
03      [BCEF4981]   [264486A1]     CRC32 
04      [220D5D1A]   [C8631D4C]     CRC32 
05      [23971A5D]   [D20A87F2]     CRC32 
06      [FBEE9E98]   [26A4AF23]     CRC32 
07      [4DCD9046]   [B909E371]     CRC32 
08      [9FEB083A]   [3883A06F]     CRC32 
09      [BAE5C697]   [70AE19C0]     CRC32 
10      [2625C539]   [7F40B7A7]     CRC32 
11      [3F9E6356]   [B3F07038]     CRC32 
12      [AC331DC0]   [DEAD6636]     CRC32 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #198
12 [AC331DC0] [DEAD6636] CRC32
 
What a satanic track
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #199
it means that file not contain null samples??? or there must by CRC for this tracks without nullsamples??? I don't undderstand

Your files are ok. Each track is accurately ripped, as the log shows.
CRCs in the end of the log are only there to compare with EAC log file.
CUETools 2.1.6