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 1911675 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 #450 –
Quote from: tuxman on
Well, in this particular case it is obvious to me. 


Why is it obvious that it is the ape decoding ? The problem can also lie in de ogg encoding.
I also converted several ape/cue images to flac files. Didn't encounter any problems (yet)
But maybe I need to listen more closely.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #451 –
It works forks for me.

If you use 'Encode and verify mode', what does the final log say?
If it says something like this:
--   [DB0F2EE1]   [8EA1A6C5]     CRC32
i.e. CRCs match the log file, then the problem is not with ape decoder,
but with external ogg encoder. Can you try a different encoder?
CUETools 2.1.6
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #452 –
Ok, I just recently found CUETools and it's great! I have tested the prog (version 2.0.2a) and I read the whole thread last weekend, BUT I still got tons of questions/suggestions/etc., I thought about your sanity Gregory and I will not post all of them in one post (some of the problems/questions include logs, who have guessed).
  • GUI beautification(?): CUETools started with /verify and filename -> window has no "proper" title bar and shows "default" VS icon in the taskbar.
  • Could you add "set read-only attribute to AR log file" feature in the options?
  • Bug/problem: "Status Report" window after AR verification (started from the main app window) disappears when changing to another virtual desktop and back (using MS Virtual Desktop Manager). After that the "Go" button gets disabled when selecting another input source from the main screen.
  • I started using ArCueDotNet.exe in my custom REACT script for "Check CD for possible different pressing with CUETools if there's no AccurateRip verification in EAC" and it works really nicely. I had one big problem what made me do tests for hours; in the end, it seems that ArCueDotNet.exe "locks" all .log files in the directory when starting/doing the verification. The verification failed always with an error message (something like: "file can't be accessed/file is in use") when I tried to redirect the output to a "<artist> - <album>.cuetools.log" file (ArCueDotNet.exe" "blahblah.cue"> "blahblah.cuetools.log"). The file didn't exist before calling the ArCueDotNet.exe command. The confusing thing was that the error message was redirected to the .log file. It was early morning when I coded that and I was very tired but finally I understood to try changing the file extension temporarily to .txt and it started to work. Is it necessary to "lock" all .log files (even non-existant ones(?)) in the directory when starting/running ArCueDotNet.exe?
  • I just accidentally found a HDCD reference in one of my CDs when running CUETools AR verification for CDs that had no AR results when ripped. I found "HDCD: peak extend: none, transient filter: none, gain: none" line in the CUETools AR log, what does it really mean when all are "none"? Is it a HDCD or not? The CD itself (CD playing surface/label, booklet) has no mention of this CD being a HDCD. I did the required searching from net but I couldn't find any good information about this. Does CUETools detect this from the audio files or from the AR database?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #453 –
Quote from: Akkurat on
Is it necessary to "lock" all .log files (even non-existant ones(?)) in the directory when starting/running ArCueDotNet.exe?

The file at this moment exists and is locked by windows because of the output redirection.
CUETools doesn't lock the file. It only tries to open it, because it might be a EAC log file, which CUETools uses.
The point is, CUETools shouldn't abort on such error. I''ll probably fix it in the next version.

Quote from: Akkurat on
HDCD: peak extend: none, transient filter: none, gain: none

This is most probably a false alert. This happenes sometimes, when
a random audio data looks like HDCD encoding by coincidence.
A real HDCD would have at least one of the three features turned on.

Thanks for other reports/suggestions as well, i will look into this someday
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #454 –
CUETools 2.0.3 is out.

I was pretty busy lately, so this release is not very different from the previous,
most of the stuff that i promissed to fix will be fixed only in 2.0.4.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #455 –
Some strings are missing in SVN. Like "Check for updates". 
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #456 –
Just commited them. Should be there by now.

Sorry, i messed up many strings this time. Again
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #457 –
I see. 
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #458 –
Some are still missing, like "Drag the files here".   
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #459 –
Uh oh 
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #460 –
I wrote a brief manual on new output path template syntax: http://www.cuetools.net/doku.php/cuetools:template
Those are wiki pages, so anyone can contribute. Feel free to join the CUETools documentation project.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #461 –
Quote from: Gregory S. Chudov on
This is most probably a false alert. This happenes sometimes, when
a random audio data looks like HDCD encoding by coincidence.
A real HDCD would have at least one of the three features turned on.

Thanks for other reports/suggestions as well, i will look into this someday


I do have some HDCDs which behave similarly though.

E.g. The Bee Gees - Their Greatest Hits The Record. They are listed as HDCD on the back cover and on the CD itself, but when I run the file through Sox or CUETools, HDCD encoding is detected but all the variables say "none".

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #462 –
Hi!

Can U pls handle the resolution issue. It's really annoying:




THNX!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #463 –
Large fonts?
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #464 –
Quote from: Boiled Beans on
E.g. The Bee Gees - Their Greatest Hits The Record. They are listed as HDCD on the back cover and on the CD itself, but when I run the file through Sox or CUETools, HDCD encoding is detected but all the variables say "none".

If you uncheck 'Settings->HDCD->Stop looking after 750 frames', more data will be analyzed. On the downside, this leads to more false alerts.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #466 –
Thanks for the previous answers. Here's the 2nd part of my questions/etc.

I'd like to verify something, if I get a log like below (if possible at all), is my rip really accurate? (log is a mock-up) I.e. it doesn't matter what offsets the verifications come from as long as all tracks are accurately ripped? Does it only mean that TRACKS were accurately ripped? Not that my PRESSING of the album was accurately ripped? Have I understood correctly that AR DB doesn't care about pressings? Or can I only be confident when all tracks WITHIN one offset are accurately ripped?

Code: [Select]
Track	[ CRC    ] Status
 01	[xxxxxxxx] (03/03) Accurately ripped as in pressing(s) #2
 02	[xxxxxxxx] (03/03) Accurately ripped as in pressing(s) #2
 03	[xxxxxxxx] (00/03) No matches
 04	[xxxxxxxx] (00/03) No matches
 05	[xxxxxxxx] (03/03) Accurately ripped as in pressing(s) #2
Offsetted by 12:
 01	[xxxxxxxx] (00/03) No matches
 02	[xxxxxxxx] (00/03) No matches
 03	[xxxxxxxx] (03/03) Accurately ripped as in pressing(s) #1
 04	[xxxxxxxx] (00/03) No matches
 05	[xxxxxxxx] (00/03) No matches
Offsetted by 280:
 01	[xxxxxxxx] (00/03) No matches
 02	[xxxxxxxx] (00/03) No matches
 03	[xxxxxxxx] (00/03) No matches
 04	[xxxxxxxx] (03/03) Accurately ripped as in pressing(s) #3
 05	[xxxxxxxx] (00/03) No matches

I'd like to +100 to the following suggestions:

1) Remove the pressing numbers from the logs! Those just confuse people.

2) Make a "summary" of the verified tracks.. IF there's an accurately ripped matches for ALL tracks WITHIN one offset, write something like: "Disc accurately ripped."? Otherwise, I don't know, can one say that it was NOT 100% accurately ripped? Suggestions?

3) I like the 2 suggestions in this post: http://www.hydrogenaudio.org/forums/index....st&p=631889
   3.1) Include the version of CUETools in the log.
   3.2) Quoting sauvage78: "grouping good results with good results in front & bad results with bad results in the bottom" would be really nice.. especially dividing the results with distinct "Good Results:" and "Bad results:" headers! Would be more easier to understand (and perhaps accept) the results..?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #467 –
Quick new additional question:

Is it possible to use the "only if found" script with "CUETools.exe [/verify] "filename"" or with "ArCueDotNet.exe"? If not, please consider adding it.

EDIT:

The "hide browser" is very nice but there's one small annoyance; if one stretches the window horizontally to see the browser more nicely and then clicks the hide button and browser button again, the previous stretched horizontal window size is not remembered.

P.S. The "where is their vote?" is nice but consider adding a link to somewhere explaining it. Also you might like to think again about getting political with your software, it's your choice of course and I do like it very much, but e.g. check this forum the owner of Notepad++ had to set up because the anger messages of Notepad++ "Boycott Beijing 2008" "advert" started to fill the normal forums.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #468 –
Hi, Gregory.

Is the source project available. I'm interested in GUI only.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #469 –
Quote from: Akkurat on
Thanks for the previous answers. Here's the 2nd part of my questions/etc.

I'd like to verify something, if I get a log like below (if possible at all), is my rip really accurate? (log is a mock-up) I.e. it doesn't matter what offsets the verifications come from as long as all tracks are accurately ripped? Does it only mean that TRACKS were accurately ripped? Not that my PRESSING of the album was accurately ripped? Have I understood correctly that AR DB doesn't care about pressings? Or can I only be confident when all tracks WITHIN one offset are accurately ripped?

I'd like to +100 to the following suggestions:

1) Remove the pressing numbers from the logs! Those just confuse people.

2) Make a "summary" of the verified tracks.. IF there's an accurately ripped matches for ALL tracks WITHIN one offset, write something like: "Disc accurately ripped."? Otherwise, I don't know, can one say that it was NOT 100% accurately ripped? Suggestions?

3) I like the 2 suggestions in this post: http://www.hydrogenaudio.org/forums/index....st&p=631889
   3.1) Include the version of CUETools in the log.
   3.2) Quoting sauvage78: "grouping good results with good results in front & bad results with bad results in the bottom" would be really nice.. especially dividing the results with distinct "Good Results:" and "Bad results:" headers! Would be more easier to understand (and perhaps accept) the results..?

I did experience something like this in a few of my CDs, where the pressings are different.

Code: [Select]
Track	[ CRC    ] Status
 01	[xxxxxxxx] (03/04) Accurately ripped as in pressing(s) #2
 02	[xxxxxxxx] (03/04) Accurately ripped as in pressing(s) #2
 03	[xxxxxxxx] (03/04) Accurately ripped as in pressing(s) #1
 04	[xxxxxxxx] (03/04) Accurately ripped as in pressing(s) #1
 05	[xxxxxxxx] (03/04) Accurately ripped as in pressing(s) #2

Offsetted by 12:
 01	[xxxxxxxx] (01/04) Accurately ripped as in pressing(s) #1
 02	[xxxxxxxx] (01/04) Accurately ripped as in pressing(s) #1
 03	[xxxxxxxx] (01/04) Accurately ripped as in pressing(s) #2
 04	[xxxxxxxx] (01/04) Accurately ripped as in pressing(s) #2
 05	[xxxxxxxx] (01/04) Accurately ripped as in pressing(s) #1

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #470 –
Quote from: Akkurat on
I'd like to verify something, if I get a log like below (if possible at all), is my rip really accurate?

A log like this is almost impossible.
Yes, AccurateRip collects data on per-track basis.
Different tracks might verify against different offsets,
if there was a certain number inserted/deleted in between.
I saw such cases, but it results in some track inbetween
(where this insertion/deletion took place) reported as inaccurate.

Quote from: Akkurat on
1) Remove the pressing numbers from the logs! Those just confuse people.
...

I strongly recomment to turn off the 'Verbose' log file option. The log would be much more simple.
The full log with 'pressings' etc is not very helpfull except for people who are really interested in
what's going on inside the database.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #471 –
Quote from: Akkurat on
Is it possible to use the "only if found" script with "CUETools.exe [/verify] "filename"" or with "ArCueDotNet.exe"? If not, please consider adding it.

I will.

Quote from: Akkurat on
The "hide browser" is very nice but there's one small annoyance; if one stretches the window horizontally to see the browser more nicely and then clicks the hide button and browser button again, the previous stretched horizontal window size is not remembered.

Will be fixed in the next version.

Quote from: Akkurat on
P.S. The "where is their vote?" is nice but consider adding a link to somewhere explaining it. Also you might like to think again about getting political with your software, it's your choice of course and I do like it very much, but e.g. check this forum the owner of Notepad++ had to set up because the anger messages of Notepad++ "Boycott Beijing 2008" "advert" started to fill the normal forums.

People who don't know what this is about can google it out in one second, if they are curious enough. Don't want to waste more pixels with a link
As for those who might not like it, there's a simple solution - turn off the check for updates and delete motd.jpg from AppData\Roaming\CUETools folder.
This place in the UI will be normally used for update notification banner.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #472 –
Quote from: denisk1981 on
Hi, Gregory.

Is the source project available. I'm interested in GUI only.


There is link to source code repository at the top of this thread.
It's http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/

By the way, i think i fixed the problem with GUI for nonstandard fonts.
Try this one please: [attachment=5200:CUETools...0.3a_x86.rar]
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #473 –
Quote from: Gregory S. Chudov on
Quote from: denisk1981 on
Hi, Gregory.

Is the source project available. I'm interested in GUI only.


There is link to source code repository at the top of this thread.
It's http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/

By the way, i think i fixed the problem with GUI for nonstandard fonts.
Try this one please: [attachment=5200:CUETools...0.3a_x86.rar]



THNX. It's perfect now!!!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #474 –
Thanks again for the answers, though you missed this one: "Or can I only be confident [that my pressing of the CD is ok] when all tracks WITHIN one offset are accurately ripped?"

Quote from: Gregory S. Chudov on
I strongly recomment to turn off the 'Verbose' log file option. The log would be much more simple. The full log with 'pressings' etc is not very helpfull except for people who are really interested in what's going on inside the database.

Well at the moment I don't want to use the non-verbose log because IMHO there's a big problem with it, which I'll demonstrate in my next post. I'm sorry but what purpose does the "as in pressing(s) #x" information serve? Is it in any way usable? IMHO, and as some others have said, it's just confusing people, it doesn't serve a purpose. And, IF I've understood correctly, the offsets represents pressings already, then why distract the user from that by outputting these non-relevant "as in pressing(s) #x" texts? Of course it's your decision but please consider making the log more understandable.

Quote from: Gregory S. Chudov on
Don't want to waste more pixels with a link ... This place in the UI will be normally used for update notification banner.

I meant that can't you put a link to that image, not a separate text link.. does the update banner have a link to download site?

P.S. Clicking the text links in the about dialog does absolutely nothing in my PC.