Билд 1514:
* Еще немного ускорен поиск (~10%)
* Улучшен детект сжатых с помощью TRUSH данных
* Пофикшено определение имен файлов в TRDos-образах (различалось для mingw/msvs версий)
* Переработан детект PT2 модулей
Скачать версию для win32
Скачать версию для медленных компьютеров с win32
Скачать версию для win64
Блоки TRUSH теперь детектируются не по текстовой сигнатуре (которую разные кулхацкеры портят), а по сигнатуре распаковщика.
Полностью переработан детект PT2 модулей. Теперь тесты AYMus (все pt2 модули из коллекции Бульбы) и Pusher проходят на 100%.
Поддержка ProTracker 2.40 от Phantom Family сделана через псевдодекомпрессор, выполняющий декомпиляцию треков с плеером (таких треков без плеера не встречал).
Немного статистики и сравнения с моим основным конкурентом и вдохновителем.
Calgary test (файл размером 770 094 519 байт):
Добавление в плейлист AYEmul (уходит в аут до конца поиска):
Результат- 6479 модулей в плейлисте, часть из них оказались невалидными
Размер результата- подсчитать не удалось (сохранение крайне затруднительно)
Затраты времени- ~400 секунд
Использование памяти по завершению- 9.8/14 Мб (private bytes/working set)
Пиковое использование памяти- 9.9/14.5 Мб
Скорость поиска- ~1880 кб/сек
Использование рипалки AYEmul (уходит в аут до конца поиска):
Результат- 6518 модулей
Размер результата- 21.3 Мб
Затраты времени- 3 часа 15 минут (~11700 секунд) (вот она- причина опоздания с данным сообщением)
Использование памяти по завершению- 13.7/23.2 Мб
Пиковое использование памяти- 14.8/23.8 Мб
Скорость поиска- ~64 кб/сек
Покрытие- 2%
Найденные модули:
ASC- 1051
FLS- 50
FTC- 7
GTR- 2
PSC- 32
PT1- 46
PT2- 1263
PT3- 1196
SQT- 38
STC- 2641
STP- 192
Анализ с помощью ZXTune (windows_x86), общий результат:
Результат- 13422 модуля
Размер результата- 48.1 Мб
Покрытие- 6% (реальное- 38%)
Найденные модули:
AS0- 1172
ASC- 1258
CHI- 1
DMM- 124
DST- 19
PDT- 2
PSG- 1
PT2- 2941
PT3- 2071
ST1- 83
STC- 5020
STP- 513
STR- 38
TS- 179
Добавление в плейлист ZXTune:
Затраты времени- ~690 секунд
Использование памяти по завершению- 25.7/32.9 Мб
Пиковое использование памяти- 641.3/1400 Мб
Скорость поиска- 1089 кб/сек (реальная- 1985 кб/с)
Использование рипалки (zxtune123):
Затраты времени- ~670 секунд
Пиковое использование памяти- 635/1388 Мб
Скорость поиска- 1122 кб/сек (реальная- 2044 кб/с)
Большой объем working set связан с проецированием в память всего файла (в этом случае ОС оптимизирует выделение памяти по факту чтения), большой объем private bytes пока не исследован- на графике видно два пика на фоне стабильного уровня.
Ввиду рекурсивного поиска в упакованных данных, алгоритм расчета покрытия и скорости обработки для ZXTune нетривиален. Считается соотношение размера отдетектированных данных к общему размеру обработанных данных.
Например, есть файл размером 100кб, в нем находится сжатый блок размером 50кб. Этот сжатый блок распаковался в 200кб, в котором было найдено несколько модулей общим размером 10кб.
Тогда покрытие будет считаться следующим образом:
Coverage = Useful/Total = (50(сжатый блок)+10(модули))/(100(исходные данные)+200(обработка распакованного блока))=60/300=20%
Для данного теста Useful=460.2(архивы) + 48.1(модули)=508.3 Мб, Total=1337.3 Мб
ЗЫ. Качество детекта детально не проверял ввиду большого объема данных для обработки. Если кто желает- милости прошу, дам архивы![]()




.
Ответить с цитированием