Что-то не могу сообразить как тут длина файла считается.
HeaderSize: dword;
FileCount: dword;
Массив.
FileOffset: dword;
FileSize: dword; <--- значительно меньше действительной длины.
http://img269.imageshack.us/i/tmnt21.gif/
По смещению идут несколько служебных переменных типа частоты и т.д., на приставке длина была тут, но в компьютерной она в массиве (см. выше), да и ничего похожего я тут не вижу. Есть подозрительные переменные, но не уверен относятся ли они к длине.
http://img703.imageshack.us/i/tmnt22.gif/
Далее после выравнивания по $800 идёт чистый 'PCM'.
Распаковщик писать не надо, просто подскажите как вычислить длину потока 'PCM'.
http://ifolder.ru/27662800.
Это не 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 байт.
На самом деле эти математические вычисления ничего нового не дают. Можно просто брать разность смещений в цикле и получить те же размеры.
А что ты будешь делать при замене файла, который больше и "в тот же размер" не умещается, даже с учётом нулей в конце? (*улыбается*)
Я просто показал как это считается, чтобы при подобных ситуациях ты мог сам с такими форматами разобраться.
Не всё же тебе на кого-то рассчитывать. (*улыбается*)