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 файл не сжать в килобайт не потеряв при этом качество. Может показаться немного маразматично так страдать из-за какого-то метра, но гора песка состоит из ма-а-аленьких песчинок. В конце концов всё просто: не хотите - не пользуйтесь. (*улыбается*)

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

[-=CHE@TER=-]

"Продолжаем разговор" (с) Карлсон

MDF2ISO

Вот небольшая программа, которая переводит .MDF файлы-образы CD в обычный .ISO. Можете съэкономить на этом около полсотни мегабайт. У меня 565 метровый .MDF диск похудел до 514 метров.
Программа настоятельно рекомендуется к использованию тем, кто не умеет делать .ISO образы и шляпает их в .MDF для игр, где нет никакой сверхсложной защиты CD, хоть как-то бы оправдывающей столь нерациональное использование свободного пространства.
Также программа пригодится тем, кто получил "по наследству" (грубо говоря такой дали/скачал) образ диска в .MDF, где защита обходится в полпинка и никакой .MDF не нужен.


Туда же:
NRG2ISO

Правда у этой утилиты есть одно большое "но": если с её помощью пытаются перевести мультисессионный .NRG в .ISO, то переводится только первая дорожка (у меня почему-то так работала).


Внимание: .NRG (не знаю, как там с .MDF) может содержать аудиодорожки. В стандарте .ISO, по-моему, поддержка аудиодорожек не предусмотрена.


P.S. Кому-нибудь эта тема вообще интересна - или это только у меня паранойя, с тех времён, когда жёсткие диски были 20 Мб величиной?..

[jTommy]

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

а может разрабы игр специально всякого не нужного туда записывают, надо же чем-то заполнять 4.7Гб.

MDF2ISO

Сам часто "конвертирую" mdf -> iso когда есть кряк. Только пользуюсь Nero'ой. Плюс, просто люблю, когда образ в одном файле, а не в двух и более (привет BlindWrite'у).

Внимание: .NRG (не знаю, как там с .MDF) может содержать аудиодорожки. В стандарте .ISO, по-моему, поддержка аудиодорожек не предусмотрена.

Точно, NRG и MDF поддерживают Audio-CD, а ISO не поддерживает.

P.S. Кому-нибудь эта тема вообще интересна - или это только у меня паранойя, с тех времён, когда жёсткие диски были 20 Мб величиной?..

Ну как тебе сказать... Я не страдаю этим, потому что на борту 250Гб + 320Гб, везде NTFS с включенным сжатием.
Хотя, все равно не хватает, потому что периодически качаю HDTV фильмы и Lossless музыку. И такая экономия мне не поможет.

В JPEG предпочитаю не лезть - Exif информация бывает полезна.
MDF, как я уже сказал, обычно в ISO "конвертирую".
NRG не пользую из принципа, если встречается что-то что ISO не поддерживает - пользую CUE/BIN связку.

Вот такие вот дела.

[Siberian GRemlin]

MDF, как я уже сказал, обычно в ISO "конвертирую".
NRG не пользую из принципа, если встречается что-то что ISO не поддерживает - пользую CUE/BIN связку.

+1. Только я использую UltraISO для конвертирования и создания образов дисков старых игр.

[-=CHE@TER=-]

а может разрабы игр специально всякого не нужного туда записывают, надо же чем-то заполнять 4.7Гб.

О да. Особенно я торчу, когда в игре 20% ресурсов есть (звуки/текстуры) которые нигде никогда не используются и их просто поленились перед релизом вычистить.

В JPEG предпочитаю не лезть - Exif информация бывает полезна.

Не спорю - если это фотография с цифровика. А, скажи, оно тебе нужно, для какой-нибудь обоины из Интернета знать, что она создана в Adobe Photoshop version 5.0 Aug 11, 2004 13:14:15 и тому подобное бла-бла? (*улыбается*) Мне - нет.




Ну и на закуску (ещё хотел большую статью про .PNG написать, но не знаю как со временем будет):

MP3DirectCut

Эта программа позволяет редактировать MP3 файлы БЕЗ ПЕРЕЖАТИЯ. Работа идёт пофреймово. Можно вырезать пустоту в начале или конце файла или вообще - сохранить отдельно какой-либо кусок. Ещё раз повторю - работа с файлами идёт БЕЗ ПЕРЕЖАТИЯ - только по уже сформированный фреймам, т.е. качество остаётся неизменным.
Из возможностей программы: поиск пустот (указывается уровень), нормализация звука (тоже указывается уровень). В общем - смотрите сами. Мне понравилась.

Имеется русский язык для интерфейса (коим я не пользуюсь в ввиду привычки (*улыбается*)) + не прописывается в реестре - так что чтобы uninstall'ировать, достаточно просто удалить папку и ярлык на рабочем столе.


И, туда же, JPEGCrop небольшие удобные тулзы для lossless работы с JPEG файлами.

[-=CHE@TER=-]

Для начала о смешном (взято отсюда):

Re: Unwanted resources in EXE and DLL
Jean [Aug 17 2005, 07:36]

>
> What is your problem with this? The size increase is negligible.
>

The problem is that almost every user in Russia tries to break-up every
program. The units in these resources may reveal my own secrets.

Рыдал над этим Jean'ом. Он думает, что убрав PACKAGEINFO и DVCLAL он сможет избежать того, чтобы его программу взломали. "Какие мы наивные!" ©

С другой стороны, если мы пишем на чистом WinAPI, то мусор который в .EXE с завидным постоянством пихает компилятор Borland просто дико раздражает.

Так что давайте немножко "похудеем" нашу программу.

Предлагаю скачать и кинуть куда-нибудь программу ResHacker (Freeware, если что) и сделать вот такой файл dreshack.bat:

CODE

@echo off
if _%1 == _ goto help
upx.exe -d "%1"
if not _%2 == _1 goto keepdvl
C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", RCData,DVCLAL,
:keepdvl
if not _%3 == _1 goto keepstr
C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", StringTable,,
:keepstr
C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", RCData,PACKAGEINFO,
C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", Cursor,,
C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", Bitmap,,
C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", Dialog,,
C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", CursorGroup,,
upx.exe -9 --exact "%1"
goto quit
:help
Echo Usage: %0 filename.exe [keepdvl] [keepstr]
:quit

После чего натравливать его на все необходимые программы:
dreshack program.exe --- снять всё нафиг (если пишем на чистом WinAPI)
dreshack program.exe 1 --- не трогать DVCLAL (если используем DBE)
dreshack program.exe 0 1 --- не трогать StringTable (если используем Dialogs или ещё что)
dreshack program.exe 1 1 --- не трогать DVCLAL и StringTable


DVCLAL необходим для работы BDE и некоторых других компонент Delphi! Иначе они откажутся работать (там просто тупая проверка, но чтобы заставить такой .EXE работать придётся либо подламывать его, либо пересобирать те компоненты Delphi, которые проверяют DVCLAL). Подробнее об этом ОБЯЗАТЕЛЬНО прочитать здесь!

Если удалить StringTable, и при этом пользоваться, например, юнитом Dialogs, то можно получить вместо "OK", "Cancel", "Yes", "No" и прочих, просто кнопки без текста - смотрится более чем дико. (*улыбается*) Если Dialogs и другие, подобные, юниты не используются - StringTable можно смело херить.

ОБРАЩАЮ ВАШЕ ВНИМАНИЕ НА ТО, ЧТО СТРОЧКИ:

CODE

C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", Cursor,,
C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", Bitmap,,
C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", Dialog,,
C:\ResourceHacker\ResHacker.exe -delete "%1", "%1", CursorGroup,,

ЦЕЛИКОМ ХЕРЯТ ВСЕ РЕСУРЫ! Т.е. если вы используете курсоры, картинки или ещё что-нибудь, то херьте только то, что суёт туда Borland (можно посмотреть номера ресурсов в том же ResHacker'е)! Иначе схерются также и ваши ресурсы!

[Grom PE]

Несколько полезных программ, работающих с командной строкой:

pngout — лучший оптимизатор PNG. Инструкция.

И совсем для маньяков оптимизации:
DeflOpt — программа, позволяющая уменьшить размер PNG, ZIP и GZIP (.gz, .tgz) на 1-500 байт.
Применять ее стоит на последнем этапе, когда другими способами файл уменьшить уже нельзя.

[Axsis]

наткнулся вот на програмку для уменьшения mp3 без перекодировки, и соответственно без потерь - исключительно за счёт махинаций с mpeg фреймами. также позволяет конвертировать CBR<->VBR опять же без потерь качества - судя по всему за счёт изменения заголовка файла и расширения низкобитрейтных VBR фреймов до полноразмерных CBR

инфа от автора

What it does:
Attempts to save space by storing frame data in the smallest possible frame. Usually MP3s are already stored in the most efficient way possible. However, for high-bitrate CBR files (like --preset insane) there can be a lot of wasted space

Features:
* Can make --preset insane files up to 10% smaller LOSSLESSLY (depending on the LAME version used)
* Squeezes out all the padding it can from any MP3 (Will not produce a larger file, unless you use the -b switch or something goes wrong)
* Writes valid LAME/XING header for proper VBR seeking
* Many people also use this backwards, to losslessly turn VBR into larger CBR files to humor players which can't handle VBR
* Includes a brute-force compression optimization option as of 1.10 to further compress files
* Finally works on directories again!
* Works on Windows, Linux, 64-bit Linux, Linux through WINE, and should work perfectly on any other platform with an OCaml port
* GPL, so anybody can tweak it as long as it stays GPL

A few caveats:
* The program will always output an MP3 that doesn't use CRCs, even if the input file uses CRC. This is primarily laziness on my part, but nobody really needs them, and it saves 600 bits per second... (it's a feature, not a bug!)

прога консльная, официальная ветка форума о ней вроде бы здесь, присутствуют исходники
в соседней ветке для неё есть GUI-шный фронтенд, так на всякий случай

лично прогу не тестил пока, судя по отзывам она уменьшает файл в среднем на несколько сотен-тысяч байт (хотя по заверению автора до 10%). всё равно думаю наших "маньяков уменьшения всего и вся" она заинтересует
а если серьёзно, то для разбора ealayer3, думаю, будет нелишним знать внутреннее устройство mp3 файлов, и исходники данной проги могут быть полезны

[-=CHE@TER=-]

Axsis!
О, спасибо большое!
Обязательно попробую.
Кстати, вот ссылка на официальный сайт: Reed's Page.

P.S. Надпись снизу:
"There have been 13256278887989457685606511039607113920 visitors since February 11, 2007"
просто поразила до невозможности. (*улыбается*)

[useretail]

мож немножко оффтоп, но опять мои 5 коп.
ISO действительно не поддерживает мультитрековость и CDDA само собой.. я лично предпочитаю BIN/CUE.. если стоит проблема в MDF, то монтирую через алкоголь и снимаю образ с виртуала.. так как тот-же UltraISO при конвертации дописывает свою инфу типа "Created by UltraISO бла-бла-бла".. а вот образы UltraISO (вроде-бы) снимает уже один к одному

[Siberian GRemlin]

ISO прекрасно хранит внутри себя несколько дорожек, только чтобы получить доступ к остальным кроме первой к ISO необходимо иметь CUE.

[-=CHE@TER=-]

Иногда после использования JPEGCrop (см. выше) результирующий файл несмотря на lossless преобразование почему-то занимает больше, чем оригинал. Товарищ Grom PE подсказал, что надо делать вот такое:
jpegtran -copy none -optimize -progressive input.jpg output.jpg
И действительно, файл резко худеет без потери качества.

[Siberian GRemlin]

Для преобразования образов в ISO советую использовать бесплатную программу ISO Buster. Она не работает с образами как с файлам и не приписывает свои реквизиты, она их (образы) только снимает, поэтому образ с лишней сотней метров корректирующих данных вставляем в виртуальный привод и снимаем образ в нужном режиме. Также с её помощью удобно снимать образ дорожками в связке ISO+WAV+CUE, что также избавляет от мусорных корректирующих данных (CUE+BIN без них никак), а также позволяет сжимать звуковые дорожки без потерь для хранения и с помощью редактирования CUE помогает избавиться от избыточного дублирования повторяющихся дорожек (игра на нескольких дисках и везде одна и та же музыка, или несколько версий одной игры). А ещё в таком виде звуковые дорожки можно слушать в WinAmp напрямую без самого образ.

P.S.: существуют ли уже готовые программные решения для срезания мусорных блоков у RIFF (WAV\AVI) и других мультимедийных контейнеров? Без пережатия потоков, естественно.

[-=CHE@TER=-]

P.S.: существуют ли уже готовые программные решения для срезания мусорных блоков у RIFF (WAV\AVI) и других мультимедийных контейнеров? Без пережатия потоков, естественно.

Я не знаю. Сам в своё время что-то такое написать хотел, да потом забил.
Если что - можешь вот эту программу переделать - я там как раз с .AVI работал. С .WAV всё проще, главное не забывать что в нём может сжатый звук быть, так что "fact" трогать нельзя в таком случае (у несжатого звука - можно).

[-=CHE@TER=-]

Искал чем можно заоптимизить .OGG - нашёл аж целую кучу утилит (там и для .OGG была): FileOptimizer
Чтобы не искать на странице ссылку на закачку: /FileOptimizer/

[Siberian GRemlin]

jpegtran портит изображение при повороте на 270 градусов: полоса верхней части изображение отражается зеркально и рисуется в самом низу, смещая большую часть вверх. Проверил на нескольких изображениях.

[-=CHE@TER=-]

Вынужден тебя огорчить - я не нашёл ни одной программы у себя (jpegtran, XnView, ACDSee и т.д.), которая поворачивала бы нормально. Проблема возникает только на изображениях, где количество пикселей не умещается ровно в блоки на которые разбит весь файл (если ты, конечно, в курсе как jpeg кодируется). К примеру, у тебя изображение разбито на блоки по 4x4 пикселей, а твоя картинка 399x400 пикселей - три крайних правых столбца пикселей т.н. "non-transformable edge blocks" ("нетрансформируемые краевые блоки").
Ты можешь увидеть эти блоки, если откроешь в jpegcrop свои файлы, затем выберешь View -> Block Grid.
Так что все существующие программы либо криво их поворачивают, либо отрезают при повороте.
В jpegtran для этого есть ключик "-trim" (см. справку), который как раз такие блоки отбрасывает:

jpegtran.exe -trim -rotate 270 input.jpg output.jpg

Изображение, в нашем примере, уменьшится до 396x400 (чтобы там только целые блоки были), но повернётся без проблем.

[Siberian GRemlin]

А как тогда объяснить тот факт, что на 90 градусов она переворачивает без ошибок? Причём я пробовал сначала на 90, потом на 180 повернуть — порча всё равно происходит. Мне кажется, тут всё же какой-то просчёт.

«Photoshop» переворачивает нормально, но там думаю, растр несжатый. Но это ещё не всё: программа «ALSee» переворачивает тоже нормально! Но есть подозрения, что она тоже пережимает изображение: размер файла уменьшается значительнее чем в любой другой программе, хотя стоит 100% качества и изображение никак не меняется, во всяком случае, я пристально рассматривал и сравнивал — разницы не увидел. Затем перегнал в BMP картинки сохранённые разными программами и вот там уже была разница в байтах.

[-=CHE@TER=-]

А как тогда объяснить тот факт, что на 90 градусов она переворачивает без ошибок? Причём я пробовал сначала на 90, потом на 180 повернуть — порча всё равно происходит. Мне кажется, тут всё же какой-то просчёт.

Ну, если тебе кажется, то креститься надо исходные коды jpegtran, а также документацию по форамту JPEG в руки и вперёд - исправлять просчёт. (*улыбается*)
См. своё изображение в jpegcrop, в частности расположение блоков - у тебя, видимо, с высотой всё нормально (блоки целиком умещаются), а с шириной нет (# - полный блок, $ - неполный краевой):
###$
###$
при повороте на 90 (напомню, что поворот идёт по часовой стрелке) превращается в:
##
##
##
$$
Снизу и справа могут быть "куцые блоки" (алгоритм так работает), но слева или сверху - нет (потому что декодирование идёт слева-направо, затем сверху-вниз).

«Photoshop» переворачивает нормально, но там думаю, растр несжатый. Но это ещё не всё: программа «ALSee» переворачивает тоже нормально!

Программы у которых нет "lossless JPEG transform" всегда пережимают изображение.

Затем перегнал в BMP картинки сохранённые разными программами и вот там уже была разница в байтах.

Что и требовалось доказать. (*улыбается*)

[-=CHE@TER=-]

Возможно для кого-то это покажется дикостью, но есть и негативные последствия использования программ для уменьшения размера.
Залил кто-то на VirusTotal мою программу в архиве.
Программа была упакована при помощи KZIP с ключом /rn, который случайным образом формировал блоки данных для упаковки.
Потом я обновил программу, а старую версию удалил (не имею привычки держать старые кривые версии).
Затем я обнаружил, что VirusTotal ругается на мой сайт. Посмотрел из-за чего и решил убрать эту программу из списка угроз, которые когда-то были на моём сайте. Так сказать, почистить историю.
Начался адовый ад - мне пришлось удалять все изменения в коде и перекомпилировать программу, чтобы она была такая же, как и старая версия. Особый головняк был с датой в заголовке PE - хорошо хоть на VirusTotal есть информация о PE-файле и я оттуда взял дату, прописал в заголовке, поправил контрольную сумму и мой файл (наконец-то!) совпал по MD5 с тем что был на VirusTotal. Я его снова залил, написал отчёты о ложном срабатывании в те антивирусы, которые там что-то находили и, в итоге, моя программа прошла проверку без проблем.
Но она была в архиве созданном KZIP c ключом /rn. И, не смотря на то что в архиве больше не было других файлов, в истории моего сайта висел именно отчёт об архиве, а не о файле, который там был.
Сутки я мучил kzip с ключом /rn пытаясь получить такой же результат. Из логов VirusTotal я знал размер и MD5 архива. В итоге у меня было штук 30 архивов нужного размера, но ни у одного не совпадал MD5 (да, дату создания файла программы в заголовке .ZIP архива я тоже перебирал посекундно в диапазоне +/- один день). И я сейчас даже не говорю о куче других архивов, которые были больше или меньше нужного размера, созданных в процессе. Я, вообще, для автоматизации перебора программу написал, но не суть. А суть в том, что нужного архива я так и не смог получить.
Итого: я больше не пользуюсь ключом /rn в KZIP, ибо повторить результат в случае необходимости можно только чудом, а также держу теперь резервные копии старых версий программ. Да, этот ключ можно использовать когда в архиве нет исполняемых файлов, а, скажем, только текстовые или графические, но кто знает где и как этот архив потом будет использоваться, а ты не сможешь, в случае необходимости, его повторить?