Zit, транспорт не влияет. пока локаторы не подвигал транспорт двигай сколько угодно и рендери хоть 10 раз все совпадет тыж видел на видео я пускал с разных мест
Погрешности MIDI-тайминга в программных секвенсорах
- Автор темы Pavell
- Дата начала
Zit, транспорта нет. пока локаторы не подвигал транспорт двиагай сколько угодно и рендери хоть 10 раз все совпадет
Zit, проверил. срендерил с включенным снепом. отключил снеп. постартовал с разных участков. срендерил. включил снеп - вставил файл. тишина. а вот если сначала вставить файл, потом включить снеп и притянуть к началу такта то да, может быть несовпадение. это связано с тем, что когда перетягиваешь новый семпл в куб он ставит стартпойнт, попал семлом не в кратную долю - стартпоинт поставится криво, и потом хоть визуально при последующем включении снепа будет притягиваться ровно, стартовать будет со стартпоинта. вроде как то так.
Zit, проверил. срендерил с включенным снепом. отключил снеп. постартовал с разных участков. срендерил. включил снеп - вставил файл. тишина. а вот если сначала вставить файл, потом включить снеп и притянуть к началу такта то да, может быть несовпадение. это связано с тем, что когда перетягиваешь новый семпл в куб он ставит стартпойнт, попал семлом не в кратную долю - стартпоинт поставится криво, и потом хоть визуально при последующем включении снепа будет притягиваться ровно, стартовать будет со стартпоинта. вроде как то так.
spred, все теории подобного рода это всего лишь фантазии. не имея технического описания программы, кода или комментариев программистов, его создававших. Если хочешь применять научный подход - то стоит воспринимать его как черный ящик. исследовать что туда вошло и что вышло, при разных алгоритмах действий пользователя. Собрать статистику и отправить разработчикам (что крайне маловероятно... ТАКИЕ баги это даже не стадия альфа и бета тестирования .. это вообще скорее всего отладка ядра проги и она тянется вероятно всего с хз еще каких времен. ). а теориий этих можно миллион щас придумать.....
щас рипер затестирую.
щас рипер затестирую.
Последнее редактирование:
Все тема напоминает тестирование ПО в слепую, даже не имея ни малейшего понятия об программной архитектуре Куба. Боулинг без кеглей....
Да и по опыту скажу, тестирование часто видит проблему по своему, и зачастую совершенно не так как это реализовано.
Сведетесь к тому, что придумаете себе сомнительное решение обойти сомнительную проблему.
Да и по опыту скажу, тестирование часто видит проблему по своему, и зачастую совершенно не так как это реализовано.
Сведетесь к тому, что придумаете себе сомнительное решение обойти сомнительную проблему.
EKmusic, прошу выложить видео твоего теста в рипере от начала до конца. на каком интерфейсе у тебя звук? потому как у меня результат тот же что и в кубе практически. я в акуе. что делаю не так ребят?? ((((( депрессняк какой то ((
[video=youtube_share;Ck4aLTGMGdU]http://youtu.be/Ck4aLTGMGdU[/video]
[video=youtube_share;Ck4aLTGMGdU]http://youtu.be/Ck4aLTGMGdU[/video]
Теорий можно придумать и миллиард, но в исследованиях такого рода немаловажную роль будет играть повторяемость результата опыта. Изначального вашего посыла, для того, чтобы заняться этими опытами я не знаю, поэтому и результаты опытов оценить не могу. Зато я знаю что и зачем лично я проверял.
Мое "исследование" заключалось в том, чтобы проверить имеет ли место в реалтайме расхождение между одновременным рендером миди и воспроизведением аудио с предположительно одинаковыми независимыми по-отдельности результатами в моем рабочем секвенсоре.
Ответ – не имеет, аудио и миди дорожка вычитаются, на общем миксе нет ни всполоха сигнала.
Следующий вопрос, который я "исследовал" – это какие нужно создать условия, чтобы создать это расхождение. Удалось выяснить, что на расхождение в лоджике всегда влияют:
– положение курсора при старте рендера
– соотношение Sample Rate проекта и его BPM
Следующий вопрос, который меня озаботил – является ли расчет расхождений внутри конкретного проекта хаотичным, или он принадлежит к области предсказуемого поведения. Удалось выяснить, что во-первых – нет, положение отрендеренных аудио-фрагментов случайным не является, и во-вторых, предсказать алгоритм поведения в данном конкретном случае – возможно. При правильном сдвиге аудио-фрагментов значительной длительности можно получить ноль в сложении противофаз.
Следующий аспект, жаждущий пролития луча света – можно ли при работе в секвенсоре оперировать математическими данными в предсказании его поведения, и на текущий момент ответ таков – да, можно. Ошибки внутри-хостового обсчета случаются, но и ошибки имеют свою предсказуемую природу – на рендер миди будут влиять разные прерывания в чем и где там они прерываются, задержки внутри ОСи и прочее, но в статистически значимом отрезке времени эти ошибки носят характер редчайших исключений, в подавляющем большинстве случаев результаты повторных проверок идентичны. Вычитаются. Если, конечно, подойти к опытам с серьёзным намерением получить результат.
Следующий вопрос – не галлюцинирую ли я, достоверны ли эти самые результаты опыта, и на текущий момент ответ такой – результаты опытов пока что во всех случаях приводят у меня к одинаковому итогу, то есть имеют важное для доказательной статистической базы свойство – повторяемость (предсказуемость).
И самое главное, на мой взгляд, для "научных исследований". Я не держусь за результаты опыта как истину в последней инстанции, наоборот – я предлагаю оспорить эти результаты любому желающему, для чего выложил проекты (не забываем что рендеры рипера и аблетона у меня в архиве пока только для визуального сравнения, вычитаться не будут). Это будет ценным прибавлением в статистическую копилку результатов, независимо от положительного или отрицательного исхода. И я не считаю ничего из того, чей принцип работы мне не понятен багом, или, если угодно, фичей, вообще, я только лишь знаю, что почти ничего не знаю. Люди могут сколько угодно фантазировать и галлюцинировать, описывая свои переживания, даже имея на руках любые комментарии программистов или техническое описание кода – но когда дело доходит до эксперимента, всё это быстро сливается в утиль. Чтобы не молоть языком есть предложение – взять сэмпл, вставить его в контакт, сохранить пресет, и отрендерить 10 тактов 8-ми нотами в разных хостах, в каждом по несколько вариантов BPM (лично меня заботят 103, 104, 125, 147 и 186 BPM). Затем – выложить полученные проекты и рендеры, не забыв пресет от контакта и сэмпл. Либо – предложить свою методику, расписанную поподробнее. А далее, на основе полученных и доступных всем данных – доказывать и опровергать.
Бала-гала-вала-ган, ёмаё.
Записать видео нечем - снес только вчера камтасию. На словах пойдет?
1.Открываю контакт
2. Загружаю туда сэмпл бочки
3. Создаю отрезок в 4 такта с бочкой.
4. Рендерю.
Загоняю срендеренный файл в проект - жму на нем значок фазы, воспроизвожу вместе с контактом - тишина.
Аудиокарта - Echo FW 4.
протестировал еще раз Ableton. поверите на слово нет - видео могу завтра выложить. На моей системе с TC как часы. рендерил двумя методами 1. через фриз с последующим копированием на аудио трек . 2 через экспорт. Все со всем совпадает все три дорожки. крутил как угодно, с любой точки воспроизведения с любыми локаторами. Миди ни разу не выпало при проигрывании в противофазе с рендеренной вавкой.. тестировал с контакт 5 и халион 3. противофазу переворачивал утилитой соналксис стерео тулз . первый раз с эблтоном не вышло что то, тогда я использовал латенси 256. при 64 сейчас сделал тест - как часы. Повторил тест с латенси 512. тишина полная. косяк был в отключенной кнопке Delay Compensation в эблтоне. без нее если рендерить миди потом вставлять вавку - не совпадает. с ней - все четко.
Так что поправляю данные: на моей системе (квад 6600 тиси десктоп) пока что стабильно работает под вин 7 только эблтон в плане нашего теста.
Так что поправляю данные: на моей системе (квад 6600 тиси десктоп) пока что стабильно работает под вин 7 только эблтон в плане нашего теста.
Последнее редактирование:
На слово верим, что ж мы не люди чтоли. Круто!
Если возможно, выложите проект с вашими рендерами – будем сравнивать часы.
немое видео если устроит.смотрите по индикатору [video=youtube_share;e_UVi5WLnLo]http://youtu.be/e_UVi5WLnLo[/video]
кнопка редуце латенси должна быть обязательно включена при рендеринге! без нее у меня НЕ СОВПАЛО!
пару минимальных советов (исходя из чисто эмпирического опыта) для практической работы в ЛЮБОМ секвенсере для достижения наибольшей четкости. НА ВСЯКИЙ СЛУЧАЙ ))
1. не меняйте PPQ в одном и том же проекте несколько раз. Хосту может снести башню от таких манипуляций в неизвестную сторону. вообще этот параметр по дэфолту оставлять - он избыточен для наших задач
2. Локаторы желательно выставить один раз и не трогать. Понимаю это неизбежно, когда приходится рендерить небольшие кусочки. проверяйте их.
3. Следите чтобы плаги давали хосту инфу о компенсации задержек. Не все плаги корректно это делают. Это можно проверить штатными средствами хоста или спец плагами для измерения и компенсации задержки
4. По пункту 3 следите чтобы в хосте компенсация задержек всегда была включена при промежуточных перезаписях в ОДНОМ значении, либо курите настройки (протулз
) Ы _
6. Не меняйте задержку latency в audio setup вашей карты при рендеринге разных кусков проекта
7. Если чувствуете что не так что то - максимально переводите проект в аудио и работайте как с магнитофоном, ориентируясь на сетку и блять слух )
8. Отключать при промежуточном рендеринге штатные средства дитеренга или лимтеры. ибо нахуй это не надо, а эти плаги тоже могут некорректно задержку свою впихнуть, хоть и штатные
9. парамтр PAN LAW до этапа сведения при всех промежуточных просчетах поставить в положение 0 Дб (протулз не даст, тока -3), мы не знаем как он работает с аудио или инструментал дорожками в том или ином хосте
кнопка редуце латенси должна быть обязательно включена при рендеринге! без нее у меня НЕ СОВПАЛО!
пару минимальных советов (исходя из чисто эмпирического опыта) для практической работы в ЛЮБОМ секвенсере для достижения наибольшей четкости. НА ВСЯКИЙ СЛУЧАЙ ))
1. не меняйте PPQ в одном и том же проекте несколько раз. Хосту может снести башню от таких манипуляций в неизвестную сторону. вообще этот параметр по дэфолту оставлять - он избыточен для наших задач
2. Локаторы желательно выставить один раз и не трогать. Понимаю это неизбежно, когда приходится рендерить небольшие кусочки. проверяйте их.
3. Следите чтобы плаги давали хосту инфу о компенсации задержек. Не все плаги корректно это делают. Это можно проверить штатными средствами хоста или спец плагами для измерения и компенсации задержки
4. По пункту 3 следите чтобы в хосте компенсация задержек всегда была включена при промежуточных перезаписях в ОДНОМ значении, либо курите настройки (протулз
) Ы _6. Не меняйте задержку latency в audio setup вашей карты при рендеринге разных кусков проекта
7. Если чувствуете что не так что то - максимально переводите проект в аудио и работайте как с магнитофоном, ориентируясь на сетку и блять слух )
8. Отключать при промежуточном рендеринге штатные средства дитеренга или лимтеры. ибо нахуй это не надо, а эти плаги тоже могут некорректно задержку свою впихнуть, хоть и штатные
9. парамтр PAN LAW до этапа сведения при всех промежуточных просчетах поставить в положение 0 Дб (протулз не даст, тока -3), мы не знаем как он работает с аудио или инструментал дорожками в том или ином хосте
Последнее редактирование:
Что интересно, два миди трека в кубейсе играют абсолютно синхронно - включите два семплера в противофазе и будет тишина. А вот миди с аудио действительно расходятся, но только в рилтайме. Если сбаунсить миди с аудио в противофазе, то файл получается пустым. Кубейс 6.5.3.
Попробовал 16-ми на 113.5, 107.796 и на 200 картина аналогичная - два миди трека играют синхронно, аудио с миди расходятся, аудио с миди после миксдауна - тишина.
Еще, что интересно - если у аудио дорожки поставить track delay на -0.04, то кол-во несовпадающих нот с мидитреком как будто сокращается.
Сделал то же в Nu4 с тем же успехом
Два семплера (Battery) дали в противофазе тишину. Аудио с миди расходятся только в реалтайме - при миксдауне результирующий файл пустой. При track delay на -0.05 получил тишину и в реалтайме аудио с миди. Правда, не сразу - некоторое время в зацикленном 5-ти тактовом куске рэндомно прорываются удары, но через 3-4 цикла наступает тишина.
spred,
пока это всё ваши домыслы и не более...
думаю всё банально, ошибка в программе и не нужно искать скелетов в шкафу
я тоже )))
если бы я запускал событие а бы как, вне сетки, оно было бы понятно, но запуск происходит в конкретный момент времени, согласно bpm, величина известная и постоянная
странная мысль, получается что две сетки, одни темповая вторая для миди сообщений, да еще думает куда бы влепить = ))))
пока это всё ваши домыслы и не более...
думаю всё банально, ошибка в программе и не нужно искать скелетов в шкафу
Последнее редактирование:
M16,
В контексте ситуации не вижу смысла опираться на банальность/небанальность, я тоже не считаю текущий расклад чем-то необычайным, но даже если это "ошибка" – я предпочитаю знать как она происходит и почему, чем она может грозить, как можно её исправить, и так далее. А если я заблуждаюсь в своих предположениях, так ничего страшного – они сейчас только предположения. Если я выбираю неверную терминологию – поправьте.
Не вижу никакого противоречия, ведь миди в секвенсоре отрабатывается по сетке темпа (да или нет?), а аудио рендерится по частоте дискретизации (иначе зачем бы она так называлась) – так вот увеличьте масштаб в любом секвенсоре и проверьте, совпадают ли тактовая и сэмпловая разметки на некратных BPM. Вопросы отпадут, а для тех, кто не хочет проверить своими глазами и ушами и готов поверить на слово – эти разметки не совпадают. Есть размеры, где каждый второй такт будет попадать ровно в начало отсчета, есть такие, где будет попадать ровно в отсчет даже 1/8 нота. Конечно, возникает вопрос – каким образом интерпретирует секвенсор этот процесс, но это как раз и есть одна из тем "исследования".
Естественно, домыслы. Но, пока происходит проверка на опытах, предпочитаю называть это "предположением". А предположение может стать домыслом как только кто-то из нас здесь выложит на обозрение опровержение результатов опыта.
В контексте ситуации не вижу смысла опираться на банальность/небанальность, я тоже не считаю текущий расклад чем-то необычайным, но даже если это "ошибка" – я предпочитаю знать как она происходит и почему, чем она может грозить, как можно её исправить, и так далее. А если я заблуждаюсь в своих предположениях, так ничего страшного – они сейчас только предположения. Если я выбираю неверную терминологию – поправьте.
проблема в том, что экспериментально получается, что в кубе ошибка больше, чем расхождение между сетками?
У меня пока нет возможности проверить как это происходит в кубе, но, если я правильно понимаю вопрос – да, в лоджике ошибка может округляться до значений превышающих единичное расхождение между соседними долями. При том, в мелком масштабе довольно значительных, где-то миллисекунда на один такт (~90 отсчетов на почти два такта при 44,1 кГц), но эта миллисекунда размазывается по всем долям такта. Если сравнивать рипер и аблетон, то там тоже есть подобное расхождение, но пока что данные говорят что схема исправления набегающей ошибки округления иная – округление происходит чаще и среднее отклонение между отдельными долями меньше, и это среднее находится в "верхней трети" отклонений лоджика (то есть лоджик в абсолютных величинах отклоняется сильнее, но в тех же величинах ставит рендер на позиции более близкие к миди-эвентам чаще), но это основано только на визуальном наблюдении и ничем больше не подтверждено. Так что прошу камнями пока не кидать, пока совсем-совсем угадайка.
А есть инструмент, который наглядно представляет форму волны на уровне сэмплов а-ля "столбиковая диаграмма" и делает это "честно"? Помню, в самплитуде меня радовала форма волны при максимальном увеличении, вот там то впервые я осознал, что такты и сэмплы могут совсем не совпадать. Такие красивые столбики закрашенного звука, эх. Не знаю, как насчет точности, но выглядело внушающе. В лоджике мельче, слабее заметно, в аблетоне в окне сэмпла что-то видно, но чтобы сравнить две волны нужно в арранже смотреть, где по временной шкале масштаб хороший, а по амплитуде – не знаю как увеличить, очень мелко. В рипере, ээ, я вот недопонял – там отсчеты отображаются не столбцами (1 сэмпл = 1 столбец) а ломаной линией, не лесенкой, а сглаженно – поэтому там визуально практически не различимы файлы рендеров лоджика и рипера.
А как вы сравнивали кто косячит больше?
Топик можно назвать "Обсуждение неточностей MIDI рендера в различных секвенсорах"
Последнее редактирование:
