Потерялся старший бит. Его восстановить и будить счастье с сохранением формы волны. Обычные деклиперы пытаются восстановить, у вас же всё есть. Надо добавить постоянную составляющую в "заклипированную" облясть. Если у вас АЦП 16 бит (думаю что это ADAT, именно он грешил подобным), то DC надо добавить на уровне
desc DC offset positiv
@sample
spl0+=2;
spl1+=2;desc DC offset negativ
@sample
spl0-=2;
spl1-=2;Для такого скрипта эта не было бы проблемой
У вас скорее всего было целочисленная оцифровка. Потерян старший бит. Так как представление сигнала идёт от -1 до 1, то разница этого бита и есть 2.
Ок. меняем условие
то же изменение будет на |2|. Такого изменения собычным или необычным сигналом не бывает. Так что можно засчитывать как за переполнение и так же применить скрипт. Скрипт можно применить на всё и если есть изменение на2, то его можно засчитывать как за переполнение.
То же самое.
Что ещё нужно учитывать при переполнении? То как сигнал получил насыщение, так это не предугадать. Хотя можете сверху деклипером потом пройтись. Только надо ли оно? Скрипт спасёт файлы от переполнения и звучать они будут как надо.
Не испортит - работа, хоть и диструктивная, будет проводиться над копией.
Это я понял. Но это описан частный случай. Разница 2 в вашей системе координат, это разница между максимальными значеними, а не промежуточными... а немаксимальные значения тоже возможны! У вас описан случай когда ризница между соседними точками равна одному, при условии что предыдущий отсчёт был максимальным. То есть грубо говоря было максимальное значение например 16536 потом амплитуда перевалила на ОДНО значение и стала -16536. Это частный случай. А если, к примеру была ситуация, когда было 16500 и разница между соседними точками составила 100, а не один.. тогда будет переполнение на 64 и они вылезут... то есть будет -16536+64 = -16472.
Почему не бывает? Правильный меандр с максимальной амплитудой именно так и выглядит. Бывает!
Вообще-то 2
На 2, а не на 1.
Ваш частный случай.
В целочисленном представление у 16-ти разрядного числа 2^15=32768 соответствует 1 в представление числа с плавающей запятой (16-ый разряд отвечает за плюс минус). Поэтому работая с числами с плавающей запятой можно не учитывать сколько разрядов у целочисленного числа. Потерянный из-за переполнения разряд даст разницу 2, так как разница между +1 и -1 есть 2. А ваше 100 в целочисленном представление будет соответствовать
Ещё раз, вы оперируете целочисленными значениями, а я описываю работы с цифрами с плавающей запятой, то как это представляется в Рипере. Не путайте пожалуйста метры с миллиметрами. Хотя это сравнение не полностью описывает эту разницу.
Я думаю вам уже пора перестать спорить в том, где вы не сильны.
Сможете это доказать - сниму шляпу, иначе вам придется извиниться.
Ваша правда. Тот самый случай когда алгоритм даст сбой. Но! Это при идеальных условиях. В реальной же ситуации к сигналу будет подмешан шум выходного каскада источника сигнала, шум входного предусилителя звуковой карты. Наверняка перегруз не сильно большой. Что-то мне подсказывает что таких файлов у вас если и будет, то очень мало.
Ну не совсем безнадёжный брак, как в случае с клиппированием в потолок. Тут всё же информация остаётся, только она вылазит снизу, и думаю можно найти способ, чтоб её восстановить. Думаю вариант предложенный выше, детектить разницу между соседними точками верный... только я не согласен с тем, что нужно детектить максимальную разницу, которая по мнению belovw равняется двум, при условии, что 2 это разница между максимальным и минимальным значением определённой разрядности. В большинстве случаем там разница будет меньше двух... но не намного... что-то типа в промежутке от 1.9 до 2. Думаю этого условия было бы достаточно для подавляющего числа проваленных пиков, чтоб брак превратить в 'не брак' ) . И до сих пор надеюсь, что есть уже готовые решения от топовых производителей плагинов, ибо ситуация классическая, и буду удивлён, что до сих пор никто не создал метода исправления.
Такой тип перегруза в отличии от "потолкового" клиппирования даёт очень жёсткие щелчки ... сигнал в таком виде точно юзать невозможно.
Со звуковухой всё норм. Дело не в микрофоне... это особенность программы Samplit. Она искажает сигнал подобным образом - и при записи и при зацикливании лупа+ нормализация, даже если исходный сигнал был без клиппирования. Недопилили софт... Если писать этот же сигнал в аудишн, то такой фигни с переполненным битом не происходит.
в случае с семплированием железа всегда приходится искать компромисс между максимально возможным уровнем полезного сигнала и минимальным шумом... Поэтому уровень записи всегда приходится выставлять на грани потолкового уровня, но.... иногда вылазят такие косяки
Есть, находятся в стадии Бетта тестирования. Так как производитель неотечественный, рассчитывать на фрэндли прайс не стоит.
Необходимы доп проверки.
