Преобразование форматов 44.1/16 в 96/24 или 48/24?

[Станислафф]

Конечно могу! ЕЩЕ РАЗ! Так не лучше ли изначально преобразовать 44/16 в 48/24 или 96/24.

Не лучше. Без вариантов.

[frezer]

Не лучше. Без вариантов.

А пару слов в обоснование.

---------- Сообщение добавлено 21:08 ---------- Предыдущее сообщение было 21:06 ----------

Любой профессиональный редактор типа Adobe Audition , Sound Forge.
С настройками конвертации на максимум.

Спасибо, попробую. А вы пробовали сами?

---------- Сообщение добавлено 22:00 ---------- Предыдущее сообщение было 21:08 ----------

Я думаю, что слуховые оценки звука не могут быть объективными (только приборами). Субъективные оценки
достаточно часто расходятся , а часто бывают противоположны.Оценивая качество пластинки (оригинала) по ее копии
можно сильно ошибиться в любую сторону.

Только осталось разработать методику объективной оценки! Субъективно я один конвертор уже забраковал.

[728323]

мой путь таков
беру CD с помощью jriver конвертирую в dsf , а потом воспроизвожу через jriver (usb dac).
минус один - размер.
критикуйте!

[frezer]

мой путь таков
беру CD с помощью jriver конвертирую в dsf , а потом воспроизвожу через jriver (usb dac).
минус один - размер.
критикуйте!

А что такое jriver? Это программа или железка?

[Игорь Гапонов]

...
Есть ли программные проверенные средства конвертации без потерь качества?
...

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

Так вот, для исходной точности 16-ть бит на сегодняшний день не реализован достаточно недорогой по железу риалтайм ресемплинг даже на 44/48. Потери времени на двукратный адекватный апсемлинг для системы с одним DSP Тигровая Акула от AD (см. их сайт про этот чип) с исходной Fd порядка 50кГц (т.е. как раз Ваш случай) я оцениваю как 1:100. На высоких частотах дискретизации потери времени ещё больше. Заметьте, это специализированный и оптимизированный под такие дела DSP. А "на компе" с замедлением (латенси) всё совсем плохо. То, чем кормят публику - полная профанация.

[728323]

jriver - софтовый плеер.
http://www.jriver.com
http://rutracker.org/forum/tracker.p...Media%20Center
попробуйте, класная штука с большими возможностями.

[frezer]

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

Так вот, для исходной точности 16-ть бит на сегодняшний день не реализован достаточно недорогой по железу риалтайм ресемплинг даже на 44/48. Потери времени на двукратный адекватный апсемлинг для системы с одним DSP Тигровая Акула от AD (см. их сайт про этот чип) с исходной Fd порядка 50кГц (т.е. как раз Ваш случай) я оцениваю как 1:100. На высоких частотах дискретизации потери времени ещё больше. Заметьте, это специализированный и оптимизированный под такие дела DSP. А "на компе" с замедлением (латенси) всё совсем плохо. То, чем кормят публику - полная профанация.

В моем цифровом кроссовере как раз Sharck -2 штуки и стоят, как впрочем и в других мною упомянутых. Так я говорю о конвертации программной, т.е. неограниченное по времени преобразование. Это ведь сделать легче?

[Игорь Гапонов]

Т.е. 100 часов на часовой диск устраивает? Тогда Матлаб, FIR реализация ресемплинга длиной (т.е. количество "нажатий") во весь файл, округления производить с 24-х битной точностью (вычисления с 25-битной). Вот и вся "программа".

[Openreel]

FIR реализация ресемплинга длиной (т.е. количество "нажатий") во весь файл

А какой смысл в таком длинном фир? Ведь его вектор при удалении от центра будет довольно быстро спадать и довольно быстро упремся в неточность коэффициентов(ошибку округления).
Да и можно его оптимизировать на скорость, примерно как это в железных фильтрах делано (нам ведь не все х160 отсетов надо, а только каждый 147ой, не нужно лишние высчитывать)

Во времена первых пней делал фир с длиной вектора 1024...2048, реализация на ассемблере, довольно быстро оно лапами шевелило, хоть и не реальное время конечно.

---------- Сообщение добавлено 00:41 ---------- Предыдущее сообщение было 00:32 ----------

Так я говорю о конвертации программной,

Если мой склероз не глючит, то давным давно для пакетной орбработки народ юзал http://linux.about.com/od/commands/l/blcmdl1_sox.htm
Под винду эта софтина была портирована уж лет 10 точно.

[Игорь Гапонов]

А какой смысл в таком длинном фир? Ведь его вектор при удалении от центра будет довольно быстро спадать и довольно быстро упремся в неточность коэффициентов(ошибку округления).
Да и можно его оптимизировать на скорость, примерно как это в железных фильтрах делано (нам ведь не все х160 отсетов надо, а только каждый 147ой, не нужно лишние высчитывать)

...

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

Уверяю Вас, что для бескомпромиссной FIR реализации точность sinc функции не ограничена (коэффициенты), а один единственный семпл ростом в единицу (т.е. на полную шкалу) лишь с расстояний приблизительно в 130000 отсчётов от точки интерполяции, приходящейся на середину Td, перестаёт влиять на точность восстановления из 16-ти битного исходного файла. Причём, более далёкие семплы влияют практически одинаково (гармонический ряд, логарифмическая зависимость частичной суммы), а узнать для ЛЮБОГО СИГНАЛА, как они влияют, можно лишь через вычисления.

Все оптимизации по определению связаны с какими-то, например, вероятностными априорными ограничениями на сигнал в файле, например, по спектру сигнала значительно ниже, чем то следует из "теоремы Котельникова", или к очень незначительным сокращениям вычислений. Например, указанный выше путь оптимизации ресемплера 44/48 приводит лишь к тому, что 1/147 файла не нуждается в вычислениях, а 146/147 нуждаются.

Но настоящего индейца интересуют ВСЕ ограниченные по спектру сигналы с ограниченными по значению отсчётами с заданной абсолютной точностью. Однако, для заданной длины последовательности/т.е. файла/ и заданных ограничений по спектру и значениям отсчётов существует т.н. предельная дуга, стягивающая два соседних отсчёта, за которую любая FIR-сумма выйти не может.

Для IIR реализации ровным счётом ничего не меняется (проблемы переполнения в циклах и округления).

[frezer]

Т.е. 100 часов на часовой диск устраивает? Тогда Матлаб, FIR реализация ресемплинга длиной (т.е. количество "нажатий") во весь файл, округления производить с 24-х битной точностью (вычисления с 25-битной). Вот и вся "программа".

Ну это не так страшно. Поставил 10 ПК на неделю и пусть конвертируют! Только 100 часов - это оценочное значение? Как Матлабу файл "скармливать":
1. медиа проигрывателем
2. "сграбленный" с CD файл
Во втором случаи время преобразования наверное будет меньше? Не в реальном же времени файл должен же обрабатываться?
Ну и если потреково записан файл, наверное длина будет ограничена длинной трека.

---------- Сообщение добавлено 06:28 ---------- Предыдущее сообщение было 06:20 ----------

Если мой склероз не глючит, то давным давно для пакетной орбработки народ юзал http://linux.about.com/od/commands/l/blcmdl1_sox.htm
Под винду эта софтина была портирована уж лет 10 точно.

Не совсем удобно для меня пользоваться ей, я не программист, придется разбираться.

[Openreel]

ь с расстояний приблизительно в 130000 отсчётов от точки интерполяции, приходящейся на середину Td, перестаёт влиять на точность восстановления из 16-ти битного исходного файла.

130000 заметно меньше, чем длина часового файла.

Например, указанный выше путь оптимизации ресемплера 44/48 приводит лишь к тому, что 1/147 файла не нуждается в вычислениях, а 146/147 нуждаются.

Похоже есть недопонимание.
Процесс, как я его понимаю:
1. апсемплинг х160. Берем исходный файл и на каждый семпл добавляем 159 нулевых семплов.
2. фир фильтрация результата(вычистить спектр все что выше х1). В лоб решать нет смысла, поскольку только 1 из 160ти семплов отличен от нуля.
классическая оптимизация - вместо одного фир фильтра делаем 160 фильтров(не считающих нулевые семплы) и чередуем их.
3. дециматор /147 однако нам не надо считать все эти 160, нам надо только каждый 147ой.

В результате имеем скорость значительно выше, чем решение в лоб, фактический тормозит только длина вектора фильтра.

Но настоящего индейца интересуют ВСЕ ограниченные по спектру сигналы с ограниченными по значению отсчётами с заданной абсолютной точностью

У нас нет никакой абсолютной точности. Исходный файл квантован на уровне 16 бит. Коэффициенты фильтра квантованы тоже.
Брать сверхдлинный фир на мой взгляд нет смысла - при удалении от центра растет ошибка округления и в конце концов остантся только один цифровой шум.
Если исходный файл 16 бит, коэффициенты вектора пусть 16 бит и длина вектора пусть 65535 отсчетов, то аккумулятор требуется уже 48 бит(на самом деле меньше, надо просчитать с учетом реального вектора).
Оно конечно не есть проблема и 64 бита аккумулятор, просто выше была некая забавная оценка про 25 бит.

Я все это к чему - у меня есть желание написать апсемплер (х2..х8, не обязательно кратный) для понять стоит ли избавиться от апаратных цифровых фильтров в цапах.

[s3tup]

а мож не париться, да зафигачить ИИР влоб с дабл-флоатом? Че париться с кучей плоских вычислений, если можно сделать немного но точных ))
25бит - да разве это точность? Не, ну когда на плиско-фпгашке место заканчивается, то итак неплохо... но в компах есть чудо даблфлоат, которым можно мучать сигнал как хочешь и не париться с ошибками округления/шлейфики из нижних битиков/прочая ерунда, мешающая жить на фиксед-пойнт вычислениях.

Ну и топикстартеру - это никоим образом не поможет, ибо ему лучше кормить его странные девайсы-ДСПшки некратными 48кгц сэмпл рейтами, ибо на сколько я эти девайсики встречал, туда тупо лепят АСРЦ на вход, чтоб внутренности ДСПшки всегда бежали под одним локальным клоком - так проще множители под частоту просчитывать. Зачем держать множителей под 44.1, 48, 88, 96 и т.д. по отдельности, да еще на лету переключать - если можно просто АСРЦшку воткнуть на вход и решить, что будем работать только с 48(96).

[Игорь Гапонов]

130000 заметно меньше, чем длина часового файла.

А 130000-й влияет почти также, как и сто единичних семплов с номера 13000000 по 13000099 . Цимес именно в том, что для очень больших номеров остаток гармонического ряда прямо пропорционален количеству отсечённых номеров (т.е количеству отсечённых единичных семплов, тут есть нюансы с чередованием знака семплов, поэтому ждите публикации).

С другой стороны, покажите мне риал тайм фир-ресемплер с количеством "нажатий" более 130000, а?

Похоже есть недопонимание.

Да всё там правильно. Одно из двух или комбинация этих двух: или 159/160 (поправлюсь, тут я ошибся, но не в Вашу пользу) файла "по фиру" или иир-фильтр 159 порядка со всеми вытекающими по устойчивости (например, всплески на крутом срезе отличающиеся от всплесков кирпичной стены их же контроллировать надо, шоб не зашкалили). Закон сохранения...

У нас нет никакой абсолютной точности. Исходный файл квантован на уровне 16 бит. Коэффициенты фильтра квантованы тоже.

Вот тут точно недопонимание, поэтому извините лаборанта за нижеследующую щепетильность.

Точность принято оценивать по отклонению измеренного от "математически ожидаемого". Модуль этого отклонения называется абсолютной погрешностью измерений или абсолютной оценкой точности, а отношение этого модуля к модулю измеренного значения - относительной погрешностью или относительной оценкой точности. На лабораторном сленге - абсолютная точность и относительная точность, потому что нативное понятие абсолютной точности при измерениях смысла не имеет- тогда уже не нужны лаборанты .

Так вот, если не указано иного, то всегда подразумевают, что в файле с нулевого по последний отсчёты- измеренные значения с предельно возможной для них точностью - 1/2 единицы младшего разряда. Однако, это совсем не значит, что математические константы или коэффициенты, вычисляемы из вполне детерминированных функций и используемые при дальнейших расчётах, должны округляться до такой же абсолютной погрешности (чуть не написал- "абсолютной точности"). А при большом количестве членов в вычислительной формуле такое даже вредно (т.е. наш случай), т.к. погрешность будет расти стремительно. Поэтому надо использовать такие коэффициенты с запасом "по разрядности". Как раз та "предельная дуга", о которой я упомянул может служить критерием ограничения разрядности констант (коэффициентов). Её высота сначала довольн сильно зависит от числа отсчётов, но необходимая разрядность не растёт катастрофически: возможная амплитуда этой дуги растёт по логарифмическому закону. Например, для одного миллиарда отсчётов достаточно +6 двоичных разрядов к исходной "битности".

Брать сверхдлинный фир на мой взгляд нет смысла - при удалении от центра растет ошибка округления и в конце концов остантся только один цифровой шум.

Это в общем случае неверно. Действительно, с удалением отсчёта от интервала интерполяции уменьшается коэффициент согласно sinc-функции, как 1/N, где N определяет удаление по времени как NTd. Но и "врождённая абсолютная ошибка" (1/2 МР) слагаемого уменьшается во столько же раз. Конечно, если выбрать адекватную точность коэффициентов (см. выше).

Если исходный файл 16 бит, коэффициенты вектора пусть 16 бит и длина вектора пусть 65535 отсчетов, то аккумулятор требуется уже 48 бит(на самом деле меньше, надо просчитать с учетом реального вектора).
Оно конечно не есть проблема и 64 бита аккумулятор, просто выше была некая забавная оценка про 25 бит.

Надеюсь, теперь Вы поняли , что 25- с избытком, т.к. 16+6=22 (см. выше). Но уверенность может дать только доказательство по "предельной дуге". Во всяком случае, оно у меня есть, и ждёт только публикации.

Я все это к чему - у меня есть желание написать апсемплер (х2..х8, не обязательно кратный) для понять стоит ли избавиться от апаратных цифровых фильтров в цапах.

Очень похвально!

P.S. 2 Оллема

1. Насколько мне известно, любое сглаживание (сплайн) есть нелинейная интерполяция, что по определению

а) расширяет исходный спектр;
б) вызывает нелинейные эффекты.

По всей видимости, нет такого сплайна для наших котельнических баранов, чтоб продукты нелинейности лежали бы ниже 1/2 МР для любого ограниченного по спектру исходного сигнала. Но доказать это строго очень сложно.

2. Искусственное устранение "звона" так же расширяет спектр, т.к. по всем известным теоремам отклик кирпичной стены на дельта импульс бесконечен во времени, т.е. принципиально звенит. Поэтому надо его "за пределами файла" оберегать, а не уничтожать. И по крайней мере так долго, как это необходимо для затуханий в 1/2 МР.

[Оллема]

Правильно ли я понимаю, что по-вашему получается, что фильтровать после передискретизации не нужно? Оберегать - это именно это?

[flipper]

По сути, дублирование процессов. Но выше 384к с компа не выведешь. Если это устараивает, можно и выкинуть ЦФ.

[frezer]

Ну и топикстартеру - это никоим образом не поможет, ибо ему лучше кормить его странные девайсы-ДСПшки некратными 48кгц сэмпл рейтами, ибо на сколько я эти девайсики встречал, туда тупо лепят АСРЦ на вход, чтоб внутренности ДСПшки всегда бежали под одним локальным клоком - так проще множители под частоту просчитывать. Зачем держать множителей под 44.1, 48, 88, 96 и т.д. по отдельности, да еще на лету переключать - если можно просто АСРЦшку воткнуть на вход и решить, что будем работать только с 48(96).

А что такое АСРЦ и что оно делает? А то не пойму почему лучше кормить не кратными 48 кГц семплами?

[Игорь Гапонов]

Правильно ли я понимаю, что по-вашему получается, что фильтровать после передискретизации не нужно? Оберегать - это именно это?

На самом деле линейная "точечная" интерполяция, что и представляет собой апсемплинг, всегда приводит к расширению файла: в исходном виде мы же подразумеваем, что "за пределами файла" лишь отсчёты равны нулю, но не то, что между ними . Именно эта договоренность/предположение обеспечивает представление ограниченного по спектру сигнала ограниченным числом НЕНУЛЕВЫХ отсчётов.

[Оллема]

апсемплинг - это не обязательно линейная интерполяция.Вопрос - какая лучше

[Игорь Гапонов]

2Оллема "Линейная" - в смысле преобразования, а не "соединение точек прямой линией", которая таки нелинейна (нелинейная интерполяция первого порядка). Сплайн обычно интерполяция третьего порядка (кубическими параболами).

Между прочим, простое "удержание отсчёта" на полный период или на часть его в качестве "антиглича" (т.е. нелинейная интерполяция нулевого порядка) не приводит к появление продуктов нелинейности в полосе сигнала (тем и славны "бесфильтровые ЦАПы"), но за пределами- таки да!

То, что мы обсуждаем с Openreel - линейные преобразования над дельта функциями (отсчётами, семплами) или, по-другому, - линейная интерполяция.