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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1900
... You might need to have both VS2005 and VS2008 installed to build them. FLAC also requires nasmw...

Thanks I have managed to get it all to build, including FLAC, although I use vs2010. Apparently nasmw is now called nasm.

Now, a question to how it works. Possibly, this belongs in a different thread so feel free to relocate this.

How does cuetools work out whether it can repair (and where does it do that) and how does it decide to or not to repair?

I have a couple of rips where one track is aweful - the rest are great. CUEtools says the confidence for the good tracks is 8/8 and that of the bad track is 1/8. My thinking is that 7/8 agree that that one track is bad, although they might not agree why. If the 7/8 also agree what is good then because they all agree about the other tracks one can safely say (7/8) that one track needs repairing and repair it.

Currently cuetools will not repair that one track. I do not know why, possibly because of the 1/8 confidence that it is ok. So I was looking for a place in the code where I could apply that well known statistical law "One is None" to the confidence level.

Do you have any pointers fro me?
H.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1901
Is this CTDB confidence or AccurateRip confidence? Confidence levels should be 2 or higher before you should consider them reliable.
The disc has to have repair data stored in the CUETools Database (CTDB) and has to differ from the content of your disc. There are known issues using 'repair' when more than one entry is in the CTDB. Some help with the log can be found here. The repair function is a custom script so not really part of the source.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1902
Hey, I was wondering if we could get a wiki as far as instructions of how to tell if an offset is accurate and how to fix it, best practices, etc?  Some things such as offsets are unclear as to whether or not they've been correctly detected and accounted for, or if further correction needs to be taken to counter offsets.  For example, if it says that it has an offset of 6, does one enter 6 into the offset correction box and tell it to fix offset or do they enter -6 to bring it back to 0?  And if some data is lost from the beginning by utilizing the wrong offset, can a repair be made to recover the correct data so none is lost?
If anyone who fully understands the program is willing, I think an online instruction manual would be awesome for the site!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1903
I'm working on wiki pages for the site with plans to include a few guides and a Q&A page. Still need to finish the program setting pages for reference. Hopeful others will jump in with additional guides and a few custom scripts.

There's really no reason to change the offset of the files and to do so is at the risk of data loss. Cross-pressing verification is there for just that...verification. If your disc was ripped with the proper offset correction then the offset is correct even if that offset isn't in the AR database. If it wasn't ripped with the proper offset correction and you don't know the offset correction for the drive used, then you're just guessing.

Unless your drive is overread capable, samples can be lost even when offset correction is applied properly. The lost samples are usually padded with zeroes by the ripping program. Both AR and CTDB account for this by ignoring samples at the beginning and end of each disc. The repair data also excludes these samples so any data lost in this area cannot be repaired.

EDIT:
Quote
For example, if it says that it has an offset of 6, does one enter 6 into the offset correction box and tell it to fix offset or do they enter -6 to bring it back to 0?
It doesn't hurt your files to use the Extra:Offset box to Verify your rip. If it says 6 then enter 6. If it says -6 then enter -6. This is actually the only way to see ARv2 entries at other offsets.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1904
It doesn't hurt your files to use the Extra:Offset box to Verify your rip. If it says 6 then enter 6. If it says -6 then enter -6. This is actually the only way to see ARv2 entries at other offsets.


When you say "If it says -6 then enter -6", what is "it"? Does that refer to the Read offset correction used on the ripping drive?

I normally rip using EAC, and have "Read offset correction" properly detected and set. For those rips that don't immediately show an AR match in the rip log, I like to use CueTools to Verify. I'd love to also be able to check against ARv2 entries at other offsets.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1905
I made the assumption the OP was referring to CUETools, with "it" being the CUETools Verify Log and correcting the offset when results came back non-zero. So my answer is based on that assumption. I agree after rereading the question that the OP could have meant something else and should've asked for clarification.

Quote
For those rips that don't immediately show an AR match in the rip log, I like to use CueTools to Verify. I'd love to also be able to check against ARv2 entries at other offsets.
When you don't see results in the verify log except at another offset "Offsetted by xxx:" and tracks show "No match (V2 was not tested)" in 2.1.4 or "No match but offset" in 2.1.2a then there's a chance of ARv2 entries (see notes below). You can enter the value xxx in the Extra:Offset box and verify again to see if the ARv2 entries exist.

Note1: "No match (V2 was not tested)" and "No match but offset" can also indicate a partial match or alternate mastering which still means "No Match".
Note2: Even if all tracks show ARv1 entries at another offset there can still be ARv2 entries that weren't tested.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1906
Is there a way of suppressing the modal popup "done" when finishing an encode?  I couldn't find it anywhere in the graphical settings and didn't want to try hacking around the settings.txt file.

Thanks!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1907
Don't think so but then I'm still trying to remember ever seeing that popup in CUETools. CUERipper has that kind of popup when it finishes ripping and I don't know of any setting to suppress that one.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1908
I made the assumption the OP was referring to CUETools, with "it" being the CUETools Verify Log and correcting the offset when results came back non-zero. So my answer is based on that assumption. I agree after rereading the question that the OP could have meant something else and should've asked for clarification.

Quote
For those rips that don't immediately show an AR match in the rip log, I like to use CueTools to Verify. I'd love to also be able to check against ARv2 entries at other offsets.
When you don't see results in the verify log except at another offset "Offsetted by xxx:" and tracks show "No match (V2 was not tested)" in 2.1.4 or "No match but offset" in 2.1.2a then there's a chance of ARv2 entries (see notes below). You can enter the value xxx in the Extra:Offset box and verify again to see if the ARv2 entries exist.

Note1: "No match (V2 was not tested)" and "No match but offset" can also indicate a partial match or alternate mastering which still means "No Match".
Note2: Even if all tracks show ARv1 entries at another offset there can still be ARv2 entries that weren't tested.


Thank you for the clear explanation.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1909
I've been using CUEtools 2.1.4 and it's giving me these special messages when verifying some files.
I've checked the CUEtools website to see what they mean but I still don't understand what they're trying to say

"Padded some input files to a frame boundary
    File(s) truncated and do not align on a frame (sector) boundary, zeroes padded to next frame (sector) boundary "

and

"Truncated 4608 extra samples in some input files
    Extra 4608 zero samples at end of file(s) detected and removed (Detection can be disabled) "

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1910
@ Gregory
Any news/info regarding the upcoming v2.1.5 Stable version

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1911
I've checked the CUEtools website to see what they mean but I still don't understand what they're trying to say
Sorry for my terse definitions on the wiki and I still haven't cross-linked to the other pages I'm working on.
Quote
"Padded some input files to a frame boundary
    File(s) truncated and do not align on a frame (sector) boundary, zeroes padded to next frame (sector) boundary "
See also Audio CD Standard technical details. The smallest chunks of CD audio are called CD 'sectors' (also known as audio 'frames'). There are 75 per second. Each CD audio file has to start and end between two of these. This message is telling you that one or more of the the audio files are landing somewhere in the middle of a sector and that the program is adding NULL samples (or zeroes) to the file so it ends between the next two sectors. This can happen with some CUE splitting programs that do not properly decode files before splitting or when a file is damaged.
Quote
"Truncated 4608 extra samples in some input files
    Extra 4608 zero samples at end of file(s) detected and removed (Detection can be disabled) "
Some erroneous FLAC encoders add an extra 4608 NULL (zero) samples at the end of each file. The program has an option to detect and remove the extra samples. Leaving these samples in would result in the files not aligning on a sector boundary and changing the detected Table of Contents (TOC) so the wrong info is used for database lookups. So the message is telling you that the program detected that at least one of the files had the extra samples and removed them.


korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1912
@ Gregory
Any news/info regarding the upcoming v2.1.5 Stable version

Sorry, this will probably take a few weeks more. I've just started on a new job and am somewhat overwhelmed at the moment.
CUETools 2.1.6


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1914
The [a href='index.php?showtopic=70202']Compression Offset[/a] feature in EAC was removed as of v1.0 beta 1 but it would cause this if applied to FLAC encoding.
korth



CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1917
In main window can't set offset, cause main windows is NOT resizable.
Windows 7 x64
CUETools 2.1.4

Same text in Russian:

Невозможно выставить смещение, т.к. выставление смещения в семплах находится за границей рабочей области программы. При этом основное окно не ресайзится.
Windows 7 x64
CUETools 2.1.4

https://sourceforge.net/tracker/?func=detai...mp;atid=1118615

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1918
I remember similar problems caused by old version of Microsoft .NET Framework 2.0. Try to install Microsoft .NET Framework 2.0 SP2, if you don't have it installed.
CUETools 2.1.6


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1920
I remember similar problems caused by old version of Microsoft .NET Framework 2.0. Try to install Microsoft .NET Framework 2.0 SP2, if you don't have it installed.
Win7 should have Microsoft .NET Framework 3.5.1 installed by default. However, I've duplicated what ManicAeon is seeing: Win7x64, CUETools 2.1.4, Microsoft .NET Framework 4.0.
Display font: Large (125%). {text: 'Offset' is visible, spinner is not completely visible}
Display font: Extra Large (150%) - appears fine.
Display font: Normal (100%) - appears fine.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1921
Sorry if this has been answered (didn't find an answer via search)...

Discovered CueTools (CueRipper mainly) while I was setting up a new machine to do some CD extraction, and quite like the software.  One of the things I noticed from the HA wiki was that FUA support is not listed, so out of curiosity I decided to take a quick peek at the source.

Now (making some assumptions since I just quickly glanced over things)... it seems that the implementation underneath (Bwg.) handling DeviceIOControl functions for SCSI MMC commands is ... well quite extensive.  As far as I can tell, the read10/read12 command already accept FUA as a boolean value for enable/disable.  From the MMC specs I belive this is all that is required to enable FUA (this of course depends on how you are making cache decisions)... though my interpretation of how this works/what you are calling underneath may be completely wrong

Any chance this would be a configuration option in the future?  Probably not high on any priority list... since I belive only a handful of drives respect this behavior (Older Plextor, etc.)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1922
Loving CUEripper. I've searched and can't find this answer.

I have a couple of HDCDs, but they're packed away at the moment.

I'm wondering will CUEripper use the HDCD settings from CUEtools to detect and process HDCDs?

I'd really like to deal with the two main rarer variants among audio CDs out there at the ripping stage, namely pre-emphasis and HDCD. HDCD is the more important of the two, particularly as I often use LossyWAV and foobar2000 which can result in HDCD being detected during a silent intro then switched off once the music gets louder and the LSBs are removed.
Dynamic – the artist formerly known as DickD

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1923
Still waiting for Grigory to chime in for your first question.
In the meantime, the config is in %appdata%\CUERipper\settings.txt
Default should be:
DetectHDCD=1
Wait750FramesForHDCD=1
DecodeHDCD=0
LossyWAVQuality=5
DecodeHDCDToLossyWAV16=0
DecodeHDCDTo24bit=1
Which are the same as CUETools Advanced Settings: 0=unchecked; 1=checked.
I honestly haven't tried changing to DecodeHDCD=1 to see if it enables the next 3 settings in CUERipper.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1924
Still waiting for Grigory to chime in for your first question.
In the meantime, the config is in %appdata%\CUERipper\settings.txt
Default should be:
DetectHDCD=1
Wait750FramesForHDCD=1
[edit: deleted much of requote]


Thanks for steering me in that direction. I didn't think to look for an settings file and check. Looks encouragingly like the CUETools settings dialogue box, and hopefully theres enough code re-use that both will behave the same. Then again, might be an experimental undocumented feature.

Maybe I'll have to dig out those old Dire Straits remasters and check and report back one day.

Cheers.
Dynamic – the artist formerly known as DickD