Strippers, или уменьшаем размер файлов Опции

[-=CHE@TER=-]

Предлагаю в данной теме рассказывать о программах, которые помогут уменьшить размер тех или иных файлов.
1) Архиваторы не предлагать.
2) Все программы Freeware.
3) Все преобразования должны быть lossless (т.е. без потери качества, когда сами данные не трогаются оставаясь как есть).

---

Первый буду:

Значится сравнивались следующие программы для удаления всего лишнего с .JPG файлов - UJPG (by dwing) (1) по сравнению с JPG/PNG Stripper (by SteelBytes) (2):
+ снимает ещё и 'JFIF'-блок, что слегка уменьшает размер
+ может снимать thumb'наилы и прочий хлам ещё и с фотографий от сотового телефона, чего (2) делать почему-то не умеет
+ гораздо меньше занимает
+ не гадит в реестре и на диске в отличие от (2), который помимо реестра гадит ещё, оказывается, и в %USERPROFILE%\Application Data\SteelBytes\
- не умеет рекурсивно обходить каталог и все подкаталоги, разыскивая там JPEG файлы и обрабатывая их
- не ведёт статистику сколько байт удалось съэкономить - (2), например, делает это очень подробно: сколько всего снято и в среднем (ещё выводит для каждого файла, сколько с него удалось снять и снято ли вообще, а (1) даже на уже почищенный файл, всё-равно выдаёт "OK!" даже ничего с него не сняв)
- не сохраняет дату модификации у файла после его изменения
- ну, (2) ещё умеет и с .PNG файлов снимать информацию лишнюю, но т.к. тут речь идёт только о .JPG, то это, на мой взгляд, не такой уж и большой минус

В общем, после написания этого обзора, стало понятно, что нужно писать свой JPEGStrip не страдающий этими косяками, что и было проделано:

JPGStrip

Что делает: снимает с .JPG (.JPEG, .JPE) файлов комментарии и информацию добавляемую туда всякими программами (PhotoShop, ACDSee (по-моему с версии 4.0) и т.д; между прочим замечу, что XNView ничего никогда в изображения "левого" не пихает). Небольшие файлы, после обработки этой программой, могут похудеть в два и более (!) раза. Это очень хорошо, если выкладываете какие-нибудь скриншоты в Интернет - трафика меньше жрётся.
Очень удобная программа - при обработке многих файлов, выводит напротив каждого (если он был обработан) сколько байт с него снято и суммарную информацию по всем файлам - сколько было обработано, сколько всего удалось съэкономить.

Программа работает в консольном режиме - это когда вы набираете где-нибудь в FAR'е:
jpgstrip *.jpg
или
jpgstrip image1.jpg
или
jpgstrip *.* /s
(Ахтунг! Последний пример снимает со всех .JPE/.JPEG./JPG файлов информацию в текущем каталоге и ВО ВСЕХ подкаталогах текущего!)

Для удобной работы с программой рекомендуется поместить её куда-нибудь в C:\WINDOWS\, чтобы была доступна через %PATH%.

ВАЖНО:
Если вы снимаете информацию с фотографий сделанной вашей цифровой камерой, то вы ПОТЕРЯЕТЕ ВСЕ ДАННЫЕ О МОДЕЛИ КАМЕРЫ, ДАТЕ И ВРЕМЕНИ, А ТАКЖЕ ВСЕХ НАСТРОЙКАХ ПРИ КОТОРЫХ БЫЛА СДЕЛАНА ФОТОГРАФИЯ - ОСТАНЕТСЯ ТОЛЬКО САМО ИЗОБРАЖЕНИЕ (превью тоже выкидывается)!


Немного насчёт JPGStrip. Берём .JPG файл-фотографию и натравливаем на него эту программу.
У меня получилось так: до - 648363 байта, после - 629012 байта. Т.е. в нашем случае разница (размер файла, а не на диске): 648363-629012=19351 байт или 18 Кб.
А теперь представим, что у нас файл сам занимает 10 Кб от силы. Допустим 50x50 обложка, скажем, диска какого-нибудь на сайте. Я не говорил, что эта программа для всех файлов (любых размеров) делает в два и более раза меньше, я сказал, что только для небольших заметна разница или, добавлю, для тех, у которых много чего в заголовок понаписано. Для других файлов будет выигрышь при их количестве. Т.е. допустим у нас, в среднем, пусть не 18 Кб, а, скажем, 15 Кб с файла удаляется. Теперь представим, что у нас в Интернете сайт, с собственной галлереей, где мы разместили превьюшки. Нехитрым подсчётом вычисляем:
1024 Кб (мегабайт) / 15 Кб = 62.2(6) - округляем до 62.
Таким образом получаем, что на каждые, примерно, полсотни картинок (неважно какого размера, хоть 2 на 2 писеля), мы экономим метр трафика. Это при том - что 15 Кб, как видно - не предел (в нашем случае - если это фотография, то всегда будет одинаковый размер информации - 18Кб).
Чудес не бывает. (*улыбается*) И .JPG файл не сжать в килобайт не потеряв при этом качество. Может показаться немного маразматично так страдать из-за какого-то метра, но гора песка состоит из ма-а-аленьких песчинок. В конце концов всё просто: не хотите - не пользуйтесь. (*улыбается*)

Раз уж начал писать офф-топ, то хочется сказать, что во многих играх и программах, любят всякие разности пихать в файлы, и получается, что тут немного + тут немного + тут немного = ого-го! Я считаю, что в программе, а уж тем более мультимедиа файлах не должно быть ничего лишнего.

[Grom PE]

-=CHE@TER=-, если ты хочешь ещё большего уровня сжатия, чем kzip, лучше не перебирать случайные таблицы в нём, а воспользоваться алгоритмом zopfli, который сейчас лучше всех жмёт DEFLATE. Для zip утилита с этим алгоритмом называется AdvanceComp/advzip.

[-=CHE@TER=-]

Во! Спасибо! Годные штуки - действительно, лучше Ken'овских утилит жмут.
advzip.exe -a -4 -i 20 test-1.zip test.exe
advzip.exe -a -4 -i 20 test-2.zip test.exe
Пот этом "test-1.zip" и "test-2.zip" будут идентичны. Ещё бы не забыть при скольких итерациях архив создавался. (*улыбается*)
Единственная проблема, которую обнаружил с "advzip.exe" - даты без учёта часового пояса почему-то сохраняются. Упаковал-распаковал и +X часов от своего часового пояса потерял. Тестировал распаковку как через WinRAR, так и через unzip (GNU'шный zip) и даже официальный DOS'овский pkunzip 2.04g - везде при распаковке часы теряются. Не смертельно, но KZIP-то жал правильно. Ещё как-нибудь при упаковке показывалась бы какая сейчас итерация идёт, а то, кроме имени файла, вообще ничего нет.
А ещё "advpng.exe" не умеет дату у файла сохранять, но это я могу внешней программой сделать.

[Grom PE]

Единственная проблема, которую обнаружил с "advzip.exe" - даты без учёта часового пояса почему-то сохраняются.

Действительно. Предлагаю три варианта:
1. Создавать архив без сжатия, а этой утилитой пережимать;
2. Поменять в исходниках в zip.cc time2zip() вызов gmtime на localtime и скомпилировать;
3. Пропатчить вызов gmtime на localtime в бинарнике (он там третий по счёту, 0xB701: 7B → 2B).

[-=CHE@TER=-]

Во! Третий вариант - это то что нужно! Спасибо большое!
А пережимать ей всё равно иногда придётся, потому что она каталоги сжимать не умеет.

[-=CHE@TER=-]

Действительно. Предлагаю три варианта:
1. Создавать архив без сжатия, а этой утилитой пережимать;
2. Поменять в исходниках в zip.cc time2zip() вызов gmtime на localtime и скомпилировать;
3. Пропатчить вызов gmtime на localtime в бинарнике (он там третий по счёту, 0xB701: 7B → 2B).

Надо же, оказывается 6 лет уже не обновлял эти программы.
Я использую вариант №1, но на случай, если кому-то понадобится вариант №3, то для последней версии advancecomp программы advzip.exe v2.3 (2022.04.15) смещение будет такое: 0x6BAC: 98 → A0.

[necros2k7]

Приветствую! Поделюсь своими изысканиями по данной теме. Вообщем перелопачено было много чего и остановился пока на следующей подборке - основной комбайн по переработке - File optimizer от друга из солнечной Испании Nikkho) Сразу оговоримся что речь идет о практическом уменьшении обьема файлов c выбросом за борт метаданных. Т.е. соотношение скорость - размер. Есть утилиты которые оптимизируют по максималке до талого но будь готов на неделю оставить комп чтобы скажем картинок 20 в PNG утрамбовало) Так вот PNG , OGG, PDF, MP3, GIF идет в Fileoptimizer, JPG в Papa`s optimizer. Остальные форматы глубоко не копал типа JS LUA CSS - из прикладного думаю можно это встретить в ресурсах браузеров и соотв. пожать. Давно мучал Firefox но после сжатия CSS были ошибки и забросил. Вообще FO интересная штука - жаль автор не дает менять ключи запуска консольных прог в ней, ибо они не оптимизированы и есть простор для экспериментов, на все реквесты он не быстро реагирует. Пробовал вручную добавлять параметры в екзешник но видимо прога считает контрольную сумму, помню была какая-то утилита делать выравнивание вроде после изменения но не помню название ее. Ах да EXE DLL OCX SCR идут в UPX (но опять же надо тестить каждый файл) Извиняюсь если сумбурно мысли изложил. По мере восстановления памяти буду дополнять)

Papa optimizer - https://papas-best.com/optimizer_en
EXIFtool тоже может резать мету - но надо тестить

JPG - хотите еще больше ужать - пакуйте в PackJPG - прекрасно открывается в XnView. В моих тестах даже в JXL больше по размеру получается.
PNG - после оптимизации в JXL тоже пробуйте (есессно не ресурсы игр а отдельные картинки)
WAD Doom - Cleanwad > doom-crusher.bat : v2.1.1, можно потом попробовать wadExt v1.1 © 2016 Christoph Oelckers (надо тестить)
MP4 - интересное наблюдение - преобразовываем в MKV > File optimizer - размер меньше)

В свою очередь есть вопрос - на гитхабе есть проекты по перепаковке PAK от UE4 - кому-то удалось сделать батник что бы по драг и дропу просто он разжимался и снова перепаковывался? Все что смотрел - полу костыли с зависимостями от версии движка я так еще понял.

[-=CHE@TER=-]

Приветствую и спасибо за сообщение!
Я в последнее время кроме .ZIP/.PNG/.JPG мало что оптимизирую.
Из последних оптимизаторов, которые пробовал, был FLACOUT (чисто ради интереса - у меня и .FLAC файлов-то почти нет).

Ах да EXE DLL OCX SCR идут в UPX (но опять же надо тестить каждый файл)

Сжатие UPX обсуждали в этой теме. Я сейчас иничего не жму им. Потому что, во-первых, проблемы с некоторыми антивирусами, во-вторых, в последнем сообщении той темы правильно написано, что со сжатыми файлами не работает FileMapping - сжатый файл жрёт оперативной памяти во время работы больше, чем не сжатый, в-третьих, если в программе захочется что-то поменять (см. эту тему), то её всё равно придётся распаковывать и так далее.
Сразу хочу заметить, что я против всякого шлака в файлах - тут вопрос больше в балансе. Вот, например, в 3D Mark каких-то последних версий, для которых мы распаковщик делали, вместо того чтобы записать размер файла как 4 байта целое, его побайтно записывали с индикацией по первому биту (если память не изменяет). Проблем и головняка при работе с такими данными (когда их все нужно прочитать, чтобы понять какой там размер поля) - выше крыши. А экономии - 1-2 килобайта, на несколько гигабайт файла-архива. Иными словами - ну его нафиг, такая экономия, которая создаёт столько проблем, при минимальном выигрыше - не стоит оно того.

MP4 - интересное наблюдение - преобразовываем в MKV > File optimizer - размер меньше)

Лет 10 назад в .MKV принудительно сжатие добавили, что, ИМХО, глупость ужасная, потому что видео и звук и так сжаты, а сжатие субтитров, шрифтов и других данных на общий размер всего файла практически не влияет. Как результат куча проигрывателей (особенно аппаратных и прошивку которых нельзя заменить обновлением) перестало такие файлы открывать. И это я ещё молчу про то, что проигрывание таких видеофайлов стало сильнее нагружать процессор: помимо декодирования видео и звука необходимо ещё и ненужное сжатие распаковывать. Приходится старой версией MKVToolnix пересохранять файлы без сжатия. Возможно, там индексная таблица сжимается или ещё что, поэтому меньше получается. Плюс, насколько я знаю, .MKV поддерживает декодирование, когда текущий кадр распаковывается не на основе предыдущего (back-frame), а на основе кадра где-то в будущем (forward-frame) - вроде бы, эту штуку только .MKV из видеоконтейнеров поддерживает (правда она нагружает процессор сильнее - на слабых компьютерах особенно заметно).
А вот с .MP4 интереснее. Взял музыку (только звук) из видео на YouTube в чистом .AAC формате. Переделал в .M4A (это .MP4, где только звук - для MP3 плеера) при помощи программы MP4Box и размер уменьшился! При это сам .MP4 формат весьма толстый, плюс там индексная таблица добавилась, в отличие от .AAC, где, как и в .MP3, только фреймы звука. Сделал вывод, что, возможно, при сохранении в .MP4 ищутся одинаковые фреймы и на них в таблице смещение указывается - т.е. второй раз они в файл не попадают. За счёт этого, наверное, размер и уменьшается.

В свою очередь есть вопрос - на гитхабе есть проекты по перепаковке PAK от UE4 - кому-то удалось сделать батник что бы по драг и дропу просто он разжимался и снова перепаковывался?

Я не особо интересуюсь UE4 и современными играми/программами (у меня до сих пор Windows XP), так что вряд ли тут чем-то помочь смогу.

[necros2k7]

Посмотри File optimizer внутри много программ по теме, еще PDF оптимизация тоже не паханое поле) Причем зависит оптимизация видимо от содержимого в PDF потому как иногда размер меньше выходит в File optimizer а иногда и при ручной оптимизации с cpdf

[Siberian GRemlin]

StripReloc.

[-=CHE@TER=-]

Посмотри File optimizer внутри много программ по теме, еще PDF оптимизация тоже не паханое поле) Причем зависит оптимизация видимо от содержимого в PDF потому как иногда размер меньше выходит в File optimizer а иногда и при ручной оптимизации с cpdf

Нашего казначея, товарища kampaster'а, бы сюда. Он как раз всякой оптимизацией и пережатием занимается. Увы, он сейчас загружен сильно, даже на почту редко отвечает.

StripReloc.

У нас даже тема по этой программе есть аж с 2007 года вот тут. (*улыбается*) Хотя понимаю, что за это время все всё опять забыли (как и с MP3). Наш форум за 16 лет существования - просто кладезь мудрости. Главное знать где что лежит. (*улыбается*)

[necros2k7]

А насколько сложно пропатчить этот File optimizer чтобы добавить туда свои флаги запуска утилитам? Так-то если exe смотреть там в открытом виде строка с флагами типа ect --strict -strip -9 --mt-file=6 --mt-deflate=6 как бы это заменить на ect --strict -strip -9 --mt-file=31 --mt-deflate=31 и чтобы прога запускалась) Это сократило бы время обработки PNG)

[-=CHE@TER=-]

Как я вижу тут нужно строчку на 2 символа увеличить (обе "6" на "31"). Если у строки есть выравнивание, то можно просто увеличить строку в любом hex-редакторе. Но это нужно исполняемый файл смотреть, чтобы понять есть там выравнивание или нет.
А ещё можно сделать совсем хитро.

Вариант 1.
Как я понимаю, "ect" - это имя утилиты. Тогда её можно переименовать, чтобы строка занимала столько же по размеру:

CODE

original (оригинал):
ect --strict -strip -9 --mt-file=6 --mt-deflate=6
required (что нужно):
ect --strict -strip -9 --mt-file=31 --mt-deflate=31
patched (как пропатчить):
z --strict -strip -9 --mt-file=31 --mt-deflate=31

Затем переименовываем "ect.exe" в "z.exe".

Вариант 2.
Так как в указанной строке у утилиты нет расширения (просто "ect", а не "ect.exe"), то можно сделать ещё проще: переименовать "ect.exe", например, в "ect2.exe", затем создать "ect.bat" такого содержания (т.к. расширение у утилиты не задано - просто "ect", то система будет искать файл подставляя расширения из списка: ".exe", ".cmd", ".bat", ".com"):

CODE

@ect2.exe --strict -strip -9 --mt-file=31 --mt-deflate=31 %6

%6 - это шестой аргумент (как я понимаю, имя файла записывается в конец, после всех аргументов).