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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1100 –
Courier New should be present in every Windows install everywhere, unless it was removed.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1101 –
Sorry, but this is really bothering me. Is there anyway the listings in the Folder Browser can be sorted alphabetically. Right now all the folders are totally random. I'm running 2.0.9.

thanks.
Is your perfect hearing worth <$200? -- USE EAR PLUGS

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1102 –
Gregory, do you plan adding CRC comparison support for XLD rips/logs? Currently only works with EAC logs as far as I know.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1103 –
Does this CueTools 1.9.5 program work with EAC?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1104 –
Hello all,

I'm back with another question regarding the CUETools log.  Can someone tell me what "No match but offset" means in this context (Track 05)?  Is it accurately ripped?  Thanks for all of your help.

Sincerely,
David


Code: [Select]
[CUETools log; Date: 10/07/2010 12:49:16; Version: 2.0.9]
CD-Extra data track length 04:22:11.
[CTDB TOCID: 3mES5USX6AGJehYoh7T5Kfd2Ssc-] found.
        [ CTDBID ] Status
        [720aa726] (309/309) Differs in 292 samples @22:35:49,22:52:04-22:52:05,23:04:11-23:04:12,23:06:46-23:06:47
[AccurateRip ID: 00157488-00b8d3b2-9a0dc30c] found.
Track   [ CRC    ] Status
 01     [a38e2507] (200/330) Accurately ripped
 02     [bd900319] (200/332) Accurately ripped
 03     [b161a1b5] (200/330) Accurately ripped
 04     [14aa242f] (200/331) Accurately ripped
 05     [ced55a29] (200/330) No match but offset
 06     [80d04dda] (200/332) Accurately ripped
 07     [0c426ddf] (200/330) Accurately ripped
 08     [0481ddad] (200/331) Accurately ripped
 09     [4b90657c] (198/325) Accurately ripped
 10     [bf5d19d6] (200/331) Accurately ripped
 11     [a724b90c] (192/321) Accurately ripped

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1105 –
Hiya, i'm just trying out CueRipper. Works well, but it would be nice to see an 'options' button in the ripper program (not just in CueTools).

Also - for some reason, it stores the files with underscore instead of dash, e.g.: "01. Commander Tom _ Are Am Eye"

I can't find a setting that might change that. It's odd because i expect to see underscores instead of spaces, but not as well as.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1106 –
Quote from: patmcg on
Sorry, but this is really bothering me. Is there anyway the listings in the Folder Browser can be sorted alphabetically. Right now all the folders are totally random. I'm running 2.0.9.

thanks.


This sounds like the bug I reported and offered a patch for back in October. ([a href='index.php?act=findpost&pid=660745']See the post here[/a])

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1107 –
dalza:
Code: [Select]
[ CTDBID ] Status
[720aa726] (309/309) Differs in 292 samples @22:35:49,22:52:04-22:52:05,23:04:11-23:04:12,23:06:46-23:06:47


seems scratched around playing time 22-23min for CTDB

Code: [Select]
05     [ced55a29] (200/330) No match but offset


seems scratched at track 5 for AR

... seems like you can fix it with CTDB, (otherwise CTDB would return either "not found", "no match" or "could not verify"), try encode/repair, then if it matches you corrected it.

Edit:
You can listen at min 22-23min & see if you ear a glitch ... then, if you ear a glitch, you can compare with your EAC log ... that is a rewarding bittersweet experience ... if you ear a glitch that EAC didn't reported despite "perfect settings" for the drive, I can tell ya that you will trust . accurip more than .log after that !!!

If earable, you can even re-listen to the glitch before & after fixing it ... to fully convince yourself.
The only problem with repair that you should be aware, is that it looks like  sometimes you can fix a perfect but not yet in database rip X with the data of perfect rip Y already in database. It's not a big issue, it's just up to the end user to decide if it's worth fixing with all the positive/negative hints privided by AR/CTDB/LOG & listening test. Personnaly, so far I always fixed unless there was 2 entry in CTDB, one matching/one differing but in this case the clash is obvious. Also fixing first & last tracks is also dubtious sometimes because of excluded samples: sometimes if it differs at the very beginnings/ends, you know you might only have partially fixed it, but it's all you can do. Anyway very short glitches shouldn't be earable at these locations (likely in the middle of silence) (... well I hope).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1108 –
Sauvage78,

Thanks again for your detailed responses.  I don't have time now to sit down and test everything you suggested; I should have the time to play around tomorrow.  I'll let you know how it turns out.  Also, thanks for the explanation about pressings.


All the best,
David

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1109 –
Is CUERipper in beta mode? Because I can't get it to work with proxy settings that I apparently have to enter in CUETools. I can get the proxy working w/ cuetools, but not cueripper, so none of the values are inputed rendering the program cumbersome to use.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1110 –
Hello:

A disk was ripped with EAC using ideal settings (Secure, accurate stream, defeat cache, no C2, offset correction 6, etc.). EAC log reports no errors. This is a portion of the EAC log for Track 3:

Quote
Track  3

    Filename E:\media\SILVIO2\Musica\Genesis\Genesis - Foxtrot (1972) [FLAC]\03 - Get 'Em Out by Friday.wav

    Pre-gap length  0:00:00.45

    Peak level 98.4 %
    Track quality 100.0 %
    Test CRC E2DFE6D2
    Copy CRC E2DFE6D2
    Cannot be verified as accurate (confidence 26)  [7948005D], AccurateRip returned [D71AE96E]
    Copy OK


I use CueTools to check rip against database, AccurateRip reports "No match but offset" for track 3. Here is the contents of the .accurip file:

Quote
[CUETools log; Date: 17/07/2010 8:40:05 AM; Version: 2.0.9]
[CTDB TOCID: .SYxP91kRf6.ipY7pUtp21PODp0-] disk not present in database.
[AccurateRip ID: 000a14a2-0036c476-3b0c0806] found.
Track  [ CRC    ] Status
01    [3cfffc33] (25/27) Accurately ripped
02    [82c6b7c0] (26/28) Accurately ripped
03    [7948005d] (26/28) No match but offset
04    [4d911a40] (26/28) Accurately ripped
05    [9f17c4d3] (26/28) Accurately ripped
06    [77ebd650] (26/28) Accurately ripped
Offsetted by -1157:
01    [e6f0797a] (02/27) No match but offset
02    [ba46bcf6] (02/28) No match but offset
03    [6663b554] (02/28) No match but offset
04    [19540bea] (02/28) No match but offset
05    [fd80f75d] (02/28) No match but offset
06    [e6aa25e7] (02/28) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
--  100.0 [67C29617] [F8810DA6]
01  99.0 [C4BFC969] [577F842C]  CRC32
02  90.5 [4DF8C633] [102914B6]  CRC32
03  98.4 [E2DFE6D2] [ACA4C6A9]  CRC32
04  100.0 [BE75E706] [882A5B84]  CRC32
05  100.0 [DDC2ECB5] [C5104D03]  CRC32
06  100.0 [ECCA4D0E] [AFE3F62A]  CRC32


So, EAC says rip is okay, but AccurateRip reports "No match but offset" for track 3.
What does this mean?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1111 –
fadsplat:
Quote
What does this mean?


... nothing special other than what you explained, either EAC is wrong & you have a scratch or EAC is right, there is no scratch & you have a third pressing that is not yet in AR. The probability is low but yes EAC log can be wrong sometimes, specially with bad settings for the drive. I noticed it dozen of times & I was sure that there was a scratch as I listened to the files & heard it ...

Listen to the file & judge yourself, many glitches cannot be heard anyway, so if the goal is to encode it lossy ... in the end it doesn't matter ... if the goal is to keep it lossless, then re-check later both AR & CTDB, maybe you'll be able to fix it with CTDB someday.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1112 –
Quote
.. nothing special other than what you explained, either EAC is wrong & you have a scratch or EAC is right, there is no scratch & you have a third pressing that is not yet in AR


EAC did not spot the error. Cuetools is reporting that 1 offset finding frame (out of 30,000) matches the data in AccurateRip (but there is an error somewhere in the other 29999 frames) - such reporting is not really required as you can see that track 3 is from that data set "accurate (confidence 26) [7948005D]" because the confidence is the same for all the other tracks.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1113 –
Quote from: spoon on
Quote
.. nothing special other than what you explained, either EAC is wrong & you have a scratch or EAC is right, there is no scratch & you have a third pressing that is not yet in AR


EAC did not spot the error. Cuetools is reporting that 1 offset finding frame (out of 30,000) matches the data in AccurateRip (but there is an error somewhere in the other 29999 frames) - such reporting is not really required as you can see that track 3 is from that data set "accurate (confidence 26) [7948005D]" because the confidence is the same for all the other tracks.

sauvage78, spoon, thank you very much for your explanations. Do you know why EAC did not spot the error ? Is it because of the drive, EAC code or a combination of the two ? Cheers

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1114 –
Quote from: spoon on
such reporting is not really required as you can see that track 3 is from that data set "accurate (confidence 26) [7948005D]" because the confidence is the same for all the other tracks

Can you please elaborate on this? Do you mean that the track is essentially accurate? Do you mean that the music has been captured correctly, but that there is just some insignificant technical error? I'd like to know more about what "No match but offset" means in such a context, as I occasionally see rips like that and wonder if such rips are okay or not.

To answer someone else's question, I save only FLAC lossless, and I listen to lossless through a good home stereo. So, I do want good rips.

Thanks.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1115 –
I finally upgraded from 2.0.4a to 2.0.9 only to find more problems. ("clean" install, deleted old settings & program files)

  • For some odd reason, when starting CUETools, my firewall kicks in and says that "CUETools.exe" is trying to start "c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.exe" (Microsoft® Visual Studio® 2005 - Visual C# Command Line Compiler). It does this 8 times before CUETools window finally opens. And it happens EVERY time when starting CUETools. 2.0.4a never did this AFAIR (maybe the first time, can't remember..). I've ".NET Framework 2.0 SP2" & "Visual C++ 2008 runtime" installed. Recently I installed the ".NET Framework 4 Client Profile" from Windows updates (I've XP SP3), I wonder if that has something to do with this. Is it really required to run that csc.exe every time? CT starts very slowly.

  • When running "CUETools.exe" /verify somecuefile.cue" from cmdline, after the 8 csc.exe processes have ran, the "working..." CT window/dialog opens & a 9th csc.exe process wants to run. After that, CT quickly "scans" the files it finds from the cue, and I'm greeted with an "Error: Object reference not set to an instance of an object.". This is exactly the same error message as in my January bug report post (point 11 in the codebox), BUT this time I've enabled the "In source folder" under "Write AccurateRip log" setting! Setting that fixed the error in the 2.0.4a version but not in 2.0.9.

    [later] Aha, found the problem! It seems that you've done something to the profiles/settings system. In 2.0.4a it was only required to enable the "In source folder" setting (it was saved to default profile) to get rid of the error. In 2.0.9 you have to first open CT and change to "verify" profile and back to "default" (this creates the "profile-verify.txt" file) to get rid of the error message. Interesting is that with 2.0.9 you don't have to enable "In source folder" setting (in "verify" NOR in "default" profile settings) at all. So you have done something to the profiles/settings system after all (no mention of it in the changelog (I'm assuming that the 1st post of this topic lists all changes)). So, the 1st bug (in summary) of the point 11 in my January bug report:
    Quote
    1. "CUETools.exe /verify" doesn't work without settings.txt file and when "In source folder" setting is set to off.

    is turned into:
    Code: [Select]
    "CUETools.exe /verify" doesn't work without profile-verify.txt (and also most probably not without settings.txt)
    bug in 2.0.9.

  • 1 regression I noticed: "Settings -> AccurateRip -> Encode if verified", there is a lone check-box in the lower left corner of that "settings group" with no label. It had an "and zero offset" label in 2.0.4a.

  • The tooltip for "Use CUETools database" doesn't show when mouse is over the check-box and/or the CT DB icon. It is shown when mouse is everywhere else in that whole "settings group" area.

  • Why isn't CTDB used when running "/verify" or "ArCueDotNet.exe" from the cmdline? The "verify" profile in the main CT window has CTDB enabled. AFAIU, CTDB can be used to verify rips as well, yes? (haven't been closely following the latest changes/posts to this thread) Or is it impossible to have "Accurately ripped" in CTDB when AR DB has none? I.e. CTDB takes/saves "Accurately ripped" info only when AR DB has some ("CTDB now accepts rips with AR confidence >= 2")? Or/and, what is the difference of "Accurately ripped" by CTDB and "Accurately ripped" by AR DB? Wow, these terms/concepts/things really requires a lot of knowledge, not for a layman. 

  • You still haven't answered/acted to my loooong January bug report post (you don't have to, but you have indirectly promised many times.. I'm not going to bother/pressure you with this after this post. ). There was some plain question too (no fixing/coding required), e.g. points 14 (how to edit a script), 16 ("check for updates" doesn't seem to work, at least not in 2.0.4a it didn't.. [update] noticed something in 2.0.9, does it only activate when "starting/running" an action in the main CT window? Wouldn't it make more sense to check for updates right after starting the app?), 18 & 19.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1116 –
Quote from: sauvage78 on
you have a scratch

Is this your universal lingo for saying the disc was ripped with an error?  It's getting quite annoying since errors can be caused by more than just scratches.  Wouldn't you rather choose words that decrease the chances that you are providing false information?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1117 –
Quote from: prefab on
Do you know why EAC did not spot the error ?
It came up the same way twice, so EAC assumed it is good.  EAC cannot detect errors that are consistent, especially if you aren't allowing it to use C2 pointers.  Unfortunately, if you were to use C2 pointers and EAC identified the error, re-reads would probably still produce the same bad results since C2 pointers aren't used during re-reads.

Quote from: prefab on
Is it because of the drive, EAC code or a combination of the two ? Cheers
Likely a combination of the drive and the disc and shortcomings with EAC when it comes to these situations.

Quote from: fadsplat on
Quote from: spoon on
such reporting is not really required as you can see that track 3 is from that data set "accurate (confidence 26) [7948005D]" because the confidence is the same for all the other tracks
Can you please elaborate on this?
Spoon is trying to tell you that there is no reason to doubt the result since all submissions to the database for your pressing of this disc by others are correct.

Quote from: fadsplat on
Do you mean that the track is essentially accurate? Do you mean that the music has been captured correctly, but that there is just some insignificant technical error?
No, he means that your rip of the track in question is in error.

Quote from: fadsplat on
I'd like to know more about what "No match but offset" means in such a context, as I occasionally see rips like that and wonder if such rips are okay or not.
As spoon told you, the offset match is just a matching hash for only one frame of audio data (588 samples).  This offset hash is included in the AR record so that people can use that particular disc to determine their drive's read offset.  It is completely useless when it comes to determining if your track was ripped accurately.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1118 –
Thanks a lot for the info greynol. So this is a generic problem: using a different ripping program with the same drive and CD would produce the same result ?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1119 –
I wouldn't go so far as to say that, no.  You might actually get a different result by switching to burst mode, or changing EAC's secure mode options; you might even get an accurate rip this way.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1120 –
Quote
Is this your universal lingo for saying the disc has an error?

I'll try to say "error" next time the data differs...

Edit:
Also I must correct myself: because you fixed the offset while ripping & because the results in AR look consistent, it can hardly be a third pressing not yet in database. It's always possible but the chances are rather low: as far as I understund it would almost mean a rare exact re-pressing (same offset, 5/6 track matching) with error/difference on track 3. Not impossible but very unlikely. With confidence 26, you'd better bet on an error in your own rip as Spoon explained.

As I personnaly don't fix offset while ripping & fix later to "highest" in cuetools, I tend to always think that it can be a pressing not yet in database with a different offset when it doesn't match, because my own offset is always "floating". It's a kind of "Déformation professionnelle" ... sorry for missleading you.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1121 –
I reworded what I said after your quote to try to be more encompassing, since the error could be the result of a problem with the ripping program, the drive, or both.  IOW, it isn't always the disc's fault.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1122 –
Thanks so much for such an amazingly useful tool!  I have a feature request:

Would it be possible to implement an test for a silent HTOA:

If a silent HTOA exists, then convert without creating HTOA file (using pregap in the cuesheet instead).
If the HTOA is non-silent, then create an HTOA file.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1123 –
I have a few requests/suggestions and questions regarding CUEripper:

* Could you implement a summary after each rip telling what CUEripper did? Did the rips comply with AR confidence? Did it submit a CTDB entry etc.
* ...also please add options for e.g. ejection of media. Currently I have no idea when it's finished (and want to move on to next disc)
* Custom path and file-formatting?
* Repair bad rips with existing CTDB-correction entrys (on the fly that is, or at least afterwards without using cuetools?)

You say that CTDB can be submitted even when AR doesn't exist. That's probably great if multiple CTDB entrys exists for the same disc. However, I own a bunch of rare discs which nobody would probably ever put up in the DB, so How do I ensure that my rip was as perfect as it can be and sit in the CTDB? Can I rip the same disc with different drives on the same PC (and same IP)?
Can't wait for a HD-AAC encoder :P

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1124 –
Hi everybody, i have a probelm with  CUETools_2.0.9,

Yesterday he recognized the CD my drive, and naming songs and album name itself. Today, however, when I put the same disc he tells me that no connections, says "Title1, Title2" etc. What could be the problem, whether there was something in my computer?

Any ideas?

Thanks for help!