UMDGen v4.00
 

UMDGen v4.00

Описание:
Я думаю большинство знает, что это за програмка, но напомню. UMDGen - програма для работы с iso и cso образами. Удаление там лишних файлов и конвертация iso<->cso.

Установка:
Установка элементарная) Нужно скачать и разархивировать в любое удобное вам место.

Использование:
Далее буду описывать то, как создать небольшой образ с образа, который содержится на UMD диске, и то, как уменьшать уже готовые образы.

Если у вас есть UMD диск
1. Нажмите в XMB Select и выберите USB Device - UMD Disc.
2. Вставьте диск в привод и подключите псп к компьютеру через USB.
3. Скопируйте образ iso на компьютер.

Далее будем ужимать наш образ.
Для примера я взял игру F1 Grand Prix.

Заходим в UMDGen. Открываем наш образ. Далее выбираем вкладку UMD Properties и в левом нижнем углу есть кнопка Optimize. Эта функция урежет ваш образ, но на игру это никак не повлияет.
У меня она ужала игру на 40.5Мб. В разных играх - по разному. Она может ужать и на 200 и на 300Мб) На скачанных образах эту фишку можете не пробовать, т.к. чаще всего их перед заливкой ужимают.
http://pic.ipicture.ru/uploads/081122/KfYbPctNOR.jpg

Далее, если вам достаточно того - на сколько он ужал, то сохраните в формате iso. А если нет, то продолжаем)

Вы можете сохранить файл в формате "ужатый cso", тем самым вы ужмете файл, но игра будет работать по медленнее.

Дальнейшие действия ужимают и скачанные игры...

Дальше будем удалять ненужные файлы.
Нажмите на файл UMD_DATA.BIN и нажмите CTRL+M.
Далее выделяйте файлы музыки, видео или неиспользуемых языков и нажимайте Ctrl+L.

Все! Теперь можно сохранять образ...
Вот я и написал вам как ужимать игры)

Вот и нифига! Optimize у меня игру Talkman в нерабочее состояние перевёл!
Так что не со всеми играми катит! Сначала попробуйте на PSP работает ли, а потом удаляйте оригинальный образ.

странно, я 4 игры так обрезал и ничего

А уже ведь была тема https://www.pspx.ru/forum/showthread.php?t=39575

alex90, я искал эту тему, но поиск что-то ничего не выдал.
Ну ладно, освежим в памяти, а то наверняка многие и не слышали об этой проге ))).

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

а в локо-рока другие языки никто не пробовал отрезать?

pathific, так там же особо он по русски не тарабанит... или по английски - там язык - это текст, а в основном вес это музыка и видео... но что же это за ЛокоРоко без музыки :)

У меня с дампеного диска не хочет оптимизировать(( что делать? ?

удаляй лишние языки и т.д.

Susuke Uchiha, вероятно тыпытаешься оптимизировать CSO.
Переконверть в ISO.

Народ а как запустить это на VISTA пишет ошибку на ХР всё работало. Dr.House скин у тебя вроде от Висты

moju, у меня Виста и нормально работает. Отключи UAC

У меня UAC давно отключена всёравно пишет ошибку [IMG]http://img211.**************/img211/5311/sshot146go5.jpg[/IMG]

Кто нибудь нашел решение проблемы, крашится UMD gen если количество файлов в образе >15000...?

У меня та же фигня, с одним только дополнением: поначалу прога работала, а в один прекрасный день стала выдавать эту ошибку. vista ultimate 64

Когда из UMDgen делается экспорт списка файлов образа, в первой колонке идёт некое число. Что оно обозначает, никто не подскажет? Почему цифры такие "круглые"? :] Это количество байт? слов? двойных слов? Наборов по 16 байт? Килобайтов?

Noricon, полностью согласен! Есть игры которые нельзя "оптимизировать". Из 180 своих образов я нашел примерно игр 15, которые "ломаются" после такой оптимизации.

я риджрейсера оптимизировал (кнопкой) на 460 метров О_о

Так разработчики любят иногда наращивать вес и забивать ненужными нулями.

они просто видимо выпендриваются перед пиратами - типа смотрите какая у нас игра классная и большая...хотя вероятно это для диска надо..может с этим "мусором" игры быстрее с них грузятся ,ведь скорость чтения там порядка 2мбайт\с))

Некоторые разработчики игровых дисков указывают на расположение файлов по их строго закреплённым позициям.

Некоторые хитрые разрабы, прибегают к адресному расположению, т.е. обращение к файлу происходит по его жёстко указанному и заранее упакованному по этому адресу(ам) файлу(ам).

Если, к примеру файл EBOOT.BIN имел определённый размер, то после декриптовки он приобретает другой размер.
И когда мы его засовываем обратно в образ, то из-за того, что размер изменился, все последующие файлы сдвигаются при сохранении. Отсюда все смещения сдвигаются и диск становиться не читаемым, т.к. в таком диске разрабы установили привязку по LBA, а не по названию.

Адресация LBA - аббревиатура этого вида дисковой адресации отражает сущность используемых в ней дисковых адресов: Logical Block Address, то есть «адрес логического блока» или «логический адрес блока».

Так вот, в данном случае один блок здесь рассчитывается из расчёта 2048 байт на блок. Один блок состоит из 4 секторов по 512 байт.
Один блок здесь - это минимальная единица исчисления и всё подчиняется этому правилу в UMD пространстве.

Это я расписал просто литературным языком, чтобы более-менее было понятно простому народу, поэтому просьба не цитировать со всякими опровержениями и сообщениями об ошибках.

Теперь перейдём из теории к практике...
Число в FileList - что оно означает?

Это число означает закреплённую позицию LBA для каждого файла, присутствующего в образе (точной копии байт-в-байт физического UMD-диска).

Если мы видим на экране монитора файл, имеющий конкретное название, например EBOOT.BIN, то это не значит, что этот файл прямо так же и записывается с этим названием.
Все названия папок и файлов записываются отдельно в определённое место на диске, а оттуда, по этим названиям идёт ссылка на сам файл по позиции LBA.

Поэтому обычно обращение к файлу идёт по его названию, т.е. идёт обращение к названию, которое записано отдельно в положенном ему месте, затем от этого названия идёт ссылка на его начальную позицию.

Но разрабы иногда хитрят и производят обращение к файлу не по его наименованию, а напрямую по позиции LBA, застраховываясь тем самым от подмены файлов в образе кем-либо. Ведь при подмене файлов, их позиции уже смещаются.

Это число LBA так же можно увидеть в UMDGen, который умеет высчитывать и показывать эти позиции (на примере "Gran Turismo"):

LBA показывает количество блоков. В данном случае, один блок равен 2048 байт. Отсюда, если нам необходимо вычислить расположение файла PSP_GAME/SYSDIR/EBOOT.BIN в образе (на диске), то нужно произвести математическое действие:
LBA 32-ой блок (как видно на 2-ом рисунке) умножить на 2048 = 65536.
Что мы видим на самом деле в хексе:

То есть эта цифра как раз указывает на количество блоков от начала образа (физического диска).
Поэтому FileList выполняет функцию закрепления всех начальных позиций файлов на свои исходные места, как они были до изменения размера одного из них (EBOOT.BIN при декриптовке в данном случае).

ErikPshat, мне долго никто не отвечал, что если честно, я сам уже разобрался. Но всё равно спасибо за развёрнутый ответ, пригодится многим, думаю.

Я объясню, откуда вопрос вообще возник. Всё дело в том, что если в ~PSP файл ELF хранится в gzip, то после распаковки его размер должен стать больше. Соответственно, размер нового EBOOT.BIN может стать больше размер старого/"закриптованного" EBOOT.BIN. Соответственно, при запаковке обратно в iso и использовании LBA-позиций из файла, хвост нового EBOOT.BIN может пересечься в "дисковом" пространстве с началом следующего по списку файла.

Учитывая, что сейчас всем рекомендуется использовать экспортированный список файлов со смещениями, это могло бы... могло бы. Кстати, на примере Disgaea2 я посмотрел, этого не происходит - во-первых, там достаточно (5 полных с хвостиком блоков) нулей, плюс, размер декриптованного ELF-а меньше(!) размера исходного запакованного.

hasherfrog добавил 08-10-2009 в 12:09
>> Но разрабы иногда хитрят
Это они ещё не хитрят. Я думаю, что самым простым следующим их шагом будет чтение первых байтов EBOOT.BIN и проверка что это не чистый ELF, а ~PSP :-P

Не совсем так. В Gzip упаковывались файлы прошивки PRX (~PSP) совсем давно в формат RLZ. Но так как PSP по сей день умеет работать с этим архивом, то разработчики Homebrew как раз этим форматом пользуются. А так же в этот формат упаковывал свои кастомные файлы и Dark_Alex, как и все последующие последователи.

Но официальные файлы Sony сейчас похоже не пакует, а просто переконверчивает их другим способом - KL3E, KL4E. По сути это не компрессия, а просто перекодировка в другой формат с шифровкой.

Поэтому зашифрованный файл имеет размер больше, чем декриптованный, т.к. зашифрованный имеет ещё и свой заголовок + модуль шифровальщика. После декриптовки файл выходит даже меньше или равным зашифрованному.

Размер файла в ~PSP проставляется так же на старых позициях в 4-ёх байтах:
0x28 - размер декриптованного файла ELF
0x2C - размер зашифрованного файла ~PSP
0хB0 - размер декриптованного файла EBOOT.BIN в играх, дополнительно к 0x28