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

  • Автор темы Автор темы Дед
  • Дата начала Дата начала
Михаил, вы уж простите неразумного, но доводов я что-то особо не узрел.
Только некие мантры... А уж про солнце и далее - дык это вообще из
серии отмены законов природы :mega_shok: Может быть позвать
какого-нибудь спеца по ЦОС, который нас рассудит - Лукина, например?
 
доводов я что-то особо не узрел
-- Мама рОдная....
И на кой хрен здесь люди писали?... время своё тратили?...
Лично я удаляюсь.
Нет желания всё в сотый раз повторять.
Тем более - впустую.........
 
Я не знаю, как это делается в реальных цифровых сумматорах (такие вообще есть?), но мне кажется, что и алгоритм Лонга, и алгоритм Александра - оба имеют право на существование. При этом с точки зрения качества - вариант Александра даже предпочтительнее, т.к. не требует SRC. Проблема только в том, что когда клоки расползутся более чем на длину буфера, с этим придется что-то делать: SRC либо выпадение.
 
  • Like
Реакции: Alexander Yakuba
Проблема только в том, что когда клоки расползутся более чем на длину буфера
-- Да плевать, больше или меньше, это не играет ни малейшей роли вообще.
Ну НЕЛЬЗЯ положить ни 99, ни 101 яблоко в ровно 100 рук, чтобы всем хватило и ничего не осталось!
 
Вы просто не хотите разобраться с предложением Александра. Он вовсе не предлагает суммировать 99 яблок с 100. Он предлагает накопить 100 по всем каналам и их просуммировать.
 
-- Угу.
Только при этом 100 с одного канала - может соответствовать, к примеру,
ОДНОЙ секунде звучания, а со второго (где их было бы 99) - 0,9 секунды...
цифры, есс-но, преувеличены для наглядности.
Но суть от этого не меняется

Для ещё большей наглядности - попробуйте так же складывать сигналы с разной fs. Скжем, один - 48 кгц, второй - 44,1 кгц... :focus:
 
Long написал(а):
Только при этом 100 с одного канала - может соответствовать, к примеру, ОДНОЙ секунде звучания, а со второго (где их было бы 99) - 0,9 секунды...
Откуда вы знаете? Может быть, и нет. Может, материал оцифрован с одним клоком, а играется - с разными?
А если и да - то разница, как правило, будет незначительной: частота-то практически одна!
 
Это старая песня.На моей памяти не один чел на заднице волосы рвал,когда пытался по цыфире всё завести без WC,и я в том числе.Вроде бы всё в 44.1,только то один щёлкнет,то через секунду другой.Цыфирь без WC это геморно,а сним и дорого и тоже бывает геморно.По моему лучше хороший АЦП,и привет старый,добрый аналог.
 
Цыфирь без WC это геморно,а сним и дорого и тоже бывает геморно
-- Это да, потому как в WC отсутствует _фазовая_ синхронизация, т.е. цифровые потоки, даже ведущиеся от одного WC, будут синхронны, но не синфазны.
Такой уж это "стандарт"... :(
 
Ой сколько понаписали....................:on_the_quiet2:

Михаил, помните сколько я вас в Аське мучал? :kiss3:

Уважаемые спорщики, а вы возьмите и перепробуйте все ВОЗМОЖНЫЕ варианты суммирования не синхронизированных по WC цифровых сигналов, а потом поговорим.
Мне очень нравятся все теоретики, которые в общем и теории точно не знают, а пытаются пользоваться исключительно логикой.
Я сам такой, но в отличии от вас провёл ВСЕ практические попытки.

Что я для этого имею и приобрёл!!!!! -

1-ый цифровой источник - Line6 Vetta II;
2-ой цифровой источник - TC-Electronic G-System;
3-ий цифровой источник - Roland VG-99
4-sq цифровой источник - Korg Oasys

Звуковая карта - RME HDSPe-MADI
Цифровые конвертора - RME ADI-642
Вордклок - Drawmer M-Clock

И для согласования цифровых источников были купленны одни из лучших на сегодня SRC - Z-System z-3src 24/96 sample rate converter и z-8src sample rate converter


И могу вам сказать, что после ДЛИТЕЛЬНЕЙШИХ попыток согласования даже с использованием SRC я имею всёравно проблемму цифровых артефактов в записываемых сигналах. Я не могу найти причин, но эта клятая цифирь, даже при её полном согласовании на SRC пробивается щелчками........:focus:

ИТОГ - если хотите потратить УЙМУ времени и/или УЙМУ денег - разбирайтесь с методикой суммирования не синхронизированных цифровых сигналов, если не хотите, делайте это при помощи Качественных DA-AD преобразований!

PS: Что касается суммирования сигналов с гитарных цифровых устройств.........., в общем я купил в итоге TLAudio Fat Track (Спасибо The GB) и просто СЧАСТЛИВ!!!
 
  • Like
Реакции: RomanD
Уважаемые спорщики, а вы возьмите и перепробуйте все ВОЗМОЖНЫЕ варианты суммирования не синхронизированных по WC цифровых сигналов, а потом поговорим.
Мне очень нравятся все теоретики, которые в общем и теории точно не знают, а пытаются пользоваться исключительно логикой.
И могу вам сказать, что после ДЛИТЕЛЬНЕЙШИХ попыток согласования даже с использованием SRC я имею всёравно проблемму цифровых артефактов в записываемых сигналах. Я не могу найти причин, но эта клятая цифирь, даже при её полном согласовании на SRC пробивается щелчками........:focus:
ИТОГ - если хотите потратить УЙМУ времени и/или УЙМУ денег - разбирайтесь с методикой суммирования не синхронизированных цифровых сигналов, если не хотите, делайте это при помощи Качественных DA-AD преобразований!

Александр, я лично с Вами абсолютно солидарен по поводу того,
что через аналог надо это делать. Процитирую себя же с первой страницы:
на грабельки при решении похожей
задачи в своё время натыкался: если цифровые источники тактируются
каждый своим клоком, а не имеют некоего общего клока (например
общий для всех вордклок) - затея скорее всего обломится, щелчки и
выпадения в цифровом потоке гарантированы! Ибо в подобной цифровой
среде мастер обязан быть один-единственый, а все остальные - слейвы. Я в
итоге (предварительно намучавшись с вордклоком, ибо денег на бигбэн
тогда не было) плюнул и завёл все входящие приборы по аналогу
Так что в данном случае не совсем теоретик я... и даже совсем не
теоретик... Только суть-то спора была немного в другом... Я предложил
вариант (как мне кажется, вполне работоспособный), при котором в обмен
на реалтайм получается абсолютная синхронизация. Я вполне допускаю,
что в алгоритме есть ошибка, но растолковать внятным техническим языком
в чём именно мне так никто и не смог, увы... Только сомнительные аналогии,
а затем посылы "в сад учить матчасть". В принципе, это нормально, ибо
далеко не каждый талантливый инженер (музыкант, любой другой
специалист) обязан быть ещё и столь же талантливыми педагогом,
особенно в этой стране, где отсутствие ШКОЛЫ в её западном понимании
вряд ли подлежит особому сомнению (если что ИМХО, для особо
впечатлительных инженеров).

зы: Аналогом моего алгоритма является... да самый обычный компьютерный
мультитрек с плагинами и инструментами - там тоже МЕЖДУ (ключевое слово,
и не надо рассказывать про общую частоту проекта!) процессами
(программами) нет никакой фазовой или какой другой синхронизации,
они существуют независимо друг от друга сами по себе, но
тем не менее все с помощью хоста все ждут друг друга и ничего не
разъезжается и не щёлкает! Но буферизация убивает реалтайм.
Ну и где тут ошибка у меня, кто-нибудь расскажет уже?!
 
-- Выводимые одновременно через НЕСКОЛЬКО НЕсинхронизированных между собой портов?
Ну, попробуйте! :clapping:
 
Alexander Yakuba,
к сожалению у меня совсем иная профессия и рассуждать о частотах и битности сигнала я могу ну почти что на уровне минимальных знаний и элементарной логики.
Ну смотрите, если я буду не прав, Михаил (если конечно захочет) меня поправит :vava: .
У звукового сигнала, который вы хотите буферизировать и потом суммировать есть ведь по одной из осей два параметра - частота и время. И если вы один из этих параметров попытаетесь по оси Х, через буфер, синхронизировать, то разбежиться второй.
И на сколько я понимаю, задача SRC, взяв за основу один из параметров, т.е. Время, точно сопоставить второй, т.е. частоту.
Я даже в своё время мучал инженеров RME, на предмет их SyncAlign и SyncCheck
Почитайте описание.
Мне казалось, что эти механизмы обязаны сигналы одной частоты, например 44,1, полностью синхронизировать.
Увы....
 
- Но буферизация убивает реалтайм.
Ну и где тут ошибка у меня, кто-нибудь расскажет уже?! -

Скажем так, если длина буффера будет равна или более длине записываемого трэка, то пожертвовав "убитым риалтаймом", можно всё благополучно досвести в софте :-)
 
-- Да, это так.
Для Alexander Yakuba - последняя попытка:
то же, что и описано ранее, но ещё более упрощённо:
три потока за ВСЁ время выдали
один - 10 сэмплов
второй - 9 сэмплов
тритий - 11
Предложите вариант их суммирования БЕЗ ПОТЕРЬ и БЕЗ ЗАПОЛНЕНИЯ пропусков х.з. чем.
 
P.S.
Желающим - предлагаю просуммировать два потока, один - 44,1 и второй - 48 кГц.
Так как с точки зрения задачи - это абсолютно НИЧЕМ не отличается от суммирования двух несинхронизированных потоков близких частот.
 
- Аналогом моего алгоритма является... да самый обычный компьютерный мультитрек с плагинами и инструментами - там тоже МЕЖДУ (ключевое слово, и не надо рассказывать про общую частоту проекта!) процессами (программами) нет никакой фазовой или какой другой синхронизации, они существуют независимо друг от друга сами по себе, но тем не менее все с помощью хоста все ждут друг друга и ничего не разъезжается и не щёлкает! -

Ну, вобщим-то, здорово!.. Что означает "нет никакой фазовой или какой другой синхронизации, они существуют независимо друг от друга сами по себе"? Что такое "помощь хоста" из-за которой всё не разъезжается? Как раз всё и держится "кучи" благодаря тому, что всё жестко привязано к сетке синхросигналов. Пусть в программе существует программный буфер (тот, от которого считают латенси), пусть даже и не совсем понятно, по каким законам он набирает-отпускает информацию. Но он один для всех трэков, и все они будут строго привязаны к величине заданной латенции (до сэмпла), а сам этот буфер - также будет обсчитываться строго по приходу синхросигнала мультитреккера.
 
Как раз всё и держится "кучи" благодаря тому, что всё жестко привязано к сетке синхросигналов
-- Уффффф!...
Уважаемый коллега, передаю Вам эстафету!
У мя уже сил нет по сто раз объяснять прописные истины. :diablo:
Может, Вам больше повезёт?....
Надеюсь от всей души!
 
-- Выводимые одновременно через НЕСКОЛЬКО НЕсинхронизированных между собой портов?
Ну, попробуйте! :clapping:
Суммирующие ВНУТРИ себя всевозможные цифровые потоки и выводящие единую сумму в файл (или ещё куда наружу). Чего и требуют условия задачи, собсно...
 
У звукового сигнала, который вы хотите буферизировать и потом суммировать есть ведь по одной из осей два параметра - частота и время. И если вы один из этих параметров попытаетесь по оси Х, через буфер, синхронизировать, то разбежиться второй.
И вот преобразовывая каждый входящий последовательный поток в
параллельный (с помощью самосинхронизации) и складывая в буфер,
параметров вместо двух остаётся один! Взгляните на картинку волны в любом
звуковом редакторе - там по оси Х время, по оси Y амплитуда. Всё. И вот уже
такие штуки (буферы, файлы) я и предлагаю суммировать!
 
P.S.
Желающим - предлагаю просуммировать два потока, один - 44,1 и второй - 48 кГц.
Так как с точки зрения задачи - это абсолютно НИЧЕМ не отличается от суммирования двух несинхронизированных потоков близких частот.
По моему алгоритму просуммируется легко! Только звучать будет
неправильно - один из потоков будет иметь неверную скорость
воспроизведения, но НИКАКИХ щелчков и выпадений не будет!
А в случае "оба по 44" и скорости все будут правильными, и щелчков не будет.
 
три потока за ВСЁ время выдали
один - 10 сэмплов
второй - 9 сэмплов
тритий - 11
Предложите вариант их суммирования БЕЗ ПОТЕРЬ и БЕЗ ЗАПОЛНЕНИЯ пропусков х.з. чем.
В моём случае (после преобразования в параллельные слова
с помощью самосинхронизации) это всего лишь означает, что
три трека этой песни имеют разную длину - бочка играет 10 секунд,
малый - 9, а хай-хет - 11. Такое бывает очень часто, я бы даже сказал -
практически всегда.
 
всё и держится "кучи" благодаря тому, что всё жестко привязано к сетке синхросигналов. Пусть в программе существует программный буфер (тот, от которого считают латенси), пусть даже и не совсем понятно, по каким законам он набирает-отпускает информацию. Но он один для всех трэков, и все они будут строго привязаны к величине заданной латенции (до сэмпла), а сам этот буфер - также будет обсчитываться строго по приходу синхросигнала мультитреккера.
Каким образом можно ПРОГРАММУ жёстко привязать к сетке синхросигналов?
(а точнее - огромную кучу программ). Вы правда никогда не слышали, как
пердят и скрипят в реалтайме (даже с буфером!) мультитреки,
когда кончаются ресурсы ЦП?! А при баунсинге тем не менее всё и всегда
гладко! Значит к чему всё это привязано? Имхо к алгоритму внутри
мультитрека, который рулит потоками как хочет, а по синхросигналу они
всего лишь отдаются на воспроизведение и принимаются на запись, но никак
не внутри генерятся и обрабатываются. Имхо так логичнее, чем ваш вариант,
нет?

зы: Или например оверсемплинг в тех же УАД-ах? Работая на частоте
44.1 кГц юзер зачастую даже и не знает, что его звук внутри некоторых
из его обработок находится уже в 88 или 96! В случае некой "жёсткой"
привязки такое было бы в принципе невозможным! Частоты гуляют внутри
проектов туда-сюда - и ничего, никто не разъезжается и не щёлкает
при этом!
 

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