Re: CUETools versions 1.9.5 through 2.1.5 (current)

flac will exit with code 1 if there were any errors, including when the MD5 checksum doesn't match the audio.Can you run Action:Verify on the input without error? You can also test your input file for errors with the flac frontend or with the flac command-line flac.exe -t yourinputfile.flac

If it happens right away, it might be due to wrong command line parameters.

It does not happen right away.

Is it possible, using CUETools, to split the album-file right though the error, i.e. ignoring the error? That way, one can at least harvest all the tracks, to find the faulty one to possibly repair, and gain all all the good ones.

May I also ask if CUETools is capable of splitting single track 24-bit albums into multiple tracks from the cue file? If not, would you kindly please recommend an application that can do that? I do not want to downsample the files.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Is it possible, using CUETools, to split the album file right though the error, i.e. ignoring the error? That way, one can at least harvest all the tracks, to find the faulty one to possibly repair, and gain all all the good ones.

May I also ask if CUETools is capable of splitting single track 24-bit albums into multiple tracks from the cue file? If not, would you kindly please recommend an application that can do that? I do not want to downsample the files.

I have now found and deployed two different applications, both of which addressed the aforementioned points quite easily. The first was addressed using dbPoweramp, and the second with Foobar Convert.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

is there a way to NOT have the cue file copied over to the destination directory.

no, but its easy to remove them. However, NOTE: the second cue is not a copy, one is an image file cue and the other is a track files cue

Open Windows Explorer, and shift-rightclick on the base folder for your converted rips and click on "Open Command window here". Check the prompt to make sure window opened at the right place, then type "del /s *.cue" without the quotes, and press return. This will step down all your folders and subfolders below the one you started in and delete anything with a .cue extension. Take care you get it right, it won't ask if you're sure.

If you've been upgraded to Windows 10 Creators Edition, the "Open Command window here" option has been removed so you'll have to use PowerShell. Click "Open PowerShell window here". This uses a different syntax, type "get-childitem . -recurse -include *.cue | remove-item" without the quotes, check what you've typed is correct, and press return.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Couple small quality of life improvements I would suggest:1) the results are displayed as text, formatting and color scheme in accordance with the Windows theme. While perfectly readable, it's far from convenient. It would be really nice to have some form of color coding here: e.g. shades of green show that it's "accurately ripped" with ok-good-great confidence, yellow for low confidence, red for not accurately ripped). I usually open the .accurip file in a text editor, which is set up to parse and color code in that fashion, but it's not a perfect solution by far, and having CUETools itself color code the results would be very much appreciated.

2) Multiselect Browser: two things here:a) the directory tree shows way too many items by defaultExample: Let's say I've got two CDs in "F:\music\something\cd1" and "F:\music\something\cd2". I paste their parent directory path ("F:\music\something") in CUETools input field. I then click on the little green icon, opening the multiselect browser (this is how I typically go about it). If I want to change any of the (automatically set) check marks, I have to do a whole lot of scrolling before I get to the input folder. This is because the multiselect browser shows the following, in order from bottom to top:- Local DB (8 items),- all directories on user's Desktop (in my case about 20 items),- Windows "users\username" directory (1 item),- Windows "My Music" and "Public Music" directories (2 items),- Root of drives with drive letters higher than the one the actual input is on (in my case: Drive "I:" and "G:" are higher than "F:" so 2 items),- any directory in the root of the same drive that has the input files (so all directories in the root of "F:" - potentially many items), - any directory that has the same parent directory as the input (i.e. all directories in "F:\music\" -- many items)

I suggest auto-focusing the view (i.e. scrolling up automatically) to the item(s) that are automatically selected (check marks).

b) auto-selection of items in the above scenario should be configurable by file type. I don't see the need to auto-select the audio files themselves in addition to the cue sheet. The cue is all you want, usually.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

After I was told that Cuetools ignores Metadata after the REM in a CUE file, I decided to see if how GENRE, Part of a Compilation and Date are handled by Cuetools. I removed all of this information from a CD and then used Cuetools to encode from the .wav and .cue file to MP3 with all of the lookups in CTDB turned on.

If you look at the image (see attached) or link you will see the tags I listed: Genre, Year, Part of a Compilation, Composer and disc# tag are in MusicBrainz. These do not get output to the mp3s built with Cuetools. I dont know if there are dropped by CTDB or Cuetools or not available in the MusicBrainz, but they are in MusicBrainz.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

The developer may respond at some point after the holidays.Compilation & Composer are not supported by CUETools. Genre may be included as part of Tags on MusicBrainz but almost anything else can be stored there as well. The CTDB does not store genre from MusicBrainz. Year and discnumber are stored.You didn't provide the CTDB TOCID for your rip so I couldn't look it up.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

With default settings, a log file named *.accurip should be in the folder with your mp3 files.edit: this file can be read in a text editor such as notepad.If you converted a single rip, the log also appears in the window at the bottom of the GUI at the end of the process.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

With default settings, a log file named *.accurip should be in the folder with your mp3 files.edit: this file can be read in a text editor such as notepad.If you converted a single rip, the log also appears in the window at the bottom of the GUI at the end of the process.

Korth, Thanks for the XML. Looking at the xml, the musicbrainz entry;- does not include Genre, but freedb one does.- the year is in the xml- the release type is missing, in the musicbrainz entry this is where 'part of a compilation; (Compilation) is stored.- per track composers are not listed in the xml for the musicbrainz entry., (there are some for this release in musicbrainz- the disc number and total number of discs are in the xml.

I removed Cuetools and did a reinstall and then an encoding for this CD. The results were:

1. Year is correct2. Genre is missing - not in entry3. Part of compilation missing4. Composer per track missing

Re: CUETools versions 1.9.5 through 2.1.5 (current)

The database file is named LocalDB.xml.zA new file will be created (as needed) if you delete it.You'll find the file in \CUE ToolsIf you're running CUETools as portable \CUE Tools is a sub-folder otherwise the location is %appdata%\CUE Tools

Re: CUETools versions 1.9.5 through 2.1.5 (current)

A word of warning to those using CUETools 2.1.6 on linux (WINE): Do not use the libFLAC decoder! For some reason, it doesn't produce valid output. The audio checksum differs on every decoding attempt (verify/encode), and of course no accurateRip/CTDB match is possible.

Changing to cuetools decoder solves the issue. I wasted a day trying to figure out why all my windows PCs report 70/70 match while all my linux PCs report 0/70, using the exact same portable CUETools installation.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

A word of warning to those using CUETools 2.1.6 on linux (WINE): Do not use the libFLAC decoder! For some reason, it doesn't produce valid output. The audio checksum differs on every decoding attempt (verify/encode), and of course no accurateRip/CTDB match is possible.

Changing to cuetools decoder solves the issue. I wasted a day trying to figure out why all my windows PCs report 70/70 match while all my linux PCs report 0/70, using the exact same portable CUETools installation.

And how do you get it to work on wine? Last time I tried it didn't work. Which version of wine and .NET did you use?

Re: CUETools versions 1.9.5 through 2.1.5 (current)

- install wine (any version really, it's been working for me for several years, I'm currently using 3.0rc6)- install wine-mono (or whatever it is called on your distribution)- create a new win32 prefix (WINEARCH=win32)- install dotnet20sp2 using winetricks. It shows a couple of errors (i.e. "mono not installed", even though it is), but the process finishes fine- install vcrun2008- copy the CUETools folder to your prefix/drive_c/Program Files/- launch CUETools.exe with WINEPREFIX set to your prefix

It takes a while to launch, but it does launch fine. The only problem I had was that configuring it as I wanted crashed on some steps.What I did was configure it as I want on a windows machine, then copy the settings.txt to my linux one.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

1: Change the behavior of the offset textbox so that it doesn't fix invalid input as you type, but only after it loses focus. The reason is every time I try to insert negative offsets, either by first deleting the existing content, or selecting the content and start typing over it, starting with the [-] minus/dash character, the box replaces my input with a [0] and sets the cursor to the left.

3: This one is not really that important, but while I'm at it, I might as well ask for it: The offets seem to be ordered alphabetically in the report, instead of logically by numeric value, as would be intuitive in this case. Either making the sorting "smart" or zero-padding the offset values to help the "non-smart" sorting would work for me.