Просто подвинуть дорожку с левым микрофоном на несколько туда/сюда нельзя чтоли?ну, без шуток - я не представляю себе как бы я двигал левый мик относительно правого (в случае оверхэдов) после записи.
Просто подвинуть дорожку с левым микрофоном на несколько туда/сюда нельзя чтоли?ну, без шуток - я не представляю себе как бы я двигал левый мик относительно правого (в случае оверхэдов) после записи.
-это да у разных устройств будет разнофаз на высоких частотах , для этого там синхра по wc предусмотрена,По итогу - что в AES, что в SPDIF - нет фреймовой синхронизации.
-такая стабильность просто не имеет смысла в нашем случае , к тому же у них фазовый шум большой т.к приведение к нужным@digilab2, а как же цезий?
Нельзя. Фотку я запостил где ваще никак нельзя. Мне кажется топикстартер меня проклянет если я этот оффтоп еще и поддерживать стану, сорри.
И Дима расширенно ответил - любая не точность установки микрофонов сместит вам слышимый центр, например малого барабана, на не сопоставимые разбежавшимся синхрам величины.это критично как только вы начинаете записывать один источник звука на несколько микрофонов.
Да вы то тут при чём? Вопрос правильный......... и обсуждение с вашим участием абсолютно корректное.@Radiator, Нельзя. Фотку я запостил где ваще никак нельзя. Мне кажется топикстартер меня проклянет если я этот оффтоп еще и поддерживать стану, сорри.
Мне был интересен механизм синхронизации двух интерфейсов по эзернету с точностю до сэмпла. Не хотел совсем чтоб это вылилось в это вот все. Глядишь щас ругань пойдет =\
не, тут вы что то не то говорите мне кажется.г) Ну если вот прям пурист-пурист, то не разбивайте стереопару на два девайса. Ну раз уж прям весь хит не создается из-за осознания того, что присутствует какой-то (какой, кстати, см. п. б) сдвиг.
Сдвиг микрофона на 3-4мм слышен точно при съеме как на моей фотке на левом кабе (два микрофона в одну точку)
боюсь не прочитали вы мое сообщение таки.Так на 3-4 мм где-нибудь в районе приклейки купола слышно в одном микрофоне. Там сильно сказывается эффект неточечного источника и неточечного съема. И ничего, живут с этим ))))
Какой же тест может выявить величину плавающего клока на разных девайсах, который может повлиять на звук?Александр - ваш тест ничего не даст. Оценивать запись постфактум, не слыша того что было до попадания сигнала в АЦП ничего не даст.
Вы же клоки время от времени синхронизируете наверное?
@buncker, у Дмитрия есть некий посыл считать свои решения верными.... от сюда возможно и кажущаяся защитная реакция...., тем более когда начинается офтоп от @digilab2, с непонятной поддержкой Лонга...
У меня же всегда более чем конструктивный подход к любой критике или даже теоретической проблеме... я крайне заинтересован в отсутствии каких либо проблем в финале этого мероприятия и ежедневно проделываю десятки тестов...
Какой же тест может выявить величину плавающего клока на разных девайсах, который может повлиять на звук?
Не в качестве защиты, а чтоб выяснить есть ли реальная проблема или она только теоретическая.
Дмитрий этого не видит и отвечает про сдвиг микрофона относительно динамика
Записать это все, инвертировать фазу на одном из треков и смотреть как вычтется?
ну, вот лично я ловлю нужную мне гребенку. Какие там еще факторы есть - мне не хватает ни опыта ни опытной базы выложить тут как готовое решение. Все что я могу сказать что есть реальные области применения где гуляющая гребенка будет браком и поводом дял криков в сети "этот интерфейс не звучит".Я вижу, конечно, я к тому, что там кроме гребенки из-за разного времени прихода масса факторов.
вероятно имеет какой то смысл сделать какие-то тесты (может и то что я пердложил сгодится), и посмотреть что получится.Ну будет разница. Какая-то. Как ее экстраполировать на реальные применения?
на сколько я понимаю один интерфейс будет плавать относительно другого на эти 2мкс
Я завтра постараюсь сделать тестовую запись на три мика ... специально на три разных девайса
засинхронизированных по сети друг с другом.
Устройства, синхронизированные только по клоку - неважно, WC или
экстрагированному из Ethernet - будут работать с одной и той же частотой
дискретизации, т.е. синхронно.
Но это не будет синфазно, т.к. сам момент старта преобразования в АЦП - он
никак, АБСОЛЮТНО НИКАК, не привязан ни к чему вообще.
Да и привязываться ему просто не к чему - я ж писал уже:
>все очень спешили в кассу, на тщательное обдумывание время тратить не хотели.
Но это не будет синфазно, т.к. сам момент старта преобразования в АЦП - он
никак, АБСОЛЮТНО НИКАК, не привязан ни к чему вообще.
А для оставшихся 5% возможной проблема станет только в случаи вашего примера с комбиком, когда итоговый тембр сильно зависит от этой разбежности - и то, только в случаи микрофонов воткнутых в разные девайсы не ясно зачем.Да и для 95% будущих юзеров это не буде тпроблемой бо будут юзать только один дивайс.
Для барабанной установки действительно одного 8-и канального девайса не хватит, но будет ли реально слышимая проблема - похоже, что нет, раз вы от теста с оверами отказались.
Вот честно - как на духу. - я технарь. Хвастаться не хорошо но какой-то опыт имею, иногда вижу какие-то возможные проблемы.А для оставшихся 5% возможной проблемой станет только в случаи вашего примера с комбиком, когда итоговый тембр сильно зависит от этой разбежности - и то, только в случаи микрофонов воткнутых в разные девайсы не ясно зачем.
Для барабанной установки действительно одного 8-и канального девайса не хватит, но будет ли реально слышимая проблема - похоже, что нет, раз вы от теста с оверами отказались.
бо реально выглядит будто я вас тут троллю, и в конце концов соскакиваю с некоего кровавого спора. Даже обидно немного...но будет ли реально слышимая проблема - похоже, что нет, раз вы от теста с оверами отказались.
-- Не, все цифры тут чисто иллюстративные, от балды - бо непредсказуемы принципиально.
Каждый следующий (пере)запуск от внешней синхронизации - сдвигает момент старта
преобразования абсолютно произвольно:
Так я же много раз в теме писал - любая конструктивная критика приветствуется!!!!Вот честно - как на духу. - я технарь. Хвастаться не хорошо но какой-то опыт имею, иногда вижу какие-то возможные проблемы.
Ваш дивайс - будущая коммерция, и вы сейчас в стадии разработки, учесть\поправить можете все что угодно.
Если я написал фигню и бред, ну и ладно.
Если есть зерно разумное, может что-то и улучшите\поправите. Не зря день прошел, не зря на форум написал.
Итого, цели доказать что-то не имею.
Не хотел обидеть аж ни разу. Я имел в виду, что вы отказались от предложенного теста видимо понимая, что на нём ни чего не увидите и не услышите. Ну почему все в начале ожидают какого то негатива...... и мысли не было. Наоборот.и вот это мне кажется не уместно
бо реально выглядит будто я вас тут троллю, и в конце концов соскакиваю с некоего кровавого спора. Даже обидно немного...
Сергей, если обнаружиться реально слышимая проблема - мы будем думать как её чинить. На самом деле есть как, но стоит ли - в этом вопрос.И если уж на то пошло - вы реально хотите чтоб я по записи сделанной где-то, кем-то, как-то, попытался услышать БЫЛА БЫ ОНА ДРУГОЙ еслиб ее записали на другой интферфейс? И доказал вам необходимость что-то чинить? Хрен знает даже... ну еслиб услышал - вы бы стали что-то чинить? ))))
ребят вы чего? ))
вы слушая компакт диск определите это овера криво стояли или потолок в студии зеркальный и звенит или рядом газонокосилка ездила или кто то сварочный аппарат приволок в соседнюю комнату? )))
На полном миксе вы вообще ни чего не услышите из осуждавшегося выше. Но при записи на три мика воткнутые в разные девайсы, при условии, что я очень аккуратно установлю все три мика и выверю расстояние до миллиметра, можно увидеть по форме сигнала разбежность, можно возможно и услышать смещение центра удара. А если ни чего не увидим и не услышим - так может и испугались зря?
Итого ведомый АЦП всегда запускается не позднее чем через 2мкс после ведущего.
Да, но реальность немного сложнее. Там есть локальный генератор, который, собственно говоря, отвечает за время запуска АЦП. Разность между временем запуска локального АЦП и временем прихода пакета синхронизации (который да, привязан к моменту старта АЦП мастера) попадает на вход PID-регулятора. Это сигнал ошибки. Выход регулятора - это управление частотой локального генератора. После старта постепенно (десяток секунд, постоянная времени специально сделана большой, чтобы отфильтровать шум, связанный с дрожанием времени прихода пакета) оба генератора оказываются в синхронизме, при этом моменты выборки совпадают. Остаются только сугубо технические моменты компенсации времени прохождения пакета через сеть и его обработки.
Естественно, в пакете синхронизации передаётся и номер фрейма у мастера, чтобы у всех все совпадало в смысле нумерации семплов.
Никакой «экстракции клока из эзернета» и прочей ереси, которая Лонгу мерещится, тут нет. Банальная PLL.
@Rst7, Дима - можно нагрузить выход двумя входами простым сплитером?