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: Accuraterip ... AR but maybe damaged (Read 11864 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Accuraterip ... AR but maybe damaged

Hi, I just searched for doublons/clones in my flac collection with cuetools & CloneSpy (a clone finder software) & I happened to find something strange: a clone with an overall different checksum (so technically CloneSpy doesn't detect it as a clone) [Edit: My collection is only made CDImage.flac] but with all matching checksums against the accuraterip database & with a very high confidence for all tracks. So the data is obviously the same ... but there is a problem: the CRC for track 1 with or without silence at the end of the log doesn't match, hence the overall checksum difference & the non detection as an exact clone by CloneSpy. So my question is: am I right to interpret this situation as a non-detected scratch (or truncated audio) in one of the 2 rips ? I mean a scratch (or truncated audio) located in the 5 first frames of the rip which accuraterip might ignore ? (I know AR ignore the last 2940 samples but does it also ignore the first 2940 samples which might be the problematic part in my case). Is my interpretation of the problem right ? or is there another explanation ?

Here is a copy/paste zoom in the problematic part of the logs:
Log1: All tracks accurate
Code: [Select]
Track    [ CRC32  ]    [W/O NULL]    
--    [BB8A18D4]    [C665239A]    
01    [52E2E723]    [303E0CCB]

Log2: All tracks accurate same checksums for individual tracks in the beginning except at the end:
Code: [Select]
Track    [ CRC32  ]    [W/O NULL]  
--    [C96571CF]    [212E440F]    
01    [D84FE9DB]    [13FF4095]


Here are the full cuetools logs:
Code: [Select]
[Verification date: 19/04/2010 22:51:27]
[Disc ID: 0014baf9-00b63a6b-a20c650b]
Track    [ CRC    ] Status
01    [56227f15] (130/227) Accurately ripped
02    [1a28dd82] (129/226) Accurately ripped
03    [6116e989] (128/224) Accurately ripped
04    [1ee3eb35] (130/226) Accurately ripped
05    [9b0f8709] (129/226) Accurately ripped
06    [6731bd99] (129/224) Accurately ripped
07    [2127ab0e] (130/225) Accurately ripped
08    [d6d7a06d] (129/223) Accurately ripped
09    [0940c3c4] (129/223) Accurately ripped
10    [9f0066c1] (131/224) Accurately ripped
11    [b372f2be] (127/219) Accurately ripped
Offsetted by -669:
01    [24323cd0] (92/227) Accurately ripped
02    [ee621a53] (95/226) Accurately ripped
03    [085e2055] (94/224) Accurately ripped
04    [3887918a] (94/226) Accurately ripped
05    [527338a1] (95/226) Accurately ripped
06    [1326e7e5] (93/224) Accurately ripped
07    [5c9d3731] (90/225) Accurately ripped
08    [212cde25] (89/223) Accurately ripped
09    [55786f8a] (92/223) Accurately ripped
10    [d05af285] (88/224) Accurately ripped
11    [344ff140] (87/219) Accurately ripped
Offsetted by -664:
01    [c47bf19e] (02/227) Accurately ripped
02    [1f296cf7] (02/226) Accurately ripped
03    [e964ac04] (02/224) Accurately ripped
04    [1c74678b] (02/226) Accurately ripped
05    [447707e9] (02/226) Accurately ripped
06    [2daa732f] (02/224) Accurately ripped
07    [06726fee] (02/225) Accurately ripped
08    [855005de] (02/223) Accurately ripped
09    [84fdb1e5] (02/223) Accurately ripped
10    [e48a9fd2] (02/224) Accurately ripped
11    [a0d957ca] (02/219) Accurately ripped

Track    [ CRC32  ]    [W/O NULL]    
--    [BB8A18D4]    [C665239A]    
01    [52E2E723]    [303E0CCB]    
02    [3898BA23]    [EC67745A]    
03    [298AA727]    [B5195132]    
04    [E1B43F46]    [CFA333F1]    
05    [2B362BD5]    [BCA7E87C]    
06    [A7D2A800]    [54FD2C90]    
07    [9FB44339]    [6E321D61]    
08    [C256DF0E]    [A744BA17]    
09    [721A93ED]    [643A858C]    
10    [380C3FD2]    [8B338E6B]    
11    [9B821032]    [E0D42D60]
   

Code: [Select]
[Verification date: 19/04/2010 22:56:03]
[Disc ID: 0014baf9-00b63a6b-a20c650b]
Track    [ CRC    ] Status
01    [56227f15] (130/227) Accurately ripped
02    [1a28dd82] (129/226) Accurately ripped
03    [6116e989] (128/224) Accurately ripped
04    [1ee3eb35] (130/226) Accurately ripped
05    [9b0f8709] (129/226) Accurately ripped
06    [6731bd99] (129/224) Accurately ripped
07    [2127ab0e] (130/225) Accurately ripped
08    [d6d7a06d] (129/223) Accurately ripped
09    [0940c3c4] (129/223) Accurately ripped
10    [9f0066c1] (131/224) Accurately ripped
11    [b372f2be] (127/219) Accurately ripped
Offsetted by -669:
01    [24323cd0] (92/227) Accurately ripped
02    [ee621a53] (95/226) Accurately ripped
03    [085e2055] (94/224) Accurately ripped
04    [3887918a] (94/226) Accurately ripped
05    [527338a1] (95/226) Accurately ripped
06    [1326e7e5] (93/224) Accurately ripped
07    [5c9d3731] (90/225) Accurately ripped
08    [212cde25] (89/223) Accurately ripped
09    [55786f8a] (92/223) Accurately ripped
10    [d05af285] (88/224) Accurately ripped
11    [344ff140] (87/219) Accurately ripped
Offsetted by -664:
01    [c47bf19e] (02/227) Accurately ripped
02    [1f296cf7] (02/226) Accurately ripped
03    [e964ac04] (02/224) Accurately ripped
04    [1c74678b] (02/226) Accurately ripped
05    [447707e9] (02/226) Accurately ripped
06    [2daa732f] (02/224) Accurately ripped
07    [06726fee] (02/225) Accurately ripped
08    [855005de] (02/223) Accurately ripped
09    [84fdb1e5] (02/223) Accurately ripped
10    [e48a9fd2] (02/224) Accurately ripped
11    [a0d957ca] (02/219) Accurately ripped

Track    [ CRC32  ]    [W/O NULL]    
--    [C96571CF]    [212E440F]    
01    [D84FE9DB]    [13FF4095]    
02    [3898BA23]    [EC67745A]    
03    [298AA727]    [B5195132]    
04    [E1B43F46]    [CFA333F1]    
05    [2B362BD5]    [BCA7E87C]    
06    [A7D2A800]    [54FD2C90]    
07    [9FB44339]    [6E321D61]    
08    [C256DF0E]    [A744BA17]    
09    [721A93ED]    [643A858C]    
10    [380C3FD2]    [8B338E6B]    
11    [9B821032]    [E0D42D60]


Note:
The album is Pantera - 1992 - Vulgar Display Of Power original pressing
& I know that:
Code: [Select]
Track    [ CRC32  ]    [W/O NULL]    
--    [BB8A18D4]    [C665239A]    
01    [52E2E723]    [303E0CCB]

is the good checksum if one of the 2 is bad. (I compared my own rip with several 3rd party rips as I own the CD ... it's one of the best heavy metal album of all time)

So the question is not which one is the good rip but rather what is happening technically & why a rip  which, at first look, is perfectly accurate rip is in fact maybe damaged.

I am worried because it was one of the very first doublon I found ... so it might not be such an exception ... I am scarred to search further now ...

Edit: By the way, we need an april update of the database Spoon

Accuraterip ... AR but maybe damaged

Reply #1
Would this be a case of someone submitting a damaged cd to the database over & over with different drives/different computers? If I'm wrong please tell me harshly

Accuraterip ... AR but maybe damaged

Reply #2
You're right sauvage78, AR does not cover the first five frames of the first track.  I don't know that I would conclude that the data in one of the tracks is in error, however.  Perhaps it's just a slight difference in pressings or rips that differed by a lack of overreading.  It could be one of your downloads came from a CD-R that was missing the first few samples of data as a result of not being able to overwrite.  You'd need to look at the raw files to have a better idea.

Accuraterip ... AR but maybe damaged

Reply #3
Thks for the hint Greynol,
I splitted the first track with F2K & had a closer look with Audacity, the audio data looks very similar & the audio seems to start after 1 second (see the screenshots) ... so if AR ignore the 5 frames it means that it ignores 5/75 of a second which is even more problematic for me, because it means that:
1- the difference is not in the first 5 frames (as it looks flat/silent in Audacity)
2- in the same time the difference is not after the 5 first frames as the AR checksum for track 1 matches ...

... this sounds impossible to me ...

Some Audacity screenshots:

Zoomed:


The md5 checksum of the audio data in F2K is also not the same between the 2 splitted track 1.

Accuraterip ... AR but maybe damaged

Reply #4
You should really inverse paste one onto the other and zoom in on the difference to see if there is any.

If you want to upload the first five frames of each version of the first track I'll gladly do it for you.

Accuraterip ... AR but maybe damaged

Reply #5
I have uploaded the 5 first frames of the 2 rips (Track 1) here

The result looks flat/silent in Audacity but the flac MD5 checksum in F2K is different so I guess that being flat in Audacity doesn't always mean silence, specially if the noise is almost zero.

I don't know how to achieve this in Audacity:
Quote
You should really inverse paste one onto the other and zoom in on the difference to see if there is any.
my skill with Audacity is very limited, basically I only use it to cut/shorten samples when I when I want to run an ABX test.

Thanks for trying to help.

Edit:
For me it looks more & more like a very small scratch within the 5 first frames which makes me wonder if 4 frames/2352 samples wouldn't be a better number than 5 frames/2940 samples for the beginning/end ... specially as the huge majority of drives (seems all) have an offset below 2000 samples.

Personnaly I don't really care if a few exotic drives cannot be used with Accuraterip if it slightly strengthen the confidency of all the other rips in the world. But I agree 1 frame will not solve the problem anyway...

The drive with the biggest offset in the database seems to be:
ASUS - CD-S480-A5    +1776
which means that 4 frames/2352 samples would be enough ... & with a good margin. (2352-1776=576=almost 1 frame of margin already)

5 frames seems more & more overkill to me. It's 1 frame of verification lost in the beginning & another one lost in the end for no real gain/safety compared to the drive offset list.
I know 2 frames is ridiculously small, but still ... it seems that my exemple shows that bad thing can happen within this 2 frames ... as small as those can be.

Edit 2: (Found a bigger offset in the database)

Accuraterip ... AR but maybe damaged

Reply #6
I have a feeling that you've either cut the wrong part or have dither applied to your samples since the data you've submitted is entirely different between the two files.  In addition it looks nothing like the first five frames of the first track on this particular pressing in question which I also happen to have:
Code: [Select]
01    [52E2E723]    [303E0CCB]

My suggestion at this point is to look over your settings (I'd provide more help but I don't use Audacity) to make sure your program isn't doing more than simply splitting data.  Larger samples (~5 seconds) would be my next request so that I can be sure that there are no differences beyond the first five frames.

I do not think that extending the AR data by one frame is going to make help things, instead it's going to make things more difficult for those who use CUETools and the new CTDB; not to mention invalidate all previous first track submissions for those using the new version, unless both are calculated.  This is really no different than the request that a separate submission is kept for drives that can overread.  IIRC, spoon wasn't interested in supporting the idea.

Accuraterip ... AR but maybe damaged

Reply #7
I have re-splitted the 5 first frames with Audacity & re-encoded to Flac with F2K ... guess what ... now the flac MD5 doesn't match between the 2 splitting ... so as I am using a beta version of Audacity I guess it might be more buggy than I thought ... sorry ... if you know a better free tool for the job let me know ...

It cannot be the wrong part or a dithering problem IMHO, but I agree adding 1 frame to the database is not really worth it as it brings a lot of trouble for the small gain ... it's just sad that Spoon made the mistake of chosing 5 frames instead of 4 ... I guess he was conservative in case a future drive pops up with an offset bigger than 4 frames ... I'll have to live with that.

Edit: I'll try the last stable version of Audacity to see if I can get more reliable results in the splitting.

Accuraterip ... AR but maybe damaged

Reply #8
I don't find it sad at all, in fact I think 5 frames is perfect.

EDIT: Looking over the database, I recall there once being drives that required and offset correction of more than 2000 samples a couple of years ago.  I guess they were purged.  I have a couple of drives that require an offset correction of +1858 for which the AR dll failed to get data.  Spoon suggested these drives had an Accurate Stream problem, though I have never once had such a problem with them.

Hope you get your splitting situation straightened out, dither is the only explanation I can come up with for why your samples are so botched; unless you know of some other reason why Audacity would randomize data.

Accuraterip ... AR but maybe damaged

Reply #9
Audacity always apply dithering for saved files, no matter what. As default, the WAVs will be manipulated as 32-bit float, but even when you change the settings to 16-bit and tell it to not dither, it will. They are working a fix for this for 1.4.0.

Accuraterip ... AR but maybe damaged

Reply #10
krafty:
Thks a lot for your insight. I'll get my hands on Adobe Audition which I was using before Audacity & re-upload the correct files later.



Accuraterip ... AR but maybe damaged

Reply #13
So the question is not which one is the good rip but rather what is happening technically & why a rip  which, at first look, is perfectly accurate rip is in fact maybe damaged.


seems rather simple to me, errors within the ignored sample ranges, are ignored.


Accuraterip ... AR but maybe damaged

Reply #15
ok well, whether they are errors are not is irrelevant:

let me rephrase my previous assertion, differences within the ignored sample ranges, are ignored

Accuraterip ... AR but maybe damaged

Reply #16
Thks Alex B
I have used Sox to re-cut the samples which are now available Here. I have a working Audition installed now but after struggling for 10min with the interface I gave up & finally used Sox. It's paradoxal but there is so many graphical options that I finally decided to go for a command line ... I have used Audition in the past but only to compare frequency analysis, not for edition ...

My new files still have different flac MD5 & still look flat/silent to me. I hope one of the 2 samples matches your own rip now (should be the first one). I am curious to know why there is a difference between the 2 samples, specially if it looks like a scratch/glitch or if it's something else for you.

Accuraterip ... AR but maybe damaged

Reply #17
The first 472 samples are null in the second file, the rest of the samples are identical.  This is consistent with a drive that requires a read offset correction of -472 that is not configured to overread into the lead-in.  There are several such drives listed in the AR offset database.

If I calculate the CRC for my track with the first 472 samples nulled I get D84FE9DB.

Accuraterip ... AR but maybe damaged

Reply #18
Thx a lot Greynol ! I understand that it is not a scratch now, but can you tell me how you analyse the audio to get these informations, plz ? All I see in Audition is ... nothing no matter how I zoom or what view I chose. I obviously lack the right methodology in case I encounter the problem later. I'd rather learn right now than annoy you again in the future.

Accuraterip ... AR but maybe damaged

Reply #19
You're welcome, sauvage78, I'm happy to help.

I'm not sure what version of Audition you use.  For those just using it for audio, it turned into some pretty serious bloat-ware after 1.5, IMO (I'm still using 1.0).

To zoom I just use the buttons in the bottom row.  There are a pair to zoom in and out in amplitude, five that allow you to zoom in time (in, out, selection, right edge of selection, left edge of selection), and one to zoom out to show the full waveform once again.

To subtract one waveform from another, you just perform a mix-paste ctrl+shift+v and select the L and R invert checkboxes.  Depending on what I'm doing, I'll usually load multiple waves in the multi-track editor and slide one relative to the other to time-align.

I've been using this program since back when it was Cool Edit Pro, so I take these types of things for granted.  Because I am so used to this program I have never liked using any other editors.  I've tried Audacity on many occasions.  Besides this problem with dithering (which makes it a non-starter for me) I would never claim that it is a bad program, just that I have difficulty working within it because I'm so accustomed to Audition.  Who knows though, it took a while and now I've warmed up to Mp3tag after using TagScanner for such a long time.

Accuraterip ... AR but maybe damaged

Reply #20
Again, thks for trying to help.

Sorry for the delay, but I was struggling with various softwares in order to try to achieve the same result as yours which actually I didn't succeed (yet). I have installed Audition 3.0 but I didn't have any luck with it. I founded it increadibly huge & bloated compared to my rememberance of Cool Audio Edit. So I get back to Cool Audio Edit Pro V2.1 which is much more suited for my needs (I like fast & small, efficient software ... & if possible free) ... basically the interface is the same than Audition but I don't know why I finally found a non-flat curve with Cool Audio Edit Pro after much zooming. I think my problem might come from the fact that I don't zoom enougth due to the unusual shortness of the files. I don't like using non-supported software, so even if great & even I had a begining of success, I don't see myself using Cool Audio Edit nowaday, it would be like going back 10 years ago (& I hate Adobe & what it has done to it to be honest  ) ... so I tried the lastest Wavelav too ... which lasted 5 min on my drive as I don't like the interface ... I was wondering if I should try Sound Forge but I gave up the idea when I saw that it has some support for video ... which is definitely not something I want in an audio editor ...

I finally get bored of all these huge & slow audio editors, specially as trying all these expensive softwares forced me to install Antivir which slow down my poor Sempron 3000+ (Barton) even more ... so in the end, I have uninstalled & deleted everything !!!

I'll try again with Audacity later, right now I am playing with Wavosaur to see if I can split without automatic dithering which is also an Audacity non-starter for me.

Your advice doesn't seem that hard with the right tool, unfortunately I don't want to use Cool Edit. I don't now why I was so unsuccessfull. I must have done something wrong to begin with or I have became completely dumb. Anyway I'll try again later as actually I am bored