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: Problems with very short tracks? (Read 3047 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

AccurateRip: Problems with very short tracks?

yo what's up people.

I am having 2 CD-Rips here where AccurateRip returns a "no match" for every track that is <= 5 seconds short.

AccurateRip logs (CUETools):
Code: [Select]
[Verification date: 5/11/2010 12:00:16 AM]
[Disc ID: 000ebd4a-007a6364-6c0a1d0a]
Track    [ CRC    ] Status
 01    [6804ba8f] (00/00) No matches
 02    [37d4978d] (04/04) Accurately ripped as in pressing(s) #1
 03    [2967ac1d] (04/04) Accurately ripped as in pressing(s) #1
 04    [844092d7] (04/04) Accurately ripped as in pressing(s) #1
 05    [3e232506] (04/04) Accurately ripped as in pressing(s) #1
 06    [34a9ead8] (04/04) Accurately ripped as in pressing(s) #1
 07    [cec0bd74] (04/04) Accurately ripped as in pressing(s) #1
 08    [e51bc772] (04/04) Accurately ripped as in pressing(s) #1
 09    [6ee40e4f] (04/04) Accurately ripped as in pressing(s) #1
 10    [5b963488] (04/04) Accurately ripped as in pressing(s) #1

Track    [ CRC32  ]    [W/O NULL]    [  LOG   ]
 --    [4A3413D7]    [5C8DA377]    
 01    [C8C693AC]    [3FDD2513]      CRC32   
 02    [5F62CCCB]    [3E83013C]      CRC32   
 03    [9CAE9EB8]    [D122E484]      CRC32   
 04    [5C8C0984]    [F9830922]      CRC32   
 05    [6B1B5037]    [E27D523C]      CRC32   
 06    [1F232035]    [7BF41FFD]      CRC32   
 07    [E1A5C4E8]    [F3D4B2BD]      CRC32   
 08    [BE8EF847]    [01052D66]      CRC32   
 09    [D5D01C40]    [EC719512]      CRC32   
 10    [0E64EA46]    [15AD2357]      CRC32


Code: [Select]
[Verification date: 5/10/2010 10:39:24 PM]
[Disc ID: 0034cf87-02d3309a-550a9715]
Track    [ CRC    ] Status
 01    [5b917f71] (06/27) Accurately ripped as in pressing(s) #2
 02    [37cc1074] (06/28) Accurately ripped as in pressing(s) #2
 03    [8a35a1de] (06/27) Accurately ripped as in pressing(s) #2
 04    [6a5e30d9] (06/28) Accurately ripped as in pressing(s) #2
 05    [8b6e635b] (06/28) Accurately ripped as in pressing(s) #2
 06    [a7fd98c1] (06/28) Accurately ripped as in pressing(s) #2
 07    [df54c235] (06/28) Accurately ripped as in pressing(s) #2
 08    [214dd4a0] (06/28) Accurately ripped as in pressing(s) #2
 09    [3245a5fe] (06/28) Accurately ripped as in pressing(s) #2
 10    [70bdf6e5] (06/28) Accurately ripped as in pressing(s) #2
 11    [00000000] (00/00) No matches
 12    [00000000] (00/00) No matches
 13    [00000000] (00/00) No matches
 14    [00000000] (00/00) No matches
 15    [00000000] (00/00) No matches
 16    [00000000] (00/00) No matches
 17    [00000000] (00/00) No matches
 18    [00000000] (00/00) No matches
 19    [00000000] (00/00) No matches
 20    [00000000] (00/00) No matches
 21    [00000000] (00/00) No matches
Offsetted by 1189:
 01    [b66e6331] (02/27) Accurately ripped as in pressing(s) #4
 02    [e71a647c] (03/28) Accurately ripped as in pressing(s) #4
 03    [3672638a] (03/27) Accurately ripped as in pressing(s) #4
 04    [7b7d6a49] (03/28) Accurately ripped as in pressing(s) #4
 05    [1f277e8b] (03/28) Accurately ripped as in pressing(s) #4
 06    [e9177cac] (03/28) Accurately ripped as in pressing(s) #4
 07    [44b738ad] (03/28) Accurately ripped as in pressing(s) #4
 08    [3e71e3b1] (03/28) Accurately ripped as in pressing(s) #4
 09    [7944472b] (03/28) Accurately ripped as in pressing(s) #4
 10    [57e66544] (03/28) Accurately ripped as in pressing(s) #4
 11    [00000000] (00/00) No matches
 12    [00000000] (00/00) No matches
 13    [00000000] (00/00) No matches
 14    [00000000] (00/00) No matches
 15    [00000000] (00/00) No matches
 16    [00000000] (00/00) No matches
 17    [00000000] (00/00) No matches
 18    [00000000] (00/00) No matches
 19    [00000000] (00/00) No matches
 20    [00000000] (00/00) No matches
 21    [00000000] (00/00) No matches
Offsetted by 1412:
 01    [c0137caa] (04/27) Accurately ripped as in pressing(s) #3
 02    [adb5e85b] (04/28) Accurately ripped as in pressing(s) #3
 03    [5081a8ce] (04/27) Accurately ripped as in pressing(s) #3
 04    [e8339b99] (04/28) Accurately ripped as in pressing(s) #3
 05    [486ca91b] (04/28) Accurately ripped as in pressing(s) #3
 06    [b74b107d] (04/28) Accurately ripped as in pressing(s) #3
 07    [80dab295] (04/28) Accurately ripped as in pressing(s) #3
 08    [b597a814] (04/28) Accurately ripped as in pressing(s) #3
 09    [f8439722] (04/28) Accurately ripped as in pressing(s) #3
 10    [de8b5e31] (04/28) Accurately ripped as in pressing(s) #3
 11    [00000000] (00/00) No matches
 12    [00000000] (00/00) No matches
 13    [00000000] (00/00) No matches
 14    [00000000] (00/00) No matches
 15    [00000000] (00/00) No matches
 16    [00000000] (00/00) No matches
 17    [00000000] (00/00) No matches
 18    [00000000] (00/00) No matches
 19    [00000000] (00/00) No matches
 20    [00000000] (00/00) No matches
 21    [00000000] (00/00) No matches
Offsetted by 2076:
 01    [ae6c8d9f] (15/27) Accurately ripped as in pressing(s) #1
 02    [e08dc2f6] (15/28) Accurately ripped as in pressing(s) #1
 03    [91792c6e] (14/27) Accurately ripped as in pressing(s) #1
 04    [363b2419] (15/28) Accurately ripped as in pressing(s) #1
 05    [8677739b] (15/28) Accurately ripped as in pressing(s) #1
 06    [824bf565] (15/28) Accurately ripped as in pressing(s) #1
 07    [5af3f8d5] (15/28) Accurately ripped as in pressing(s) #1
 08    [9458784c] (15/28) Accurately ripped as in pressing(s) #1
 09    [ee63fb7a] (15/28) Accurately ripped as in pressing(s) #1
 10    [ea4af679] (15/28) Accurately ripped as in pressing(s) #1
 11    [00000000] (00/00) No matches
 12    [00000000] (00/00) No matches
 13    [00000000] (00/00) No matches
 14    [00000000] (00/00) No matches
 15    [00000000] (00/00) No matches
 16    [00000000] (00/00) No matches
 17    [00000000] (00/00) No matches
 18    [00000000] (00/00) No matches
 19    [00000000] (00/00) No matches
 20    [00000000] (00/00) No matches
 21    [00000000] (00/00) No matches

Track    [ CRC32  ]    [W/O NULL]    [  LOG   ]
 --    [D3F0071B]    [86FD7E9A]    
 01    [7857D46F]    [D64CA238]      CRC32   
 02    [183B54F5]    [0DEC6844]      CRC32   
 03    [5DDE6D74]    [34EE85FA]      CRC32   
 04    [B32DB7F1]    [7398351D]      CRC32   
 05    [CBCCA78A]    [29FA6586]      CRC32   
 06    [D9E80E1B]    [68B67432]      CRC32   
 07    [E3992F64]    [B3A9D22B]      CRC32   
 08    [FEEB89F7]    [1875340F]      CRC32   
 09    [9DAB611C]    [E422D95E]      CRC32   
 10    [2AFE687E]    [57FD21B8]      CRC32   
 11    [02864C0E]    [00000000]      CRC32   
 12    [02864C0E]    [00000000]      CRC32   
 13    [02864C0E]    [00000000]      CRC32   
 14    [02864C0E]    [00000000]      CRC32   
 15    [02864C0E]    [00000000]      CRC32   
 16    [02864C0E]    [00000000]      CRC32   
 17    [02864C0E]    [00000000]      CRC32   
 18    [02864C0E]    [00000000]      CRC32   
 19    [02864C0E]    [00000000]      CRC32   
 20    [02864C0E]    [00000000]      CRC32   
 21    [02864C0E]    [00000000]      CRC32


In the logs above, every track that is classified as "no match" is <= 5seconds.

Of course it could just be bad rips but I think that is rather unlikely here.

Have you experienced similar? Is this a bug I don't know of?

AccurateRip: Problems with very short tracks?

Reply #1 –
Yo, Drizzetto Do'Urden

For log2:
Code: [Select]
11    [00000000] (00/00) No matches

These [00000000] are null silent tracks, AR doesn't keep record of those so this is normal, the rip is Accurate.

For log 1:
Code: [Select]
01    [6804ba8f] (00/00) No matches


I think that this is due to people ripping as separate tracks instead of CDImage.

Accuraterip is track based, so if a user rip a CD with non-null silent tracks, the user can decide by himself that it is not worth ripping the silent tracks. Then only the full songs are reported to the AR database.

This is an example of how the human factor can affect the database. If the ripper decide that some tracks are not worth ripping due to their content, then it creates holes in the AR database ...

This is my explanation of why short tracks like interludes, intro, spoken word tracks in the middle of music, or non-null silent tracks often have a lower confidence than full music tracks.

I am not not sure if this explanation is valid, but this is how I interpret it personnaly.

If I am right, then  reporting the track lenght in the AR log wouldn't be stupid as it would at last gives you of an hint of what is happening without having to open the audio data.

AccurateRip: Problems with very short tracks?

Reply #2 –
 

Quote
These [00000000] are null silent tracks, AR doesn't keep record of those so this is normal, the rip is Accurate.

Ah I see. Haven't looked at the CRCs. Makes sense.

Quote
I am not not sure if this explanation is valid, but this is how I interpret it personnaly.

I think it is. I thought of that, too. So if this:

Quote
01    [6804ba8f] (00/00) No matches


isn't some sort of bug relating to very short tracks (which I think isn't) and the rip is good (which I think is), 4 people simply haven't ripped that track.

AccurateRip: Problems with very short tracks?

Reply #3 –
This isn't a really "bug", this is just how AR works.

Yes, it seems to me that 4 people simply haven't ripped that track.
It's likely that they all ripped as separate tracks without cue sheet & have chosen that this track wasn't worth ripping because according to them it was not worth to keep such a short track on their HDD.

This is a consequence of people listening tracks instead of albums & so ripping as tracks instead of albums.

Keep in mind that the AR database was created by the DBpoweramp developper & that DBpa didn't support cue sheet (& CDImage) for a long time (I dunno if it does now, I still use EAC), so it is likely that many entry in the AR database comes from separate tracks rips without cue sheet made with DBpa. As far as I understund, all these DBpa entries might not includes the non-null silent tracks if the ripper has manually chosen so.

AccurateRip: Problems with very short tracks?

Reply #4 –
Quote
This isn't a really "bug", this is just how AR works.

yeah I know:
Quote
which I think isn't


You see, if I noticed the null-silent tracks in the logs and identified them as such, I wouldn't have started this topic

Not having noticed the null-silent tracks, the logs looked strange to me. Especially when you take the track lengths into account. You pointed me to the null-silent tracks and the mystery was solved.

Quote
This is a consequence of people listening tracks instead of albums & so ripping as tracks instead of albums.

I generally prefer to rip to tracks + (noncompliant) cue. Can't see anything in a range rip that would be beneficial for me. I DO ~90% of the time listen to albums as a whole. But I can do that with single tracks equally fine. Oh, this was slightly off-topic. 

AccurateRip: Problems with very short tracks?

Reply #5 –
You think that this is off-topic because despite ripping as separate tracks you still keep a cue, for people who don't keep a cue at all, there is no gain keeping a small file full of silence. Hence they don't even rip those. This is directly related to the topic because the reason why they don't rip those files is exactly because they won't listen to these files. Worst they see those files as annoying noise polluting their HDD instead of part of the album architecture.

Quote
Can't see anything in a range rip that would be beneficial for me.

... well the 4 people who "selfishly" (I admit it's a word abuse here) ripped the album as separate tracks+"delete what I don't need" thougth like you, with this way of thinking you will wait for your first track checksum untill someone like me rip the whole album as a CDImage+cue ... good luck

Edit:
I agree the problem is not really CDImage Vs Separate Tracks here but weither if you rip all tracks or not. I am only saying that ripping with a cue helps, but ripping as a CDImage+cue forces you.

AccurateRip: Problems with very short tracks?

Reply #6 –
Quote
You think that this is off-topic because despite ripping as separate tracks you still keep a cue, for people who don't keep a cue at all, there is no gain keeping a small file full of silence. Hence they don't even rip those. This is directly related to the topic because the reason why they don't rip those files is exactly because they won't listen to these files. Worst they see those files as annoying noise polluting their HDD instead of part of the album architecture.

with "slightly" off-topic I meant my answer to the quote in my previous post. Not what you wrote. I perfectly understand what you mean, and you're right. I'm not one of "them" but they exist.


Quote
...thougth like you, with this way of thinking you will wait for your first track checksum untill someone like me rip the whole album as a CDImage+cue

hm? If nothing is deleted from a proper tracks+cue rip, then it is just as well suited for an AR "upp", no need for a range rip here. That "Can't see anything in a range rip that would be beneficial for me." was meant in a general manner. I can't see advantages over a proper tracks+cue rip (with nothing! deleted). One major disadvantage would be the VERY limited tagging capabilities of cue-sheets.

EDIT:
Quote
I agree the problem is not really CDImage Vs Separate Tracks here but weither if you rip all tracks or not. I am only saying that ripping with a cue helps, but ripping as a CDImage+cue forces you.

okay

AccurateRip: Problems with very short tracks?

Reply #7 –
Well actually I still use CDImage+cue, but I may switch to Separate Tracks+cue one day because of tags so I understand your point of view. It doesn't really matter as long as you rip all tracks+cue.

I have edited my post to reflect that I agree with you, but you were faster.

See ya in the Underdark

AccurateRip: Problems with very short tracks?

Reply #8 –
Quote
It doesn't really matter as long as you rip all tracks+cue.

Hai!

Quote
I have edited my post to reflect that I agree with you, but you were faster.

Zetto the fast one! 

Quote
See ya in the Underdark

 
*Hides in Shadows*