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 1925275 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 #1125 –
I'm a total n00b to CUETools. I've been reading the forums and CUETools seems to be the the splitter of choice when it comes to splitting a single FLAC album into separate tracks compared to Medieval CUE Splitter.

I am currently in drag'n drop mode and output has been grayed out. I want to save the tracks on my desktop but it's forcing me to use a template.

My other question is, after selecting FLAC for audio output what are the difference between libFLAC, FlaCuda, libFlake, and flake? Which is the best encoder to use?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1127 –
Quote from: Daffy on
Directly from the CUETools website:

CUETools FLAC Encoders Comparison


Thanks, where can I find information that explains the functions in settings, for example under Gaps Handling, what is Gaps Appended + HTOA? and what are the settings for separating a single FLAC album into individual tracks?

Action is set to: Encode (this is the settings that confuses me the most, I'm not trying to "encode" anything, I just want to split the album into separate tracks)

Mode is set to: Tracks

Audio Output is set to: Lossless, flac, libFLAC

Will these settings split any album with a proper cue sheet into individual tracks?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1128 –
This is the accurip result from a rip:

Code: [Select]
[CUETools log; Date: 31/07/2010 11:09:19 AM; Version: 2.0.9]
[CTDB TOCID: ywGA0VEGplUQBvpiAqaZhRuK5FM-] disk not present in database.
[AccurateRip ID: 0023db0a-0182babe-ba11940e] found.
Track   [ CRC    ] Status
 01     [ada7bd94] (0/0) No match
 02     [2187068f] (0/0) No match
 03     [1c7bdcd6] (0/0) No match
 04     [45ddad7c] (0/0) No match
 05     [120153c9] (0/1) No match
 06     [962ab792] (0/1) No match
 07     [f9d004d4] (0/1) No match
 08     [cbaeb8a7] (0/1) No match
 09     [3387a182] (0/1) No match
 10     [402570c9] (0/1) No match
 11     [ebd2ef5b] (0/0) No match
 12     [fda743a9] (0/0) No match
 13     [b0448498] (0/1) No match
 14     [65cbe62d] (0/1) No match
Offsetted by 664:
 01     [23b09bfc] (0/0) No match
 02     [a8c84027] (0/0) No match
 03     [54fe11ae] (0/0) No match
 04     [f071096c] (0/0) No match
 05     [ebebacb1] (1/1) Accurately ripped
 06     [f975bc22] (1/1) Accurately ripped
 07     [812b435c] (1/1) Accurately ripped
 08     [49310417] (1/1) Accurately ripped
 09     [675d017a] (1/1) Accurately ripped
 10     [591052f9] (1/1) Accurately ripped
 11     [67191463] (0/0) No match
 12     [4aac27b1] (0/0) No match
 13     [4cc10158] (1/1) Accurately ripped
 14     [8b5b041b] (1/1) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --   98.1 [0369921D] [F11AB304]
 01   98.1 [9E02E5DB] [326EE1AA]
 02   94.2 [11D0F840] [871A3913]
 03   95.9 [C91A2A23] [2C56EA92]
 04   95.6 [3750EE7A] [82E55CDB]
 05   95.4 [4439B63A] [A0AE2395]
 06   95.4 [37A5E994] [A15EC1C7]
 07   95.7 [CDD32218] [CDC0F7DF]
 08   97.0 [B4DC74CF] [0BF56714]
 09   97.2 [D3E915D3] [36FABDE8]
 10   96.7 [FA06A049] [D47E58CB]
 11   97.3 [29030D07] [196EF2D6]
 12   96.3 [0C17EEF2] [D0205E7D]
 13   96.8 [A6A6FE36] [601D5B37]
 14   96.8 [01F4968F] [1262C656]

Does this mean the rip is definitely not accurate, or is it simply that this particular disk/pressing may not be in the AccurateRip database?

Thanks.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1129 –
fadsplat:
Hi.
Not yet fully in AR database. Nothing bad to worry about so far.
See Ya.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1130 –
I see the term "no match" but I don't see the term "not accurate".

It is pretty clear that there is no data available for tracks 1-4, 11 and 12.  For the other tracks you got a match, so it should be readily obvious once you consider what X/Y means (X is the number of people who submitted that particular checksum out of Y total checksum submissions for that track), that the tracks without a match the result is inconclusive.
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1131 –
CUETools is constantly giving me an array index out of bound exception when trying to process any cue file ...
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1132 –
Open the cue sheet with notepad & post it, from my experience this kind of things happens when:
1-INDEX 00 is frozen. (Not chronological order)
2-INDEX 00 is after the end of the whole CD range.
3-The cue was produced when splitting with "Medieval Cue Splitter".

It's pure speculation but the two first may be related to bad gap/index detection either due to CD protection or broken software/hardware.

Edit: If you can, post a CDImage type cue sheet, because I am only used to this displaying.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1133 –
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.
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1134 –
Oh... I am of no help sorry ... I never used MusicBrainz. Sound weird.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1135 –
Indeed it does. 
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1136 –
Quote from: sauvage78 on
Not yet fully in AR database. Nothing bad to worry about so far.

Quote from: greynol on
I see the term "no match" but I don't see the term "not accurate".

It is pretty clear that there is no data available for tracks 1-4, 11 and 12.  For the other tracks you got a match, so it should be readily obvious once you consider what X/Y means (X is the number of people who submitted that particular checksum out of Y total checksum submissions for that track), that the tracks without a match the result is inconclusive.


That's what I thought. And yet, the single line summary that appears in CueTools says:
Quote
Off White.cue: AR: offset 664, rip not accurate (0/1), CTDB: disk not present in database.

Why does CueTools say "not accurate", when examining the .accurip report suggests more that there is just not enough data yet and that this disk/pressing is not yet in the database?


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1137 –
fadsplat:
Quote
Why does CueTools say "not accurate"


Because Cuetools is a machine & because AR works more on positive matches than on negative missmatches, which means that AR is made to tell you if your rip is perfect or not. When it is not it doesn't tell you why. It just tell you that it doesn't match.

If CT/AR returns a perfect results then there is a near 100% probability that it is right.
If CT/AR returns a non perfect results, CT/AR make no assumption on the files & leaves the final verdict to the end user's judgement.

"rip not accurate" may be missleading at first. But it is right, the rip is "not accurate according to accuraterip database" which in your case means "not accurate yet because the database is incomplete".

Reading "rip not accurate" in a CT's log is not as definitive as reading "There were errors" in an EAC's secure log.

In fact reading CT/AR logs is the reverse of reading EAC secure logs:
- usually CT/AR logs are near 100% reliable when it tells you that there is no errors (all tracks matches) & not 100% reliable when something doesn't match (The database may be incomplete)
[Edit: Well AR is reliable but CT's conclusion is not)
- usually EAC secure logs are near 100% reliable when there is an error, but not 100% reliable when there is no error. (there can be unnoticed error, specially with bad settings for the drive)

The irony here is that some people read the exact opposite, they think an EAC secure log with no error is perfect & start whinning when CT/AR returns "rip not accurate".

"rip not accurate" in CT/AR doesn't necessary mean "rip inaccurate". Both are not synonymous in the context of CT/AR logs.

Cuetools cannot return a personnalized anwser for each rip. When the answer is not clear, it means that it can only give you hints that you have to interpret.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1138 –
Thank you. That explanation is very helpful.

I guess the the problem is the terminology that CueTools uses. When it says "rip not accurate", that is a clear statement that the rip is bad, and yet this statement may be wrong.

It would be better if CueTools reported something like "rip does not match" in such cases.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1139 –
Does the latest download of CUETools typically include a Readme file that covers installation proceedure of the program?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1140 –
Quote from: sauvage78 on
"rip not accurate" may be missleading at first. But it is right, the rip is "not accurate according to accuraterip database" which in your case means "not accurate yet because the database is incomplete".

It is not right nor are any of these interpretations that you're offering right.  It's also not "may be" misleading "at first," it is completely misleading, especially in the situation presented by fadsplat.

There is absolutely no reason whatsoever why the wording need be the way that it is.  Have a look at the messages presented in an EAC log regarding AR results if you have any doubts.

IMO, the rest of your answer was spot-on including the part about EAC's log only being "almost" perfect when it says there are errors.  It's quite possible for EAC to tell you there was an error even though the track was indeed ripped accurately.  This will usually happen when the most consistent data is accurate data but not consistent enough for EAC not to report an error (fewer than eight matches out of every set of sixteen re-reads).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1141 –
Quote from: greynol on
EAC's log only being "almost" perfect when it says there are errors.  It's quite possible for EAC to tell you there was an error even though the track was indeed ripped accurately.  This will usually happen when the most consistent data is accurate data but not consistent enough for EAC not to report an error (fewer than eight matches out of every set of sixteen re-reads).

The reverse situation also occurs: EAC reports "no errors", even though there are CRC mis-matches between Test and Copy on some tracks.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1142 –
Quote from: fadsplat on
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. The "Copy" part of the ripping is the only deciding factor when EAC decides whether the rip was good or not.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1143 –
I stand on my position, I refrained answering to not enter in an endless debate with Greynol. I know that in the end we will both agree even if he may actually be convinced that we won't. I agree with the rare specials cases mentioned, I used "usually" or "near" (perfect) as I had those exceptions in mind ... & also as I knew Greynol wouldn't agree because it was not comprehensive in a scientific way. Those were just general guidelines on how to read a log, nevermind ... Furthermore I happily agree that Greynol's knowledge on audio is higher than mine ... so he doesn't even have to endlessly prove this point

More seriously, it's just that Greynol seems to have an ethic problem with telling a newbie a biased truth in order to save time, personnaly if I consider that my answer is right ~95% of time... I don't.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1144 –
Ethic problem?  Have you been smoking something?  Do you know what the word ethic even means?

What's this "biased truth" bs?  How has anything that I've said to fadsplat been biased?  Make that two words about which you should consult an English dictionary.

You sure have a funny way about communicating for someone who doesn't want to enter into a debate.

The guy wanted to know why his rip was deemed inaccurate and the answer is simple, the wording is wrong.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1145 –
Quote from: Akkurat on
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.

Quote from: Akkurat on
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).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1147 –
Download CueTools, and if necessary .NET Framework 2 SP2 and Visual C++ 2008 Runtime, and run the executables. Voila: installation begins.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1148 –
Quote from: dv1989 on
Download CueTools, and if necessary .NET Framework 2 SP2 and Visual C++ 2008 Runtime, and run the executables. Voila: installation begins.


By executable you mean an install.exe?  If so, no such thing in the recent CUETools download I just unzipped.  Did you ever see a README file for CUETools?  I have read posts that I believe refer to it as also having some operating instructions.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1149 –
Oh, sorry for the mistake. Now that you mention it, I remember that, having checked the archive for a readme yesterday in response to your question. Terrible memory.

In that case, installation is as simple as unzipping everything to a directory of your choice, then running the main executable from there.

There is a CUETools Documentation link on Gregory's official CUETools site. I don't know if that is sufficient for you.
Furthermore, the old author Moitah's page suggests users "See the ReadMe.txt file included with the binary for help with the options." Perhaps that may be of some use (albeit outdated).