Размер тега RIFF ICMT не соответствует данным
Я пытаюсь прочитать данные, хранящиеся в теге ICMT, в файле WAV, созданном устройством мониторинга шума.
Кажется, что код синтаксического анализа RIFF работает нормально, за исключением того факта, что тег ICMT, похоже, содержит данные после объявленного размера. По счастливой случайности, это временная метка, которая является абсолютно важной информацией для моего приложения.
SYN это шестнадцатеричное 16, что дает размер 22, что соответствует NUL до отметки времени. Документация монитора не помогает; он говорит, что тег включает время, но их пример также имеет ту же проблему.
Это последний тег в прилагаемом списке, и размер списка включает его - означает ли это, что ему не нужен идентификатор чанка? Я изо всех сил пытаюсь найти приличные документы RIFF, но я не могу найти ничего, что бы указывало на это; Кроме того, я не могу понять, как можно было бы определить, что это был последний кусок, и поэтому знаю, чтобы прочитать его без идентификатора чанка.
Кроме того, блок комментариев ICMT - это последнее, что есть в файле - это особый случай? Могу ли я просто получить время, прочитав все от конца объявленной длины ICMT до конца файла, и предположить, что это всегда будет работать?
Текущее поведение синтаксического анализатора заключается в том, что он читается после информации о канале / дБ в виде идентификатора чанка + размер, а затем жалуется на то, что в файле осталось недостаточно данных для выполнения запроса.
1 ответ
Нет, ему все равно нужен собственный идентификатор. Нет, быть последней вещью в файле тоже не особый случай. То, что вы показываете здесь, искажено.
Ваш текущий синтаксический анализатор правильно ошибается, так как следующая вещь, которую следует ожидать снова, - это 4-байтовый идентификатор, за которым следуют 4 байта для длины. Потенциальный идентификатор _10: неизвестно и будет пропущено, но интерпретация 51:4 как DWORD на длину конечно напрашивается на неприятности.
Устройство является виновником. Есть ли у вас другие поля INFO, которые используют байты NULL? Если нет, то я предполагаю, что устройство достаточно наивно, чтобы считать NULL концом строки, несмотря на то, что он сам создает строки с несколькими NULL.
Так как я столкнулся с бесчисленным количеством файлов, не придерживающихся стандартов, я могу только сказать, что ваш синтаксический анализатор также слишком наивен: он знает, насколько длинен инкапсулирующий список, и, таким образом, может легко определять длины полей, которые больше не будут соответствовать. И мог игнорировать мусор, как это. Или, в вашем случае, предложите очень специфическую опцию "добавить в последнее поле".