Другая идея. Я не знаю как работает TrueCrypt. Но допустим это симметричка в режиме ECB. Каждый блок шифруется независимо от другого и нету сцеплений. Размер блока нам известен допустим 4096 байт. Блок файловой системы. И допустим автор сохранил пароль (ключ).
Тогда я предлагаю следующее. Взять создать 2 логических тома которые полностью совпадают с оригинальным по размеру. Зашифровать первый. Сделать дубль на второй. Потом отформатировать первый так-же как и сделал автор. В quick format. После этого у нас есть два одинаковых диска первые из которых с поврежденными блоками.
Теперь если мы сравним их поблочно - то мы знаем что было повреждено.
Миллион раз было в фейсбуке. Писал кому-то что-то умное. И потом скролл-скролл. И капец. Потом ничего не найти. Вобщем этот Цукер-букер сделал соц-сеть с альцгеймером. Я уже в себе стал сомневаться. А вдруг я реально НЕ ПИСАЛ.
ThunderCat, да. Обычно крупные проекты реализуют не одну а множество парадигм и множество точек зрения на разработку. У таких проектов такой длинный lifecycle (видел Java-код которому по 15-20 лет) что меняются архитекторы и изнутри, их код и документация являют собой лоскутное одеяло. Тоесть там - можно найти вообще ВСЁ.
ThunderCat, в современных языках вообще - много фич которые давно отодвинули ООП куда-то
в сторону. Например аннотации и процессинг аннотаций. Аспекты. Это что вообще? Это получается
что есть некая сквозная логика. Или некий скрый flow который программист не писал. Но этот flow
реализован ПОВЕРХ той логики что уже есть.
Или процессор шаблонов в С++. Это - язык в языке. Это - логика которая во время компилляции
встраивается в вашу логику проходя сложные циклы доказательств возможности применения.
Доказываете теорему каждый раз компилируя свой код. На одной из конференций (кажется HiLoad)
один С++ ник утверждал что не доказан останов для этой логики. Тоесть теоретически ваша
компилляция может никогда не закончится.
Я не знаю как в Эклипсе, но обычно проекты создают на основе сборщиков. Maven, gradle e.t.c.
Вот в настройке сборщика - можно указать ту библиотеку которая использовалась в оригинальном проекте.
Какая именно - я не знаю - но в Java этих json-библиотек - как собак нерезанных. Вот навскидку дам названия
Я тебе подсказал направление. А уже expectations ты сам сформулируй точно. У тебя по тексту "получаем" или "моя программа" совершенно не видно где эталонные данные.
Собери все эти tiff на две кучки. В первую - те которые выдают ошиюки. А во вторую кучку = те которые удачно конвертятся.
И потом понаблюдай через identify или convert --print что у них в заголовке. Скорее всего - какой-то экзотический формат цвета. Может 48-битный цвет или YUV или сжатие нестандартное. Вот. Эта информация поможет установить причину проблемы. Тогда и фиксить проще. Не перебирать миллионы утилит и библиотек.
smartctl -i ...