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 1912225 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 #375 –
Quote from: tuxman on
Aw, a new version without intermediate builds on SVN... gonna translate some new stuff, brb.

Sorry for that  I figured if i don't release a version today, i will start rewriting major parts again and there won't be new version for another month or so.

Quote from: sauvage78 on
What I meant is that I like fixing the offset because it creates shorter logs...

Uncheck 'Verbose' option for log files, and you will have shorter logs
If you still want to 'fix' offsets, uncheck 'to nearest' option.
'Verify than encode' action is now replaced by "Encode and verify' with script 'fix offset' (you can select it in that combobox under available actions).
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #376 –
Is it intended that the comboboxes are not translatable?

What about creating a new file for those strings (like the status bar messages, too) to allow translations?

audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #377 –
For status messages yes, but comboboxes mostly contain things that are unlikely to be translated - file extensions, encoder names...
Maybe it makes sense for script names, but most of those are very likely to be user-defined.
But you're right, i should make at least the word 'Default' translatable
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #378 –
Quote from: Gregory S. Chudov on
'Verify than encode' action is now replaced by "Encode and verify' with script 'fix offset'.


When disc not present in database, 'Verify than encode' in old versions performs encoding without offset correction.
In new version 'Encode and verify' with script 'fix offset' does NOT perform encoding. Only displays 'Status Report: disk not present in database'.

Is it possible to modify the 'fix offset' script to perform encoding without offset correction, when disc not present in database?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #379 –
The new version seems to be going in the right direction. I already like V2.0.2 much more than 2.0.1 which I never really used.

I like the new parameters of the corrector, I like that "correct filenames" moved to "action", I like the new "drag the files here".

I will test it more & consider switching from 1.9.5a, it has several nice little features that I asked for so thks a lot.

As a sidenote the CUE icon is ugly when displayed as large icon. I don't care much but it's a shame that I change the icon on my desktop ... Even the same white & black icon but less pixelised when zoomed would do the job ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #380 –
Quote from: user44 on
Is it possible to modify the 'fix offset' script to perform encoding without offset correction, when disc not present in database?

Yeah.
In Advanced settings->Scripts, select any script and press insert.
Give it a name, e.g. 'fix anyway', check 'Verify and convert' in conditions, and copy-paste the script from 'fix offset'.
Modify the second line:

Code: [Select]
if (processor.ArVerify.AccResult != HttpStatusCode.OK)
    return processor.Go(); // was return processor.WriteReport();
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #381 –
Quote from: sauvage78 on
As a sidenote the CUE icon is ugly when displayed as large icon. I don't care much but it's a shame that I change the icon on my desktop ... Even the same white & black icon but less pixelised when zoomed would do the job ...
We should start a logo contest. In a seperate thread, of course.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #382 –
Thanks for the improvements, I like 2.02 much more than 2.01.
The first  drag & drop into the directory tree is a bit slow, but after that it is quick as 1.9.5a
The correct filenames is a click more, but I can live with that 

I do have a request:
I would like a small status window where, after a task, the status report is showed in stead of the pop-up window.
Or maybe it could be showed in the bar on the same place where it shows how far a verify is.
I don't like pop-up windows which I must close before I can proceed.

Maybe this isn't possible because of the length of some status messages.
In that case:
  • a auto wrap in the status window would be nice.
  • a choice between status report & full log would be nice

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #383 –
typo: action verify: displayed tip ==> databse instead of database

also when I select lossy: ogg just below I have the choice between oggenc & nero aac & when I select m4a nero aac is not there, I didn't try these options but I guess there is a problem there too.

The logic would be :
m4a: nero aac
ogg: oggenc

& not :
m4a: empty
ogg: oggenc & nero aac

I didn't tried but having nero aac under ogg was surprising ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #384 –
When using a short version of log would it be possible that valid result from incomplete pressing/offset would be excluded

Actually if the rip in the database is

offset xxx
1 100/100
2 100/100
3 00/100
4 00/100

offset yyy
1 00/100
2 00/100
3 100/100
4 100/100

the short log will ouput this:
All offset
1 100/100
2 100/100
3 100/100
4 100/100

the user of the short log version will not be aware that there might be a problem with offset.

the short log should only display valid results if there are valid results with at least confidence 1 for all track within the same offset ... doing so most valid rips will not be affected. (at worst they should display a little less results) while incomplete pressings will not be reported as perfect ...

with this filter my exemple would return:
All offset
1 0/100
2 0/100
3 0/100
4 0/100

which would warn you to do a long log to understand what is happening.

Also would it be possible to have an option to output the short log in front of the long log & also an option to output both long & short long at the same time separately ... because actually if I want both I fear will have to run my collection twice which I don't like ...

Finally I already asked for it but I redo as it is important for me: would it be possible to have an option to hide "as in pressing(s) #" within the logs because these numbers means nothing (specially when tangled) & are disturbing. It's nothing but added noise in my log, I dislike seeing it, each time I read my logs.
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #385 –
Quote from: Fandango on
Quote from: sauvage78 on
As a sidenote the CUE icon is ugly when displayed as large icon. I don't care much but it's a shame that I change the icon on my desktop ... Even the same white & black icon but less pixelised when zoomed would do the job ...
We should start a logo contest. In a seperate thread, of course.

Exactly six months ago, I created an icon set for cuetools. I did it for personal use, but my intention was to perhaps give it some finishing touches and offer it to Gregory as a very modest contribution from my side. At some stage, before I had a chance to revisit the design, Gregory added the current icon and I didn't feel that my contribution was necessary anymore.

However, I have happily used my icon set with my shortcuts and I think it works quite well. Here is how it looks:





The gearwheel is an attempt to visualize the word "tools" and the sun-like ball kind of symbolizes the recreation power of CUETools. The functional purpose of its shape and colors is naturally to make it easily distinguishable in all sizes.

I attached a ready to use .ico file (in a zip package). It contains the icon in four common standard sizes. Feel free to use it if you like the design.

[attachment=5077:cuetools_icon_set.zip]

Gregory, as I said, I think I could give the design some finishing touches and also further develop it so that it would be usable as a logo.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #386 –
Well that's all about taste ... personnaly I don't like gearwheel much, my problem with the old icon is not that I don't like it, but that it doesn't seem to include a large version of the icon, so as I use large icon it use a zoomed small icon which create ugly pixelisation ... also black & white is a little sad ... the old icon with your sun in the back would be perfect for my need. Another option would be to create a sunny like gearwheel & remove the word CUE from the icon as 99% of icons don't include text.

In the end it's up to Gregory to decide so I don't care much ... give me a non-pixelised large icon that's all I ask

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #387 –
Quote from: Tigerman on
I do have a request:
I would like a small status window where, after a task, the status report is showed in stead of the pop-up window.
Or maybe it could be showed in the bar on the same place where it shows how far a verify is.
I don't like pop-up windows which I must close before I can proceed.

ImgBurn uses an extra window for that. It can be stickied to the main window. I think that's a very elegant solution, since you can close the status window if you don't want to see it, of course.


Quote from: Alex B on
Gregory, as I said, I think I could give the design some finishing touches and also further develop it so that it would be usable as a logo.
Well, I like it. It's definetly better than the current one.  Finishing touches would include making it "Vista-ready", i.e. bigger bitmaps. 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #388 –
Quote
ImgBurn uses an extra window for that. It can be stickied to the main window. I think that's a very elegant solution, since you can close the status window if you don't want to see it, of course.


Is also a fine solution. As long as I can proceed without a mandatory click.
Autowrap and a choice between status report or log would be nice in that case.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #389 –
Cosmetic request:

Actually results are sorted by offset no matter if the results are good or bad, could the results still be sorted by offset but grouping good results with good results in front & bad results with bad results in the bottom.

For exemple actually we have:

Code: [Select]
[Verification date: 03/05/2009 19:42:46]
[Disc ID: 000cdb40-00609af6-7209a309]
Pregap length 00:00:32.
Track    [ CRC    ] Status
 01    [dd66af1f] (10/25) Accurately ripped as in pressing(s) #1
 02    [0913cf12] (10/26) Accurately ripped as in pressing(s) #1
 03    [0baae567] (10/26) Accurately ripped as in pressing(s) #1
 04    [fa0725ba] (10/25) Accurately ripped as in pressing(s) #1
 05    [e566df1c] (10/25) Accurately ripped as in pressing(s) #1
 06    [fa882817] (10/25) Accurately ripped as in pressing(s) #1
 07    [e8e6d151] (10/26) Accurately ripped as in pressing(s) #1
 08    [a6e967a7] (10/25) Accurately ripped as in pressing(s) #1
 09    [247fd59b] (10/24) Accurately ripped as in pressing(s) #1
Offsetted by 51:
 01    [ed0a694b] (02/25) Accurately ripped as in pressing(s) #4
 02    [b719e5c3] (02/26) Accurately ripped as in pressing(s) #4
 03    [2bbf587c] (02/26) Accurately ripped as in pressing(s) #4
 04    [6d8a58a6] (02/25) Accurately ripped as in pressing(s) #4
 05    [ccaea6c2] (02/25) Accurately ripped as in pressing(s) #4
 06    [88d92bee] (02/25) Accurately ripped as in pressing(s) #4
 07    [16282b32] (02/26) Accurately ripped as in pressing(s) #4
 08    [3c250b8d] (02/25) Accurately ripped as in pressing(s) #4
 09    [d5575d93] (02/24) Partial match to pressing(s) #4 
Offsetted by 657:
 01    [a6e01c83] (09/25) Accurately ripped as in pressing(s) #2
 02    [d465c546] (09/26) Accurately ripped as in pressing(s) #2
 03    [d34c7529] (09/26) Accurately ripped as in pressing(s) #2
 04    [1ddd62f2] (09/25) Accurately ripped as in pressing(s) #2
 05    [0130ef32] (09/25) Accurately ripped as in pressing(s) #2
 06    [05c8ff34] (09/25) Accurately ripped as in pressing(s) #2
 07    [11c7481c] (09/26) Accurately ripped as in pressing(s) #2
 08    [de16e349] (09/25) Accurately ripped as in pressing(s) #2
 09    [19b2bc43] (09/24) Accurately ripped as in pressing(s) #2
Offsetted by 930:
 01    [fa97d3e7] (04/25) Accurately ripped as in pressing(s) #3
 02    [bf2b1dd9] (05/26) Accurately ripped as in pressing(s) #3
 03    [e69fb170] (05/26) Accurately ripped as in pressing(s) #3
 04    [58a8fb39] (04/25) Accurately ripped as in pressing(s) #3
 05    [0ad7e311] (04/25) Accurately ripped as in pressing(s) #3
 06    [59f322d1] (04/25) Accurately ripped as in pressing(s) #3
 07    [5e615667] (05/26) Accurately ripped as in pressing(s) #3
 08    [dece9beb] (04/25) Accurately ripped as in pressing(s) #3
 09    [9f2566eb] (03/24) Partial match to pressing(s) #3 

Track    [ CRC32  ]    [W/O NULL]    
 --    [8EABAAA6]    [35EAF7A9]    
 01    [AAF365AA]    [D8B6D46B]    
 02    [A5FB5392]    [95F59865]    
 03    [B3239AE3]    [AD32FF39]    
 04    [40BB5312]    [1682867B]    
 05    [C6E4854D]    [BC1DEFAC]    
 06    [3C96C5B8]    [08C20719]    
 07    [B224471B]    [ACBA60BF]    
 08    [7424A68B]    [26A14BA7]    
 09    [6AB8C336]    [20C653C5]


with some sorting we could have:

Quote
[Verification date: 03/05/2009 19:42:46]
[Disc ID: 000cdb40-00609af6-7209a309]
Pregap length 00:00:32.

Good Results:
Track   [ CRC   ] Status
01   [dd66af1f] (10/25) Accurately ripped as in pressing(s) #1
02   [0913cf12] (10/26) Accurately ripped as in pressing(s) #1
03   [0baae567] (10/26) Accurately ripped as in pressing(s) #1
04   [fa0725ba] (10/25) Accurately ripped as in pressing(s) #1
05   [e566df1c] (10/25) Accurately ripped as in pressing(s) #1
06   [fa882817] (10/25) Accurately ripped as in pressing(s) #1
07   [e8e6d151] (10/26) Accurately ripped as in pressing(s) #1
08   [a6e967a7] (10/25) Accurately ripped as in pressing(s) #1
09   [247fd59b] (10/24) Accurately ripped as in pressing(s) #1
Offsetted by 657:
01   [a6e01c83] (09/25) Accurately ripped as in pressing(s) #2
02   [d465c546] (09/26) Accurately ripped as in pressing(s) #2
03   [d34c7529] (09/26) Accurately ripped as in pressing(s) #2
04   [1ddd62f2] (09/25) Accurately ripped as in pressing(s) #2
05   [0130ef32] (09/25) Accurately ripped as in pressing(s) #2
06   [05c8ff34] (09/25) Accurately ripped as in pressing(s) #2
07   [11c7481c] (09/26) Accurately ripped as in pressing(s) #2
08   [de16e349] (09/25) Accurately ripped as in pressing(s) #2
09   [19b2bc43] (09/24) Accurately ripped as in pressing(s) #2

Bad results:
Offsetted by 51:
01   [ed0a694b] (02/25) Accurately ripped as in pressing(s) #4
02   [b719e5c3] (02/26) Accurately ripped as in pressing(s) #4
03   [2bbf587c] (02/26) Accurately ripped as in pressing(s) #4
04   [6d8a58a6] (02/25) Accurately ripped as in pressing(s) #4
05   [ccaea6c2] (02/25) Accurately ripped as in pressing(s) #4
06   [88d92bee] (02/25) Accurately ripped as in pressing(s) #4
07   [16282b32] (02/26) Accurately ripped as in pressing(s) #4
08   [3c250b8d] (02/25) Accurately ripped as in pressing(s) #4
09   [d5575d93] (02/24) Partial match to pressing(s) #4
Offsetted by 930:
01   [fa97d3e7] (04/25) Accurately ripped as in pressing(s) #3
02   [bf2b1dd9] (05/26) Accurately ripped as in pressing(s) #3
03   [e69fb170] (05/26) Accurately ripped as in pressing(s) #3
04   [58a8fb39] (04/25) Accurately ripped as in pressing(s) #3
05   [0ad7e311] (04/25) Accurately ripped as in pressing(s) #3
06   [59f322d1] (04/25) Accurately ripped as in pressing(s) #3
07   [5e615667] (05/26) Accurately ripped as in pressing(s) #3
08   [dece9beb] (04/25) Accurately ripped as in pressing(s) #3
09   [9f2566eb] (03/24) Partial match to pressing(s) #3

Track   [ CRC32  ]   [W/O NULL]   
--   [8EABAAA6]   [35EAF7A9]   
01   [AAF365AA]   [D8B6D46B]   
02   [A5FB5392]   [95F59865]   
03   [B3239AE3]   [AD32FF39]   
04   [40BB5312]   [1682867B]   
05   [C6E4854D]   [BC1DEFAC]   
06   [3C96C5B8]   [08C20719]   
07   [B224471B]   [ACBA60BF]   
08   [7424A68B]   [26A14BA7]   
09   [6AB8C336]   [20C653C5]


the more results there are the more it make the log easier to read, & if there are more then 10 results you are sure that the good results are displayed first, while actually it displays the ten first results no matter if it's noise.

As a sidenote I use .acc.txt as my extension personnaly, it's searchable & supported by default by winxp, short & instantly identifiable. I think you could put the cuetools version that generated the log within the log because if you don't know cuetools you may ask yourself where the text file come from & what does it means ... actually you have no clue specially if the extension is not default.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #390 –
A behavior that I don't understand:

If I use "append to finename"+New:

CDImage.cue
CDImage.flac
CDImage.log

I want it to output

CDImageNew.cue
CDImageNew.flac
CDImageNew.log

It tells me that files already exist, ask if I want to overwrite & the report tells me that source folder cannot be the same as output folder ... so I am forced to use "create a subdirectory"+New & then move my files which is slow & is a pain if you have a big collection. I don't understand because with New appended to filename, the path is not exactly the same anymore ... so it shouldn't try to overwrite CDImage.flac but just write a new CDImageNew.flac file in the same directory ? No ?

Is this working correctly, am I just thinking that "append to finename"+New is supposed to behave in a way that it is not intended to behave ?

If I only want to verify I can use "in source folder", I want the same thing (with a different filename indeed) when I write cue+flac+log, what option am I supposed to use ?

As a sidenote, CUETools V2.0.2 is nice, it has so many new features/fixes that I wanted that I have completely get rid of V1.9.5a now.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #391 –
Great tool!

Is there a way to write a CUE sheet for WAV files?

Example write:

FILE "01-whatever.wav" WAVE

Instead of

FILE "01-whatever.flac" WAVE

Even though the files are FLAC?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #392 –
Quote from: sauvage78 on
the user of the short log version will not be aware that there might be a problem with offset.

Not quite.
In fact, the output will be like

1 100/100 with offset(s) xxx
2 100/100 with offset(s) xxx
3 100/100 with offset(s) yyy
4 100/100 with offset(s) yyy

This contains all the important information about the rip accuracy.
So in my opinion, the short log is totally enough if you don't care about pressing numbers.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #393 –
The short log version doesn't display any info about offset if the offset is correct (which is normal) & unfortunately I only tested on albums with fixed offset so I wasn't seeing this information ... that's why I thought it would behave like this. Short logs seems more interesting now that I know offset are included, thks. My mistake, sorry.

Quote
[Verification date: 06/05/2009 15:35:28]
[Disc ID: 00097de0-0032a15c-5f094606]
Track    Status
01    (39/39) Accurately ripped with offset(s) 102
02    (39/39) Accurately ripped with offset(s) 102
03    (39/39) Accurately ripped with offset(s) 102
04    (39/39) Accurately ripped with offset(s) 102
05    (39/39) Accurately ripped with offset(s) 102
06    (39/39) Accurately ripped with offset(s) 102

Track   [ CRC32  ]   [W/O NULL]   [  LOG  ]
--   [AEEEF003]   [7F3E4567]    W/O NULL
01   [27B9F38A]   [0AD58D4D]   
02   [6E00EE2D]   [82FFFE8A]   
03   [B4BFD657]   [923B9A8A]   
04   [3B488384]   [A8A2EC20]   
05   [D4B897B3]   [20E88B93]   
06   [0355B0CE]   [823FD78A]   

01   [A9CA3FE6]   [BB8EF499]   
02   [75724575]   [F57105B8]   
03   [961C45E7]   [1DD2490E]   
04   [393435E8]   [A4E86A92]   
05   [46BC57DA]   [1B2F7913]   
06   [DF276EAF]   [D736A794]   
07   [B4FC6610]   [A85BEF3E]   
08   [BFF40CD3]   [98683549]   
09   [E3EBDE40]   [02A681CF]   
10   [65C27299]   [523716EE]   
11   [B584BC23]   [7E69281B]


Code: [Select]
[Verification date: 06/05/2009 15:34:26]
[Disc ID: 00097de0-0032a15c-5f094606]
Track    [ CRC    ] Status
 01    [9c413287] (00/39) No matches
 02    [2e7863a3] (00/39) No matches
 03    [5a8e2933] (00/39) No matches
 04    [b40d87ca] (00/39) No matches
 05    [f801ac04] (00/39) No matches
 06    [ac3716b6] (00/39) No matches
Offsetted by 102:
 01    [ba22a97f] (39/39) Accurately ripped as in pressing(s) #1
 02    [cd97987b] (39/39) Accurately ripped as in pressing(s) #1
 03    [7745e99d] (39/39) Accurately ripped as in pressing(s) #1
 04    [320444b2] (39/39) Accurately ripped as in pressing(s) #1
 05    [59153532] (39/39) Accurately ripped as in pressing(s) #1
 06    [c0875030] (39/39) Accurately ripped as in pressing(s) #1

Track    [ CRC32  ]    [W/O NULL]    [  LOG   ]
 --    [AEEEF003]    [7F3E4567]     W/O NULL 
 01    [27B9F38A]    [0AD58D4D]    
 02    [6E00EE2D]    [82FFFE8A]    
 03    [B4BFD657]    [923B9A8A]    
 04    [3B488384]    [A8A2EC20]    
 05    [D4B897B3]    [20E88B93]    
 06    [0355B0CE]    [823FD78A]


Below with offset already fixed, there is no info on offset displayed ... quite normal, but it misslead me at first as I am used to long logs with lot of offsets ...

Code: [Select]
[Verification date: 06/05/2009 15:29:34]
[Disc ID: 0013d426-00ad3f96-9c0b460b]
Track     Status
 01     (02/06) Accurately ripped
 02     (02/06) Accurately ripped
 03     (02/06) Accurately ripped
 04     (02/06) Accurately ripped
 05     (02/06) Accurately ripped
 06     (02/06) Accurately ripped
 07     (02/06) Accurately ripped
 08     (02/06) Accurately ripped
 09     (02/06) Accurately ripped
 10     (02/06) Accurately ripped
 11     (02/06) Accurately ripped

Track    [ CRC32  ]    [W/O NULL]    [  LOG   ]
 --    [70B05B5B]    [E22286CB]     W/O NULL

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #394 –
Quote from: sauvage78 on
Is this working correctly, am I just thinking that "append to finename"+New is supposed to behave in a way that it is not intended to behave ?

I tested this, and found out that "append to finename" works ok with single file images, but doesn't work in gaps appended mode, because track filenames don't get this suffix. I will have to think what to do about it. Does it work for you with single file images?
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #395 –
Well I dunno what more to say that I haven't already said, I don't know how it is supposed to work in your mind so I don't know if it's normal ... all I know is that I thought it would output CDImageNEW.flac in the same folder as the CDImage.flac input, but it doesn't, it wants to overwrite as if "NEW" wasn't appended to filename. It is not a new behavior, it has always worked like that even in pre-acuraterip cuetools version I think as I have always used create a subfolder "NEW" instead as it wasn't working for me, so it might very well be normal, but in case it is normal I don't understand what it is supposed to do, because it doesn't work as I understand it... the short awnser is no it doesnt work with CDImage for me. As far as I can recall it never did & I used cuetools since a long time now. It never annoyed me much because so far I only pass a few albums at the same time though cuetool, but now that I intend to pass my whole collection though accuraterip it is more annoying. It is MUCH easier to output CDIMageNEW in the same folder & then batch delete all files without NEW appended, than to switch between folders to cut/past/delete & replace old files from sourcefolder with new files from NEW subfolder.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #396 –
I see.

For single image rips this works if Advanced Settings->CUETools->Single format is set to %F. (forcing the flac filename to be equal to the cue sheet filename, so that it also gets that -new suffix).
Probably also works ok for file-per-track rips if track format includes %F, like %N. %F - %T.
I will see how to make it work in other situations.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #397 –
Well I just verified this setting, it seems %F is set by default, I think I never changed it & it never worked here ...

Edit: Maybe there should be a parameter before "NEW" in the "append to filename" box ? Maybe I have deleted something there ?

Note: I am running WinXP SP2 not Vista. In a couple of months when I will install Win7 RC I will see if it change anything ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #398 –
I didn't tell it because it was obvious for me but indeed, if you try to convert one format to another it works because the path is not the same, for example I can convert wavpack to flac:

Input:
CDImage.wv
CDImage.cue
CDImage.log

it will output:
CDImage.flac
CDImageNEW.cue
CDImageNEW.log

but even in this case you can notice that "NEW" is appended to .cue & .log but NOT to the audio file, which is why it doesn't work when converting flac to flac.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #399 –
Quote from: Gregory S. Chudov on
For single image rips this works if Advanced Settings->CUETools->Single format is set to %F. (forcing the flac filename to be equal to the cue sheet filename, so that it also gets that -new suffix).
Probably also works ok for file-per-track rips if track format includes %F, like %N. %F - %T.
I will see how to make it work in other situations.

Correction: "Keep original filenames" must be turned off for this to work.
CUETools 2.1.6