![]() |
Добро пожаловать, гость ( Вход | Регистрация )
![]() ![]() |
![]() |
Siberian GRemlin |
![]() ![]()
Сообщение
#1
|
![]() Advanced Member ![]() ![]() ![]() Группа: CTPAX-X Сообщений: 537 Регистрация: 4-February 08 Пользователь №: 2 Спасибо сказали: 221 раз(а) ![]() |
Что-то не могу сообразить как тут длина файла считается.
HeaderSize: dword; FileCount: dword; Массив. FileOffset: dword; FileSize: dword; <--- значительно меньше действительной длины. ![]() По смещению идут несколько служебных переменных типа частоты и т.д., на приставке длина была тут, но в компьютерной она в массиве (см. выше), да и ничего похожего я тут не вижу. Есть подозрительные переменные, но не уверен относятся ли они к длине. ![]() Далее после выравнивания по $800 идёт чистый 'PCM'. Распаковщик писать не надо, просто подскажите как вычислить длину потока 'PCM'. Образец. |
-=CHE@TER=- |
![]()
Сообщение
#2
|
Walter Sullivan ![]() ![]() ![]() Группа: Root Admin Сообщений: 1,360 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 313 раз(а) ![]() |
Это не CRC16 и не ID файла - т.к. есть повторяющиеся значения (2090, 2355, 1638, 2031, 2915).
Зато заметил интересное - все файлы в архиве выравнены на границу в 65536 байт. Т.е. файл состоит из заголовка 2048 байт ($800) + данные ($10000*N, N>=1). Это видно, если собрать статистику по выложенному файлу: Размер в архиве | Как считается | -> неизвестное_поле_min..неизвестное_поле_max 67584 | 2048 + 65536 -> 1059..1444 133120 | 2048 + 65536*2 -> 1504..2954 198656 | 2048 + 65536*3 -> 3020..4326 264192 | 2048 + 65536*4 -> 4774..5675 Т.е. файлы в выложенном архиве встречаются только размеров: 67584, 133120, 198656 и 264192. Второй столбец - это как считается их размер. Отсюда видно, что следующий размер-выравнивание, будет предыдущий + 65536. Т.е. если файл занимает, к примеру, 67585 байт, то под него будет выделен блок в 133120 байт, потому что в 67584 он не влезет. Т.е. реально файл в архиве выглядит так: 2048 байт - заголовок XXXX - тело файла сколько-то байт-нулей до границы, делящейся на 65536. Опытным путём удалось выяснить, что в заголовке коэффициент для размера - 44. Т.е. размер файла считается как (например): (1504*44)+$800 = 68224 68224 больше 67584 (2048+65536*1) следовательно надо брать блок 133120 (2048+65536*2). При коэффициенте менее 44 - файл укладывается в блок 67584, что, по условию (см. первую строку таблицы), нам не подходит. Т.к. 2048 - это размер заголовка, то подозреваю, что даже файл в 1 байт будет занимать 67584 (2048+65536*1) байт, ибо наращивается всё кусками по 65536 байт. CODE # QucikBMS script for unpacking TMNT2 "voice2.bin" ImpType Standard Get HdrSize Long Get FileCount Long For I = 1 To FileCount Get FileOffs Long Get FileSize Long Math FileSize * 44 Math FileSize + 2048 Math RealSize = 2048 Do Math RealSize + 65536 While FileSize > RealSize String FileName p= "%08d" I Log FileName FileOffs RealSize FOO FSO Next I Спасибо сказали:
|
Siberian GRemlin |
![]()
Сообщение
#3
|
![]() Advanced Member ![]() ![]() ![]() Группа: CTPAX-X Сообщений: 537 Регистрация: 4-February 08 Пользователь №: 2 Спасибо сказали: 221 раз(а) ![]() |
На самом деле эти математические вычисления ничего нового не дают. Можно просто брать разность смещений в цикле и получить те же размеры.
|
-=CHE@TER=- |
![]()
Сообщение
#4
|
Walter Sullivan ![]() ![]() ![]() Группа: Root Admin Сообщений: 1,360 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 313 раз(а) ![]() |
А что ты будешь делать при замене файла, который больше и "в тот же размер" не умещается, даже с учётом нулей в конце? (*улыбается*)
Я просто показал как это считается, чтобы при подобных ситуациях ты мог сам с такими форматами разобраться. Не всё же тебе на кого-то рассчитывать. (*улыбается*) |
![]() ![]() |
Упрощённая версия | Сейчас: 8th September 2024 - 02:06 |