Клиппинг (потеря старшего бита)

[TechnoIsBack]

Подскажите, как быть если при записи был клиппинг, при этом сигнал не просто упирается в "потолок", а вылазит снизу. Какими средствами это можно исправить ... желательно пакетно? Обычно деклипперы работают с сигналом, который упёрся в потолок... а такой тип клиппирования как-то можно пофиксить?

PS - форум глюканул... удалите плиз одну из копий темы

 

[belovw]

такой тип клиппирования как-то можно пофиксить?

Потерялся старший бит. Его восстановить и будить счастье с сохранением формы волны. Обычные деклиперы пытаются восстановить, у вас же всё есть. Надо добавить постоянную составляющую в "заклипированную" облясть. Если у вас АЦП 16 бит (думаю что это ADAT, именно он грешил подобным), то DC надо добавить на уровне
20*log(2^16)=96,329598612473982468396446311838 дБ.
Это для положительной полуволны. С отрицательной полуволной наверное происходит что-то подобное. У неё скорее всего тоже надо будет ввести DC сдвиг, только не в плюс, а в минус.

К сожалению варианта пакетной обработки такого "клипирования" я не знаю. Поэтому каждый участок придется обработать в ручную. В рипере я бы написал два плагина для положительного и отрицательного DC offset. Код получается очень простым. Ведь смещать надо на постоянную величину и независимо от разрядности АЦП значение DC offset составляет 2 для положительного клипа и -2 для отрицательного. Посадил бы их на горячие клавиши и назначал бы на айтемы которые надо сдвинуть.

код:

desc DC offset positiv
@sample
spl0+=2;
spl1+=2;

desc DC offset negativ
@sample
spl0-=2;
spl1-=2;

 

[TechnoIsBack]

@belovw, Спасибо за ответ. Но ... к сожалению вручную нереально... 16000 файлов отсемплированной библиотеки... в некоторых из них проскакивает такой тип клиппирования. Нужно что-то, что на автомате детектило бы перегруз... и желательно в пакетном режиме. Идеально, если бы эта функция была в AdobeAudition или SoundForge. Но вроде там такого типа деклиппера с переполненным старшим битом не нашёл. А может там и есть такая функция... может я как-то неправильно настраиваю штатные деклипперы.

 

[belovw]

Можно было бы и скрипт написать что бы автоматически вставить DC offset, но я в этом не силён.
@Michael или @PianoIst могли бы помочь. Мож ещё кто, не припомню.
Думаю в качестве условия подключения DC offset можно использовать изменение громкости сэмпла на значение 2. Срендерить новый айтем и диструктивно его изменять. Например:

Для просмотра скрытого содержимого необходимо Войти или Зарегистрироваться.

Думаю такой скрипт был бы тем что нужно.

16000 файлов отсемплированной библиотеки

Для такого скрипта эта не было бы проблемой
Загружаете последовательно все файлы на один трек, запускаете скрипт и он генерит новые файлы.

 

[TechnoIsBack]

@belovw, думаю там всё же условие должно быть сложнее, а алгоритм деклиппера должен учитывать различные варианты. На 2 это частный случай. Сигнал мог прыгнуть выше порога на одно значение , а мог и на два, три, пять... сто... эти два, три, пять ... сто... вылезут снизу ... И если это будет сто, то уже не так явно, но всё равно возможно. С другой стороны если взять прямоугольную форму фолны, то там тоже значения будут с резким перепадом от низкого к высокому... Такой сигнал собъёт с толка такой алгоритм. Или другой "правильный" высокочастотный сигнал с резкими перепадами. Алгоритм должен учитывать не просто соседние биты в перепаде... а понимать, что произошло клиппирование ряда соседних значений. Короче, тут нужен продуманный подход, а не простой скрипт... иначе такой простой скрипт скорее испортит файлы, чем внесёт ясность. Там нужен скорее всего какой-то дифференциальный анализатор, который будет отслеживать направление сигнала по разнице соседних бит... типа если направление волны было вверх, и потом она резко вылезла снизу с тем же направлением, то зафиксировать в этой области факт переполнения бита... что-то вроде этого, думаю, было бы более эффективным ... и это явно должна быть область с медленным движением волны в отличии от явных резких границ.

 

[belovw]

На 2 это частный случай.

У вас скорее всего было целочисленная оцифровка. Потерян старший бит. Так как представление сигнала идёт от -1 до 1, то разница этого бита и есть 2.

Сигнал мог прыгнуть выше порога на одно значение , а мог и на два, три, пять... сто... эти два, три, пять ... сто... вылезут снизу

Ок. меняем условие

Для просмотра скрытого содержимого необходимо Войти или Зарегистрироваться.

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

то же изменение будет на |2|. Такого изменения собычным или необычным сигналом не бывает. Так что можно засчитывать как за переполнение и так же применить скрипт. Скрипт можно применить на всё и если есть изменение на2, то его можно засчитывать как за переполнение.

Или другой высокочастотный сигнал.

То же самое.

Алгоритм должен учитывать не просто соседние биты в перепаде...

Что ещё нужно учитывать при переполнении? То как сигнал получил насыщение, так это не предугадать. Хотя можете сверху деклипером потом пройтись. Только надо ли оно? Скрипт спасёт файлы от переполнения и звучать они будут как надо.

иначе такой простой скрипт скорее испортит файлы

Не испортит - работа, хоть и диструктивная, будет проводиться над копией.
В прочем проблема ваша, развлекайтесь. Удачи.

 

[TechnoIsBack]

У вас скорее всего было целочисленная оцифровка. Потерян старший бит. Так как представление сигнала идёт от -1 до 1, то разница этого бита и есть 2.

Это я понял. Но это описан частный случай. Разница 2 в вашей системе координат, это разница между максимальными значеними, а не промежуточными... а немаксимальные значения тоже возможны! У вас описан случай когда ризница между соседними точками равна одному, при условии что предыдущий отсчёт был максимальным. То есть грубо говоря было максимальное значение например 16536 потом амплитуда перевалила на ОДНО значение и стала -16536. Это частный случай. А если, к примеру была ситуация, когда было 16500 и разница между соседними точками составила 100, а не один.. тогда будет переполнение на 64 и они вылезут... то есть будет -16536+64 = -16472.

Ваше условие этого не учитывает, а вариант возможный... и таких вариантов много. Ваш вариант учитывает только случай, когда разница между соседними точками увеличивается на одно значение амлитуды из миллиона.

Такого изменения не бывает. Так что можно засчитывать как за переполнение.

Почему не бывает? Правильный меандр с максимальной амплитудой именно так и выглядит. Бывает!

 

[belovw]

описан случай, когда ризница между соседними битами равна одному

Вообще-то 2

То есть было максимальное значение например 16536 потом амплитуда перевалила на ОДНО значение и стала -16536.

На 2, а не на 1.

Это частный случай.

Ваш частный случай.

А если, к примеру была ситуация, когда было 16500 и разница между соседними битами составила 100, а не один

В целочисленном представление у 16-ти разрядного числа 2^15=32768 соответствует 1 в представление числа с плавающей запятой (16-ый разряд отвечает за плюс минус). Поэтому работая с числами с плавающей запятой можно не учитывать сколько разрядов у целочисленного числа. Потерянный из-за переполнения разряд даст разницу 2, так как разница между +1 и -1 есть 2. А ваше 100 в целочисленном представление будет соответствовать
100/(2^15)=0.0030517 числу с плавающей запятой, а это даже близко не 2

А если, к примеру была ситуация, когда было 16500 и разница между соседними битами составила 100, а не один.. тогда будет переполнение на 64 и они вылезут... то есть будет -16536+64 = -16472.

Ещё раз, вы оперируете целочисленными значениями, а я описываю работы с цифрами с плавающей запятой, то как это представляется в Рипере. Не путайте пожалуйста метры с миллиметрами. Хотя это сравнение не полностью описывает эту разницу.

Ваше условие этого не учитывает, а вариант возможный... и их таких вариантов много.

Я думаю вам уже пора перестать спорить в том, где вы не сильны.

 

[TechnoIsBack]

Я думаю вам уже пора перестать спорить в том, где вы не сильны.

Взаимно!

 

[belovw]

Взаимно!

Сможете это доказать - сниму шляпу, иначе вам придется извиниться.

 

[Jeysound]

Буду краток.
Брак, в помойку.
Либо "как есть" пользовать.
Это вообще с микрофонами святое дело уровень входящего сигнала настроить. Причём надо не "помычать" в него. А именно поорать, на уровне интонации и планируемой записи громкости. Тогда всё будет гут.
Если есть сомнения, уровень меньше, всегда лучше чем уровень больше.
Голос штука такая, может прыгать в пределах 30дб.

 

[basЫl]

причем брак ацп - форма сигнала сохранена

 

[belovw]

@TechnoIsBack, скиньте с десяток заклипированных файлов. У меня есть идея безскриптового решения с помощью плагина, который я только что придумал. Если кратко то метод основывается на последовательном преобразовании рядов с вычетом аппроксимации многочлена. На моей математической модели алгоритм дал 100% восстановление сигнала. В вашем случае будет присутствовать доп насыщение сигнала. Если бы знать ВАХ звукозаписывающего тракта то можно было и это восстановить, но боюсь информацией о четырехполюснике вы не обладаете.

 

[belovw]

С другой стороны если взять прямоугольную форму фолны, то там тоже значения будут с резким перепадом от низкого к высокому... Такой сигнал собъёт с толка такой алгоритм.

Ваша правда. Тот самый случай когда алгоритм даст сбой. Но! Это при идеальных условиях. В реальной же ситуации к сигналу будет подмешан шум выходного каскада источника сигнала, шум входного предусилителя звуковой карты. Наверняка перегруз не сильно большой. Что-то мне подсказывает что таких файлов у вас если и будет, то очень мало.
В общем жду от вас образцы с перегрузом, таким как вы показали на картинке в первом посте этой темы.

 

[belovw]

Чистый меандр и пила пока нормально не восстанавливаются этой версией алгоритма. Но комплексный сигнал без проблем.

 

[TechnoIsBack]

Буду краток.
Брак, в помойку.

Ну не совсем безнадёжный брак, как в случае с клиппированием в потолок. Тут всё же информация остаётся, только она вылазит снизу, и думаю можно найти способ, чтоб её восстановить. Думаю вариант предложенный выше, детектить разницу между соседними точками верный... только я не согласен с тем, что нужно детектить максимальную разницу, которая по мнению belovw равняется двум, при условии, что 2 это разница между максимальным и минимальным значением определённой разрядности. В большинстве случаем там разница будет меньше двух... но не намного... что-то типа в промежутке от 1.9 до 2. Думаю этого условия было бы достаточно для подавляющего числа проваленных пиков, чтоб брак превратить в 'не брак' ) . И до сих пор надеюсь, что есть уже готовые решения от топовых производителей плагинов, ибо ситуация классическая, и буду удивлён, что до сих пор никто не создал метода исправления.

Либо "как есть" пользовать.

Такой тип перегруза в отличии от "потолкового" клиппирования даёт очень жёсткие щелчки ... сигнал в таком виде точно юзать невозможно.

Это вообще с микрофонами святое дело уровень входящего сигнала настроить. Причём надо не "помычать" в него. А именно поорать, на уровне интонации и планируемой записи громкости. Тогда всё будет гут.
Если есть сомнения, уровень меньше, всегда лучше чем уровень больше.
Голос штука такая, может прыгать в пределах 30дб.

Со звуковухой всё норм. Дело не в микрофоне... это особенность программы Samplit. Она искажает сигнал подобным образом - и при записи и при зацикливании лупа+ нормализация, даже если исходный сигнал был без клиппирования. Недопилили софт... Если писать этот же сигнал в аудишн, то такой фигни с переполненным битом не происходит.

Если есть сомнения, уровень меньше, всегда лучше чем уровень больше.

в случае с семплированием железа всегда приходится искать компромисс между максимально возможным уровнем полезного сигнала и минимальным шумом... Поэтому уровень записи всегда приходится выставлять на грани потолкового уровня, но.... иногда вылазят такие косяки

 

[Long]

Для просмотра скрытого содержимого необходимо иметь 100500 сообщений

-- Лихо!

 

[Long]

-- Эх, даже Zerocool - и тот, не сможет прочесть!

 

[belovw]

надеюсь, что есть уже готовые решения от топовых производителей плагинов

Есть, находятся в стадии Бетта тестирования. Так как производитель неотечественный, рассчитывать на фрэндли прайс не стоит.

 

[TechnoIsBack]

Чистый меандр и пила пока нормально не восстанавливаются этой версией алгоритма. Но комплексный сигнал без проблем.

Необходимы доп проверки.

Для пилы нужно проверять условие, чтоб после переполнения был возврат с той же стороны в пределах разумного периода, скажем в пределах нескольких мс. В этом случае пила не пройдёт, потому что пила выходит с одной стороны, а заходит в другую.

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