Skip to main content
Topic: Small bug in XLD's "Check files with AccurateRip" & (Read 3350 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Small bug in XLD's "Check files with AccurateRip" &

Quote
My intended title got cut: Small bug in XLD's "Check files with AccurateRip" & "Detect Offset"???
So, I'm not SAYING it's a bug... I'm just posting to see what you guys think of it, ok?


I have just sent this to tmkk:


I have a CD I have just checked the offset, to see if I needed to perform any correction...
The CD was found in AccurateRip database, with a confidence level of 3.
There's also another pressing (probably) which also has a confidence level of 3...

Here's just an excerpt from the log...
Code: [Select]
List of suggested offset correction values
    (1) 644 (confidence 3)

All Tracks
    Album gain : -1.95 dB
    Peak       : 0.999939

Track 01
    Track gain             : -3.04 dB
    Peak                   : 0.999939
    CRC32 hash             : 335F2B05
    CRC32 hash (skip zero) : 5DA1EE83
    AccurateRip signature  : E365505F
        ->Accurately ripped! (confidence 3)

Track 02
    Track gain             : 4.62 dB
    Peak                   : 0.490479
    CRC32 hash             : FD5F9AAF
    CRC32 hash (skip zero) : FAAE4100
    AccurateRip signature  : FB603D04
        ->Accurately ripped! (confidence 3)


The rip looks good (all tracks have the same AccurateRip confidence level of 3) and doesn't need any additional offset correction...
But here's what happens when I select "Detect offset" from the menu:



The alternate offset is selected as the default one, although my rip is present on AccurateRip and the confidence level is the same...

Am I wrong to think this is a bug?
As far as I understand it, as long as the rip IS present on AccurateRip (all tracks), the rip is fine and it shouldn't be recommended to perform an offset correction even if the other pressing had a higher AccurateRip confidence level (unlike in this case... it was the same)...

Small bug in XLD's "Check files with AccurateRip" &

Reply #1
It would be easier to assess this if you could do a quick burst rip of track 2 and show us what the alternate offsets are on the newer XLD log.

I would think that 644 is an alternate (or as XLD confusingly puts it, "suggested") offset.

A log would straighten this out really quickly.

Small bug in XLD's "Check files with AccurateRip" &

Reply #2
It would be easier to assess this if you could do a quick burst rip of track 2 and show us what the alternate offsets are on the newer XLD log.

But I can't... This is not my rip... I only have the files and I was using XLD's capabilities to check existing rips against AccurateRip...

 

Small bug in XLD's "Check files with AccurateRip" &

Reply #3
I'll try running loading one of my own cue sheets and see what the alternate offsets are.

I'll post the results soon.

 
SimplePortal 1.0.0 RC1 © 2008-2020