Yamaha S-YXG50 Portable VSTi v1.0.0 [2016/04/25] (MIDI-синтезатор)

Программный MIDI-синтезатор для Windows, который работает как VSTi-плагин. Поддерживает расширения Yamaha XG и Roland GS, что является уникальной особенностью S-YXG50. Основан на пробной версии из пакета Yamaha SOL2. Yamaha так и не выпустила полную версию данного VSTi, прекратив поддержку всех своих программных синтезаторов в 2003 году. К счастью, пробная версия содержит полную версию движка S-YXG50, что позволило создать полноценную версию S-YXG50 VSTi своими силами. Помимо снятых ограничений пробной версии, этот патч предлагает полную переносимость (не требуется установка и ключи в реестре), а также использует зашитую в ресурсы DLL-файла 4MB-версию официального wavetable, лучше которого для S-YXG50 не выпускалось.

Скачать: yamaha_syxg50_vsti.7z (3.0MB).

Что нового в этом патче?

  • Не требуется установка. SYXG50.DLL теперь всегда читает файлы из своей директории.
  • Файлы таблиц звуковых данных расшифрованы и сохранены в ресурсах DLL-файла.
  • Если же их удалить из ресурсов, то VSTi будет искать их в своей директории (SXGBIN41.TBL, SXGWAVE4.TBL).
  • Полностью удалён антиотладочный код, код проверки серийного номера и код trial-режима.
  • Скрытые настройки читаются из ini-файла с именем, аналогичным имени dll-файла, но с расширением ini.
  • По умолчанию лимит полифонии равен 128.
  • Более частые обновления информации в GUI.
  • Кнопка Help будет спрятана, если нет файла SYXG.CHM.
  • Мета-информация VST находится в ресурсах (String Table), поэтому при необходимости её можно легко изменить.
  • GUI может быть выключено и ресурсы GUI могут быть удалены, в результате чего этот VSTi будет работать как SGP.DLL.

Как использовать

Для проигрывания MIDI при помощи этого синтезатора необходимо настроить какой-нибудь VST-хост. В качестве него может выступать ваш любимый плеер, только нужно найти соответствующий плагин. В качестве примера ниже приведено несколько инструкций. Для проверки корректности настройки послушайте bi2_polkovnik.mid (35KB) — он должен звучать идентично записи bi2_polkovnik_syxg50.ogg (2.0MB).

VST MIDI Driver (как системный MIDI-синтезатор)

VST MIDI Driver позволяет использовать любой VSTi как глобальный системный MIDI-синтезатор. В данном случае каждая игра или MIDI-плеер, которые используют стандартный системный MIDI-синтезатор, будут использовать Yamaha S-YXG50 VSTi.

  1. Скачайте и установите VST MIDI Driver с этой страницы.
  2. Скопируйте syxg50.dll из yamaha_syxg50_vsti.7z в любой каталог.
  3. Откройте настройки VST MIDI Driver, нажмите кнопку Load VSTi и выберите syxg50.dll.
  4. Во вкладке Advanced выберите VST MIDI synth в выпадающем списке Default MIDI synth.
  5. Готово! Сейчас Yamaha S-YXG50 VSTi будет использоваться как системный MIDI-синтезатор по умолчанию.

Yamaha S-YXG50 WDM (официальный драйвер только для Windows XP)

VST MIDI Driver поддерживает Windows XP/Vista/7+, но на Windows XP лучше использовать официальный Yamaha S-YXG50 WDM-драйвер, который можно скачать с серверов Microsoft Windows Update: 4MB-версия (лучше качество, расходует больше ресурсов), 2MB-версия (хуже качество, расходует меньше ресурсов). Установка этого WDM-драйвера производится вручную при помощи мастера установки оборудования в панели управления. Не забудьте выбрать Yamaha S-YXG50 как синтезатор MIDI по умолчанию в системных настройках звука. Когда используется Yamaha S-YXG50 WDM, в VSTi версии этого синтезатора нет необходимости.

foobar2000 (лучший плеер для тех, кто влюблён в музыку)

foobar2000 не использует системный MIDI-синтезатор, но это не является недостатком. Это позволяет использовать Yamaha S-YXG50 VSTi без установки драйверов в систему, что более надёжно.

  1. Скачайте и установите плагин foo_midi с сайта foobar2000.
  2. Создайте в каталоге foobar2000 подкаталог с именем vsti и скопируйте в него файл syxg50.dll из yamaha_syxg50_vsti.7z.
  3. Откройте в плеере настройки, Advanced → Playback → MIDI Decoder → VSTi search patch, укажите в этом поле полный путь до созданного вами подкаталога vsti, после чего примените изменения и перезайдите в окно настроек.
  4. Перейдите в Playback → Input → MIDI synthesizer host. В выпадающем списке plug-in выберите Yamaha S-YXG50, примените изменения.
  5. Готово! Теперь MIDI в foobar2000 будут воспроизводиться при помощи Yamaha S-YXG50.

Ссылки

  • yamaha_syxg50_vsti.7z (3.0MB) — версия со встроенным 4MB wavetable, для обычного использования.
  • yamaha_syxg50_vsti_ext.7z (4.0MB) — версия с внешними 2MB и 4MB wavetable, для экспериментов.
  • bi2_polkovnik.mid (35KB) и bi2_polkovnik_syxg50.ogg (2.0MB) — MIDI и пример его корректного звучания для проверки корректности настроек вашего плеера и работоспособности самого VSTi.
  1. #901
    Wlad

    Alexys, тут я тебя немного поправлю, в YAMAHе есть такие настройки, аналогов которых в SF2 нет, а некоторые я вообще впервые вижу (касается синтезаторной части), т.е. если даже и получится как то собрать в ручную SF2 на YAMAHовских семплах, то как YAMAHA этот SF2 всё равно звучать не будет. Нужно как нибудь нам будет связаться, я обновил проект, и показать тебе как они работают, может сможешь распознать некоторые из них, а если нет, то хотя бы попробуем их правильно описать.

  2. #902
    VEG Автор

    Alexys,

    Тоже непрально говорите. Причем здесь непрерывность файла ?

    Речь о том, что если вы запишете, например, 5 разных звуков подряд, в один общий файл с сырыми данными всех звуков, а потом начнёте менять частоту дискретизации, то ресемплер не будет знать, где начало и конец каждого звука, и будет интерполировать (в простейшем случае) последний семпл предыдущего звука с первым семплом следующего звука в сырых данных. То есть при увеличении частоты дискретизации вдвое будет добавлен дополнительный лишний семпл с неправильной амплитудой между каждой парой звуков. Trancein говорил об этом же.

    Пример, для наглядности. Вычисления аналогичны тем, что были тут.

    Представим, что у нас есть пара звуков в формате 22050/8:
    0x55 0x53 и 0x20 0x24
    Мы их записали в один файл подряд:
    0x55 0x53 0x20 0x24
    Конвертируем в 22050/16:
    0x5555 0x5353 0x2020 0x2424
    Конвертируем в 44100/16:
    0x5555 0x5454 0x5353 0x3939 0x2020 0x2222 0x2424

    Получили один лишний семпл 0x3939, который никак не связан ни с первым звуком, ни с вторым. Это среднее между последним семплом первого звука и первым семплом второго звука.

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

  3. #903
    Alexys

    VEG, Но, ведь речь то идет не об одном, а о нескольких файлах.. «G~Lí†ch» то говорил о непрерывности файла, а не о непрерывности звука. Да, даже, если и звуки записаны в файле прерывисто, то это не означает, что данные там прерывисты, это означает, что амплитуда в некоторых местах имеет значения нуля.

    Речь о том, что если вы запишете, например, 5 разных звуков подряд,

    Вот поэтому звуки в банке записаны через некоторые промежутки по три-пять байт.

    Получили один лишний семпл 0x3939, который никак не связан ни с первым звуком, ни с вторым. Это среднее между последним семплом первого звука и первым семплом второго звука.

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

    С этим согласен.

  4. #904
    VEG Автор

    Alexys, ну в файле с сырыми звуковыми данными записаны же все звуки подряд. Если скармливать всё это целиком в ресемплер — для него это всё будет один огромный звук, и обрабатывать он будет его соответствующим образом. Даже если там есть отступы между звуками — это значит, что ресемплер будет вставлять на границе с последним семплом звука и отступом лишний семпл, который будет средним между значением семпла и значением, записанном в отступе (например, 0x0000).

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

  5. #905
    Wlad

    VEG, а разве вы не ошибаетесь. Файл из 22050 8-бит в 44100 16-бит увеличивается ровно в четыре раза, и ни каких лишних и недостающих байт не получается. Привожу точный пример метода конвертации байт на основе вашего примера (0x55 0x53 и 0x20 0x24), при помощи Wavosaur. Именно этим методом я и конвертировал весь банк одним файлом, который получился без единого щелчка, вначале я конвертировал разрядность, а после ч.д. с применением Polynome 2nd Degrees интерполяции.
    Берём : 55 53 20 24 , конвертируем из 22050 8-бит в 22050 16-бит (Process\Bit depth converter), и получаем AA D4 A6 D2 40 9F 48 A3 , размер увеличился ровно вдвое т.к. теперь разрядность описывается двумя байтами. Далее конвертируем из 22050 16-бит в 44100 16-бит (Process\resample), и получаем размер ещё в два раза больше : 20 BF 20 BF 40 9F 57 9A 48 A3 8E C6 00 00 97 0B , т.к. теперь стало отсчётов в два раза больше.

  6. #906
    VEG Автор

    Alexys,

    И опять пример. Имеем звук 22050/16, который должен проигрываться по кругу (луп-регион размером в весь звук):
    0x5555 0x5353
    Если просто прогнать его через ресемплер, получим:
    0x5555 0x5454 0x5353
    Если мы попробуем проиграть его по кругу, выйдет:
    0x5555 0x5454 0x5353 0x5555 0x5454 0x5353

    Если же перед ресемплингом исходный звук продублировать:
    0x5555 0x5353 0x5555 0x5353
    То в 44100/16 получим:
    0x5555 0x5454 0x5353 0x5454 0x5555 0x5454 0x5353
    Отсекаем хвост с дублем лупа:
    0x5555 0x5454 0x5353 0x5454
    Зацикливаем:
    0x5555 0x5454 0x5353 0x5454 0x5555 0x5454 0x5353 0x5454

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

    Wlad, вы уверены, что у вас 8 и 16 бит не в разных форматах (signed/unsigned)? Уж слишком разные числа у вас получились, не похоже на правду. Также, возможно, 16-бит у вас little endian, то есть при записи в человекопонятном виде порядок байт в парах нужно менять.

    Сейчас сам попробую.

  7. #907
    Wlad

    Вы правы, Unsigned в Signed.
    Я всего лишь привел точный пример того, как конвертировался сам банк, и что увеличение размера после каждой конвертации происходит ровно вдвое. Самое интересное ещё то, что после конвертации банка из 22050 8-бит в 22050 16-бит, файл увеличился всё же на два байта, а с 22050 16-бит в 44100 16-бит ещё на два, в итоге получается четыре лишних байта на весь банк (в Audition тоже самое).
    Размеры файлов до конвертации, и после :
    dsxgwave (Unsigned) 22050 8-бит - 2.417.446
    dsxgwave (Signed) 22050 16-бит - 4.834.890
    dsxgwave (Signed) 44100 16-бит - 9.669.780

    Теперь можно попробовать только с Unsigned такое сделать, сейчас также попробую это сделать.

  8. #908
    Wlad

    dsxgwave (Unsigned) 22050 8-бит - 2.417.446
    dsxgwave (Signed) 22050 16-бит - 4.834.890
    dsxgwave (Signed) 44100 16-бит - 9.669.780

    Прошу прощения, допустил ошибку, размер банка увеличивается ровно вдвое !

    dsxgwave (Unsigned) 22050 8-бит - 2.417.445
    dsxgwave (Signed) 22050 16-бит - 4.834.890
    dsxgwave (Signed) 44100 16-бит - 9.669.780

  9. #909
    VEG Автор

    После Wawosaur при конвертации в 16 бит я получил (при экспорте надо указывать 16 bit, unsigned, big endian):
    0x54A9 0x52A5 0x1F3F 0x2347
    Не могу сказать какой алгоритм Wawosaur использовал для этих целей, но выглядит результат не очень хорошо, звук явно стал немного тише. Впрочем, это уже похоже на полученное мной по описанной формуле:
    0x5555 0x5353 0x2020 0x2424
    Для примера взял SoX (к слову, в этой утилите доступен один из самых лучших ресемплеров, с исходным кодом), выполнил команду для преобразования в 16 бит:

    sox --encoding unsigned-integer --bits 8 --endian big --channels 1 --rate 22050 _test.raw --encoding unsigned-integer --bits 16 --endian big --channels 1 --rate 22050 _test_out16.raw

    Получилось:
    0x5500 0x5300 0x2000 0x2400
    Авторы SoX использовали описанную мной формулу, только делят число на 256, что некорректно (я обосновывал почему ранее) — нужно будет написать авторам баг-репорт. Я сам попадал в эту ловушку и допускал такую ошибку недавно, когда в патче для NFS3 делал конвертацию цветов для каждого кадра видео в формате RGB565 (16 бит) в формат RGB888 (24 бита). На картинке эта ошибка проявлялась в виде более тёмного изображения, чем было изначально. В случае со звуком эта ошибка даст более тихий звук, но разница будет меньше 0.5%, поэтому на слух её не слышно.

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

  10. #910
    Wlad

    Вот что у меня получилось в Unsigned, big endian.
    55 53 20 24
    54 A9 52 A5 1F 3F 23 47
    3F 1E 3F 1E 1F 3F 1A 55 23 47 46 8D 80 00 8B 97

  11. #911
    VEG Автор

    Ну а теперь для сравнения проделайте то же самое раздельно с звуками 0x55 0x53 и 0x20 0x24, когда это два отдельных файла. И потом сравните, что выдаст вам ресемплер с тем, что у вас получилось, когда вы два этих звука преобразовывали одним махом, будто это один звук. По идее, результат должен быть разным.

  12. #912
    Wlad

    Никакой разницы.
    55 53 - 20 24
    54 A9 52 A5 - 1F 3F 23 47

  13. #913
    VEG Автор

    Wlad, никакой разницы и не должно быть для изменения разрядности. Проблема должна возникать при изменении частоты дискретизации (для большинства алгоритмов, по крайней мере). То есть, вам нужно ещё в 2 раза поднять частоту дискретизации каждого из этих двух файлов. Вот это и нужно будет сравнивать с тем, что у вас получилось в первый раз.

  14. #914
    Wlad

    Верно, получился совсем другой результат.
    63 67 63 67 80 00 85 AB - 46 8D 46 8D 80 00 8B 97

  15. #915
    best_italo

    всем привет
    вег,влад к какому выводу-то пришли?
    при переходе от 22050Гц к 44100 появляются лишние отсчеты которые приводят к щелчкам в loop-ах или что?

  16. #916
    VEG Автор

    best_italo, к тому что resample(A+B+C) не то же самое что resample(A)+resample(B)+resample(C) для большинства алгоритмов изменения частоты дискретизации. Эта же проблема будет проявляться для любой обработки звука, где работа ведётся не с каждым семплом в отдельности (как при преобразовании 8 бит в 16 бит), а где работа ведётся целиком с волной (эффекты, шумодавы и т.д.). Можно предположить, что это может быть причиной щелчков, но наверняка утверждать это не берусь. Разница может быть и неслышимой.

  17. #917
    best_italo

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

  18. #918
    VEG Автор

    best_italo,

    Такое впечатление что вы не заметили результаты теста, что Wlad привёл тремя сообщениями выше. Лишний семпл был бы в том алгоритме с простейшей интерполяцией, который я описал для наглядной демонстрации проблемы (потому что хоть о проблеме и упоминали тут несколько раз, всё равно не всем было понятно, о чём речь). Но этот алгоритм в реальности не используется. Используются более сложные алгоритмы изменения частоты дискретизации, которые работают не с парами семплов, а целиком с волной (то есть затрагивают сразу много семплов), и об этом я тоже тут писал. Таким образом, начало следующего звука будет влиять на конец предыдущего звука, поскольку алгоритм изменения частоты дискретизации будет пытаться передать звучание этого перехода между звуками. Что Влад и продемонстрировал, проведя эксперимент.

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

  19. #919
    best_italo

    Такое впечатление что вы не читали результаты теста, что написал Wlad двумя сообщениями выше.

    я все прочитал вег и неоднократно упоминал про метки на которые вы почему-то не обращаете внимания
    ну хорошо давайте сделаем так:
    сделайте в Adobe Audition или в WaveLab-е (другие нежелательны в виду их меньшей профессиональности) образец того о чем вы пишите - это и будет ярким и наглядным подтверждением вашей точки зрения
    если вы плохо знаете эти программы то может и влад это сделать
    он ведь достаточно хорошо понял о чем речь и сможет все это дело смоделировать
    при желании потом это можно будет открыть и посмотреть в каком-нибудь HEX-редакторе

    p.s. никого не хотел обидеть своими постами просто стало интересно и захотелось докопаться до истины
    я ведь могу и ошибаться что в общем свойственно человеку

  20. #920
    VEG Автор

    best_italo,

    я все прочитал вег и неоднократно упоминал про метки на которые вы почему-то не обращаете внимания

    В обсуждаемом случае ресемплер ничего не знает об этих метках. Ресемплер обрабатывает весь поток звуковых данных так, будто он будет проигрываться именно в таком виде, где все звуки воспроизводятся один за одним. И на стыках между звуками ресемплер будет пытаться передать именно то звучание, какое было бы, если бы весь этот поток воспроизводился как единое целое. Соответственно, первые и последние семплы каждого звука в этом потоке будут немного отличаться от тех семплов, которые получились бы, если бы ресемплер применялся к каждому звуку в отдельности. Ощутима ли эта разница на слух — это отдельный вопрос, которого я не касаюсь.

    Я уже достаточно подробно расписал. Не вижу смысла повторяться. Если вы действительно хотите разобраться — внимательно перечитайте написанное в предыдущих сообщениях.

    Драматичность последствий от этой проблемы для конкретного алгоритма передискретизации можно оценить использованным выше способом. Нужно взять несколько длинных звуков, и сделать два варианта: resample(A+B) и resample(A)+resample(B). Результаты сохранить в raw/16 bit/unsigned/big endian. Это позволит с удобством сравнивать звуковые данные этих файлов любым инструментом для сравнения и поиска различий в двоичных файлах.

  21. #921
    best_italo

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

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

  22. #922
    Wlad

    Доброго всем дня.

    вег,влад к какому выводу-то пришли?

    best_italo, я ещё раз очень внимательно всё перепроверю и опишу все результаты, что бы быть уверенным на 100%, и к тому же Wavosaur как оказалось не корректно конвертирует разрядность влияя тем самым на звук, и на вышеприведённые результаты, а вот в Adobe audition такого с разрядностью замечено не было, и после того как я конвертировал вчера разрядность банка в Audition, звук в синтезаторе стал немного другим, как мне показалось мягче что ли, и шум, хоть едва заметен, но стал менее выразительным. Вот этот синтезатор для оценки : https://yadi.sk/d/zRBxl9Km3LFuV7

  23. #923
    VEG Автор

    best_italo,

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

    Похоже, что вы даже не пытаетесь понять о чём речь. Речь не о том, что данные смещаются или что-то ещё. Речь о том, что сами значения семплов могут искажаться. Семплов, которые входят в области, отмеченные этими метками.

    Trancein,

    724 выполняла требования к Microsoft DLS, по которому на вход для проигрывания семпла подается структура, очень похожая на структуру WAV файла с луп регионами, питчами и служебной информацией о формате. Так что чип должен изначально уметь проигрывать WAV в разных форматах с разной битностью и частотой дискретизации. Может быть, там были ограничения к перечню форматов, но уже не помню. Но 16 бит он нормально подхватил.

    В софт-синтезаторе проигрывание семпла может быть совсем другим, с другими алгоритмами ресемплинга.

    Движок S-YXG50 по умолчанию (без правок кода) поддерживает два формата семплов: 8-bit unsigned и 16-bit unsigned.

  24. #924
    «G~Lí†ch»

    «G~Lí†ch»:

    Можно ли как-нибудь эти "операционные коды" привинтить к ямахе?

    Alexys:

    Какой тогда смысл "прикручивать" SF2-пакеты к Ямахе, если все это уже есть ?

    Alexys, где вы из моих слов видели, что я упомянул импортирование самих SF2 в ямаху? Посмотрите на окно редактора sfZed, там те же функции, что использует ямаха: eg (adsr), cutoff, reso, pitch, level, pan, effect1, effect2... Если каким-нибудь образом импортировать в sfZed какие-нибудь патчи из TBLицы, то из ямахи можно сделать те же патчи, только в sfz формате, которые очень любят некоторые композиторы, музыканты и разработчики типа Cakewalk Twelve Tone Systems и (Dimension, Rapture, Session Drummer).
    Но стоит упомянуть, что в sfZed точность таких настроек гораздо выше, чем в ямахе (нет ограничений в «битах»)... Поэтому при "упаковке" SFZ-шек назад в TBL-файл данные могут исказиться. А насчёт SF2-банками тоже неплохая идея, но, я не уверен, что и онѝ не исказятся. В ямахе же как-никак ограниченное количество бит на определённую настройку. Это просто как "упрощённая" альтернатива сэмплера TX16Wx.
    А вообще, какого бита чёрта вы из 8-бит конвертируете? И вообще, какой смысл работать с некачественным «сырьём» (шлаком/браком)? Мало того, что выбрали банк 22050, да ещё и с ограниченным уровнем [-127;0;+127].
    А "ваш алгоритм" Polynome 2° при конвертации ПИЛЫ делает практически то же, что и Sound Forge. Конечно, при преобразовании с 8 бит в 16, мы получим "погнутые зубы пилы" такой же результат, а вот при конвертации из 22050 в 44100 мы получим "крюк" после резкого спада в определённую фазу.
    best_italo, Аудишн гадёныш в файл вписывает слишком много лишней мета-информации, из-за которой САМ ЖЕ АУДИШН этот файл иногда ОТКАЗЫВАЕТСЯ ОТКРЫВАТЬ :)! А как его отучить от этого, пока не понятно.
    Но то, что происходит с пилой в WaveLab-е, просто ужас. Сгенерировл пилу на уровне 80% в 22050, 8 бит, после конвертации в 44100 она "на углах" загуляла, и почти ДО ПИКА (98%) выстреливает в двух фазах.
    Из этого следует, что единого алгоритма апсемплирования для всех сэмплов не существует, и к каждому сэмплу нужно применять отдельный алгоритм.

  25. #925
    best_italo

    вег, вы немного изменили суть полемики
    вот цитата из вашего поста #902

    Речь о том, что если вы запишете, например, 5 разных звуков подряд, в один общий файл с сырыми данными всех звуков, а потом начнёте менять частоту дискретизации, то ресемплер не будет знать, где начало и конец каждого звука, и будет интерполировать (в простейшем случае) последний семпл предыдущего звука с первым семплом следующего звука в сырых данных. То есть при увеличении частоты дискретизации вдвое будет добавлен дополнительный лишний семпл с неправильной амплитудой между каждой парой звуков.

    а это цитата из вашего поста #923

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

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

    Движок S-YXG50 по умолчанию (без правок кода) поддерживает два формата семплов: 8-bit unsigned и 16-bit unsigned.

    а какое отношение к нашей дискусии имеет 8 битный или 16 битный беззнаковый формат?
    тоже ведь для убедительности нужно моделировать ситуацию и "ткнуть носом" а так это все слова

  26. #926
    Alexys

    VEG,
    ответ на пост 904.
    Абсолютно с Вами согласен, что ресемплер будет обрабатывать весь звук, как весь, а не раздельно. Я понимаю, что «G~Lí†ch» имел в виду именно это, но говорил то он о разрывности данных, чего не может существовать в одном файле. Т.е. если есть разрывы, то это уже разные файлы.
    Насчет ресемплирования отдельных файлов, то тут тоже особо придумывать нечего, поскольку, например, та же Awave Studio имеет возможность batch-обработки. Можно класть сколько угодно файлов. Проблема здесь только в подготовке этих звуков. Одно дело, когда сам, изначально набираешь весь банк, идя медленно и скрупулезно и совсем другое, когда имеется уже готовый банк, который достаточно БЫ обработать в пять секунд. Но вот тут загвоздка, потому что не очень хочется его резать на полторы тысячи фрагментов.
    Не думаю, что требуется учить ресемплер понимать, где какие важные пользователю точки стоят в звуке. Луп-регион - это такое же абстрактное для "цифры" понятие, как и угол атаки, как фронт спада. Это уже касается только полезного сигнала, т.е. самого звука, его временнЫх характеристик, где не столь важно какой ЧД и битностью этот сигнал определен.

    Ответ на пост 906.
    Наоборот, при появлении последнего отсчета 0х5454 в последовательности 0х5555 0х5454 0х5353 0х5454 появится щелчок, поскольку он мало того, что дополнительный в цепочке, так еще и имеет некоторое значение. Если звук достаточно длинный и имеет свою фазу перехода в регионе, то такой отсчет создаст дополнительные искажения в звуке, что на слух и будут восприниматься как щелчки. А вот для простейших коротких сигналов это не важно, так как этот отсчет создаст только дополнительные гармоники, что является более положительным свойством (чем больше искажений, тем богаче звук тембрально).

    Ответ на пост 909
    Wavosaur Вам выдал верный результат.
    Я еще тогда обратил внимание, когда Вы приводили пример с ресемплингом, где делили 255 на 255. Все-таки это не так - делить надо на 256. Ведь чисел то всего 256, а не 255. Да, верно, последнее значение - 255, но всего чисел 256. А значит все математические операции производятся со всем числовым рядом, а не с последним значением этого ряда.
    Например в зрительном зале ряды стульев. (приводж этот пример уже в десятый раз, наверное, каждому по отдельности...) Стульев в ряду всего 20. Нумерация начинается от нуля. Каким по номеру будет последний стул ? Правильно - 19-й. Но стульев то 20.
    Также с иными числовыми рядами. 0 1 2 3 4 5 6 7 8 9 - сколько чисел ? Правильно - 10.
    Поделим все эти ряды пополам.
    256 - 128, 20 - 10, 10 - 5.
    А под каким номерами будут эти числа ?
    Правильно в 256-и будет 127-й, в 20 стульях будет 9-й, а в десятке будет 4-й.
    Т.е. вылазит пресловутое n - 1 для ряда с нулем.
    А Вы говорили, что делить надо 255 на 255. А что тогда будет половиной ? 127,5 ? Нет, конечно. Числа должны быть целые.
    Поэтому заключение, что 255/256 - верно. Это будет действительно 0,99609375 (конечное, кстати, число). Т.е. значение действительно немного меньше единицы.
    Скорее всего программы об этом знают и добавляют недостающее число, если есть необходимость. Хотя, врядли регистры имеют верхний пустующий разряд.
    Возможно многие скажут - "а как же клиппинг звука, возникший в результате обработки ? Ведь это увеличение амплитуды ?" Да, верно, это увеличение амплитуды. Но никто ведь не говорит, почему-то, какой разрядности сами обработчики, а ведь чаще всего они 32-битные, где возможно создать запас по амплитуде. Кроме того, амплитуда сигнала здесь - понятие относительное.
    Влад сказал:

    Самое интересное ещё то, что после конвертации банка из 22050 8-бит в 22050 16-бит, файл увеличился всё же на два байта, а с 22050 16-бит в 44100 16-бит ещё на два, в итоге получается четыре лишних байта на весь банк (в Audition тоже самое).

    Что и подтверждает теорию о числовом ряде n - 1.

    И VEG, пожалуйста, поправьте шрифт в поле набора текста, а то из-за смещения курсора порой делаешь глупые ошибки. Трудно определить количество пробелов при наборе текста - то ли их два, то ли он вообще отсутствует.

  27. #927
    VEG Автор

    best_italo, ну так дочитывайте цитируемые сообщения до конца. Даже в том что вы процитировали есть отсылка, что я говорю именно о приведённом мной простейшем методе интерполяции (там написано «в простейшем случае»). А чуть ниже в этом же сообщении я написал:

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

    И дальше, в последующих сообщениях, я повторял это несколько раз, причём делал упор уже именно на искажения значений семплов. Потому что реально используемые алгоритмы передискретизации далеки от наивной интерполяции, которую я использовал для наглядной демонстрации проблемы, о которой говорили другие люди на предыдущей странице. Они могут не ограничиваться парами соседних семплов, как было в моём примере, они могут могут работать с волной целиком, учитывая при работе сразу большое количество семплов. О чём я тоже писал.

    и почему-то вег вы упорно не хотите смоделировать то о чем пишете

    Потому что я представляю какого результата стоит ожидать. Я вклинился в разговор лишь с целью объяснить на доступных примерах, о какой проблеме говорили предыдущие ораторы. У меня нет цели убедить вас, что проблема имеет место быть. Если мои примеры не делают обсуждаемую проблему очевидной для вас — можете сами себе провести ряд экспериментов. Ну или и дальше игнорировать её. Как я тоже уже писал, эти искажения могут быть и неслышимыми вовсе.

    а какое отношение к нашей дискусии имеет 8 битный или 16 битный беззнаковый формат?

    Это не было адресовано вам. Цитата взята с предыдущей страницы, которая к текущей дискуссии отношения уже не имеет. Речь лишь о том, что для оригинального движка S-YXG50 можно сделать банк с 16-битными семплами, и он будет работать. Wlad на предыдущей странице делал демонстрационные банки в несовместимом с оригинальным движком формате. Можно было бы подумать, что оригинальный движок не имеет каких-то возможностей для эмуляции YMF7xx. Но на самом деле это не так, и обсуждаемые на предыдущей странице банки можно было сделать и в совместимом с оригинальным движком формате. Не то чтобы эта информация имела какое-то решающее значение, просто маленькое дополнение.

  28. #928
    best_italo

    Alexys может хватит уже строить из себя гуру?
    давно читаю этот блог и честно говоря уже остонадоела ахинея которая почти в каждом посте исходит от вас глитча и ямахаюзверя
    то что у нас здесь возникла дискусия по достаточно непростой теме которая лежит в области DSP, аудиопрограммирование и т.д. и т.п. еще ни о чем не говорит тем более если учесть что вег достаточно далек от музыки (если я ничего не напутал) и тем еще более что я допускаю что могу быть не во всем прав, поэтому и хотел поставить все точки над i
    но то что вы в своем посте #926 позволяете себе вести полемику так как будто вы академик а вег первокласник, это уже извините ни в какие "ворота"
    для начала советую позаниматься программированием лет 10-15 желательно еще и с заходом в реверсинг
    насколько я правильно понял благодаря реверсингу вега мы все имееи возможность использовать Yamaha S-YXG50 на 7-ке и выше

    p.s. еще раз хочу подчеркнуть что никого не хотел обидеть и советую вегу не тратить время на ответы тому бреду который очень часто исходит от Alexys и ему подобным

  29. #929
    VEG Автор

    Alexys,

    Насчет ресемплирования отдельных файлов, то тут тоже особо придумывать нечего, поскольку, например, та же Awave Studio имеет возможность batch-обработки. Можно класть сколько угодно файлов. Проблема здесь только в подготовке этих звуков. Одно дело, когда сам, изначально набираешь весь банк, идя медленно и скрупулезно и совсем другое, когда имеется уже готовый банк, который достаточно БЫ обработать в пять секунд. Но вот тут загвоздка, потому что не очень хочется его резать на полторы тысячи фрагментов.

    Я просто постарался пояснить суть указанной кем-то другим проблемы. Принимать это во внимание или нет — решать не мне.

    Я еще тогда обратил внимание, когда Вы приводили пример с ресемплингом, где делили 255 на 255. Все-таки это не так - делить надо на 256. Ведь чисел то всего 256, а не 255.

    Считать нужно не количество точек, а количество отрезков, на которые эти точки делят прямую от минимальной амплитуды до максимальной. Пример: 0_1_2_3_4_5. Точек 6, но отрезков — 5. Длина этой прямой от минимальной до максимальной амплитуды всегда одна и та же. В зависимости от разрядности, мы имеем разное количество точек на этой прямой. Чем больше разрядность — тем меньшие отрезки между точками. Значение семпла указывает на одну из точек на этой прямой. При повышении разрядности новое значение должно указывать в ту же самую точку (или максимально близкую) на этой прямой. Если вы будете делить на количество возможных значений (точек на этой прямой), то точки начнут сдвигаться влево и звук станет немного тише, что я уже вам демонстрировал.

    Это я уже объяснял. Повторяюсь же.

    Ладно, ещё один пример, с вещественными числами. Представьте, что минимальная амплитуда — 0.0, а максимальная — 1.0. То есть это отрезок от нуля до единицы. Чтобы преобразовать unsigned int любой разрядности к этому виду — нужно просто разделить текущее значение семпла на максимально возможное значение семпла для текущей разрядности. То есть для 8 бит делим на 255, а для 16 бит делим на 65535. Это число — от нуля до единицы — опишет, куда именно попала наша точка на прямой. При конвертации из 8 бит в 16 бит точка на прямой должна попадать в одно и то же место, то есть после преобразования 8-битного и 16-битного варианта в вариант с вещественным числом у нас должны получиться одинаковые или максимально близкие друг к другу числа. Если же окажется, что преобразованный в 16 бит семпл указывает далеко от исходного места, и если можно выбрать точку, которая ближе к исходной — значит преобразование было выполнено неверно.

    Wavosaur Вам выдал верный результат.

    Присмотритесь внимательно. Wavosaur явно использует другой алгоритм, так как его значения значительно меньше тех, которые были бы, если бы там было деление на 256 и умножение на 65536. Похоже, вы спутали Wavosaur с SoX. Именно SoX выдал такой результат, о котором вы говорите.

    А что тогда будет половиной ? 127,5 ? Нет, конечно. Числа должны быть целые.

    Я наверное сейчас открою вам большую и страшную тайну про цифровой звук. В знаковом 8-битном звуке минимальное значение -128, а максимальное — 127. Середина — на нуле. В знаковом 16-битном звуке тоже «середина» смещена: допустимы значения от -32768 до 32767. Чтобы сделать из таких семплов беззнаковые — нужно просто добавить 128 и 32768 соответственно. Но «середина» всё равно будет немного смещена. Для 8-битных семплов она будет на отметке 128, а для 16-битных семплов она будет на отметке 32768.

    Поэтому заключение, что 255/256 - верно. Это будет действительно 0,99609375 (конечное, кстати, число). Т.е. значение действительно немного меньше единицы.

    Ага, и для максимального значения амплитуды будет потеряно аж 255 пунктов (65280 вместо 65535). Но поднять весь сигнал на эти недостающие 255 мы не можем, потому что для минимальной 8-битной амплитуды 0x00 по вашей формуле выйдет 0x0000, и если вы начнёте что-то дополнительно двигать, то вы потеряете минимальную амплитуду.

    Скорее всего программы об этом знают и добавляют недостающее число, если есть необходимость.

    Ну да, конечно, все программы при проигрывании 16-битного звука в первую очередь ориентируются на какой-то один алгоритм повышения разрядности с 8 до 16 бит, и корректируют все значения семплов на лету. Вы это серьёзно? Ну то есть вы серьёзно полагаете, что при проигрывании материала, изначально предоставленного в 44100/16, всегда применяется некоторая коррекция, которую вы придумали из-за некоторого несоответствия, которое возникло при конвертации из 8 бит в 16 бит по одному из алгоритмов?

    Наоборот, при появлении последнего отсчета 0х5454 в последовательности 0х5555 0х5454 0х5353 0х5454 появится щелчок, поскольку он мало того, что дополнительный в цепочке, так еще и имеет некоторое значение.

    Представим, что у нас есть звук A, в котором есть луп-регион. Как этот звук должен проигрываться? Так, будто за последним семплом луп-региона находится первый семпл этого же луп-региона. Упрощаем. Считаем, что этот луп-регион должен повториться ровно 100 раз. Таким образом, звук A должен звучать так же, как если бы мы взяли этот звук A, продублировали бы в нём луп-регион 100 раз, а сами данные о луп-регионе удалили. Назовём такой звук, где луп регион просто продублирован 100 раз, A*. Согласны ли, что звуки A (при проигрывании с учётом луп-региона) и A* должны звучать идентично? Если да (а тут нет оснований считать иначе), идём дальше. Прогоняем звук A через ресемплер. Получаем resample(A). Так же поступаем с A* и получаем resample(A*). Согласны ли вы, что resample(A) должно звуачать максимально близко к идентичному с resample(A*)? Логично, что должно. Но в случае, когда ресемплер работает с обычным A, когда он занимается изменением частоты дискретизации конца луп-региона, не знает, что за этими семплами будут повторно проигрываться семплы из начала луп-региона. Поэтому он может установить не самые лучшие значения для последних семплов в луп-регионе, и результат окажется хуже resample(A*), где у ресемплера не было такой проблемы.

    В моём примере с наглядной интерполяцией между соседними семплами, если вы сразу исходный звук продублируете 100 раз, а потом измените частоту дискретизации — то там между дублями всюду будут эти 0х5454. То есть в версии с луп-регионом 0х5454 должно в него попасть, и это не будет лишним семплом.

    Это не будет лишним семплом также исходя из той мысли, что частота дискретизации у нас в 2 раза выше, и без этого «лишнего» семпла воспроизведение луп-региона ускорится аж на 25% (ведь вместо 4 семплов, которые должны были бы быть, у нас получится 3).

    best_italo,

    вег достаточно далек от музыки

    Я далёк от написания музыки и ничего в этом не смыслю. Но адекватное представление о самом цифровом звуке имеется.

  30. #930
    YAMAHA User

    Wlad
    Cпасибо! Вот теперь и только теперь мы имеем чистые 16 бит ) шума ноль ) осталось сделать одним файлом и ляпота будет )

    Влад , я нашёл нарушение луп региона.
    Вот здесь https://yadi.sk/d/oNDzNoPG3LGSsx если проиграть миссию и прослушать композицию геймовера , то в конце когда начинается басовый такой звук , слышно что с лупом что-то не так.

    Alexys, вот ты и дошёл до того о чём мы на old-games ) , только чуть позже )