[Baranius]

Anonymоus! Безупречно.
Не только я, все пользователи AIMPa, будут благодарны Вам. Это ж сколько дискового пространства у каждого освободится! А в мировом масштабе? (скрипт использует уникальные свойства плейлиста AIMPa, для поиска дубликатов. Интересно - стучитесь).
Последние вопросы:
- нет ли ограничений на количество строк в файле "test.txt", ну, или его веса?
- нельзя ли вместо черного окна cmd.exe увидеть уставшее, но доброе лицо Anonymоusа, и вместо привычного текста "Нажмите.." прочитать "Налейте...", да, и ещё
- мы все можем пользоваться Вашим скриптом? (можно подумать, что это кого-то остановит. И всё же)
Спасибо!

[Anonymоus]

- нет ли ограничений на количество строк в файле "test.txt", ну, или его веса? »

Только по времени - чем больше список, тем медленней отрабатывает Find (каждую строку ищёт по всему файлу). Думаю, где-то до двухсот тысяч строк не должно возникать никаких затруднений. Если нужно обрабатывать очень большие списки, могу переделать скрипт с использование grep вместо find, он намного быстрее работает, но минус в том, что это стороняя утилита и по умолчанию отсутствует в windows.

[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тизначное) с цифрами в пути.
А про тесты синхронизации старого ПЛ с упорядочненными файлами на диске (умный поиск-сравнение в списках) отпишусь в родной теме.
Ещё раз, спасибо за поддержку и понимание.

[Anonymоus]

Да, результаты интересные. Выходит, сочетание идентификации по длительности, плюс ошибки самого алгоритма поиска явно не дают требуемой точности. Сравнение одновременно с длительностью ещё и по размеру - это не совсем адекватная задача для чистого cmd, без применения внешних утилит, не тот инструмент.

- время обработки растёт не пропорционально кол-ву обрабатываемых строк, очевидно Find не отбрасывает из рассмотрения 1 строку, после того, как переходит ко второй и т.д.; »

Так и есть, не отбрасывает. Каждая строка ищется по всему файлу каждый раз.

Увы, по итогам выходит, что практического применения данный скрипт не имеет.

[Baranius]

Увы, по итогам выходит, что практического применения данный скрипт не имеет. »

Неправда, Вы взгляните на благодарности. Уже кому-то это решение показалось полезным. И, наверняка найдется куча задач, где Ваш скрипт очень пригодится (отчет-сводка за день, неделю). Я же, например, с удовольствием теперь анализирую свою фонотеку по частям (у меня папки 2002, 2003...сейчас уже 2012). И работать мне с полученными данными прямо в AIMPe (см. выше-_dup-203сек.jpg) очень удобно, хотя есть куча программ для поиска дубликатов.
Спасибо!