Проблема: Как проверить, оригинальный ли аудиофайл или обрезанный


Необходимо установить, подвергался ли файл неавторизованному усечению (например, удаление концовки, вставка тишины) или склейке. Это требуется при анализе цифровых улик, проверке диктофонных записей перед предоставлением в суд или контроле целостности медиа.

Суть проблемы: Злоумышленник может физически вырезать фрагмент или использовать софт для изменения временной метки конца файла без перекодирования (тримминг). Глаз/ухо не всегда отличают технически обрезанный конец от естественного окончания.

---

Причины: Почему возникают сомнения в целостности аудио


1. Несоответствие метаданных и реального содержимого: Хэш-сумма не совпадает с официально опубликованной (например, для записи с диктофона с известной прошивкой). Или длительность, указанная в тегах (ID3), отличается от фактического объема данных.
2. Спектральные аномалии на границе обрезки: Если файл обрезан «грубо» (без fade-out), на спектрограмме видна резкая вертикальная линия на частотах — артефакт «хлопка» или цифрового щелчка. Плавные же окончания (например, запись с микрофона с шумом помещения) обрываются без затухания шума.
3. Отсутствие корректных «концевых» маркеров в контейнере: В WAV есть чанк `data` с заявленным размером: если он отличается от реального количества сэмплов после заголовка — файл усечен программно (например, испорчен заголовок после trim-операции в Python или FFmpeg без опции `-map`).
4. Нестыковка в логах сетевого трафика или FS-метаданных: Размер файла, зафиксированный в момент загрузки (Content-Length), не соответствует фактическому размеру диска — признак усечения при передаче.

---

Решение: Методы верификации с примерами команд


Используйте комбинацию методов для подтверждения «как проверить, что аудиофайл не обрезан»: хэширование, спектральный анализ и бинарная экспертиза.

#### 1. Анализ целостности аудио по хэшу (если есть эталон)
Сравните SHA-256 вашего файла с официальной хэш-суммой (если предоставлена источником). Любое изменение — включая обрезку концовки — изменит хэш.

bash
sha256sum suspect.wav

<h2 id="rezultat-f1d2d2f924e986ac86fdf7b36c94bcdf32beec15-vs-ozhidaemyy-nesovpadenie">Результат: f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 vs. ожидаемый — несовпадение</h2>


Ограничение: если эталона нет — не поможет. Требуется контекст (например, запись с IP-камеры с фиксированным хэшем прошивки).

#### 2. Спектрограмма: поиск аномалий «склейки» и «обреза»
Откройте файл в Audacity → Spectrogram (вид по умолчанию) и визуально осмотрите начало и конец.

Признак обрезки (грубая): Внезапный переход от белого шума/тишины к плотному спектру на одной частоте — это артефакт обрезания клипа. Нормальное окончание речи/музыки — постепенное затухание гармоник.
Признак обрезки (программная без перекодирования): Если файл — WAV/FLAC без сжатия с потерями, проверьте последний сэмпл. В командной строке:

bash
<h2 id="izvlech-poslednie-1000-semplov-v-binarnom-vide">Извлечь последние 1000 сэмплов в бинарном виде</h2>

ffmpeg -i suspect.wav -f s16le -acodec pcm_s16le - | tail -c 2000 | xxd | less

<h2 id="esli-poslednie-100-bayt-nuli-0x0000-eto-mozhet-byt-podognannyy-hvost-pri-trim-iskusstvennaya-tishina">Если последние 100 байт — нули (0x0000), это может быть подогнанный хвост при trim (искусственная тишина).</h2>


#### 3. Проверка заголовков контейнера (WAV/MP4)
Для WAV: сравните размер `data`-чанка с реальным объемом данных после заголовка. Используйте `ffprobe` или `soxi`:

bash
soxi -s suspect.wav  # выводит число сэмплов

<h2 id="esli-ono-menshe-ozhidaemogo-po-logu-naprimer-ip-kamera-pisala-30-sek-a-tut-27-fayl-obrezan">Если оно меньше ожидаемого по логу (например, IP-камера писала 30 сек, а тут 27) — файл обрезан.</h2>


Для MP3/MP4: используйте `mediainfo --full` — поле `File size`, `Duration` и `Stream size`. Расхождение `File size` с вычисленным по `Overall bit rate` × `Duration` — ошибка в заголовке, что типично для усечения в процессе передачи (частичная загрузка).

#### 4. Бинарный анализ окончания файла (шестнадцатеричный просмотр)
Обрезанный конец часто содержит мусор (повтор последнего кадра или обрыв ID3-тега).

bash
xxd suspect.wav | tail -n 5

<h2 id="norma-poslednie-2-4-bayta-markery-tegov-naprimer-data-0x0a-0x00-ili-nuli-esli-zapis-korrektno-finalizirovana">Норма: последние 2-4 байта — маркеры тегов (например, ... &#039;DATA&#039; 0x0A 0x00) или нули (если запись корректно финализирована).</h2>

<h2 id="anomaliya-nechitaemye-simvoly-obryv-na-seredine-id3v1-ogranichenie-poslednie-128-bayt">Аномалия: нечитаемые символы, обрыв на середине ID3v1 (ограничение: последние 128 байт).</h2>


Итоговый алгоритм для эксперта:
1. Получить эталон (хэш, логи загрузки, оригинал с сервера).
2. Спектрограмма + бинарный просмотр конца.
3. Если файл соответствует эталонному хэшу или показывает непрерывную спектрограмму с естественным затуханием — оригинален. Иначе — вероятен trim.

Важно: все методы легальны и не требуют взлома. Использование для судебной экспертизы — дополнительно проверять целостность контейнера через `foremost`/`scalpel` на предмет hidden-данных после логического конца (признак склейки скрытого материала).