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 1894626 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 #550
My friend told me yesterday that new version 2.0.4 were out. I worked with 2.03 but I got no info from the built-in update. Should that be because of the experimental version?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #551
My friend told me yesterday that new version 2.0.4 were out. I worked with 2.03 but I got no info from the built-in update. Should that be because of the experimental version?


mine shows it in the main log window when i start up 2.0.3.. it says 2.0.4 is out! but it wasn't a popup box or anything.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #552
The field on the left (where earlier the file browser was) is really thin and the main program window doesn't let to make itself brighter.

I updated 2.3a to 2.04 at home without problems - just deleted all files in program folder and unzipped the new ones.
As I did the same at work I became first an error, by the second try the program started with just 1 profile listed.
After that I deleted all old settings files and now it works fine.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #553
First time I started the new 2.0.4 version I got an unexpected error in .net framework:



Code: [Select]
See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
  at JDP.frmCUETools.set_FileBrowserState(FileBrowserStateEnum value)
  at JDP.frmCUETools.LoadSettings()
  at JDP.frmCUETools.frmCUETools_Load(Object sender, EventArgs e)
  at System.Windows.Forms.Form.OnLoad(EventArgs e)
  at System.Windows.Forms.Form.OnCreateControl()
  at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
  at System.Windows.Forms.Control.CreateControl()
  at System.Windows.Forms.Control.WmShowWindow(Message& m)
  at System.Windows.Forms.Control.WndProc(Message& m)
  at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
  at System.Windows.Forms.ContainerControl.WndProc(Message& m)
  at System.Windows.Forms.Form.WmShowWindow(Message& m)
  at System.Windows.Forms.Form.WndProc(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
  at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
CUETools
Assembly Version: 2.0.3.1
Win32 Version: 2.0.3.1
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUETools.exe
----------------------------------------
CUETools.Processor
Assembly Version: 1.9.4.0
Win32 Version: 1.9.4.0
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUETools.Processor.DLL
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
CUEControls
Assembly Version: 1.0.3469.35476
Win32 Version: 1.0.0.0
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUEControls.DLL
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Accessibility
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

After quiting and restarting cuetools it gave no error (started complete with dropzone). Working with 32-bit XP service pack 3.

Also since I started it I have some problems:
* notepad doesn't start
* word doesn't start
* totalcommander stopped working
Don't know if it all relates to the unexpected error, but had no problems before starting cuetools.


update:
I opened cuetools on another pc without servicepack3. There it starts without a problem, but this time without a drag 'n drop zone, except a small indication where it should be (same as sauvage78).

Update2: screamed too early, I had to choose from the pull down menu 
But after dropping and a verify I got the same error as Chinch
Also in filebrowser mode I get the same error.


I like the lay-out much more than the previous one. Many thanks for all the efforts!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #554
Sorry, but things are getting worser & worser for me, I already never used V2.03, but I cannot even test V2.04 as the drag&drop zone has completely disapeared ... & I am not even using 120% fonts this time.

Windows XP SP2 (Net Framework V2.0+Ms Visual C++) Font Size=100% (Default):


I think i found the source of your problems.
Tried it out on freshly installed XP, and got the same picture.
Problem dissapeared after i updated the .NET framework: http://www.microsoft.com/downloads/details...;displaylang=en
Microsoft also recommends this update.

Thanks everyone for your reports, i'm currently investigating them.
CUETools 2.1.6

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #555
C:\FLAC\01 - Whatever.flac: Could not load file or assembly 'CUETools.Codecs.TTA, Version=1.0.3505.28501, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1).

Ok, i think i solved this one too. Windows Update silently updated my Visual Studio to use more recent version of VC redistributable package. You will need to download this one:

http://www.microsoft.com/downloads/details...;displaylang=en
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #556
C:\FLAC\01 - Whatever.flac: Could not load file or assembly 'CUETools.Codecs.TTA, Version=1.0.3505.28501, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1).

Ok, i think i solved this one too. Windows Update silently updated my Visual Studio to use more recent version of VC redistributable package. You will need to download this one:

http://www.microsoft.com/downloads/details...;displaylang=en

I updated my xp sp3 to .net framework 2 (seemed I only had 1.1 installed), installed the servicepack and update.
Now it opens without a problem, but still had the chinch problem.
After updating with vcresist it seems to work now, thanks very much.

Now do some testing

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #557
Edited: Seems to works now, thks. (The problem was .NET 2.0 only instead of .NET 2.0 SP2)

Can someone confirm that this is the normal display of V2.04, plz ? In the beginning I was searching Drag&Drop zone on the left & completely missed that the Input Box appeared on the top ... Are the lines on the left normal ? I can drag&drop to the Input Box but there used to be a drag&drop zone on the left so I am still not sure that all is ok right now.

Input Box appeared:

Radio Buttons fixed:

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #558
I had a look to see if my bug with 120% fonts was related to .NET 2.0 SP2, it is not as I still have the bug with cuetools V2.02+.NET 2.0 SP2 ... but even if it's not in the changelog it is fixed in V2.04. I don't know what you did, & I don't know if you fixed it by mistake, but thks for fixing this one.

V2.02 120% Fonts=Bugs


V2.04 120% Fonts=No More Bugs

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #559
Hi,

First off, thank you so much for creating this application. I love it and all its features, but I was wondering if you could add one more feature (or create a small separate utility) that would re-check rips in the AccurateRip database based solely from the generated .accurip files. The .accurip files already have the hash and CRCs of the disc, so wouldn't it be possible to check for increased confidence levels of rips done in the past from the .accurip files? That way I could just place all of my old .accurip files in one folder, and load them all in batch and have the utility quickly check each one (and possibly generate new .accurip files with updated confidence levels) without having to re-scan the audio files.

The reason why I think this would be useful is I have about 100 or so of my rips that aren't yet cataloged in the AccurateRip database, but it would be interesting to see perhaps six months or a year from now the increased confidence levels of my rips, or which of my CDs have been added to the database by other people, without having re-scan them.

Thanks

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #560
First time I started the new 2.0.4 version I got an unexpected error in .net framework:
Code: [Select]
See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
  at JDP.frmCUETools.set_FileBrowserState(FileBrowserStateEnum value)
  at JDP.frmCUETools.LoadSettings()
  at JDP.frmCUETools.frmCUETools_Load(Object sender, EventArgs e)
  at System.Windows.Forms.Form.OnLoad(EventArgs e)
  at System.Windows.Forms.Form.OnCreateControl()
  at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
  at System.Windows.Forms.Control.CreateControl()
  at System.Windows.Forms.Control.WmShowWindow(Message& m)
  at System.Windows.Forms.Control.WndProc(Message& m)
  at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
  at System.Windows.Forms.ContainerControl.WndProc(Message& m)
  at System.Windows.Forms.Form.WmShowWindow(Message& m)
  at System.Windows.Forms.Form.WndProc(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
  at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
CUETools
Assembly Version: 2.0.3.1
Win32 Version: 2.0.3.1
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUETools.exe
----------------------------------------
CUETools.Processor
Assembly Version: 1.9.4.0
Win32 Version: 1.9.4.0
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUETools.Processor.DLL
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
CUEControls
Assembly Version: 1.0.3469.35476
Win32 Version: 1.0.0.0
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUEControls.DLL
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Accessibility
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
I'm on Windows7 RC and I also had this the first time I started the x64 version. After restarting it seems to work fine though!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #561
Ok, i think i solved this one too. Windows Update silently updated my Visual Studio to use more recent version of VC redistributable package. You will need to download this one:

http://www.microsoft.com/downloads/details...;displaylang=en


yep.. good work.. that one did it, installing that version of the C++ redist.

although the first time i opened it after the install i did get a .net runtime error as mentioned by another poster... but it only happened the first run, after that it i haven't seen it again. [edit: it appears that it happens the first time you open 2.0.4 after opening an older version.. for instance, if you go back and open 2.0.3, then go open 2.0.4, you'll get the JIT error dialog again... no big deal cause nobody should be switching back and forth between versions, but just a little bit of added info]

thanks for looking into the fix!

now i can check out the new version of CUETools.


out of curiosity, what exactly was the problem... the newer version of the redist was causing the crashes, so installing that version downgraded it to a compatible version or what? just curious if it was an update that is going to try and pull down again

also one other question.. don't know how hard it would be to do this, it's been so long since i messed around with visual studio, but can't you make the bottom output window and the top portion a split/resizable pane? example... if you maximize the program and bring up a browser on the side... the border that separates the log area from the file browser/control area is fixed, it would be a nice little feature/fix if you could resize that, at least down, so you could see more of the file listing for instance, and have a smaller log area.

i realize that it cannot be resized up past a certain point, or it would interfere with/overlap the controls... is there some sort of property to allow it to only resize UP to a certain level? (just below where the controls start

just a suggestion for the future.. no biggie

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #562
Gregory S. Chudov:
Thks for your work, despite some minor bugs I have already adopted V2.04. Congratulations  .

I still have trouble with Cuetools reminding some of my settings & I don't really understand the upper left part of the new interface (profile), but overall I am happy with what you gave. I like the new bach log in the bottom, I like the cleaner logs & the mostly-fixed 120% fonts bug.

I thinks icons in the upper left like in V2.03 are more intuitive than the actual empty box that pops up when you use the Input/Output menus, in the beginning I was convinced that it was a display bug so I installed XP SP3, then .net 3 SP1 & then .net 3.5 just to make these icons (& the drag&drop zone) appear ... only to realize when I started testing that it was now working thought the menus ... stupid me 


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #564
Tuxman:
I will, but I must first get used to the new interface, it's a lot of change for a die-hard 2.02 user like me. Actually I am not sure if those are bugs or normal behaviour that I miss-understand.

For example the displaying bug with 120% fonts is gone in advanced setting, but I think that it is still there in a new form: on the main windows, the manual offset box is not usable. I must confirm this by switching to 100% fonts again but it requires a reboot. Don't worry, I didn't found anything that affects the ouput.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #565
i've got a question for those of you who are more knowledgable than me with offsets and pregaps, etc. i have a copy of a cd that has been bothering me for a few hours now.. it has been driving me crazy trying to figure out what is going on.. but i think i just found the answer as i started typing this.

my problem was that TripleFLAC was showing the CD as having some 100+ matches, reading a drive offset of +120 and a pre-gap of 00:02:32 (same according to log file, which is where it pulled it from). problem was.. in CUETools, it kept reporting CD not in the database and showing a (?) cd icon -- when paired with the correct log, it kept reporting lead-in was 00:00:24, with no matches.

I kept trying to figure out where in the hell 24 was coming from. I tried changing the pre-gap to 00:00:24,  00:02:00, nope. started looking around in musicbrainz for TOC's and track lengths and indexes, etc. tried to make my own cue files. got really just frustrated and confused that i couldn't get CUETools to agree and wanted to get to the bottom of it so i could understand.

Long story short, I looked in TripleFLAC and saw it said two possible lead-in's (24 & 32). suddenly it clicked. CUETools was for some reason reading the entry with a pre-gap of 00:00:24, which did not match at all, and TripleFLAC was reading both, and matching on the pre-gap of 00:00:32, giving me a perfect match.

So -- my questions are... can someone please clear this up for me, I'm still learning but very interested.

i understand that pre-gap and lead-in are the same thing. also, from what i understand.. these are measured in samples. i.e. "the lead-in/pre-gap is 32 samples"

1- what is the correlation between sectors and samples? i know what a sector is, it's an area of information on a disc... and samples are audio data.. but i can't seem to make sense of the two together... when i look up on MusicBrainz for instance and see 15323 sectors, etc...  i seem to have gathered from MusicBrainz that 2 seconds=00:02:00=150 sectors, but when referencing TOC stuff there, do i even need to worry about the sectors, or is that purely a media based thing.. that is, counting or matching on sectors only applies when reading the physical CD data, not the digital copy, correct?


2- why did TripleFLAC pick up two pre-gap possibilities, but CUETools seemed to only read/use the 24 entry and insist that the disc was not in the DB? i even removed all tags and took away the cue file so that it couldn't be reading any discid or anything pointing it to the wrong version. i thought normally these would show as different pressings, correct? or am i wrong in thinking that different offsets/pressings are the same as different pre-gaps/lead-ins? i thought they were both the same thing essentially...? just curious as to what went wrong there, because as soon as i put in a manual pre-gap of 00:00:32, CUETools matched it instantly, and it would be very helpful to know why it never picked up on the 32 difference at all, as if it didn't exist.

3- i understand that 00:02:00 is a pretty common pre-gap and that seems to translate to 150 sectors... no problem. but where does 00:02:32 come from in my example? i will assume that the write offset may have been off by 32 samples (or not set at all), which caused the extra :32 at the end of the real 2 second pre-gap. am i correct in this? (in that case, it would point to the fact that this was ripped from a COPY with a write offset problem of 32 samples, rather than an ORIGINAL disc, correct?)

i don't know though.. this confuses me further because i notice several other rips from different drives also seem to have a 00:02:32 pregap as well.. wtf. is this a common one as well? i thought the first was just an anomaly.

i'm slowly trying to learn on this.. and reading from you guys here on the forums has been a great help.. i'm getting a pretty good hold on the basic concepts i think (in the beginning i was confused as hell, i'll admit), i just want to make sure i'm correct in my thoughts.

I ran a search on the forums and the internet, but i am coming up empty handed... i know it's not directly related to this topic, so i'm sorry but hopefully nobody minds: what ever became of TripleFLAC? it's as if it never existed.. I can find no reference to it really other than here. What was the last/latest version? Is there a home page or any release place? Documentation? It surely doesn't replace CUETools, i just find it useful as a backup supplement in cases like the above. i have figured out bright green means match on all pressings, dark green means match on at least one of the pressings but not all, yellow is non-zero offset.. but what about the log and cue files? what does red higlighted log file mean, etc?


Thanks for putting up with all the questions... I hope someone would like to help me out and fill me in on these things! I have read posts here and knew of the board's existence for a long time, but it's CUETools that made me actually make an account and start learning more about all of this stuff, so thank you to Gregory and his program for this new interest!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #566
One more thing: what does "Fix Encoding" do when using the Freedb lookup option?  It searches Freedb and Musicbrainz and comes up with a bunch of CD track times, start and finish.  I have a CD in which my start and finish times were different than Freedb's start and finish times for each track.  So, I checked the "Fix Encoding" box and then made a new encoding of it.  I then began a new encoding with THAT new copy to check it against Freedb again, and the exact same difference came up.  It's like it didn't do anything.

"Fix encoding" has nothing to do with track lengths, it fixes track names for entries that were submitted using non-unicode software, such as EAC, when track names are in non-latin (e.g. cyrillic) encoding.


i have to admit, the wording on that option was confusing to me as well.. i thought it was the same as 'fix offset' when encoding for whatever reason (even though that wouldn't make much sense i don't think, since it is not showing accuraterip in the list)... but you may want to just change the text to read something like "fix character encoding" or something like that; an easy fix that would prevent any confusion. i suppose the problem is when people are working with audio files and see the word 'encoding', they immediately think of audio encoding, not text 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #567
3- i understand that 00:02:00 is a pretty common pre-gap and that seems to translate to 150 sectors... no problem. but where does 00:02:32 come from in my example? i will assume that the write offset may have been off by 32 samples (or not set at all), which caused the extra :32 at the end of the real 2 second pre-gap. am i correct in this? (in that case, it would point to the fact that this was ripped from a COPY with a write offset problem of 32 samples, rather than an ORIGINAL disc, correct?)


I do own many original CDs with a 2.32 pregap. I notice most of them are from Universal and its subsidiaries, e.g. U2, The Police, etc...

Not sure what's the purpose of it though.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #568
3- i understand that 00:02:00 is a pretty common pre-gap and that seems to translate to 150 sectors... no problem. but where does 00:02:32 come from in my example? i will assume that the write offset may have been off by 32 samples (or not set at all), which caused the extra :32 at the end of the real 2 second pre-gap. am i correct in this? (in that case, it would point to the fact that this was ripped from a COPY with a write offset problem of 32 samples, rather than an ORIGINAL disc, correct?)


I do own many original CDs with a 2.32 pregap. I notice most of them are from Universal and its subsidiaries, e.g. U2, The Police, etc...

Not sure what's the purpose of it though.


really ? very interesting..... i'm glad i'm not crazy! 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #569
Mmm, can't get that MS patch to install, it's having problems locating vcredist.msi.. which is odd because I think that file is contained within the downloaded package. I'm using XP SP3 with all updates. I'll search a bit to try to fix it, otherwise I'll roll back to an earlier cuetools.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #571
Just some little requests, actually rips with confidence 1 are reported as accurate in the logs, could this be changed to something like "Unknown: Confidence level is too low" both in batch log & in text log, plz.

IMHO it would be more accurate/safer to start using the conclusion "rip accurate" only with confidence 2.

Also could the conclusion displayed in bach log (accurate or not) be added somewhere in front of the text log so that I could instantly search within text log & split my collection in two (accurate or not, well plus unkknown if you add it) after checking.

Also could there be an option to not add "Offset applied: XXX" within the text log, because I fix offset according to the most popular in the database & as I don't really care about offset this information is useless for me, specially as if I re-check my rip later & delete the old logs this information gets lost anyway in the new logs. So for people fixing offset to most popular pressing this information is useless & should be optionnal. (I actually delete it manually which is a  pain)

Thks for listening, keep the good work going.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #572
Just some little requests, actually rips with confidence 1 are reported as accurate in the logs, could this be changed to something like "Unknown: Confidence level is too low" both in batch log & in text log, plz.

IMHO it would be more accurate/safer to start using the conclusion "rip accurate" only with confidence 2.

Also could the conclusion displayed in bach log (accurate or not) be added somewhere in front of the text log so that I could instantly search within text log & split my collection in two (accurate or not, well plus unkknown if you add it) after checking.

Also could there be an option to not add "Offset applied: XXX" within the text log, because I fix offset according to the most popular in the database & as I don't really care about offset this information is useless for me, specially as if I re-check my rip later & delete the old logs this information gets lost anyway in the new logs. So for people fixing offset to most popular pressing this information is useless & should be optionnal. (I actually delete it manually which is a  pain)

Thks for listening, keep the good work going.


well i think there is sort of this option if you go into options and then accuraterip tab.. over on the right.. you can set the confidence level condition before you fix an offset or encode... but i don't think it's an option for simply verifying. that might be useful... maybe for 'show rip as accurate only if xx matches'... otherwise it would still show the 1 match, but as you said... show that it cannot be absolutely verified as accurate... but let me give you this to think about ---  can it ever be absolutely verified as accurate? it mainly can say you "most likely have a good match" since this many others got the same result -- which, statistically could be true..

BUT... when you're fixing an offset.. is your rip really 'accurate'? accurate is pretty much all relative unless you own the original cd, you make an exact copy of it the correct way, then you match against the DB... otherwise, by changing the offset of the samples, you're possibly destroying data if you're matching to another pressing other than the original CD physically ripped by you. so with the original CD + your drive's proper offset, you can say it is accurate... reburn it with a proper cue file.... then see if everything still matches. do a checksum on the tracks or better yet, entire CD via ultraiso or something that can MD5 hash a full CD. otherwise, unless you exact match on a zero offset one... you don't know. and you really still don't know even then, cause someone could have already fixed the offset, so it only appears it was perfect from the start. this is probably why he adds that it was corrected in the logs, for informational purposes. also, you already know this in your head that 1 match means it might not be accurate, so why do you really need to see it in the log? for others? that's mostly just telling someone else that your rip might be bad... kind of defeats the porpoise either way

not to be a deal breaker though! not trying to say it's a bad idea, but my main point i guess is unless you're ripping from your own original copy with the correct offset(s), you can't really rely on TRUE accuracy of a rip, ever i'd think... you can just prove that it's accurate give or take a certain range of samples, + or -  !

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #573
Dear Chinch

well I disagree with you on 99% of your answer, but I don't want to fight with less experienced users ... it only leads to trouble here.

For the first part of your answer, well indeed you can never be 100% sure everything is perfect. But with confidence 1 & checking your own rip, the probability that your rip is accurate is near to nihil: you cannot say it is accurate, it has already been debated on other topics. Now the real question is: even if you are not an evil pirate, are sure 100% that the rip you made by yourself has made its way thru the accuraterip database ? the anwser is NO. There is plenty of reason why your own rip which could be the only result in the database has not made it's way thru the database (due to bad configuration, firewall, loss of internet connection ...). So it is not a problem of the 1 result in the database being your own rip or you being an evil pirate that checks illegal rips ... It is the problem that you can NEVER be 100% sure that the 1 result in the database his yours or not, even if you know you ripped this CD. So that leads to the conclusion that result with confidence 1 should be marked as UNKNOWN.

For the second part of your answer, well you should learn about offsets because offsets has nothing to do with accuracy, it is only usefull to actually find the CRC in the database ... my accurate rips with fixed offsets according to most popular in database is in NO WAY less accurate than your "so-called perfect rip" made with your the official pressing you bought yourself. On the one hand, your "so-called perfect official rip" is likely to be a very rare pressing in the database if you bought it in japan or russia ... on the other hand, my "so-called rip with destroyed data" (Note: no offense but it was funny to read) is likely to match the official pressing of rich country like europe or USA ... so let's repeat after me: "offset has nothing to do with audio-quality"  The second part of your answer is completly wrong according to me.

Edit: RE-reading your post, I think I understund a part of your miss-understanding: silent samples is not used in accuraterip CRC calculation, so shifting the data with offsets doesn't affect the data CRC. The so called "destroyed data" is zero bit silence ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #574
Another annoying behavior I noticed: for example I have my own profile set as "encode+fix offset" if I go to advanced setting & then exit advanced setting it automatically reverts back to "encode+default" ... due to this behaviour I was forced to encode twice as I didn't notice it the first time ...