>Running this now - will confirm how long it takes to complete against a >library of 35871 tracks when its finished. > It finished (left it going unattended). Not sure how long it took - couldn't find anything in the log to indicate when it had actually finished, but it did take a significant amount of time. This will add to rescan times.
Detecting using (number of bytes): 10000 Detected: 35871 Checksum duplicates: 1405 duplicates (Incorrect duplicates: 1325) Duplicates: 80 It actually highlighted a handfull of actual duplicates that I wasn't aware of (eg. where I have remix versions from old CD singles that are named differently but are actually the same thing). After I ignored duplicates that obviously weren't duplicates (eg. due to cue sheets - see below), there were actually only two false positives. The checksum from the first 10,000 bytes matches, and the song length is identical, but the songs are certainly not the same. >What about support for cue sheets? i.e. a single audio file that is chopped >up into songs via a cue sheet - each song references the same audio file, but >with a different sub-set of the data. Does the duplicate checker take account >of this; treating each track as if it were a separate file chopped into >segments? > Answer to this is that every track that comes from the same source file in a cue sheet is detected as a duplicate. eg. in the duplicates log file, I have 26 lines of: 71eb89d6770416109fca35e97cde57e8-34d5db7e M:\Music\Surround Sound\The Beatles\Love\Love.dts.flac I have a single .mov file that SBS understands (and just plays the audio content). This appears in the Duplicates log as: NOCHECKSUM-NOSIZE M:\Music\Phil's Music\Progressive Rock\Thom Yorke\Other\Rabbit In Your Headlights.mov I guess your code doesn't understand .mov files, but SBS can. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
