Безопасно ли хранить точное положение звука в секундах в секундах?

Question

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

Так что я думаю о сохранении позиции в виде 8-байтового действительного значения в секундах, то есть в два раза, и таким образом, как REAL в SQLite. Это делает структуру базы данных более согласованной.

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

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

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

Обновление:

Поскольку обсуждения теперь сосредоточены на рисках, связанных с конвертацией и округлением, вот метод 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;

Это безопасно и симметрично?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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