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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1850
CUERipper: There still appears to be a problem with EAC style rip log in Paranoid mode.
Just tested Burst mode. Everything was fine. Switched to Paranoid mode, rip was fine, rip log says Burst mode. Even the wav file locations show the folder for previous Burst rip. Restarted CUERipper. Switched to Paranoid mode, rip was fine, rip log says Secure mode. File locations correct.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1851
I personally find this an overkill, but that's what many people are used to. Personally, i just use default settings (secure mode, no test&copy),...

Thanks a lot, that's exactly the kind of precisions I was waiting for. This does clarify the process and the changes made. Now this question's been figured out, I can resume ripping my CDs without wondering   

Cheers

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1852
Am I the only one who has encountered a problem with the CUERipper 2.1.4 'Test & Copy' mode? I'm unable to use it. Whenever I have the box checked I get an Exception error: "Gap Detection Failed." It does this with every disc I have tried, using two different drives. CUERipper works perfectly fine if I do not check the 'Test & Copy' box.

I can't think of any logical reason why choosing 'Test & Copy' would cause gap detection to fail, but it does.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1853
Am I the only one who has encountered a problem with the CUERipper 2.1.4 'Test & Copy' mode? I'm unable to use it. Whenever I have the box checked I get an Exception error: "Gap Detection Failed." It does this with every disc I have tried, using two different drives. CUERipper works perfectly fine if I do not check the 'Test & Copy' box.

I can't think of any logical reason why choosing 'Test & Copy' would cause gap detection to fail, but it does.


'Test & Copy' works just fine here. Have made like 4-5 rips with it.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1854
What about getting a 'Medium' option for 'Album art search'. There is only Small and Large available now.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1855
CUERipper is not using Google to search images. It uses artwork from Musicbrainz & Discogs, and there are only full size pictures and thumbnails in those databases. However i will consider implementing custom image sizes by downloading full size images, than shrinking them to desired size.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1856
CUERipper is not using Google to search images. It uses artwork from Musicbrainz & Discogs, and there are only full size pictures and thumbnails in those databases. However i will consider implementing custom image sizes by downloading full size images, than shrinking them to desired size.


Thnx for the reply/info Gregory.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1857
Just noticed that the embedded cover art gets added twice.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1858
'Test & Copy' works just fine here. Have made like 4-5 rips with it.


Very strange problem. I still can't figure out why it's giving me that Exception error. Test & Copy is merely a switch that tells CUERipper to start the ripping process over again after the first cycle is complete. There doesn't seem to be any reason why it would make a difference whether or not I have the switch engaged. Odd.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1859
1. I thought that the confidence results are only based on actual rips, but after I verify an rip not present in CTDB with CUETools, next time will have confidence 1. Can you please explain?

2. I got quite a few errors like this:

Code: [Select]
.\Joss Stone - 2005-07-08 - Mind Body & Soul\Joss Stone - 2005-07-08 - Mind Body & Soul.cue: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index.


And the accurip log reads:

Code: [Select]
[CUETools log; Date: 4/25/2012 8:54:01 PM; Version: 2.1.4]
[CTDB TOCID: YDhmfif05xgrPtNh8.pN4sFhCp8-] found.
        [ CTDBID ] Status
        [eb466f8b] (25/48) Accurately ripped
        [0dd4fda1] (01/48) No match


Is it accurate or not? And why is the log looking like that?

Edit: that's the whole log.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1860
1. I haven't disabled CUETools submissions yet, so for CDs that are not yet present in the database any rip with AR confidence >= 2 can be submitted, and will have CTDB confidence == 1 (AR confidence is ignored, but CTDB confidence cannot be zero). Only results with CTDB confidence >= 2 can be considered reliable, which means that CTDB no longer trusts AR, but AR-verified rips need only one independent rip to be confirmed and receive CTDB confidence == 2.

2. Thanks, found a bug in the code that produces detailed CTDB log. This happens when CD has a data track. My advice is turn detailed CTDB log off until i make a hotfix. This option is off by default, so most users don't need to worry.
CUETools 2.1.6

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1861
Code: [Select]
 Index was out of range. Must be non-negative and less than the size of the collection.


So this means that the CD has a data track, it could be a perfectly good rip, but it cannot be verified. Is that correct?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1862
Yep. It is perfectly verified. "(25/48) Accurately ripped". Just turn off the detailed option of the log, the standard one is easier to read.
Also refer to this: http://www.cuetools.net/wiki/CUETools_log
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1863
Yep. It is perfectly verified. "(25/48) Accurately ripped". Just turn off the detailed option of the log, the standard one is easier to read.
Also refer to this: http://www.cuetools.net/wiki/CUETools_log


Now  I got it. I only have that message and the weird log when I use the detailed option.


I want to thank you for all your work you put in the development of CT, I really appreciate it. It is one of the few applications I install the first day I have a new OS.

Thank you.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1864
Hey folks,

I have two questions.

1. Is there any way to make CUETools transfer tags 1:1 on conversion? Whenever I convert files, the full value for %date& is truncated. For instance "1995-11-20" is only "1995" after conversion.

2. Can I somehow configure CUETools to always fix offsets to the result with the highest confidence?

Thanks!

:-)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1865
Quote
1. Is there any way to make CUETools transfer tags 1:1 on conversion? Whenever I convert files, the full value for %date& is truncated. For instance "1995-11-20" is only "1995" after conversion.
CUETools is getting that info from your cue file or online database. Does your cue file have 1995-11-20?
Quote
2. Can I somehow configure CUETools to always fix offsets to the result with the highest confidence?
Untick 'to nearest' in Advanced Options on the AccurateRip tab.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1866
2. Can I somehow configure CUETools to always fix offsets to the result with the highest confidence?


Why would anyone want to do this? This whole process is to make an accurate copy of your CD. So, you want to go through the trouble of creating an accurate copy and in the final step convert it into an inaccurate copy?
Glass half full!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1867
CUETools is getting that info from your cue file or online database. Does your cue file have 1995-11-20?

Yes. I have all my music stored as FLAC images where the CUE sheets are embedded though.
The embedded CUE sheet has the value as shown here: "REM DATE 1995-11-20".
I've made some tests with different settings in the tagging menu.
However either the date is truncated, or it is copied completely - but then the disc number info is missing.

Untick 'to nearest' in Advanced Options on the AccurateRip tab.

Thanks! :-)


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1868
The embedded CUE sheet has the value as shown here: "REM DATE 1995-11-20".
OK that helps a little. Using the embedded cue only, it does appear that CUETools reads the date correctly, will use it as %DATE% everywhere else (templates, cue, embedded cue) but does not write it to the tags if split into tracks (date is blank if more than 4 digits). So if you're converting to tracks, I won't be able to help with settings unless Gregory wants to change this.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1869
I've been an EAC user and recently started working with CUERipper. I really like the speed of the ripper. One downside, however, is the metadata. I really like having access to the GD3 database in EAC. I find it often has CDs that aren't in musicbrainz and the quality of the metadata (especially the higher res images) seems better. Andre seems to have worked out a really cheap lifetime license for EAC users to get access to GD3. Do you think it would be possible to add this to CUERipper?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1870
I'm not sure about obtaining cheap lifetime licenses, but it shouldn't be difficult to add support for GD3 to CUERipper for users who purchase their your own licenses.

On the other hand, i'm not sure i want to promote proprietary solution when we have decent open alternatives, i would rather work on improving integration with musicbrainz.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1871
When using 'EAC style log' in CUERipper, should it not say 'CUERipper extraction log' on the 2nd row of the log instead of 'EAC extraction log'?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1872
Does it not say 'CUERipper' on the top line of the page? Everything below that mimics the EAC logfile and should tell us so.
'EAC-style extraction logfile' maybe.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1873
Just because the option say 'EAC style log' doesn't mean it have to say EAC in a CUERipper log or?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1874
Make more sense than having two completely different looking log files titled and named exactly the same.
korth