[Baranius]

Anonymоus, может Вам будут интересны результаты тестирования.
Собрал на старой машине (Barton 1,8 Мгц, память - 1Гб) ~15 000 файлов (70Гб весом). Из плейлиста подготовил "test.txt " - запустил Ваш скрипт поиска дублей. Комп загрузился на 100%, (процессы.jpg) и работал он ... 1час 40 минут. Стресс-тест, как говорится, но результат выдал.
И вот первый вывод: кол-во песен с равной до миллисекунды длительностью (судя по весу файла "! duplicated (1ч 40м) весь - 15 000.txt") почти равно половине всех песен (вторая строчка на скриншоте _кол-во дублей.jpg ). Не поверил, взял первую 1 000 строк из "test.txt ", потом первые 3 000, следом ещё 3 000 строк из середины файла (там, где длина песен "L=226s" самая распространённая) - результат тот же и неутешительный для меня - слишком много совпадений и искать именно дубли одинаковых песен среди такого кол-ва совпадений будет некомфортно. Так и вышло. Вот скрин (_dup-203сек.jpg) совпадений песен в диапазоне только одной секунды 203000 - 203999мс (3:23). Из 53 штук только 2 пары дублей (желтенькие).
Выводы - одного поля для сравнения, а тем более, поиска дубликатов мало (нужно чем-то подпирать, хоть тем же размером);
- время обработки растёт не пропорционально кол-ву обрабатываемых строк, очевидно Find не отбрасывает из рассмотрения 1 строку, после того, как переходит ко второй и т.д.;
- нашлись и неточности, присущие Find, о которых Вы говорили ранее - несколько сотен почему-то именно коротких файлов (L- 5тизначное) с цифрами в пути.
А про тесты синхронизации старого ПЛ с упорядочненными файлами на диске (умный поиск-сравнение в списках) отпишусь в родной теме.
Ещё раз, спасибо за поддержку и понимание.