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 2026343 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 #1575 –
Quote from: a1020012 on
1. Approximately how many seconds (milliseconds) are there for one offset? e.g. +6 offset = X milliseconds. Or, stated differently, how many write offsets would equal one second of audio? Just looking for a guesstimate, not an exact calculation.

6/44100 ? 0.136 ms or 136 ?s (136 microseconds or millionths of a second)

One second of audio equals 44100 samples.

Quote from: sauvage78 on
1: As far as I remember 1 is 1/75 of a second.

One second of also audio equals 75 frames, where one frame equals 588 samples, but offsets are measured in samples, not frames.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1576 –
I now see the option for "to nearest" under AccurateRip options. Still not clear how CT makes it's judgement of what is nearest. I would think the DISCID in the .cue would help.

So correcting an offset of 6 to audio tracks is practically like doing "nothing" to them at all. Or even adjusting 500.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1577 –
Is it possible that you simply have a pressing not in the database, in which case correcting the offset will match a disc belonging to someone else, rather than the original that was ripped?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1578 –
Quote from: a1020012 on
Still not clear how CT makes it's judgement of what is nearest.

6 is nearer than 18. 18 is nearer than 30. 30 is nearer than -48.

Quote from: a1020012 on
I would think the DISCID in the .cue would help.

The DISCID "aabbbbcc" is aa=checksum, bbbb=total seconds, cc=# of tracks, all in hex. Not much help.

Quote from: a1020012 on
So correcting an offset of 6 to audio tracks is practically like doing "nothing" to them at all. Or even adjusting 500.

Provided there are enough null samples. Applying an offset greater than the null samples available will result in data loss. A live recording, for example, could be damaged. (I'm referring to a manual adjustment, not the 'fix offset' feature.)
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1579 –
If I were right, an offset of say +/-2000 would means a few seconds, so I now realized I answered too quickly. Greynol is right, it's very very small.

Edit:
Personnaly I fix to highest only if all tracks are AR(2) since  a couple of years now (since the feature was added in fact) I never heard anything wrong (I do this to have the highest display first in log).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1580 –
Quote from: greynol on
Is it possible that you simply have a pressing not in the database, in which case correcting the offset will match a disc belonging to someone else, rather than the original that was ripped?

Yes, exactly -- and that's why I need to understand what I'm doing before I alter my tracks. Understanding how CT makes it's decision to "fix offset" is the info I'm after. If it is 100% certain that it's choosing the right offset, I'll do it. If CT is just guessing, I won't.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1581 –
What is the proper offset correction for the drive used (relative to the EAC reference adopted by AccurateRip), and was it applied at the time of the rip?

CT does not have any provision to ensure that the criteria I provided in the question above is met.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1582 –
Something like the "correct" offset is dream as the CD makers themselves don't care about offsets.
As an end user what matters is that you at least match a pressing within the offset range of the AR ID so that your log is shorter & doesn't display "No match" on all tracks for "offset 0".
So, the "fix offset" feature doesn't really "fix" audio, it mainly fixes cosmetics within the log.
It is not a feature for people who always fix their drive offset correctly while ripping. It's mainly for people who discover the existence of offsets with AR & CT.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1583 –
Quote from: sauvage78 on
As an end user what matters is that you at least match a pressing within the offset range of the AR ID so that your log is shorter & doesn't display "No match" on all tracks for "offset 0".

Speak for yourself!

This concern about offsets and what is shown in log files is really nothing more than anal-retentiveness.
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1584 –
I just learned a new word: retentiveness, thks, I already knew the other one ! lol

... and yes offet are a#?*, I never said I care about offsets ... I don't even know their length !

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1586 –
Just curious, why does CT sometimes popup asking me which log to pick when there is only one in the directory?

Also, does this still apply?
(from CT Wiki under "What's wrong if i'm sure the CD is present in the database, but CUETools doesn't find it")
Quote
"For this to work, .log file should have the same filename as a .cue file, except for extension."

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1587 –
When .log file has the same filename as a .cue file, it silently used.
If not, it can be also silently used if it's the only .log file with matching TOC in the directory.

Log files from old EAC versions don't contain TOC, and EAC by default uses different filenames for .cue and .log files, so CUETools has to ask user for confirmation.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1588 –
Congratulations on having the EAC plugin included in the install package. The EAC effect is clearly visible: http://db.cuetools.net/stats.php , can't wait for the next EAC release, I'm sure it will be default.

I hope you will continue to develop CTDB, many more things can be accomplished.

Thank you.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1589 –
Thanks! Support of the HA community is what made it possible.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1590 –
Is there a changelog for the CTDB plugin? What's new in V2.1.3?
EDIT: Okay I just realized the options slightly differ, as you can set the metadata search mode now. Though I'm not really sure what it is about at this moment.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1591 –
2.1.2 supported only Musicbrainz, 2.1.3 supports also Discogs and Freedb. Full search in all databases can take quite a lot of time, and produce too many results, so the default mode looks for exact match in Musicbrainz, then tries Discogs and Freedb, if still out of luck - tries fuzzy search. Fast mode doesn't do fuzzy searches, and Exhaustive mode does every kind of search and returns all results. This logic is inside the CTDB server and can change over time, if i find better ways to do it. I recommend keeping the default setting.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1592 –
Okay, thank you for the quick response. I just realized you can select the CTDB plugin as metadata provider in EAC, so that's what it's for.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1593 –
Does CUERipper have any command line options for running from the console? If not this is my request to add some.  I know CUETools has a couple as listed on the wiki but I was not able to find any listed for CUERipper.  My goal is to try and use CUERipper with a CD changer for automated ripping and having CUERipper controllable from the console would make this task a whole lot easier. Thanks!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1594 –
Code: [Select]
C:\Users\user\Downloads\CUETools_2.1.2a>CUETools.ConsoleRipper.exe -h
CUERipper v2.1.2 Copyright (C) 2008-10 Gregory S. Chudov
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Usage    : CUERipper.exe <options>

-S, --secure             secure mode, read each block twice (default);
-B, --burst              burst (1 pass) mode;
-P, --paranoid           maximum level of error correction;
-D, --drive <letter>     use a specific CD drive, e.g. E: F:;
-O, --offset <samples>   use specific drive read offset;
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1595 –
Thank you Gregory!  How on earth did I miss that?  Off to try my lame scripting skills.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1596 –
I managed to get CUETools.ConsoleRipper.exe working with my Sony VGP-XL1B2 using a very crude batch file!  However it turns out CUETools.ConsoleRipper.exe does not seem to be entirely compatible with the MATSHITA DVD-RAM SW-9584 mechanism that is in the changer.  I am guessing it has something to do with the over read capabilities of the drive?  The result is that the first track ripped from the disc does not match the database and while ripping the last track CUETools.ConsoleRipper.exe reports 15 ripping errors at the very end of the disc however it does match the database along with all of the other tracks on the disc.  Its the same for every disc I have tried so far.  All these discs rip without errors and match the database with my LITE-ON  DVDRW SOHW-1693S.  Any suggestions making this work outside of replacing the changer? Thanks!

A little more detail as it turns out using CUETools.ConsoleRipper.exe in secure mode on this drive results in errors across the whole disc as opposed to just the end when in burst mode.  I am also curious if CUETools.ConsoleRipper.exe has the ability to submit to the CUETools DB.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1597 –
Hi,

Can you please explain to me this result:

Quote
.\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 1)\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 1).cue: AR: rip accurate (36/55), CTDB: verified OK, confidence 36.
.\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 2)\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 2).cue: AR: rip accurate (36/57), CTDB: verified OK, confidence 1.
.\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 3)\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 3).cue: AR: rip accurate (34/56), CTDB: verified OK, confidence 34, or differs in 8920 samples, confidence 1.


How come the second disk only has confidence 1, and the other two have confidence 34/36?
It seems that the disk two and three has the confidence from the AR database and was submitted to the database by CUETools, but the second disk was ripped with CUERipper or EAC. Why doesn't the second disk has the same confidence as the as AR confidence (36)?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1598 –
Quote from: radu on
Why doesn't the second disk has the same confidence as the as AR confidence (36)?

Likely because the first submission came from a rip. Once a CTDB record is created, the confidence only increases with each additional rip. If someone had made the first submission using CUETools verify, the confidence would have been set to match the current AR confidence.
Perhaps the user who submitted the other two discs had an inaccurate copy of disc 2.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1599 –
Maybe, once a rip has been made, the confidence level should include only the submitted rips, and only a disk without a rip, submitted by CUETools, should have the AR confidence level.

A confidence level beyond 2 or 3 becomes irrelevant for checking the accuracy of a rip. But I like statistics, and the confidence level tells you how popular a disk is, unfortunately this is not possible right now.