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

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2825
Shouldn't that be rather simple? Either based on the submitting user's ID (as e.g. Accurate Rip does it),... or at least by storing the discIDs of ripped discs locally and not counting those that have been submitted before?
Didn't you say that you were concerned because you made submissions of the same disc but with different operating systems, or did I miss something?

simply because it's rather unlikely that both have had errors in the very same places.
Not necessarily.  Due to physical damage, yes but this is only one potential reason for errors; buggy hardware and/or software can be the source errors, among other things; and these errors can be consistent.

This is not to say there is no possible way for improvement, just that there will always be edge cases.

Tell me, honestly, have you heard any problems with the extractions in question?  Have you looked for any signs of erroneous data with a competent wave editor?  ...or is this just wanking your OCD?

I'm sorry if this sounds harsh or you think I'm being a troll, but I went down this road over a decade ago.  Thankfully, I got over it.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2826
Post script:
If you are that concerned about these uncommon titles, you could always purchase a second physical copy and extract it with different hardware, or attempt to obtain a digital copy through other means.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2827
Another small request: at some point, please move the create .toc option to the main window of the GUI, make it a tick box there. Personally, I use .toc to store the datatrack length instead of new EAC logs with included TOC for the very good reason that most of the rips of my own collection pre-date the EAC era with TOC in logs. So when accuraterip tells me that a CD which was not found may have an extra-track, I enter the suggested length manually & create a .toc while I check it with the extra-track, so that Cuetools will automatically find the extra-track length in the .toc next time I check it. The option is more important than what it first seemed, especially as enhanced CD are very frequent, having it somewhere in the main window would be handy ;)

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2828
Didn't you say that you were concerned because you made submissions of the same disc but with different operating systems, or did I miss something?
No that was another issue, i.e. when one changes the computer or reinstalls windows and gets a new ID,… actually I had this already once with AccurateRip...
The question there is, how could one manually set his own old ID.

Of course, this is somehow related to the issue of counting one's own submissions towards confidence in the case of very rare CDs.

Not necessarily.  Due to physical damage, yes but this is only one potential reason for errors; buggy hardware and/or software can be the source errors, among other things; and these errors can be consistent.
This is not to say there is no possible way for improvement, just that there will always be edge cases.
Even in the case of buggy hardware (unless it's a firmware bug, i.e. always fails under the same conditions, which isn't necessarily the case for FW bugs either), it's pretty likely that the error may pop up in another block.
So sure, errors may be consistent, but it would be still better to catch those cases where they aren't.

Tell me, honestly, have you heard any problems with the extractions in question?  Have you looked for any signs of erroneous data with a competent wave editor?  ...or is this just wanking your OCD?

I'm sorry if this sounds harsh or you think I'm being a troll, but I went down this road over a decade ago.  Thankfully, I got over it.
Well I think we've had that very same discussion a while ago over in the EAC forum, hadn't we?
My answers are basically the same as back then, different software, even different extraction modes produced different results, inculding errors which one software found and the other node.
I recently found a bug in EAC, which leads to all tracks <7s or so to have wrong AccurateRip checksum calculated (Andre finally found the cause in his code, but I think it's not yet fixed in the most recent version).
This for example didn't change the actual raw PCM, but I also had cases where on both rippers didn't notice errors, but produced different files and one could clearly hear some distortion.

Apart from that, if I'd wish to "waste" my time by "wanking" my CD's… wouldn't that be up to me?!


Post script:
If you are that concerned about these uncommon titles, you could always purchase a second physical copy and extract it with different hardware, or attempt to obtain a digital copy through other means.
Well, the thing about such extremely rare CDs is typically that they're extremely rare  ::) … and even if multiple copies would be available to buy (which generally isn't the case), they cost a hell of a fortune…

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2829
The question there is, how could one manually set his own old ID.
...then follows the concern about intentional multiple submissions (bad data or otherwise).

it's pretty likely that the error may pop up in another block.
...or not.

Well I think we've had that very same discussion a while ago over in the EAC forum, hadn't we?
I recall you made a lot of claims without any hard evidence and were not open to configuration suggestions.

Apart from that, if I'd wish to "waste" my time by "wanking" my CD's… wouldn't that be up to me?!
OCD and I never used the word waste.  How you choose to spend your time is indeed your business.  I wouldn't expect too much of other people's time, though. ;)

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2830
@Gregory:
Anything new about the other issues I've described above?

Is there a public bugtracker where one could properly record these?

Any there's another one (at least in 2.1.6):
While CUERipper seems to properly store the SecureMode=<n> setting on exit, it doesn't seem to reload it on start, at least not when the value was 2/Paranoid.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2831
The link to the bug tracker page can be found on the CUETools wiki.

CUERipper does not start in Paranoid mode (known issue - see end of post).

Note: You seem to think (unless I misread) that AccurateRip somehow prevents you from verifying against your own rip. You might not be able to verify against your own rip in AccurateRip immediately but that doesn't mean it won't show up for you to verify against in time. (one reference - posted by the developer.)
korth

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2832
Note: You seem to think (unless I misread) that AccurateRip somehow prevents you from verifying against your own rip. You might not be able to verify against your own rip in AccurateRip immediately but that doesn't mean it won't show up for you to verify against in time. (one reference - posted by the developer.)

Hmm perhaps Spoon meant after the AR ID has changed?
At least so far I never found AR to count up my own submission to the confidence and I did in fact re-rip quite a number of CDs a year or so later after the first submission.


Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2834
At least so far I never found AR to count up my own submission to the confidence and I did in fact re-rip quite a number of CDs a year or so later after the first submission.

If you used dBpoweramp on the same computer, AccurateRip will know; getting and submitting an identical result will not increase the confidence.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2835
I searched, and couldn't find anything on this -- is there any chance we could get the ability to use a proxy with the EAC CUETools plugin?  (Or am I missing something, and is that already possible?)

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2836
Feature request: Two minor options that I'd like to have:

1- Force pregap 00:00:00, as actually you can enter any pregap except 00:00:00, it's not very usefull but sometime I have a non-accurate rip with a non-00:00:00 pregap & a high CTDB confidence and CTDB telling me that a pressing with pregap 00:00:00 exists ... in that special case I'd like to be able to overwrite the pregap in the CUE without editing it manually, in order to simply check the confidence with PG 00:00:00.

2: Force to test without CD-Extra Data even if there is a bonus track length in the CTDB database which is automatically added, as most of the time, the automatically added length is correct, but not always.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2837
Yesterday I was surprised, I thought Cuetools was able to verify pressings with different offset automatically and I realized it was not always the case.

Before fixing the offset manually: (Not accurate)

Code: [Select]
[CUETools log; Date: 20/07/2016 06:01:28; Version: 2.1.6]
[CTDB TOCID: FJE5bHuttMI.k7ZJG_ShMtRgoNo-] found.
        [ CTDBID ] Status
        [4960160e] (16/16) Accurately ripped
Track | CTDB Status
  1   | (16/16) Accurately ripped
  2   | (16/16) Accurately ripped
  3   | (16/16) Accurately ripped
  4   | (16/16) Accurately ripped
  5   | (16/16) Accurately ripped
  6   | (16/16) Accurately ripped
  7   | (16/16) Accurately ripped
  8   | (16/16) Accurately ripped
  9   | (16/16) Accurately ripped
 10   | (16/16) Accurately ripped
 11   | (16/16) Accurately ripped
 12   | (16/16) Accurately ripped
 13   | (16/16) Accurately ripped
 14   | (16/16) Accurately ripped
 15   | (16/16) Accurately ripped
 16   | (16/16) Accurately ripped
 17   | (16/16) Accurately ripped
[AccurateRip ID: 0025e3fc-01ebb30d-e70fa511] found.
Track   [  CRC   |   V2   ] Status
 01     [1119c2ae|5c8a5a62] (0+0/4) No match
 02     [4a4667c4|489a7912] (0+0/4) No match
 03     [17f79a3c|e7085aa5] (0+0/4) No match
 04     [bba8b337|91d1d4b8] (0+0/4) No match
 05     [20c25d31|6ccba031] (0+0/4) No match
 06     [900ca1dc|f061f75d] (0+0/4) No match
 07     [1473cf38|d62bb70b] (0+0/4) No match
 08     [155dac0e|de8857f3] (0+0/4) No match
 09     [4dc0b8f8|f7e792ee] (0+0/4) No match
 10     [5c3bda5f|8412677b] (0+0/4) No match
 11     [96f35c77|f7ef8664] (0+0/4) No match
 12     [ae06e6ba|71d5f14c] (0+0/4) No match
 13     [73db24ce|69fd7ede] (0+0/4) No match
 14     [f37febc9|3ca717d3] (0+0/4) No match
 15     [fb719bd0|b05afe4d] (0+0/4) No match
 16     [1d5413c7|33b843f6] (0+0/4) No match
 17     [71e6694d|b31d295f] (0+0/4) No match
Offsetted by 667:
 01     [f4b37882] (0/4) No match (V2 was not tested)
 02     [19bfc8ac] (0/4) No match (V2 was not tested)
 03     [18482812] (0/4) No match (V2 was not tested)
 04     [0ba29c5e] (0/4) No match (V2 was not tested)
 05     [f78bf496] (0/4) No match (V2 was not tested)
 06     [4dfdfe3c] (0/4) No match (V2 was not tested)
 07     [d3b8b914] (0/4) No match (V2 was not tested)
 08     [f4de77f4] (0/4) No match (V2 was not tested)
 09     [0d5abad6] (0/4) No match (V2 was not tested)
 10     [b0e8e9d5] (0/4) No match (V2 was not tested)
 11     [3f125ab3] (0/4) No match (V2 was not tested)
 12     [5882633b] (0/4) No match (V2 was not tested)
 13     [e2fdca3b] (0/4) No match (V2 was not tested)
 14     [60b05e38] (0/4) No match (V2 was not tested)
 15     [9cc72543] (0/4) No match (V2 was not tested)
 16     [dcac27da] (0/4) No match (V2 was not tested)
 17     [1bc80690] (0/4) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL]
 --  100,0 [D790BC83] [EBD10AB9]          
 01   98,8 [5A304890] [9D1CDDFA]          
 02   98,8 [ABED67C9] [8BBEE65F]          
 03   98,8 [EC11C3D8] [E0D4AD23]          
 04   98,8 [664C7EB4] [8A64C043]          
 05   98,8 [37A9D3D9] [103B3090]          
 06   98,8 [DFE5262B] [378BDFF5]          
 07   98,8 [E0765CC3] [E3921E80]          
 08   98,8 [04E4EE5C] [FB09F0D8]          
 09   98,7 [1BB4C16E] [11BBBF09]          
 10   98,8 [FCDFB00E] [44299CCA]          
 11   98,8 [08892148] [C0E24480]          
 12   98,8 [F88319F3] [52C69A3A]          
 13  100,0 [3A3F14EE] [0B3EB7DE]          
 14   98,8 [1274678F] [98350307]          
 15   98,8 [FED211D7] [EE3F9CB0]          
 16   98,8 [CE3261CA] [0D3C74B2]          
 17   98,8 [FA20A189] [97703284]          

After fixing the offset manually (Accurate) :

Code: [Select]
[CUETools log; Date: 20/07/2016 18:18:46; Version: 2.1.6]
Offset applied: 667
[CTDB TOCID: FJE5bHuttMI.k7ZJG_ShMtRgoNo-] found.
        [ CTDBID ] Status
        [4960160e] (16/16) Accurately ripped
Track | CTDB Status
  1   | (16/16) Accurately ripped
  2   | (16/16) Accurately ripped
  3   | (16/16) Accurately ripped
  4   | (16/16) Accurately ripped
  5   | (16/16) Accurately ripped
  6   | (16/16) Accurately ripped
  7   | (16/16) Accurately ripped
  8   | (16/16) Accurately ripped
  9   | (16/16) Accurately ripped
 10   | (16/16) Accurately ripped
 11   | (16/16) Accurately ripped
 12   | (16/16) Accurately ripped
 13   | (16/16) Accurately ripped
 14   | (16/16) Accurately ripped
 15   | (16/16) Accurately ripped
 16   | (16/16) Accurately ripped
 17   | (16/16) Accurately ripped
[AccurateRip ID: 0025e3fc-01ebb30d-e70fa511] found.
Track   [  CRC   |   V2   ] Status
 01     [f4b37882|33435413] (0+4/4) Accurately ripped
 02     [19bfc8ac|0984b049] (0+4/4) Accurately ripped
 03     [18482812|d44093d6] (0+4/4) Accurately ripped
 04     [0ba29c5e|ec114523] (0+4/4) Accurately ripped
 05     [f78bf496|3d6ed076] (0+4/4) Accurately ripped
 06     [4dfdfe3c|5be027bd] (0+4/4) Accurately ripped
 07     [d3b8b914|86942f6e] (0+4/4) Accurately ripped
 08     [f4de77f4|b7fae96d] (0+4/4) Accurately ripped
 09     [0d5abad6|8db9a53e] (0+4/4) Accurately ripped
 10     [b0e8e9d5|1a74c90a] (0+4/4) Accurately ripped
 11     [3f125ab3|9fc472ac] (0+4/4) Accurately ripped
 12     [5882633b|1868d81b] (0+4/4) Accurately ripped
 13     [e2fdca3b|d5ddf15d] (0+4/4) Accurately ripped
 14     [60b05e38|a061772e] (0+4/4) Accurately ripped
 15     [9cc72543|75bc2576] (0+4/4) Accurately ripped
 16     [dcac27da|f788f3ef] (0+4/4) Accurately ripped
 17     [1bc80690|3ad45fbd] (0+4/4) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  100,0 [3DAFCCF6] [EBD10AB9]          
 01   98,8 [47F69EA5] [7D6BB354]          
 02   98,8 [3AFEB0FE] [E8C695D5]          
 03   98,8 [2E3FFF18] [1DA7215B]          
 04   98,8 [A88A6210] [DEC72C5E]          
 05   98,8 [8499EDB3] [5D786BAE]          
 06   98,8 [E793291F] [B260FA5B]          
 07   98,8 [E2444CD0] [EABB0EE8]          
 08   98,8 [D0E24621] [45EEBC97]          
 09   98,7 [B4685EED] [55DB28CE]          
 10   98,8 [81A5A9D4] [01E48252]          
 11   98,8 [422329BF] [72E0357E]          
 12   98,8 [59BA900F] [F3F3368B]          
 13  100,0 [3D90862C] [E4340417]          
 14   98,8 [83F3F19B] [68D4FCF6]          
 15   98,8 [B0AD8226] [C05CF207]          
 16   98,8 [AA15B1DE] [2E26F637]          
 17   98,8 [9C74A495] [92DE76A7]

Is this normal ? I thought Cuetools was able to check a rip with a bad offset automatically ... Is it just me who was wrong assuming Cuetools could do it ? I was kinda shocked as I may have deleted a bunch of perfectly valid rips due to my assumption ...

Quote from Cuetools Wiki:
Quote
The unique feature of CUETools AccurateRip verification is offset detection. A rip that was made without offset correction can still be verified against the database; the offset can be found and corrected.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2838
AccurateRip V2 CRC is fundamentally broken... It was supposed to be better than V1 in avoiding collisions (it is not), but instead it lost the symmetry that allowed V1 to be offset-corrected. A choice of a well-designed CRC like CRC32 would solve both problems, unfortunately that path wasn't taken. Which was part of the reason why CTDB now has per-track CRCs.
CUETools 2.1.6

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2839
OK thks for the quick answer ... this is getting really tricky. Let me summarize what I think I understund so far, plz correct me if I assume anything wrong.

- Accuraterip V2 is a correct CRC for corruption verification but is broken for offset detection, right ? (I assume that because otherwise I guess you would have completely removed it, no ?)

quote from Cuetools Wiki on V2

Quote
No match (V2 was not tested) NEW in 2.1.4
    Track starts at correct position (for that offset) but CRC doesn't match, possible ARv2 CRC matches

(ARv2 is only tested at zero offset)

So in my case/exemple above, the rip after offset correction is accurate, right ?

Now this leads me to 2 questions:

- How is it possible that accuraterip CRC V2 would be a 100% match & accuraterip CRC V1 would be a 0% match ? (unless V2 is completely broken for corruption check too, cf. the case above)

- I just checked a couple of recent 2016 releases to compare V1 vs. V2 confidence, it seems most of them rely on V2, so am I right to assume that, as of now, Accuraterip somehow relies on V1 to find the offset & on V2 to check the CRC, right ?

If all the above is not completely wrong, then why CRC V2 is not tested outside of offset 0 ? Then my rip would have been accurate from the begining & this discussion would not have occured.

There must be something I don't get here because either V2 is completely wrong (both for offset & check) & it should be removed ... or it is at least OK for verification & then it should be used by default (even outside of offset zero) ... finally, if V2 is ok for verification how can it be that both disagree (cf. case above) ... I mean if I compare with .sfv & .md5 checksums, if I have both a .sfv & a .md5 of the same set of files & the md5 checksum says it's ok, then the probability that the .sfv says the files are OK too is very high ... the way I see it, it should be similar with Accuraterip V1 & V2.

I must be missing something somewhere. Again thks for trying to explain ;)

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2840
Accuraterip V2 is about as good for corruption verification as V1. It's flawed, but definitely good enough.
And yeah, it's broken for non-offset corrected verification. E.g. you have to recalculate it from scratch for every offset that you want to verify, unlike symmetrical CRCs such as AR V1/CRC32 that allow you to "offset-correct" a CRC without re-processing the whole data.

Quote
So in my case/exemple above, the rip after offset correction is accurate, right ?
Yes.

Quote
- How is it possible that accuraterip CRC V2 would be a 100% match & accuraterip CRC V1 would be a 0% match (unless V2 is completely broken for corruption check too, cf. the case above)
No match doesn't mean that it's corrupted - it just means that there were no matches, e.g. no submissions in the database with CRC that equals V1 CRC of your tracks. I assume this is a new CD and nobody ever copied it using old AccurateRip software that produces V1 CRCs.

Quote
- I just checked a couple of recent 2016 releases to compare V1 vs. V2 confidence, it seems most of them rely on V2, so am I right to assume that, as of now, Accuraterip somehow relies on V1 to find the offset & on V2 to check the CRC.
Yes. For each track, AccurateRip returns keeps pairs of CRCs - one for offset detection (which is a CRC of a short fragment of a track), and one actual CRC for the whole track. Surprisingly, the first one is always V1.

Quote
If all the above is not completely wrong, then why CRC V2 is not tested outside of offset 0 ? Then my rip would have been accurate from the begining & this discussion would not have occured.
Because it would take at least twice the time to do verification - once to find offsets, and then potentially many times to calculate CRCs with offsets found in step one.
CUETools 2.1.6

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2841
Thanks a lot for the clarification ;) I "more or less" knew all that, especially as I read most of this thread, yet I didn't realize its implication on rips tagged as "V2 was not tested" ... from now on, I will take special care of those ... damned, I think I deleted a whole lot of perfect rips over the years ;(

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2842
FLACCL: hi-res audio support refers to the CUETools.FLACCL.cmd.exe command-line tool.

CUETools.exe still only accepts PCM (or lossless) Red Book audio input. You will still receive an "Exception: Audio format is not Red Book PCM" in CUETools if you try to input other than 16-bit, 44.1kHz stereo.


Any chance to remove this limitation in an update?

It would be really nice to be able to use CT for images od DTS-CDs, or audio rips from DVDs and BDs in format of one file + cue to split to tracks.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2843

Any chance to remove this limitation in an update?

It would be really nice to be able to use CT for images od DTS-CDs, or audio rips from DVDs and BDs in format of one file + cue to split to tracks.

It would be gr8 if that limitation could be removed.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2844
This limitation was actually useful to me more than once, so if ever you remove it plz make it optional, so that you're still warned that you're processing 24bit or mono files without having to check.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2845
Hi there,

I'm using CUETools for two or three years now and I'm very happy with it. But some months ago I started to run into some problems with the ripper and I don't know why.
It doesn't load/find most of my recently bought CDs although they are present in the MusicBrainz database (I even submitted most of them on my own to MusicBrainz). Clicking "refresh" doesn't change a thing but when I click on the MusicBrainz logo in the right lower corner the CD is found at once in the MusicBrainz database in my browser. So the information IS in the MusicBrainz database, my CUERipper somehow just fails to find and catch it there.

My system:
i7 2600K (not overclocked)
GTX 970
8GB RAM
LG CH10LS20 with firmware 1.02
Windows 10 64bit updated from Windows 7 64bit

What I already tried:

- lots of googeling hoping to find the answer
- CUETools versions 2.1.4. to 2.1.6. with deleted custom settings/default settings
- changing CTDB server in the options to freedb.musicbrainz.org, http://freedb.musicbrainz.org:80/~cddb/cddb.cgi and freedb.freedb.org
- most of my CDs which have been found in the database by CUERipper before

Any ideas on how to solve my problem? CUERipper really is my favorite CD ripper and I don't want to have to look for another program. :-/

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2846
MusicBrainz updates its schema and replication software from time to time, and every time it does, i need to do some changes on the server to make it update again. They did it again around May i think, but i somehow missed it, so ctdb's copy of musicbrainz started falling behind. I've started fixing it a few weeks ago, together with moving wiki to cue.tools domain, upgrading the server and other maintenance tasks, but got distracted ;) I'll try to find the time in coming weeks.
CUETools 2.1.6

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2847
hi there.
i've been trying cueripper today on Win10 and... no audio gets extracted at all, only the cue sheet is created :-) and it all ends with a message that the extracted HTOA track cannot be found. before I go and start ranting... is there any debug mode / extra information I can collect and analyze? btw, same in 2.1.6.
thanks!

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2848
I'm running Cuetools 2.1.5 under Windows 10 x64. The problem I have is that when encoding a CD ripped as separate ALAC tracks in iTunes to a single FLAC file, Cuetools is telling me that one particular ALAC file is not ALAC. The CD is CD1 of Pink Floyd's The Wall: as soon as I click the "Go" button in Cuetools, I get the error msg ".\1-01 In The Flesh_.m4a: Expecting ALAC data format." The file is definitely ALAC - when I look at info for the track in iTunes, it is shown as Apple Lossless audio file. I also completely deleted the album from iTunes and re-ripped all tracks as lossless, but still have the same problem when trying to encode to FLAC. Other Pink Floyd albums that are identically ripped - DSoTM, The Final Cut, and CD2 of The Wall, encode to FLAC no problem.

I've attached screen dumps of the Cuetools error msg and the file properties dialog from iTunes.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2849
Cuetools is telling me that one particular ALAC file is not ALAC.
That exception appears when a specific section of data is not exactly as expected. The developer would be able to explain better than I. Hopeful he replies.
korth