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- Strange Transcoding Behaviour (Read 3451 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Cuetools- Strange Transcoding Behaviour

I'm trying to transcode one of my albums in cuetools 2.1.5 from flac -5 to flac -8 and keep getting an error:

It writes to track 01 upto and above around 1200% and then gives me this message:
"Exception: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index"

Verify runs with no problem with CTDB/AR (29/261). If I create a new dummy cue sheet (which is identical according to notepad++ compare plugin) it rips with no problems but with poor results in the CTDB/AR database (29/2).

Could someone please help me understand what the heck is going on?

Original cue (identical to dummy cue):
Code: [Select]
REM COMMENT "CUETools generated dummy CUE sheet"
PERFORMER "Fleetwood Mac"
TITLE "Mirage"
REM DATE 1982
REM DISCNUMBER 1
REM TOTALDISCS 1
REM GENRE "Pop"
FILE "01 - Love In Store.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Love In Store"
    INDEX 01 00:00:00
FILE "02 - Can't Go Back.flac" WAVE
  TRACK 02 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Can't Go Back"
    INDEX 01 00:00:00
FILE "03 - That's Alright.flac" WAVE
  TRACK 03 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "That's Alright"
    INDEX 01 00:00:00
FILE "04 - Book Of Love.flac" WAVE
  TRACK 04 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Book Of Love"
    INDEX 01 00:00:00
FILE "05 - Gypsy.flac" WAVE
  TRACK 05 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Gypsy"
    INDEX 01 00:00:00
FILE "06 - Only Over You.flac" WAVE
  TRACK 06 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Only Over You"
    INDEX 01 00:00:00
FILE "07 - Empire State.flac" WAVE
  TRACK 07 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Empire State"
    INDEX 01 00:00:00
FILE "08 - Straight Back.flac" WAVE
  TRACK 08 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Straight Back"
    INDEX 01 00:00:00
FILE "09 - Hold Me.flac" WAVE
  TRACK 09 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Hold Me"
    INDEX 01 00:00:00
FILE "10 - Oh Diane.flac" WAVE
  TRACK 10 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Oh Diane"
    INDEX 01 00:00:00
FILE "11 - Eyes Of The World.flac" WAVE
  TRACK 11 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Eyes Of The World"
    INDEX 01 00:00:00
FILE "12 - Wish You Were Here.flac" WAVE
  TRACK 12 AUDIO
    PERFORMER "Fleetwood Mac"
    TITLE "Wish You Were Here"
    INDEX 01 00:00:00

Cuetools- Strange Transcoding Behaviour

Reply #1 –
CUETools can use additional data from an EAC or CUERipper log file with the same base filename as the CUE file. The difference in the two verify logs also might provide more info.

BTW, low AR numbers ≠ poor results
korth

Cuetools- Strange Transcoding Behaviour

Reply #2 –
Quote from: korth on
CUETools can use additional data from an EAC or CUERipper log file with the same base filename as the CUE file. The difference in the two verify logs also might provide more info.
Thank you that explains a lot. The log file had all pre gap lengths adjusted to 1:58:07.71. Didn't realize cuetools looked at the logs as well.

However I'm still a bit confused as to why the log makes such a big difference in verification for AR and not CT. I would have thought that having the lossless tracks alone would be enough for verification.

I do realize that the low AR does not make this a poor rip but I'd like to 'fix' this if I can.

.accurip with original log:
Code: [Select]
[CUETools log; Date: 6/1/2015 9:34:40 PM; Version: 2.1.5]
Pregap length 00:00:33.
[CTDB TOCID: emYfSYJa1Dh8z7kYN_isbwXM2GY-] found.
        [ CTDBID ] Status
        [a93bc7c9] (25/29) Accurately ripped
        [b2779332] (01/29) Has pregap length 00:00:00, No match
        [07f31337] (01/29) No match
        [7ccf083b] (01/29) No match
        [f814442c] (01/29) No match
Track | CTDB Status
  1   | (28/29) Accurately ripped
  2   | (28/29) Accurately ripped
  3   | (28/29) Accurately ripped
  4   | (28/29) Accurately ripped
  5   | (28/29) Accurately ripped
  6   | (27/29) Accurately ripped
  7   | (28/29) Accurately ripped
  8   | (28/29) Accurately ripped
  9   | (27/29) Accurately ripped
 10   | (28/29) Accurately ripped
 11   | (28/29) Accurately ripped
 12   | (27/29) Accurately ripped
[AccurateRip ID: 00129b10-00af7f2e-a60a290c] found.
Track   [  CRC   |   V2   ] Status
 01     [8e35ef7e|73c363bb] (061+068/264) Accurately ripped
 02     [a1724de2|3b6d0fbb] (063+069/266) Accurately ripped
 03     [e2ce8357|0193a0b1] (061+069/264) Accurately ripped
 04     [83ddb925|68b3ded3] (063+069/265) Accurately ripped
 05     [82160020|50e7f97b] (062+067/267) Accurately ripped
 06     [2bb47aac|ce5fcc58] (062+068/264) Accurately ripped
 07     [46404b88|5ff35ee4] (063+068/263) Accurately ripped
 08     [bee52714|ead436b0] (062+068/265) Accurately ripped
 09     [d1778ec8|00a3ee7d] (063+067/265) Accurately ripped
 10     [51c018aa|f559dcc0] (063+068/265) Accurately ripped
 11     [d6d3663b|25e557b4] (063+068/264) Accurately ripped
 12     [d85c949b|58bd8184] (061+065/261) Accurately ripped
Offsetted by -2551:
 01     [51ffb0fd] (002/264) Accurately ripped
 02     [5f31131d] (002/266) Accurately ripped
 03     [f15fdbda] (002/264) Accurately ripped
 04     [c87f65b3] (002/265) Accurately ripped
 05     [cbe3fe54] (002/267) Accurately ripped
 06     [04e42a58] (002/264) Accurately ripped
 07     [d3208392] (002/263) Accurately ripped
 08     [ffa98e01] (002/265) Accurately ripped
 09     [741d24b5] (002/265) Accurately ripped
 10     [76ccd347] (002/265) Accurately ripped
 11     [96da7930] (002/264) Accurately ripped
 12     [b7deafb8] (002/261) Accurately ripped
Offsetted by -1887:
 01     [bb2fa125] (028/264) Accurately ripped
 02     [c3541de5] (028/266) Accurately ripped
 03     [8d8b8362] (028/264) Accurately ripped
 04     [ce040783] (028/265) Accurately ripped
 05     [e5a35634] (028/267) Accurately ripped
 06     [889f2778] (028/264) Accurately ripped
 07     [b2c60a02] (028/263) Accurately ripped
 08     [5cb0bcf9] (028/265) Accurately ripped
 09     [49e0fbad] (028/265) Accurately ripped
 10     [f7a4aebf] (028/265) Accurately ripped
 11     [ec2566e8] (028/264) Accurately ripped
 12     [3a996d8f] (028/261) Accurately ripped
Offsetted by -1223:
 01     [245f914d] (015/264) Accurately ripped
 02     [277728ad] (015/266) Accurately ripped
 03     [29b72aea] (015/264) Accurately ripped
 04     [d388a953] (015/265) Accurately ripped
 05     [ff62ae14] (015/267) Accurately ripped
 06     [0c5a2498] (015/264) Accurately ripped
 07     [926b9072] (015/263) Accurately ripped
 08     [b9b7ebf1] (015/265) Accurately ripped
 09     [1fa4d2a5] (015/265) Accurately ripped
 10     [787c8a37] (015/265) Accurately ripped
 11     [417054a0] (015/264) Accurately ripped
 12     [055face8] (014/261) Accurately ripped
Offsetted by -564:
 01     [ad276f12] (011/264) Accurately ripped
 02     [d10458c6] (011/266) Accurately ripped
 03     [6a7e409b] (011/264) Accurately ripped
 04     [11af610d] (011/265) Accurately ripped
 05     [660c2610] (011/267) Accurately ripped
 06     [c1fb6f3c] (011/264) Accurately ripped
 07     [0fff43c0] (010/263) Accurately ripped
 08     [dd5f0d10] (011/265) Accurately ripped
 09     [942f48c4] (011/265) Accurately ripped
 10     [282aace6] (011/265) Accurately ripped
 11     [f73eef97] (011/264) Accurately ripped
 12     [4af2d4d3] (009/261) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --  100.0 [9315DB26] [C0DB8A57]           
 01  100.0 [47C73B57] [797D7FF7]   CRC32   
 02  100.0 [C8EE701C] [DE9333B8]   CRC32   
 03   99.8 [25E4B95A] [CC17066B]   CRC32   
 04  100.0 [4570D467] [0CDCA2A0]   CRC32   
 05  100.0 [68AE99E7] [4F6F0A67]   CRC32   
 06   77.7 [7DCE6142] [5977CCA3]   CRC32   
 07   85.0 [6A7DFE86] [BAC84FFB]   CRC32   
 08   83.6 [5FC80722] [559765DF]   CRC32   
 09   88.2 [FEE927CA] [C52782CD]   CRC32   
 10   68.5 [ED3073D6] [973D881B]   CRC32   
 11   55.7 [FE9927B7] [8E30F26E]   CRC32   
 12  100.0 [B070F6B6] [C42A6E5F]   CRC32 

.accurip without the log file:
Code: [Select]
[CUETools log; Date: 6/1/2015 9:33:04 PM; Version: 2.1.5]
[CTDB TOCID: emYfSYJa1Dh8z7kYN_isbwXM2GY-] found.
        [ CTDBID ] Status
        [a93bc7c9] (25/29) Has pregap length 00:00:33, Accurately ripped
        [b2779332] (01/29) No match
        [07f31337] (01/29) Has pregap length 00:00:33, No match
        [7ccf083b] (01/29) Has pregap length 00:00:33, No match
        [f814442c] (01/29) Has pregap length 00:00:33, No match
Track | CTDB Status
  1   | (28/29) Accurately ripped
  2   | (28/29) Accurately ripped
  3   | (28/29) Accurately ripped
  4   | (28/29) Accurately ripped
  5   | (28/29) Accurately ripped
  6   | (27/29) Accurately ripped
  7   | (28/29) Accurately ripped
  8   | (28/29) Accurately ripped
  9   | (27/29) Accurately ripped
 10   | (28/29) Accurately ripped
 11   | (28/29) Accurately ripped
 12   | (27/29) Accurately ripped
[AccurateRip ID: 00129963-00af7374-a10a290c] found.
Track   [  CRC   |   V2   ] Status
 01     [8e35ef7e|73c363bb] (0+0/2) No match
 02     [a1724de2|3b6d0fbb] (0+0/2) No match
 03     [e2ce8357|0193a0b1] (0+0/2) No match
 04     [83ddb925|68b3ded3] (0+0/2) No match
 05     [82160020|50e7f97b] (0+0/2) No match
 06     [2bb47aac|ce5fcc58] (0+0/2) No match
 07     [46404b88|5ff35ee4] (0+0/2) No match
 08     [bee52714|ead436b0] (0+0/2) No match
 09     [d1778ec8|00a3ee7d] (0+0/2) No match
 10     [51c018aa|f559dcc0] (0+0/2) No match
 11     [d6d3663b|25e557b4] (0+0/2) No match
 12     [d85c949b|58bd8184] (0+0/2) No match
Offsetted by -18:
 01     [6658e080] (1/2) Accurately ripped
 02     [ce8a076c] (1/2) Accurately ripped
 03     [33647651] (1/2) Accurately ripped
 04     [82f20809] (1/2) Accurately ripped
 05     [96fa73b8] (1/2) Accurately ripped
 06     [128b2b54] (1/2) Accurately ripped
 07     [e5335374] (1/2) Accurately ripped
 08     [bd24f53a] (1/2) Accurately ripped
 09     [a6a8feee] (1/2) Accurately ripped
 10     [60c37f70] (1/2) Accurately ripped
 11     [657a3c51] (1/2) Accurately ripped
 12     [eb031fa7] (1/2) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] 
 --  100.0 [90A90850] [C0DB8A57]           
 01  100.0 [47C73B57] [797D7FF7]           
 02  100.0 [C8EE701C] [DE9333B8]           
 03   99.8 [25E4B95A] [CC17066B]           
 04  100.0 [4570D467] [0CDCA2A0]           
 05  100.0 [68AE99E7] [4F6F0A67]           
 06   77.7 [7DCE6142] [5977CCA3]           
 07   85.0 [6A7DFE86] [BAC84FFB]           
 08   83.6 [5FC80722] [559765DF]           
 09   88.2 [FEE927CA] [C52782CD]           
 10   68.5 [ED3073D6] [973D881B]           
 11   55.7 [FE9927B7] [8E30F26E]           
 12  100.0 [B070F6B6] [C42A6E5F]         

Cuetools- Strange Transcoding Behaviour

Reply #3 –
The CTDB doesn't care about disc pregap (the pregap area of track 1 or HTOA) in order to verify a rip. AR needs this calculated into the AccurateRip ID to look up the correct records. You can see the two .accurip logs have a different AccurateRip ID. You can also see the first .accurip log has the line
Pregap length 00:00:33.

the dummy CUE did not contain the line
    PREGAP 00:00:33
before the INDEX 01 of Track 1

Since that info was also missing in the original CUE, CUETools was reading the Pregap from the EAC/CUERipper log file.

You can put 00:00:33 in the Pregap area of the Extra section (and temporarily remove the EAC/CUERipper log file from the folder like you did). Just don't forget to return the Pregap setting back to 00:00:00 after you verify/encode or it will also be applied to the future rips you process.
korth
 

Cuetools- Strange Transcoding Behaviour

Reply #4 –
Quote from: korth on
You can put 00:00:33 in the Pregap area of the Extra section (and temporarily remove the EAC/CUERipper log file from the folder like you did). Just don't forget to return the Pregap setting back to 00:00:00 after you verify/encode or it will also be applied to the future rips you process.


Thanks, that did the trick! Also found that zeroing the incorrect pregaps in the log file is a more permanent solution.