Как я могу определить, имеет ли WAV-файл 44- или 46-байтовый заголовок?
=======================================================================

мы обнаружили, что опасно предполагать, что все аудиофайлы PCM wav имеют 44 байта данных заголовка до начала семплов. Хотя это часто встречается, многие приложения (например, ffmpeg) будут генерировать wavs с 46-байтовым заголовком, и игнорирование этого факта во время обработки приведет к повреждению и нечитаемости файла. Но как определить, насколько длинным является заголовок?

Очевидно, что есть способ сделать это, но я искал и нашел небольшое обсуждение по этому поводу. Множество аудиопроектов предполагают 44 (или, наоборот, 46) в зависимости от контекста авторов.

 чтобы посмотреть наSubchunk1Size», которое является 4-байтовым целым числом, начинающимся с байта 16 заголовка. В обычном 44-байтовом wav это целое число будет 16 [10, 0, 0, 0]. Если оно'Для 46-байтового заголовка это целое число будет 18 [12, 0, 0, 0] или, возможно, даже выше, если есть дополнительные расширяемые метаданные (редко?).

Дополнительные данные (если они есть) начинаются с байта 36.

Таким образом, простая программа на C # для определения длины заголовка будет выглядеть так:



 чтобы увидеть, каковы фактические размеры. Файлы Broadcast Wave Format будут содержать еще больший подчанк расширения. Файлы WAV и AIFF от Pro Tools имеют еще больше расширений, которые не документированы, а также данные после аудио. Если вы хотите быть уверенными в том, где начинается и заканчивается пример данных, вам нужно по-настоящему искать блок данных ('данные' для файлов WAV иSSND» для AIFF).

Как обзор, все подэмплы WAV соответствуют следующему формату:

```
Subchunk Descriptor (4 bytes)
    Subchunk Size (4 byte integer, little endian)
    Subchunk Data (size is Subchunk Size)

```
Это очень легко обрабатывать. Все, что вам нужно сделать, это прочитать дескриптор, если онне тот, который вы ищете, прочитайте размер данных и переходите к следующему. Простая подпрограмма Java, которая делает это, будет выглядеть так:

Например, вот случайный WAV-файл, который у меня был:

```
Found 'RIFF' descriptor.
Found 'bext' descriptor.
Found 'fmt ' descriptor.
Found 'minf' descriptor.
Found 'elm1' descriptor.
Found 'data' descriptor.
Found 'regn' descriptor.
Found 'ovwf' descriptor.
Found 'umid' descriptor.
End of file.
```
Примечательно, что здесь обафмт а также 'данные' законно появляются между другими кусками, потому что[Microsoft»спецификация RIFF](https://msdn.microsoft.com/en-us/library/windows/desktop/ee415713%28v=vs.85%29.aspx) говорит, что фрагменты могут появляться в любом порядке. Даже некоторые крупные аудиосистемы, о которых я знаю, ошибаются и нене стоит это учитывать.

Поэтому, если вы хотите найти определенный фрагмент, просматривайте файл, проверяя каждый дескриптор, пока не найдете тот, который вам нужен.ищу.



отличный ответ, яЯ хотел бы добавить 3 вещи, которые неЭто очевидно.

Единственным правилом для файлов WAV является то, что блок FMT предшествует блоку данных. Кроме того, вы найдете куски, которые вы нене знаю об этом в начале, до блока данных и после него. Вы должны прочитать заголовок для каждого чанка, чтобы перейти к следующему чанку.

Блок FMT обычно встречается в 16-байтовых и 18-байтовых вариациях, но на самом деле спецификация также позволяет использовать более 18 байтов. Если кусок FMT ' поле размера заголовка говорит, что больше 16, байты 17 и 18 также указывают, сколько дополнительных байтов есть, поэтому, если они оба равны нулю, вы получите 18-байтовый блок FMT, идентичный 16-байтовому. Безопасно читать только первые 16 байтов блока FMT и анализировать их, игнорируя больше. Почему это важно? - немного больше, но Windows XP 's Media Player мог воспроизводить 16-битные WAV-файлы, но 24-битные WAV-файлы, только если фрагмент FMT был расширенной (18+ байтной) версией. Раньше было много жалоб, которые "Windows невоспроизводить мои 24-битные файлы WAV ", но если бы у него был 18-байтовый блок FMT, это было бы ... Microsoft исправила это когда-то в первые дни Windows 7, поэтому 24-битные с 16-байтовыми файлами FMT теперь работают нормально.

(Недавно добавлено) Размеры чанков с нечетными размерами встречаются довольно часто. В основном видно, когда создается 24-битный монофайл. Из спецификации неясно, но размер порции указывает фактическую длину данных (нечетное значение), и байт pad (ноль) добавляется после порции и перед началом следующего порции. Таким образом, чанки всегда начинаются с четных границ, но сам размер чанка сохраняется как фактическое нечетное значение.