Блог

Мне нужно сохранить точную позицию звука в базе данных, а именно SQLite. Я мог бы сохранить позицию кадра (смещение выборки / каналы) как целое число, но это привело бы к дополнительному обслуживанию данных в случае определенных преобразований файлов.

Итак, я подумываю о сохранении позиции в виде 8-байтового реального значения в секундах, то есть double, и, следовательно, как РЕАЛЬНОГО в SQLite. Это делает структуру базы данных более согласованной.

Но, учитывая максимальную частоту дискретизации 192 кГц, достаточна ли двойная точность, чтобы я всегда мог восстановить точную позицию кадра при умножении значения на частоту дискретизации?

Существует ли определенное максимальное положение, выше которого может возникнуть ошибка? Какова эта максимальная позиция?

PS: речь идет о SQLite REAL, но также о типах C и Java double, которые могут содержать значение позиции на разных этапах.

Обновить:

Поскольку обсуждения сейчас сосредоточены на рисках, связанных с преобразованием и округлением, вот метод C, который я планирую использовать:

 // Given these types:
int samplerate;
long long framepos;
double position;

// First compute the position in seconds from the framepos:
position = (double) framepos / samplerate;

// Now store the position in an SQLite REAL column, and retrieve it later

// Then compute the framepos back from position, with rounding:
framepos = position * samplerate   0.5;
  

Безопасно ли это и симметрично ли?

Точность double составляет 51 бит. В зависимости от части экспоненты, некоторые из этих битов будут представлять целые числа (секунды в вашем случае), другие доли секунды. При 48 килобитах требуется минимум 16 бит, чтобы получить достаточно точную подсекунду (больше, если округление не является оптимальным). Это оставляет 35 бит для секунд, которые будут занимать чуть более тысячи лет.

Таким образом, даже если вам нужен дополнительный бит или два для подсекунды, чтобы защититься от округления, и даже если SQL теряет бит или два точности при преобразовании его в десятичное число и обратно здесь и там, вы и близко не потеряете точность выборки с вашим номером двойной точности. Убедитесь, что ваше округление работает правильно — C имеет тенденцию всегда округлять в меньшую сторону при преобразовании в целое число, поэтому даже незначительная ошибка преобразования может сбить вас с толку на 1.

Я бы сохранил ее как (64-разрядное) целое число, представляющее микросекунды (приблизительно 2 * * 20). Это позволяет избежать аппаратного / программного обеспечения с плавающей запятой, легко понимается всеми и дает вам диапазон 0 .. 2 ** 44 секунды, что составляет чуть более 55 тысяч лет.

В качестве альтернативы используйте читаемое десятичное представление с фиксированной точностью (20 цифр должно быть достаточно). Выравнивание по правому краю с начальными нулями. Стоимость преобразования в любом случае незначительна по сравнению с доступом к БД.

Одним из преимуществ этих опций является то, что любая база данных будет тривиально знать, как их упорядочить, не обязательно очевидно для значений с плавающей запятой.

Как объясняется в ответе Маттиаса Ванделя, вероятно, беспокоиться не о чем. OTOH используя целые числа, вы получите фиксированную точность независимо от величины, которая может быть полезна.

Скажем, используйте 64-разрядное целое число и храните время в виде микросекунд. Это дает вам эквивалентную точность дискретизации в 1 МГц и диапазон почти в 300000 лет (если мой быстрый расчет верен).

Редактировать Даже если принять во внимание необходимость того, чтобы временная метка * sample_rate помещалась в 64-разрядное целое число, у вас все еще есть диапазон в 1,5 года (2**63/ 1e6/3600/24/365/ 192e3), предполагая максимальную частоту дискретизации 192 кГц.