Цифровой сумматор...

  • Автор темы Автор темы Дед
  • Дата начала Дата начала
Вот вам ещё аналогия - берём кучу цифровых источников, и кучу
записыващих устройств с цифровым входом. Соединяем каждый
с каждым и в один момент времени запускаем всю эту трехомудию:
источники на воспроизведение, а приёмники на запись. Пишем
какое-то время, и также синхронно всё останавливаем. Затем
получившиеся ФАЙЛЫ (вероятнее всего одинаковой длины,
либо пренебрежимо малых расхождений в ~пару-тройку семплов)
РУКАМИ переносим из каждого рекордера в отдельный проект в
компьютерный мультитрекер и там суммируем. На выходе получаем
сумму. Ну просто самая прямая аналогия, причём вполне подлежащая
проверке на практике! Опровергайте!

Ну зачем же так сложно?
Просто последовательно запишите каждый из цифровых источников, сделав его Мастером.
А чё опровергать то?
Мультитрэк работает точно также как и SRC - т.е. приводит всё к единому Clock-у!!!!
Но он не умеет этого делать при записи нескольких не синхронизированных источников.
 
Alexander Yakuba,
согласен..., больше про "базовые знания" и всё такое... - не буду.
Тэрмина самосинхронизация не существует, а БигБэна у вас даже больше чем два, оброзно говоря, естественно. Один стоит в вашем Пульте (там есть Clock), второй стоит в вашей звук. карте RME, ещё по одному в каждом Рэковом Pod-е. Цифровым устройствам современным пофиг по какому шнурку передавать опорный сигнал, что по отдельному кооксиалу, что по любому из цифровых шнурков с данными. В AES/EBU (SPDIF) нету никакой самосинхронизации, в этих стандартах просто, кроме полезного сигнала, выделяется несколько бит для передачи Синхроимпульсов от того Clock-а, который вы назначите Мастером.
Александр. Термин "самосинхронизация" - существует! Не верите
музыченковскому FAQ-у? Эх, наверное Вас не было в фидо...
Вы спросите у Михаила - он-то наверняка помнит...
Хорошо, гуглим дальше:
http://ru.wikipedia.org/wiki/Spdif
Протокол
S/PDIF может быть использован для передачи цифровых сигналов множества форматов. Наиболее распространены из них: формат использованный в DAT с частотой дискретизации 48 кГц и формат записи компакт-дисков с частотой дискретизации 44,1 кГц. Для того, чтобы поддерживать обе эти системы, формат не имеет определенного битрейта данных. Взамен данные передаются, используя Biphase Mark Code, который имеет один или два перехода для каждого бита данных, позволяя передавать оригинальный word clock вместе с самим сигналом.

http://www.intuit.ru/department/network/baslocnet/3/3.html
Три остальных кода (RZ, манчестерский код, бифазный код) принципиально отличаются от NRZ тем, что сигнал имеет дополнительные переходы (фронты) в пределах битового интервала. Это сделано для того, чтобы приемник мог подстраивать свои часы под принимаемый сигнал на каждом битовом интервале. Отслеживая фронты сигналов, приемник может точно синхронизовать прием каждого бита. В результате небольшие расхождения часов приемника и передатчика уже не имеют значения. Приемник может надежно принимать последовательности любой длины. Такие коды называются самосинхронизирующимися. Можно считать, что самосинхронизирующиеся коды несут в себе синхросигнал.

И далее, там и про бифазный код:
http://www.intuit.ru/department/network/baslocnet/3/4.html
http://www.intuit.ru/department/network/baslocnet/3/5.html

Всё это хозяйство входило в наш институтский курс "периферийные
устройства" - на этом самом кодировании работают дисководы,
винчестеры и т.п. ЗУ, локальные сети и т.д...
Препод у нас строгий был, все эти коды среди ночи разбуди тогда
я помнил наизусть... Сейчас всё подзабыл, конечно, но гугль рулит :)
 
Мультитрэк работает точно также как и SRC - т.е. приводит всё к единому Clock-у!!!!
Нет. SRC - это именно conversion - преобразование, или пересчёт.
В мультитреке же исходные сигналы НЕ преобразуются (в простейшем
случае воспроизведения или суммирования без использования
обработок и функций микшера).
 
Выборка осуществляется исключительно по фактическому приходу первого слова с каждого из потоков

Простите, не удержался... А что это у Вас за мультитрек, которому пофиг, с какими частотами по разных входах в него приходят данные, при том он принимает их по факту а не клоку, без клипов и тп всё съедает и, главное, потом также само хорошо рулит обратно? Может у него ввод-вывод производится на частотах кратных, например, 44100х48000? Тогда да! - можно, да ещё и в риэлтайм! А если ещё поднять - порядка на три повыше - так он сможет разложить по полочкам всё цыфровое, что имеем сейчас в наличии!!!
 
что это у Вас за мультитрек, которому пофиг, с какими частотами по разных входах в него приходят данные, при том он принимает их по факту а не клоку, без клипов и тп всё съедает и, главное, потом также само хорошо рулит обратно? Может у него ввод-вывод производится на частотах кратных, например, 44100х48000? Тогда да! - можно, да ещё и в риэлтайм! А если ещё поднять - порядка на три повыше - так он сможет разложить по полочкам всё цыфровое, что имеем сейчас в наличии!!!
Мультитрек разумеется гипотетический. Я всего лишь пытаюсь объяснить,
что такие варианты в принципе возможны, как мне кажется. Ваша задача -
доказать обратное ;)

Чтож, буду опять повторяться:
1. "Частоты пофиг"? Да, фактические частоты пофиг, и если я на время укажу,
что разночастотные треки имеют единую частоту - любой мультитрек
из просуммирует. Присылайте мне два файла 44 и 48, сделаю цифровую сумму
без SRC (только в одном из файлов изменится скорость).
2. "По факту"? Разумеется по факту - когда я руками вгружаю в него файлы -
это и есть приём по факту, а не по клоку. Реалтайм-то кончился.
3. Про "клипы и тп" - не совсем понял, если честно... :-\
 
А чё опровергать то?
Как это что? Что алгоритм работает! :victory: Он ведь работает, Александр?

а БигБэна у вас даже больше чем два, оброзно говоря, естественно. Один стоит в вашем Пульте (там есть Clock), второй стоит в вашей звук. карте RME, ещё по одному в каждом Рэковом Pod-е.
Но они несинхронны меж собой. А в биг-бене все его выходы синхронны.
Это такой же мастерклок генератор, как и ваш Drawmer M-Clock Plus.
http://www.apogeedigital.com/products/bigben.php

Ошибаетесь, и термин РиалТайм не правильно понимаете.
Так растолкуйте же неразумному, как надо ПРАВИЛЬНО понимать термин
Realtime!
 
Я конечно "10 000 раз" прошу прощения, но как-то оно сильно напоминает разсуждения про сферического коня в вакууме, или соревнования у кого богаче фантазия... очень надеюсь, что ошибаюсь...
 
Я конечно "10 000 раз" прошу прощения, но как-то оно сильно напоминает разсуждения про сферического коня в вакууме, или соревнования у кого богаче фантазия... очень надеюсь, что ошибаюсь...
Ага - мультитрековый самосинхронизирующийся конь! :girl_crazy:

зы: Даже если и фантазия - а разве фантазия это плохо? Тем более
для творческих работников! Может быть это как раз то, чего некоторым
в этой жизни немного не хватает? ;)
 
Aleksandr_Oleynik написал(а):
Алексей, пока вы с Александром не остались один на один с найденным вами чудо-алгоритмом, ответте на совсем простой вопрос -
почему это до такого "решения" никто до сих пор не додумался и не реализовал его ХОТЯБЫ в софтовом варианте?
На это ответить очень просто! Такое решение давно реализовано в софтовом варианте в любой многодорожечной звуковой студии или даже просто компьютерном мультитрекере. Если вы возьмете файлы со всех ваших "несинхронных" устройств и перепишете их на одно устройство (хоть по AES, хоть на дискетке - неважно), а потом смикшируете, то при этом будет достигнут ровно такой результат, какой будет достигнут в предлагаемом Александром внешнем устройстве. Более того, - осмелюсь еще раз подчеркнуть - этот метод, скорее всего, будет более правильным и качественным, чем если бы использовалась SRC. Еще раз поясню: Александр предлагает именно эмуляцию обычного мультитрекера во внешнем устройстве.
 
Alexander Yakuba написал(а):
Таким образом самосинхронизация выделит некое "абсолютное" время, и получившиеся в буферах вавки а-приори корректны.
Вот тут есть возможная ошибка. Хотя считается, что разные дорожки для многодорожечного проекта надо записывать с общим мастер-клоком, этого на практике никто не гарантирует. Если они были записаны с различными независимыми клоками, то "абсолютное время, восстановленное по отсчетам", будет (немного) расходиться.
 
  • Like
Реакции: Alexander Yakuba
Александр, все ваши цитаты всего лишь подтверждают тот факт, что цифрового сигнала, который бы сам себя синхронизировал, не существует. -

Протокол
S/PDIF может быть использован для передачи цифровых сигналов множества форматов. Наиболее распространены из них: формат использованный в DAT с частотой дискретизации 48 кГц и формат записи компакт-дисков с частотой дискретизации 44,1 кГц. Для того, чтобы поддерживать обе эти системы, формат не имеет определенного битрейта данных. Взамен данные передаются, используя Biphase Mark Code, который имеет один или два перехода для каждого бита данных, позволяя передавать оригинальный word clock вместе с самим сигналом.
Ключевое выражения я отметил!

Три остальных кода (RZ, манчестерский код, бифазный код) принципиально отличаются от NRZ тем, что сигнал имеет дополнительные переходы (фронты) в пределах битового интервала. Это сделано для того, чтобы приемник мог подстраивать свои часы под принимаемый сигнал на каждом битовом интервале. Отслеживая фронты сигналов, приемник может точно синхронизовать прием каждого бита. В результате небольшие расхождения часов приемника и передатчика уже не имеют значения. Приемник может надежно принимать последовательности любой длины. Такие коды называются самосинхронизирующимися. Можно считать, что самосинхронизирующиеся коды несут в себе синхросигнал.
Тоже из выделенного совершенно ясно, что приёмник принимает опорный сигнал от передатчика, и в контексте нашего обсуждения скажите - что будет делать Приёмник, если передатчиков будет ДВА и они не будут между собой засинхронизированны?????

Нет. SRC - это именно conversion - преобразование, или пересчёт.
В мультитреке же исходные сигналы НЕ преобразуются (в простейшем
случае воспроизведения или суммирования без использования
обработок и функций микшера).
Я думаю вы ошибаетесь. Для того, чтобы в интервале времени, в котором из одного источника поместилось 100 сэмплов, поместить сигнал из второго источника, в котором за это-же время пришли 101 сэмпл, нужно именно ПЕРЕСЧИТАТЬ второй сигнал и изменить длину каждого из сэмплов (читай частоту). Сэмпл это не абстрактная величина с едиными для любых сигналов величинами, его размерность какраз и определяется опорным сигналом каждого из источников.

Мультитрек разумеется гипотетический. Я всего лишь пытаюсь объяснить,
что такие варианты в принципе возможны, как мне кажется. Ваша задача -
доказать обратное ;)
:this:
И чего это мы должны вам что-то доказывать?
Да и как можно вам что-то доказать, если для вас Сэмл величина абстрактная, не имеющая ни каких размеров.

1. "Частоты пофиг"? Да, фактические частоты пофиг, и если я на время укажу,
что разночастотные треки имеют единую частоту - любой мультитрек
их просуммирует. Присылайте мне два файла 44 и 48, сделаю цифровую сумму
без SRC (только в одном из файлов изменится скорость).
Ну наконец то. И что получиться в итоге? Вы предлагаете принебречь величинами, которыми НИКТО в Мире музыки принибрегать не станет.
Для улучшения качества звука поднимаются частоты дискретизации до 192 KHz и выше, а вы с лёгкостью ---- туду-сюда один сэмпл и меняете ТОН с лёгкостью факира.
Да самый гадкий DA-AD конвертер не наделает столько бед, как ваш "механизм" суммирования не синхронизированных сигналов.

а БигБэна у вас даже больше чем два, оброзно говоря, естественно. Один стоит в вашем Пульте (там есть Clock), второй стоит в вашей звук. карте RME, ещё по одному в каждом Рэковом Pod-е.
Но они несинхронны меж собой. А в биг-бене все его выходы синхронны.
Это такой же мастерклок генератор, как и ваш Drawmer M-Clock Plus.
О господи.....:cray:
Я знаю что такое Биг Бэн и утверждю, что он по сути своей ничем не отличается от того Клока, который у вас стоит в том-же рэковом POD-е!
Какое кол-во выходов имеет КЛОК не имеет никакого знчения, тем более при схеме цифровых сигналов. Вы ведь тут столько цитат привели про то, что в цифровом сигнале есть место и для опорного сигнала от Клока.
Ну чтож вы в трёх соснах то путаетесь?
Да и при раздаче синхросигнала на несколько устройств от того-же Биг Бэна можно использовать последовательную схму и T образные конекторы и при этом нам будет нужен от Биг Бэна только один его выход.

Так растолкуйте же неразумному, как надо ПРАВИЛЬНО понимать термин Realtime!
В том контексте как вы его используете РиалТайма в природе вообще не существует, так как задержка от источника до приёмника (например нашего уха) есть ВСЕГДА, просто в зависимости от сложности и многоступенчатости обработки она разная. Даже передача звука в комнате от исполнителя к слушателю происходит с задержкой прямо паропорциональной расстоянию.
 
Вот тут есть возможная ошибка. Хотя считается, что разные дорожки для многодорожечного проекта надо записывать с общим мастер-клоком, этого на практике никто не гарантирует. Если они были записаны с различными независимыми клоками, то "абсолютное время, восстановленное по отсчетам", будет (немного) расходиться.

Да что вы говорите?
И к чему это приведёт? :girl_witch:
Да, и вот это самое "(немного)" в мире нулей и единиц попахивает....., не буду говорить чем.
 
Aleksandr_Oleynik написал(а):
И к чему это приведёт?
Приведет к тому, что смикшированные дорожки слегка разойдутся по времени (в пределах 7 мс, см. мой пост выше). Никаких артефактов (типа цифровых выпадений) от этого не возникнет.
Но этот случай уже сам по себе изначально неправилен: отдельные дорожки одного мультитрека надо писать в общим мастер-клоком.
 
А можно хоть в общих чертах обьяснить, как мультитрек будет принимать разночастотные потоки? А ещё лучше - технологию этого процесса.
 
Ну почему же разночастотные? У всех WAV-файлов, которые вы перепишете на дискетке с разных устройств будет обозначена одна частота дискретизации. Даже если вы перепишете все дорожки по-отдельности по AES или S/PDIF, то у них тоже будет одна частота дискретизации (без всякого SRC).
 
Последнее редактирование:
Приведет к тому, что смикшированные дорожки слегка разойдутся по времени (в пределах 7 мс, см. мой пост выше). Никаких артефактов (типа цифровых выпадений) от этого не возникнет.
Но этот случай уже сам по себе изначально неправилен: отдельные дорожки одного мультитрека надо писать в общим мастер-клоком.
И как вы станете это делать с двумя тремя не синхронизированными между собой цифровыми потоками? Ну, так чтоб всеже вернуться к обсуждаемой проблеме.....
 
Aleksandr_Oleynik написал(а):
И как вы станете это делать с двумя темя не синхронизированными между собой цифровыми потоками?
Микшировать, что ли? Так в пределах одной рабочей станции не надо никакой синхронизации! Я же написал: все треки (по-отдельности) переписываются в одну DAW через интерфейс AES или просто перегоняются как файлы. И вставляются в мультитрек для микширования.
 
Понятно. Мы записываем в разные устройства. На разные компики, в разные мультитреки, которые сами позаботятся о клоке и пр. Потом - всё на флэшки и - в один мультитрек, так сказать, на уровень файловой системы :mda:
Так что-ли?
 
Да! Именно так. При этом, если мы грамотны в звукозаписи, то в процессе записи все устройства работали от общего мастер-клока. Но даже если нет - ничего страшного... 7 мс.
 
Ну, слава Богу!!! От процесса ввода мы благополучно избавились, наконец-то!
 
Ну а теперь можно перейти к тому, что идея Александра предлагает делать то же самое в реальном времени, микшируя точно так же (без SRC) слегка "разбегающиеся" цифровые потоки (пока они не разбегутся настолько, что переполнят буфер).
 
А когда " они не разбегутся настолько, что переполнят буфер" то что делать ? Знаю, говорить Стоп, минутку отдыхаем :spiteful:
 
Я об этом уже писал, читайте выше.
Тогда останется либо делать SRC (лучший способ), либо делать выпадения (худший способ). Именно поэтому всякие цифровые патчбеи и используют SRC - они должны работать бесконечно, а не ограниченное время.
 
Есть необходимость обьединить несколько приборов с цифровыми выходами в один цифровой вход на пульте...


Ну а теперь можно перейти к тому...

Ну нет уж! Больно весёлое обсуждение цифрового сумматора несклоченных потоков ("почти склоченных") получилось с уходом от темы на 180 градусов. Прям, как фантастика какая-то!
 
Да! Именно так. При этом, если мы грамотны в звукозаписи, то в процессе записи все устройства работали от общего мастер-клока. Но даже если нет - ничего страшного... 7 мс.
Меня не устраивают не 7 мс, ни одна - это цифровой брак, особенно если речь идёт об одном и том-же инструменте записанном в риалтайме через разные цифровые преобразователи (наприме эл. гитара включенная в несколько цифровых педалей.
Я это уже пробовал - результат ужасный.
Вы знаете сколько потраченно усилий, чтобы ТОГО, что предложил Александр, а вы поддержали, не происходило???????
 
Я об этом уже писал, читайте выше.
Тогда останется либо делать SRC (лучший способ), либо делать выпадения (худший способ).
Т.е. "алгоритм" Александра предполагает смешанный способ суммирования?
До каких-то величин расхождения (которые для каждой аранжировки и каждого инструмента будут видимо определять специально) будем писать разбежавшиеся во времени потоки, а потом будем включать SRC?
Худший способ не рассматриваем. Или фиг с ним, сгорела хата, гори сарай...
Именно поэтому всякие цифровые патчбеи и используют SRC - они должны работать бесконечно, а не ограниченное время.
А кто может работать ограниченное время?
На входе в звукозаписывающую студию повесите объявление - Пишем до переполнения буфера и только аранжировки в которых нет унисонов?
 
Aleksandr_Oleynik написал(а):
Меня не устраивают не 7 мс, ни одна - это цифровой брак
Это зависит от записи, а не от микширования. Если был мастер-клок, то не будет ни одной мс, все будет идеально.


Aleksandr_Oleynik написал(а):
Т.е. "алгоритм" Александра предполагает смешанный способ суммирования?
Нет, в предложении Александра этого изначально не было: предполагалось, что записи не слишком длинные и их расхождение не переполнит буфер.
 
Тема оказалась интереснейшей! Я с большим удовольствием читаю и вникаю в мир "цифровых потоков"... Счастье в том, что я ничччего в этом не понимаю!!! Я хотел просто увеличить число цифровых входов в свой DM24, а прочитав топик - крепко задумался. Может получиться все наоборот, оказывается. В любом случае буду с удовольствием читать этот топик и дальше... Просьба: ну не разругайтесь, пожалуйста!!!

С уважением
 
Это зависит от записи, а не от микширования. Если был мастер-клок, то не будет ни одной мс, все будет идеально.
Алексей, ну что вы в самом деле? Какой может быть мастер клок у нескольких не заклоченных цифровых источников? Они все сами себе Мастера, а хост - сам себе, а между ними придуманный Александром и вами одобренный алгоритм записи.....
Нет, в предложении Александра этого изначально не было: предполагалось, что записи не слишком длинные и их расхождение не переполнит буфер.
Ну подумаешь........, сделаете буфер по больше.
 
Если общего клока на записи не было, то при микшировании по такому методу записи будут расползаться по времени. 7 мс - это на самом деле совсем немного, и это может быть лучше, чем артефакты от SRC. Но если даже такая задержка нежелательна - то остается один путь - SRC. Или изначально писать грамотно: с общим клоком.
Если сделать буфер побольше - то дорожки будут дальше и дальше расходиться по времени, что после некоторого предела становится заметно и нежелательно.
 
Последнее редактирование:

Сейчас просматривают